Sự khác biệt giữa thực tiễn tốt nhất và ý thức chung?

Có rất nhiều cuộc trò chuyện liên quan đến thực tiễn tốt nhất ¹ trong phát triển phần mềm. Tôi đã thấy ít nhất ba điểm chính nhận được nhiều cuộc thảo luận cả về SE và các nơi khác:

• Những gì đủ điều kiện là một thực hành tốt nhất, và tại sao?
• Có phải thực tiễn tốt nhất thậm chí đáng để thảo luận ở nơi đầu tiên, bởi vì thật hợp lý để khẳng định rằng không có thực hành nào là thực tiễn "tốt nhất"?
• Khi nào bạn nên từ bỏ một thực tiễn tốt nhất - hoặc có lẽ là hầu hết các thực tiễn tốt nhất - bởi vì nó dường như không thể áp dụng hoặc do các ràng buộc bên ngoài (thời gian, tiền bạc, v.v.) làm cho sự đánh đổi không thực tế?

Một cái gì đó dường như xuất hiện ít thường xuyên hơn, nhưng hơn bao giờ hết, là một khái niệm về lẽ thường trong phát triển phần mềm. Kinh nghiệm gần đây đã đưa khái niệm này trở lại trước tâm trí tôi một lần nữa.

Ấn tượng ban đầu của tôi là nó là một cuộc thảo luận khác với thực tiễn tốt nhất, nhưng có lẽ với một số sự thụ phấn chéo.

Khi tôi nghĩ về lẽ thường, tôi nghĩ về một bộ quy tắc mà bạn đã chọn hoặc được dạy để cung cấp cho bạn một cơ sở để suy luận và đưa ra quyết định. Theo ý nghĩa thông thường là một cách tốt để tránh bạn bắn toàn bộ chân của bạn. Nhưng vượt quá mức cơ bản khá thấp, lẽ thường sẽ nhường chỗ cho nhu cầu đưa ra quyết định có giáo dục, và quyết định có giáo dục thậm chí có thể ghi đè lên ý thức chung khi bằng chứng có vẻ đủ thuyết phục. Tôi có thể chơi hơi lỏng lẻo với định nghĩa ở đây, nhưng tôi nghĩ nó đủ gần để dẫn đầu ví dụ của tôi.

Khi tôi nghĩ về ý thức chung trong phát triển phần mềm, tôi nghĩ đến tất cả các quy tắc vệ sinh cơ bản để ngăn chặn một cơ sở mã hóa nhanh chóng phân rã thành một mớ hỗn độn khó hiểu. Ví dụ, những thứ như: không sử dụng một cấu trúc toàn cầu duy nhất để duy trì và giao tiếp trạng thái trong một chương trình không tầm thường; không sử dụng tên biến / phương thức / lớp chỉ là vô nghĩa ngẫu nhiên; những thứ có lẽ giống với những gì chúng ta đến để gọi chống mẫu khá chặt chẽ. Khi áp dụng thực tiễn tốt nhất tương tự thực tế vào mô hình học tập, áp dụng ý thức chung có thể được coi là tương tự thực tế của việc học chống mẫu.

Với suy nghĩ này, tôi muốn đặt ra một vài câu hỏi rằng xem câu trả lời của người khác có thể giúp tôi giải thích vấn đề này.

Những người khác có tin rằng có một khái niệm về ý thức chung trong phát triển phần mềm không? Sẽ được quan tâm biết lý do một trong hai cách.

Nếu vậy, nó có phải là một khái niệm đáng để thảo luận? Đó có phải là một cái gì đó chúng ta nên thúc đẩy nhiều như chúng ta đôi khi làm với các thực tiễn tốt nhất? Đó có phải là một cái gì đó đáng để đẩy cho khó khăn hơn?

Nếu sự tương tự với các mẫu chống có vẻ hợp lý, thì quy tắc chung là các mẫu chống chỉ được sử dụng nếu không có cách nào khác, và thậm chí sau đó chỉ trong những trường hợp rất hạn chế. Làm thế nào linh hoạt một người nên được cho phép một codebase đi chệch khỏi ý nghĩa thông thường? Có vẻ như không hợp lý khi câu trả lời là "hoàn toàn không", bởi vì đôi khi sự cần thiết đòi hỏi sự sai lệch. Nhưng, nó có vẻ như là một loại lập luận khác với khi sử dụng một "thực tiễn tốt nhất". Có lẽ không phải vậy; nếu bạn không nghĩ vậy, tôi muốn tìm hiểu lý do tại sao.

