Những rào cản để áp dụng thực hành tốt nhất là gì? Làm thế nào họ có thể vượt qua? [đóng cửa]

Chúng ta đều đã thấy (và hầu hết chúng ta đã viết) rất nhiều mã được viết kém. Tại sao? Điều gì làm cho chúng ta áp dụng các thực hành kém hơn là những người tốt?

Câu trả lời rõ ràng nhất (với tôi) là "thiếu hiểu biết", nhưng tôi chắc chắn đó không phải là lý do duy nhất. Những gì người khác đang có? Chúng ta có thể làm gì để vượt qua sự cám dỗ để viết mã xấu?

Đề kháng với sự thay đổi.

Đó là động lực chính đằng sau sự thiếu hiểu biết, quản lý kém, vv

Chương 30 của Peopleware 2nd Edition được dành cho chủ đề này. Và nó trích dẫn từ một cuốn sách của một nhà tư vấn khá nổi tiếng khác, được viết sớm hơn một chút:

Và cần phải xem xét rằng không có gì khó khăn hơn để xử lý, nghi ngờ thành công hơn, cũng không nguy hiểm hơn để quản lý, sau đó đặt bản thân vào đầu giới thiệu các đơn đặt hàng mới. Đối với người giới thiệu có tất cả những người hưởng lợi từ các mệnh lệnh cũ là kẻ thù, và anh ta có những người bảo vệ ấm áp trong tất cả những người có thể hưởng lợi từ các mệnh lệnh mới.

Niccolo Machiavelli: Hoàng tử (1513)

DeMarco và Lister tiếp tục nêu câu thần chú để ghi nhớ trước khi yêu cầu mọi người thay đổi:

Phản ứng cơ bản để thay đổi không phải là logic, mà là cảm xúc.

Quá trình thay đổi hiếm khi là một động lực thẳng và trơn tru từ các điều kiện dưới mức tối ưu hiện tại đến thế giới mới, được cải thiện. Đối với bất kỳ thay đổi không cần thiết, luôn có một khoảng thời gian bối rối và hỗn loạn trước khi đến với hiện trạng mới . Học các công cụ, quy trình và cách suy nghĩ mới là khó , và mất thời gian. Trong thời gian chuyển đổi năng suất này giảm, tinh thần bị ảnh hưởng, mọi người có thể phàn nàn và mong muốn nếu chỉ có thể trở lại với những cách làm tốt cũ. Rất thường họ làm, ngay cả với tất cả các vấn đề, bởi vì họ cảm thấy rằng các vấn đề được biết đến của ol tốt hơn so với các vấn đề mới, chưa biết, gây khó chịu và lúng túng. Đây là sự kháng cự phải khéo léo và nhẹ nhàng, nhưng quyết định vượt qua để thành công.

Với sự kiên nhẫn và kiên trì, cuối cùng cả đội đi từ Chaos sang giai đoạn tiếp theo, Luyện tập và Tích hợp. Mọi người, mặc dù không hoàn toàn thoải mái với các công cụ / quy trình mới, bắt đầu hiểu rõ về những công cụ này. Có thể có những trải nghiệm "Aha" tích cực. Và dần dần, nhóm đạt được một hiện trạng mới.

Điều thực sự quan trọng là nhận ra rằng hỗn loạn là một phần không thể thiếu, không thể tránh khỏi của quá trình thay đổi . Không có kiến ​​thức này - và chuẩn bị cho nó -, người ta có thể hoảng loạn khi đánh vào giai đoạn Chaos, và nhầm nó với hiện trạng mới. Sau đó, quá trình thay đổi bị hủy bỏ và nhóm trở lại trạng thái khốn khổ trước đó, nhưng thậm chí còn ít hy vọng cải thiện bất cứ điều gì ...

Để tham khảo, các giai đoạn được mô tả ở trên ban đầu được xác định trong Mô hình thay đổi Satir (được đặt tên theo Virginia Satir ).

Péter Török nói đúng, nhưng bỏ qua một điểm quan trọng và lạc quan:

• mọi người có thể thích thay đổi mà họ tham gia, nhưng họ hầu như không bao giờ thích thay đổi chỉ "xảy ra" với họ

vì vậy hãy tham gia, để họ đóng góp ý kiến, để họ tạo ra cổ phần trong đó và sẽ không quá đau đớn

Lưu ý: điều này có liên quan đến lập trình trong đó nhiều dự án phần mềm thành công về mặt kỹ thuật thất bại do người dùng từ chối chúng .

Thời gian dường như là một ngày lớn nơi tôi làm việc.

ví dụ: Tại sao phải áp dụng thử nghiệm đơn vị khi bạn phải viết nhiều mã hơn và do đó mất nhiều thời gian hơn để có được một sản phẩm đáng tin cậy? Khách hàng x muốn ngay bây giờ! Mã nhanh hơn!

(Điều này rõ ràng là không kết thúc tốt)

Đây cũng là kết quả của việc quản lý và kinh tế kém, không thu phí khách hàng đủ để chi trả thời gian cho việc làm đúng.

Mặc dù có bằng chứng lớn ngược lại, mọi người thường là những sinh vật rất lý trí. Lý do mà mọi người không áp dụng các thực tiễn tốt nhất, như TDD chẳng hạn, là vì họ không nghĩ rằng nó sẽ có giá trị. Hoặc là họ nghĩ rằng thực tế không phải là tốt nhất; và rằng nó thực sự sẽ khiến họ tốn nhiều tiền hơn nó sẽ cứu họ. Hoặc họ nghĩ rằng lợi ích rất ít đến mức chi phí thay đổi sẽ lớn hơn lợi ích nhỏ bé. Điểm mấu chốt là vấn đề thực hành tốt nhất là vấn đề của điểm mấu chốt.

Nếu bạn muốn trở thành một tác nhân thay đổi, nhiệm vụ của bạn là chứng minh rằng nhận thức của họ về điểm mấu chốt là thiếu sót. Bạn cần chỉ ra rằng thực hành tốt nhất thực sự là tốt nhất. Rằng những lợi ích là ngay lập tức và đáng kể . Bạn cần chỉ ra rằng đường cong học tập đủ nhỏ để chịu đựng và ít nhất một số lợi ích bắt đầu ngay lập tức.

Làm thế nào để bạn thể hiện điều này? Bằng cách áp dụng thực hành tốt nhất cho mình! Không có gì phục vụ để thuyết phục người khác tốt hơn hành vi của chính bạn. Nếu bạn làm theo cách thực hành tốt nhất và phát biểu về nó, những người khác sẽ thấy rằng bạn đã phân tích kinh tế và đưa ra quyết định ngược lại. Điều đó sẽ khiến họ xem xét lại quyết định của họ. Họ sẽ làm điều này một cách riêng tư, và không bao giờ thừa nhận nó lúc đầu. Nhưng tất cả những người nhìn thấy bạn sử dụng thực tiễn tốt nhất đó, sẽ kiểm tra lại vị trí của họ.

Đó là điều tốt nhất bạn có thể hy vọng. Nếu thực hành tốt nhất là thực hành tốt nhất, thì phần còn lại sẽ tự động làm theo. Ồ, nó sẽ không nhanh đâu, và sẽ có nhiều sự kìm hãm. Quá trình chuyển đổi sẽ chậm và đốm; và bạn sẽ trải qua nhiều thất vọng. Nhưng quá trình chuyển đổi cũng sẽ không thể tránh khỏi và không thể tránh khỏi. Nó có thể mất một thế hệ, nhưng thực hành tốt nhất sẽ giành chiến thắng.

Để chứng minh điều đó, hãy tự hỏi khi bạn nhìn thấy ai đó sử dụng goto lần cuối.

Đó là kết quả của việc không biết, hoặc nghĩ rằng người ta biết phương pháp lý tưởng. Mọi người không chọn viết mã kém; đó là một trường hợp không biết tốt hơn. " Ngây thơ ", trái ngược với " thiếu hiểu biết " sẽ là một từ tốt hơn.