Đây là kết thúc mở nhiều hơn và có thể xứng đáng với một câu hỏi tiếp theo của riêng mình, những loại khuyến nghị nào bạn sẽ chỉ ra rằng dường như đó là vấn đề của lẽ thường?

Những suy nghĩ khác cũng được chào đón.

¹ Có lẽ tôi sẽ gọi chúng là "các mẫu miền thường xuyên lặp lại", nhưng tên "thực tiễn tốt nhất" đủ phổ biến để mọi người biết chúng là gì, ngay cả khi chúng không đồng ý rằng chúng là. Nếu phần "tốt nhất" làm phiền bạn, chỉ cần tưởng tượng tôi đã thay thế "thực hành tốt nhất" bằng một âm thanh ít thẩm quyền hơn.

Thực tiễn tốt nhất là các thực tiễn đã được tìm thấy để hoạt động tốt trong một lĩnh vực tương đối rộng. Vấn đề với họ là A) biểu thức đôi khi bị lạm dụng để tiếp thị và B) như các quy tắc cố định, chúng không đủ linh hoạt; không nên tuân theo các quy tắc cố định mà không cần suy nghĩ về việc liệu chúng có áp dụng cho tình huống hiện tại hay không.

Thực hành tốt nhất là tuyệt vời khi chúng đi kèm với giải thích tại sao chúng là "tốt nhất" và trong trường hợp nào chúng nên được sử dụng. Sau đó, bạn có thể lý do khi không sử dụng chúng.

Vấn đề với "lẽ thường" là nó quá linh hoạt - nó có thể được sử dụng để biện minh cho hầu hết mọi thứ và bạn thực sự không thể có một cuộc thảo luận hợp lý khi mọi người không đồng ý và cả hai đều cho rằng vị trí của họ là "lẽ thường". Thật tốt khi có nhưng nghèo làm kim chỉ nam cho một nhóm làm theo.

Tôi nghĩ rằng bạn có nó ngược.

Khi dạy lập trình viên những điều cơ bản về bảo mật, tôi luôn dạy họ sử dụng best practices, và khi giao tiếp với các chuyên gia bảo mật (hoặc nhiều lập trình viên "có kinh nghiệm bảo mật") tôi sẽ không bao giờ thảo luận best practices, thực tế tôi sẽ thường xuyên vi phạm.

Một định nghĩa tốt hơn sẽ là:

"Thực tiễn tốt nhất" là lẽ thường từ các chuyên gia, nên được áp dụng bởi những người không phải là chuyên gia.

Đó là, bạn không được yêu cầu "lẽ thường" cho đến khi bạn có đủ chuyên môn trong lĩnh vực nhất định để hiểu được sự đánh đổi tinh tế; và khi bạn làm thế, bạn sẽ không còn mù quáng tuân theo "thực hành tốt nhất" của trình cắt cookie.

"Thực tiễn tốt nhất" là một giữ chỗ tạm thời cho đến khi bạn có đủ kinh nghiệm để sử dụng "ý thức chung" của riêng bạn.

Thực hành tốt nhất -> "đầu tiên, bạn học các quy tắc". Kinh nghiệm -> "sau đó, bạn tìm hiểu khi nào và làm thế nào để phá vỡ chúng".

Sẵn sàng thử nghiệm các lựa chọn thay thế (trong mã không quan trọng, tất nhiên - tốt nhất là các dự án cá nhân và ném xa) có thể giúp xây dựng trải nghiệm bạn cần.

Tất nhiên, thông thường không giống như kinh nghiệm và bạn không cần luôn có nhiều kinh nghiệm để thấy lỗ hổng trong việc áp dụng một kỹ thuật tốt ở sai vị trí - nhưng rất dễ dàng để xây dựng các hợp lý sai cho cả việc áp dụng quá mức và áp dụng một kỹ thuật và vì "ý thức chung" ở đây rõ ràng không phải là kiến ​​thức bẩm sinh về lập trình, nên ý nghĩa đó rõ ràng là "phổ biến" chỉ trong các nhóm cụ thể.