Cách đơn giản nhất để tuân thủ thực tiễn tốt là thừa nhận (rất có thể) một cách tốt hơn để viết mã mà bạn vừa viết, và sau đó khao khát tìm hiểu "cách tốt hơn" đó là gì.

Hai nguyên nhân

• Vô minh.

• Kiêu căng.

Làm thế nào họ có thể vượt qua?

• Ưu đãi.

Cho đến khi các nhà quản lý (tức là những người mua kỹ năng của nhà phát triển) yêu cầu thực hành tốt nhất như là một phần của việc phân phối phần mềm, không có gì có thể thay đổi. Nhiều tổ chức rõ ràng là tâm thần phân liệt: họ giáo dục các nhà phát triển trong các công nghệ khác nhau và sau đó yêu cầu phần mềm chưa được kiểm tra hoặc một thiết kế không thể kiểm chứng. Hoặc tồi tệ hơn.

Thực hành tốt nhất đối với tôi là một phần mềm mà một nhóm 8 người đã viết. Chúng tôi không có yêu cầu bằng văn bản, đánh giá mã, kiểm tra đơn vị, tài liệu phát hành định dạng. Không có thử nghiệm người dùng cuối, không có gì trong tất cả những gì sách nói rằng chúng ta nên làm. Các mã đã được vội vàng, lỗi và không thể duy trì. Nó đã bị loại bỏ 3 năm sau khi phát hành, nó rất tệ. Vì vậy, những gì đã rất tuyệt vời về nó. Hai năm sau khi phát hành đầu tiên, chủ sở hữu công ty (người đã tài trợ cho sự phát triển bằng một khoản thế chấp tại nhà riêng của mình) đã bỏ đi với 30- 40 triệu đô la trong túi sau của mình.

Chúng ta thường mất cảnh giác về thực tế chúng ta (thường xuyên hơn không) ở đây để tạo ra phần mềm kiếm tiền cho doanh nghiệp. Các doanh nghiệp không tồn tại để cung cấp cho chúng tôi cơ hội phát triển phần mềm bằng cách sử dụng "Thực tiễn tốt nhất", họ tồn tại để kiếm tiền.

Hầu hết các thực hành "Thực hành tốt nhất" không cải thiện lợi nhuận. Những người làm, nên và đang, được áp dụng rộng rãi. Đó là lý do tại sao "thực hành tốt nhất" không được thực hành.

Rủi ro chấp nhận được

Bạn chưa bao giờ mạo hiểm và đánh bạc vào thứ gì đó? Có một thời gian khủng hoảng, vì vậy bạn làm cho nó hoạt động với ý định tái cấu trúc nó sau (trái ngược với tái cấu trúc nó sớm hơn). Đó thực sự được coi là một thực hành tốt cho một số người.

Cuối cùng, bạn bị đốt cháy đủ số lần và bạn thay đổi cách của mình. Hãy nghĩ về tất cả các 'thực hành tốt nhất' hiện có. Bạn có thể theo dõi tất cả chúng mọi lúc không? Có mâu thuẫn với nhau không? Bạn không muốn lãng phí thời gian xử lý mọi ngoại lệ.

Nếu tôi viết mã xấu hoạt động và không ai nhìn lại nó, nó vẫn bị coi là xấu? (Xin vui lòng, chúng ta đừng phá hỏng cuộc tranh luận triết học bằng cách tranh luận về 'mã xấu' là gì.)