Rất dễ "đứng về phía". Trên thực tế, không thể tránh được - đôi khi một bên thực sự đúng, còn bên kia thực sự sai, và sẽ không hợp lý khi tranh luận về sự cân bằng. Vấn đề ở đây là địa ngục thực sự không quá nặng nề đối với một thực tiễn tốt nhất cho sự phù hợp, nhưng khi hai ý kiến ​​thực tiễn tốt nhất mâu thuẫn xảy ra.

Đối phó với điều này có lẽ là nhiều về kỹ năng con người hơn là về kỹ năng kỹ thuật. Tôi rất tệ về điều đó :-(

Mặc dù vậy, điều quan trọng là phải học hỏi từ kinh nghiệm của những người khác cũng như của chính bạn - tức là tìm hiểu các thực tiễn tốt nhất là gì, tại sao chúng được sử dụng và những lợi thế (và nhược điểm) là gì.

Dường như với tôi rằng câu hỏi này là một mánh khóe ngữ nghĩa. Nếu chúng ta sử dụng các định nghĩa này thì không có câu hỏi:

Thực tiễn tốt nhất: một cách đã được chứng minh trong cách giải quyết vấn đề trong một miền nhất định (ví dụ: thực tiễn tốt nhất theo thời gian thực hoàn toàn xa lạ với thực tiễn tốt nhất về cơ sở dữ liệu)

Ý thức chung: kinh nghiệm chuyên môn phục vụ để cảnh báo các lập trình viên về những cạm bẫy cần tránh

Cuối cùng, Thực tiễn tốt nhất là một mẫu thiết kế meta để giải quyết một vấn đề cụ thể và được chọn dựa trên kinh nghiệm thực tế trong khi Common Sense là hướng dẫn giải quyết vấn đề dựa trên quan sát chung qua nhiều bộ vấn đề.

Common sense = You.CommonSense

Best practices = Sum(Experts.Experience + Experts.CommonSense)

Thời gian thú vị. Tuần trước bài viết này đã được xuất bản thảo luận về lý do tại sao ý thức chung không nhất thiết là lý tưởng trong tất cả các tình huống.

Tâm lý chung là thích nghi một cách tinh tế để xử lý loại phức tạp nảy sinh trong các tình huống hàng ngày ... Và bởi vì nó hoạt động rất tốt trong những tình huống này, chúng tôi có xu hướng tin tưởng nó trong mọi tình huống

(lời tôi in đậm)

Về cơ bản - con người không giỏi sử dụng ý thức chung trong các lĩnh vực như nơi chúng ta chưa phát triển một hệ thống ăn sâu, vì vậy chúng ta LUÔN LUÔN sử dụng một bộ tiêu chuẩn được lập thành tài liệu và không dựa vào ý thức chung của chúng ta!

Ý thức thông thường không tương ứng với việc học các mô hình chống, cũng không khác biệt, hoặc trái ngược với thực tiễn tốt nhất.

Vấn đề đầu tiên với lẽ thường là tên của nó - nó dẫn đến kết luận rằng nó vừa phổ biến vừa hợp lý. Như thường được sử dụng, nó có thể tấn công vào cả hai tội danh. Sử dụng ví dụ của bạn:

chống mẫu chỉ được sử dụng nếu không có cách nào khác, và thậm chí sau đó chỉ trong những trường hợp rất hạn chế

Theo hiểu biết của tôi thì đây không phải là cách mà các mô hình chống phát sinh. Đó là từ sự bồi đắp các yếu tố văn hóa và xã hội; coi thường các thực tiễn và tiêu chuẩn tốt nhất trong một thời gian đáng kể; bỏ qua các chi phí trong tương lai để đạt được lợi ích ngắn hạn - ví dụ để đáp ứng thời hạn bằng cách sử dụng một giải pháp cắt ngắn là một cơn ác mộng bảo trì; v.v ... Không có cơ quan nào bắt đầu áp dụng một mô hình chống có chủ ý - chúng chỉ phát triển.

Một cách công bằng, thông thường thường được sử dụng quá nhiều để có nghĩa là "điều đó được thực hiện phổ biến", và biện minh cho việc thiếu suy nghĩ, hiểu biết sâu sắc và làm việc chăm chỉ để giải quyết những gì liên quan đến việc cung cấp giải pháp. Nó cũng được sử dụng như là sự biện minh cho "đó là cách tôi làm, vì vậy rõ ràng đó là lẽ thường" - và như một sự bảo vệ chống lại sự xem xét và chỉ trích.

Theo như các thực tiễn tốt nhất có liên quan @ hai đoạn đầu của Michael là một bản tóm tắt tuyệt vời về thực tiễn tốt nhất nên là gì - một nguồn lực để hỗ trợ mọi người cải thiện những gì họ làm. Nó cũng cung cấp tính minh bạch của các quyết định (đặc biệt là các quyết định thiết kế) và khả năng học hỏi từ những người khác. Nhược điểm của thực tiễn tốt nhất là khi nó tạo ra văn hóa danh sách kiểm tra - "Tôi đã đánh dấu vào tất cả các ô, vì vậy những gì tôi đã làm phải ổn" - không áp dụng suy nghĩ, quan tâm và chú ý đến bản chất của khả năng áp dụng danh sách kiểm tra.

Đây là một cuộc tranh luận dốc trơn trượt thường bị phá hủy trong một cuộc chiến tôn giáo.

Hầu như bất kỳ thực hành tốt nhất có thể được chống lại với một trường hợp hợp lệ để làm ngược lại.

Một số thực hành tốt nhất là "tốt nhất" hơn những thực hành khác. Các biến trạng thái toàn cầu hầu như luôn được thực hiện tốt hơn theo một cách khác và GOTO thường là một ý tưởng tồi, nhưng khi bạn đi vào mô hình / chống mẫu hoặc dữ liệu trực tiếp / đối số dữ liệu trừu tượng thì sẽ rõ ràng hơn một chút. Thậm chí nhiều hơn khi bạn bắt đầu nói về phương pháp và thực tiễn phát triển.

Trong một số tình huống, ý thức chung và thực tiễn tốt nhất thậm chí đối lập với nhau.

Không có cơ quan quản lý thực hành tốt nhất và không có nhóm duy nhất ngay cả khi nó tồn tại có thể xác định mọi "tốt nhất" có thể cho mọi tình huống có thể. Nhiều thứ được dán nhãn là thực tiễn tốt nhất chỉ là tiếp thị tồi khi cố gắng bán các công cụ hoặc đào tạo cá nhân không hiểu biết.

Ngay cả khi toàn bộ nhóm của bạn đồng ý rằng một cái gì đó là tốt nhất, không phải lúc nào cũng có thể thực hiện nó theo cách đó cho các yếu tố ràng buộc khác nhau.

IMHO bạn phải sử dụng thực tiễn tốt nhất như một hướng dẫn về những gì cần xem xét cẩn thận hơn trong thiết kế của bạn. Bạn có thể có một lý do hợp lệ cho việc đi chệch hướng, nhưng có lẽ bạn cần chắc chắn rằng mọi người khác trong nhóm đồng ý trước khi bạn đi và xây dựng một cái gì đó kỳ lạ.

Một số tranh luận về các thực tiễn tốt nhất sau thời điểm đó khá sôi nổi khi không xây dựng một cái gì đó mà nhà phát triển tiếp theo phải làm việc với nó sẽ ghét. Mọi người đều ghét mã không phải là phong cách của họ và mọi người đổ lỗi cho bất cứ ai rời bỏ, vì vậy hoặc bạn sẽ giải thích nó cho nhà phát triển tiếp theo sau khi họ càu nhàu về điều gì đó, hoặc bạn sẽ không ở đó và bị nói xấu bất kể bạn viết mã như thế nào Điều này làm cho mối quan tâm đó chủ yếu là không liên quan.

Tâm lý chung không phải lúc nào cũng mang lại kết quả tốt nhất. Thực hành tốt nhất, tuy nhiên, đã được thử. Điều này làm cho thực tiễn tốt nhất là một nguồn thông tin đáng tin cậy hơn.

Các thực tiễn tốt nhất không phải là tốt nhất và ý thức chung không phổ biến. ;-)