IME đó là sự kết hợp của những gì người khác đã nói. Sự thiếu hiểu biết ("Tôi chỉ từng sử dụng DataSets, tại sao phải bận tâm với công cụ LINQ này?", Thiếu thời gian ("Ông chủ muốn nó được thực hiện càng sớm càng tốt, chúng tôi không thể dành nhiều thời gian cho nó"), thiếu về sự hiểu biết ("Có gì sai khi viết tất cả mã của tôi trong mã phía sau?") đều góp phần.

Điều trớ trêu mà tôi thấy là một khi bạn bắt đầu con đường đó, bạn chỉ cần tự khắc sâu hơn. Nếu bạn cắt các góc ngay bây giờ và ném tất cả mã cho một ứng dụng trong các tệp ASPX, bạn sẽ không bao giờ có thể sửa nó sau này; những điều mới sẽ tiếp tục bị ném vào bạn, điều đó có nghĩa là bạn phải thực hiện chúng nhanh chóng, điều đó có nghĩa là bạn phải tung tất cả mã trong tệp ASPX (thề rằng bạn sẽ sửa nó một ngày nào đó), v.v. - xoắn ốc vì bạn không còn có thể ngừng phát triển và nói rằng mọi thứ cần phải được sửa chữa trước tiên.

Thông thường các nhà phát triển đơn giản là không được chứng minh thực tiễn tốt hơn hoặc quan trọng hơn là lợi ích của việc sử dụng thực tiễn tốt hơn (Tôi bắt đầu ngừng sử dụng thuật ngữ 'Thực tiễn tốt nhất' vì nhiều lý do).

Có một lý thuyết cho rằng các nhà phát triển 'cố tình lười biếng'. Nói cách khác, họ sẽ có xu hướng chọn con đường ít kháng cự nhất.

Khi bạn nhanh chóng cho họ thấy những lợi ích của việc thực hành tốt hơn (chẳng hạn như TDD, hoặc nói, tuân theo các nguyên tắc RẮN) và nó thực sự cho phép họ trở thành một nhà phát triển tốt hơn (nhưng vẫn "lười biếng"), bạn có xu hướng thấy rằng sự kháng cự tan chảy xa.

Đó là vấn đề giáo dục :)

(Thiếu) Kiến thức và Kỹ năng + Thời gian để đầu tư

Tôi ngạc nhiên không ai khác đưa cái này ra, nhưng có lẽ điều đó là hiển nhiên đối với tôi bởi vì rất nhiều công việc của tôi là một lập trình viên đơn lẻ, không có ai (ngoài stack) đi đến khi tôi phải vật lộn với điều gì đó. Tôi biết 'về' các kỹ thuật tốt hơn - chẳng hạn như TDD - nhưng thường thì tôi không hiểu rõ về chúng để sử dụng chúng và gặp khó khăn trong việc tìm kiếm thông tin tốt để giúp tôi bắt đầu sử dụng chúng. Một lần nữa, sử dụng TDD làm ví dụ, tôi hiểu ý nghĩa cơ bản của nó - xây dựng các bài kiểm tra khẳng định mã của bạn đưa ra một kết quả cụ thể - nhưng thực sự triển khai nó?

Khác với thực tế là XCode đã thử nghiệm đơn vị tích hợp sẵn trong những ngày này, tôi không biết phải bắt đầu từ đâu. Tôi có khẳng định rằng chế độ xem có các nút X trên đó sau khi tôi chạy một thói quen để tạo chúng không? Làm thế nào về việc khẳng định rằng UIView của tôi đã được sắp xếp lại một cách thích hợp sau khi tôi gọi thẻ xoay?

Heck, làm thế nào để tôi thậm chí viết một bài kiểm tra đơn vị trong XCode? Đó là điều khác tôi cần dành thời gian để học.

@Zues và @Joshua Smith

Có, tôi đồng ý đôi khi thời gian và ngân sách là một số hạn chế không cho phép bạn đưa mọi nguyên tắc lập trình tốt hơn của YouTube mà bạn biết vào một chương trình.

Bạn biết rằng nhiệm vụ hiện tại có thể được thực hiện theo cách mạnh mẽ hơn nhiều nếu chỉ có bạn có thêm thời gian. Nhưng rất ít khách hàng (đặc biệt là nếu họ hoàn thành Ứng dụng iPhone đầu tiên hoặc phần mềm thông minh kinh doanh tùy chỉnh đầu tiên của họ) hiểu khi bạn nói rằng bạn đang triển khai lại một cái gì đó đã được thực hiện bởi vì bạn đã tìm ra cách tốt hơn để làm điều đó.