Đối với các thực tiễn tốt nhất hoặc thông thường, tôi thích nghĩ về chúng như các mẫu; Ghi nhớ định nghĩa của một mẫu: Một giải pháp trong bối cảnh giải quyết các lực vào bối cảnh kết quả .

Đối với bất cứ điều gì bạn muốn làm, bạn nên biết bối cảnh mà nó áp dụng, các lực lượng mà nó giải quyết và bối cảnh kết quả mà nó tạo ra. Sau đó, quyết định cho nhóm của bạn những mẫu bạn sẽ sử dụng thường là gì. (Điều này có thể chính thức hoặc không chính thức, nhưng dù bằng cách nào, nó lớn hơn nhiều so với cuốn sách Gang of Four. Điều này bao gồm các thành ngữ ngôn ngữ và thư viện trợ giúp địa phương, không chỉ các mẫu được xuất bản.)

Nếu bạn cảm thấy, dựa trên kinh nghiệm của mình, rằng trong một hoàn cảnh nhất định, tốt hơn là không sử dụng một mẫu nhất định, mà để làm một cái gì đó khác, hãy cho mọi người biết. Có lẽ bối cảnh hoặc lực lượng khác nhau ở đây (hoặc có lẽ bối cảnh kết quả là không mong muốn.) Tôi không quan tâm nếu đó là một cuộc họp, nhận xét mã hay gì, nhưng nếu bạn nói rõ rằng bạn đã phá vỡ mô hình trên mục đích , bạn sẽ có dặm về phía trước.