Tương tự cho các bài kiểm tra đơn vị. Thật không may, tôi vẫn chưa gặp một khách hàng đã sẵn sàng phân bổ ngân sách cho những người đó. Trả lời điển hình giống như kiểm tra hồi quy tự động của Hồi giáo OK Tôi hiểu nhưng kiểm tra đơn vị? Chúng tôi không có thời gian cho việc đó! Chúng tôi cần nhanh chóng đưa ra thị trường!

Hai phần trong hầu hết kinh nghiệm của tôi:

• thời gian
• có đủ người để đồng ý về những thực hành tốt nhất cho tình huống hiện tại

"Thực tiễn tốt nhất" là RẤT chủ quan trong nhiều tình huống thực tế. Nếu một nửa của nhóm đang cố gắng thực hiện một loạt RẮN & TDD trong khi nửa còn lại làm việc 60 giờ một tuần để loại bỏ các giây trong thời gian chạy ở đây và thông qua bất kỳ phương tiện cần thiết nào vì bạn đã qua thời điểm quá muộn để thiết kế lại một cái gì đó không thực hiện kịp thời cho bản phát hành tiếp theo của bạn, bạn sẽ không đi được rất xa.

Ngay cả khi bạn không gặp quá nhiều bất đồng trong nhóm, vẫn rất nỗ lực để có được thỏa thuận chính thức, tài liệu và đào tạo về bất kỳ chính sách nào bạn quyết định sẽ tuân theo. Đó là một khối lớn thời gian phi sản xuất theo quan điểm kinh doanh mà bạn sẽ phải biện minh cẩn thận.

Đôi khi, bạn sẽ thấy thói quen đó cũng là một đóng góp chính cho việc viết mã khủng khiếp.

Bạn có thể là một lập trình viên rất có kinh nghiệm và bạn có thể biết tất cả về các thực tiễn tốt nhất trong ngành hiện tại. Địa ngục, bạn thậm chí có thể là chuyên gia về những điều như vậy. Kinh nghiệm cho tôi biết rằng những người như vậy thường không viết mã khủng khiếp, nhưng có thể dễ dàng bỏ lại các thói quen cũ và làm điều gì đó mà bạn biết sẽ phá vỡ các quy tắc, đơn giản vì cảm thấy an toàn và thuận tiện. Trong những trường hợp như vậy, sự thờ ơ và kiêu ngạo và tất cả các tính từ chỉ ngón tay khác mà bạn có thể nghĩ ra không thực sự quan trọng. Không nhất thiết là những lập trình viên như vậy đặc biệt tệ với những gì họ làm (mặc dù điều này thường xuyên hơn), hoặc thậm chí là họ muốn tạo ra một mớ hỗn độn khủng khiếp.

Thật không may là tôi đã tận mắt chứng kiến ​​điều này xảy ra nhiều lần hơn tôi muốn đếm, nơi một số người thực sự tài năng đã tạo ra rác rưởi vì ngón tay và bộ não của họ đã hoạt động tự động trong một vài tháng. Thông thường đây là nơi bạn thấy bằng chứng kiệt sức, đau buồn và căng thẳng chồng chất. Đôi khi nó thực sự chỉ là thói quen mù quáng mang chúng qua các chuyển động hàng ngày. Đó là điều tôi đã học được để theo dõi cẩn thận để tránh mạo hiểm dán nhãn những người dễ bị tổn thương không cần thiết.

Chỉ cần một số thực phẩm cho những người trong chúng ta thấy dễ dàng hơn để đi đến kết luận tiêu cực ... mặc dù đáng buồn là bạn sẽ đúng thường xuyên hơn không.

Không ai thể hiện sự quan tâm để trả tiền cho một dự án có tiêu đề gì đó cùng với tái cấu trúc. Nó phải có một số từ thu hút các lợi ích của 'doanh nghiệp'. Các từ như cải tạo, tái tạo sức sống, làm lại toàn bộ, nâng cấp vòng đời, vv làm việc tại nơi làm việc của tôi. Hầu như tất cả trong số họ đã tái cấu trúc như là một phần chính của dự án.

Đáng buồn thay, nhờ người đánh kinh tế, công việc chỉ xảy ra khi có lương. Ngay cả khi công việc chỉ để tiết kiệm tài sản kinh doanh trong thời gian dài.