Thực hành tốt nhất là những gì họ dạy bạn ở trường, Thông thường là những gì ông chủ muốn hình thành bạn. Cái trước tạo ra phần mềm đáp ứng các tiêu chuẩn nhất định về sự thanh lịch, phong cách và như vậy. Người sau trả các hóa đơn / kiếm tiền để bạn được trả tiền mỗi tuần.

Một là nghệ thuật, kinh doanh khác, quá nhiều người trong chúng ta quên nó.

Để phóng đại một chút: Sự khác biệt là Ý thức chung là Định kiến, Thực tiễn tốt nhất là (nên là) Khoa học

Theo kinh nghiệm của tôi, 'Ý thức chung' được sử dụng khi người ta không muốn cung cấp bằng chứng hoặc ít nhất là các lập luận cho cách làm việc. Điều đó không có nghĩa là cách đó không đúng, nhưng điều đó cũng không có nghĩa là nó cũng tốt.

Trong số những điều tôi gặp phải, được hợp lý hóa như ý nghĩa thông thường của loài ong là những viên đá quý.

• Phương thức HTTP phần lớn không liên quan, hãy sử dụng GET khi bạn truyền ít dữ liệu, sử dụng POST khi truyền nhiều hơn (nghĩa là nhiều cho URL)
• các chức năng không nên quá nhỏ, vì thật khó để nhớ những gì chúng làm. một chức năng lớn tốt hơn là 5 chức năng nhỏ hơn, bởi vì bạn có thể đọc nó như một chức năng
• cơ sở dữ liệu và máy chủ web PHẢI chạy trên cùng một máy, nếu không thì dịch vụ web sẽ bị chậm. Cách duy nhất để mở rộng quy mô là tăng tốc mã bằng cách hack và bằng cách trừu tượng hóa, để sức mạnh của một máy đủ.

Điều buồn cười về 'Ý thức chung' là, nó không phổ biến: chọn hai đội và để họ nói lên điều họ là 'lẽ thường', và tận hưởng các cuộc chiến tôn giáo.

Mặt khác, với tư cách là 'Thực hành tốt nhất', tôi sẽ xem xét các cách thực hiện, có thêm một chút 'đánh giá ngang hàng'. Để coi một cái gì đó là 'thực tiễn tốt nhất', tôi hy vọng nó sẽ được xây dựng đủ rõ ràng để nó có thể được trình bày dưới dạng một khái niệm ('lập trình có cấu trúc' là cách thực hành tốt nhất, 'gotos gây nhầm lẫn, tránh chúng' là lẽ thường) áp dụng nhiều lần, với kết quả tốt.