Làm thế nào để các lập trình viên nhanh và bẩn biết rằng họ đã hiểu đúng?

Nếu bạn hỏi các lập trình viên tại sao họ nên viết mã sạch, câu trả lời số một bạn nhận được là khả năng duy trì. Mặc dù trong danh sách của tôi, lý do chính của tôi là ngay lập tức và ít vị tha hơn: Tôi không thể biết liệu mã mới của mình có đúng hay không nếu nó quá bẩn. Tôi thấy rằng tôi đã tập trung vào các chức năng và dòng mã riêng lẻ đến mức khi tôi hoàn thành bản nháp đầu tiên của mình và quay lại nhìn vào bức tranh lớn, đôi khi nó không khớp với nhau rất gọn gàng. Dành một hoặc hai giờ để tái cấu trúc cho sự sạch sẽ thường xuyên phát hiện ra các lỗi sao chép / dán hoặc các điều kiện biên rất khó phát hiện trong bản nháp thô.

Tuy nhiên, một số người cảm thấy thỉnh thoảng vẫn ổn khi cố tình kiểm tra mã bẩn vì lợi ích của phần mềm vận chuyển, với kế hoạch "làm sạch nó sau". Có một số kỹ thuật thực tế giúp họ tự tin về tính chính xác của mã của họ khi khả năng đọc kém hơn lý tưởng? Đó có phải là một kỹ năng đáng để cố gắng phát triển? Hoặc là sự thiếu tự tin về mã mà một số người chỉ thấy dễ chấp nhận hơn?

Mã có lẽ không đúng.

Tuy nhiên, nó có thể không quan trọng.

Nhanh và bẩn có thể là cách đúng đắn để đi trong các tình huống:

• Mã có tuổi thọ ngắn . Ví dụ: bạn đang chuyển đổi một loạt dữ liệu sang định dạng chuẩn bằng chương trình đặc biệt.
• Tác động tiêu cực của thất bại là thấp :
  • Dữ liệu bạn đang chuyển đổi là không nghiêm trọng và có thể dễ dàng sửa các lỗi trong đó
  • Người dùng cuối là một lập trình viên thông cảm, người sẽ lý giải về các thông báo lỗi và làm việc xung quanh chúng bằng cách nói, xoa bóp đầu vào.

Đôi khi, mã không mạnh mẽ và xử lý mọi đầu vào có thể hiểu được. Đôi khi nó chỉ cần xử lý dữ liệu bạn biết có trong tay.

Trong tình huống đó, nếu các bài kiểm tra đơn vị giúp bạn nhận được mã được viết nhanh hơn (đây là trường hợp của tôi), thì hãy sử dụng chúng. Nếu không, mã nhanh và bẩn, hoàn thành công việc. Lỗi không kích hoạt không quan trọng. Lỗi bạn sửa hoặc làm việc xung quanh không quan trọng.

Điều hoàn toàn quan trọng là bạn không chẩn đoán sai những tình huống này. Nếu bạn viết mã nhanh và bẩn vì mã chỉ được sử dụng một lần, thì ai đó quyết định sử dụng lại mã trong một số dự án xứng đáng với mã tốt hơn, mã đó đáng được chăm sóc hơn.

Họ không. Tôi hiện đang làm việc trên một cơ sở mã được tạo bởi các lập trình viên "nhanh và bẩn", những người sẽ "dọn sạch nó sau". Họ đã qua lâu, và mật mã vẫn tiếp tục, đi theo hướng lãng quên. Nói chung, các lập trình viên cao bồi chỉ đơn giản là không hiểu tất cả các chế độ thất bại tiềm năng mà phần mềm của họ có thể có và không hiểu những rủi ro mà họ đang làm lộ ra công ty (và khách hàng).

Được rồi, có nguy cơ bị hạ bệ hoàn toàn, tôi sẽ "quỷ ủng hộ" quan điểm đối nghịch.

Tôi đề nghị rằng các nhà phát triển của chúng tôi có xu hướng quan tâm quá mức về những thứ như thực hành đúng và sạch mã. Tôi đề nghị rằng, trong khi những điều đó là quan trọng, không có vấn đề gì nếu bạn không bao giờ giao hàng .

Bất cứ ai đã từng kinh doanh trong một thời gian có lẽ sẽ đồng ý rằng có thể sử dụng một phần mềm ít nhiều vô thời hạn. Công tước Nukem Mãi mãi, các bạn của tôi. Đã có lúc tính năng tốt đẹp đó hoặc công việc tái cấu trúc quá khẩn cấp chỉ nên được đặt sang một bên và điều này nên được gọi là XONG.

Tôi đã chiến đấu với các đồng nghiệp của tôi về điều này nhiều lần. Có thêm một điều chỉnh nữa, một điều nữa "nên" được thực hiện cho nó là "đúng". Bạn có thể LUÔN tìm thấy điều đó. Tại một số điểm, trong thế giới thực, đủ tốt chỉ cần phải đủ tốt. Không có phần mềm vận chuyển trong thế giới thực, thực tế là hoàn hảo. Không ai. Tốt nhất, nó đủ tốt.

Những lập trình viên như vậy hầu như không bao giờ biết họ đã làm đúng, chỉ tin như vậy. Và sự khác biệt có thể không dễ nhận biết.

Tôi nhớ cách tôi đã sử dụng để lập trình trước khi tôi biết về thử nghiệm đơn vị. Và tôi nhớ rằng cảm giác tự tin và tin tưởng ở một cấp độ hoàn toàn khác sau khi tôi chạy bộ thử nghiệm đơn vị đàng hoàng đầu tiên của mình. Tôi đã không biết mức độ tin cậy như vậy trong mã của tôi tồn tại trước đây.

Đối với một người thiếu kinh nghiệm này, không thể giải thích sự khác biệt. Vì vậy, họ thậm chí có thể tiếp tục phát triển trong chế độ cầu nguyện trong suốt cuộc đời, nhân từ (và thờ ơ) tin rằng họ đang cố gắng hết sức để xem xét hoàn cảnh.

Điều đó nói rằng, thực sự có thể có những lập trình viên tuyệt vời và những trường hợp đặc biệt, khi một người thực sự xoay sở để giữ toàn bộ không gian vấn đề trong tâm trí của mình, trong một trạng thái hoàn chỉnh. Tôi đã trải qua những khoảnh khắc hiếm hoi như thế này, khi tôi hoàn toàn biết phải viết gì, mã chỉ bay ra khỏi tôi một cách dễ dàng, tôi có thể thấy trước tất cả các trường hợp đặc biệt và điều kiện biên, và mã kết quả chỉ hoạt động . Tôi không nghi ngờ gì nữa, có những thiên tài lập trình ngoài kia, những người có thể ở trong tình trạng dòng chảy như vậy trong thời gian dài hoặc thậm chí hầu hết thời gian của họ, và những gì họ tạo ra là mã đẹp, dường như không cần nỗ lực. Tôi đoán những người như vậy có thể cảm thấy không cần phải viết bài kiểm tra đơn vị trừng phạt để xác minh những gì họ đã biết. Và nếu bạn thực sự là một thiên tài như vậy, điều đó có thể ổn (mặc dù sau đó, bạn sẽ không ở bên dự án đó mãi mãi và bạn nên nghĩ về những người kế nhiệm của mình ...). Nhưng nếu không...

Và hãy đối mặt với nó, rất có thể là bạn không. Tôi, cho chính tôi, biết tôi không. Tôi đã có một số khoảnh khắc hiếm hoi của dòng chảy - và vô số giờ đau buồn và đau khổ, thường là do sai lầm của chính tôi. Tốt hơn là thành thật và thực tế. Trên thực tế, tôi tin rằng các lập trình viên vĩ đại nhất nhận thức đầy đủ về khả năng sai lầm của chính họ và những sai lầm trong quá khứ, vì vậy họ đã có ý thức phát triển thói quen kiểm tra lại các giả định của họ và viết các bài kiểm tra đơn vị nhỏ đó, để giữ an toàn cho bản thân. ( "Tôi không phải là một lập trình viên tuyệt vời - chỉ là một lập trình viên giỏi với những thói quen tuyệt vời." - Kent Beck.)

Bài kiểm tra đơn vị . Đó là cách duy nhất để có niềm tin vào bất kỳ mã nào (bẩn hay không).

Còn một chú ý đáng nói;

cắt ngắn làm cho sự chậm trễ lâu (Pippin)

Thật tốt khi học cách chấp nhận rằng không có hệ thống phần mềm nào có độ phức tạp hợp lý sẽ hoàn hảo cho dù có bao nhiêu thử nghiệm đơn vị và chỉnh sửa mã được thực hiện. Một số mức độ hỗn loạn và dễ bị tổn thương đến bất ngờ sẽ luôn ẩn trong mã. Điều này không có nghĩa là người ta không nên cố gắng tạo ra mã tốt hoặc tiến hành kiểm tra đơn vị. Đây là, tất nhiên, quan trọng. Có một sự cân bằng phải được tìm kiếm và điều này sẽ thay đổi từ dự án này sang dự án khác.

Kỹ năng được phát triển là sự hiểu biết về mức độ 'hoàn hảo' cần được sử dụng cho một dự án cụ thể. Ví dụ: nếu bạn đang viết một ứng dụng hồ sơ y tế điện tử với thời gian dự án 12 tháng, bạn sẽ muốn dành nhiều thời gian hơn để thử nghiệm và đảm bảo mã của bạn có thể duy trì được hơn so với ứng dụng web đăng ký hội nghị một lần mà phải được triển khai vào thứ Sáu. Vấn đề xảy ra khi ai đó làm ứng dụng EMR bị cẩu thả hoặc ứng dụng đăng ký không được triển khai kịp thời vì lập trình viên quá bận chỉnh sửa mã.

Nhanh và bẩn là hoàn toàn tốt trong một hệ thống con . Nếu bạn có một giao diện được xác định rõ giữa crap của bạn và phần còn lại của hệ thống, và một bộ kiểm tra đơn vị tốt để xác minh rằng mã nhanh và bẩn xấu xí của bạn làm điều đúng, nó có thể hoàn toàn ổn.

Ví dụ, có thể bạn có một số hack đáng ghét của các biểu thức thông thường và các byte bù để phân tích một số tệp đến từ bên thứ ba. Và giả sử bạn có một bài kiểm tra nói rằng kết quả bạn nhận được từ việc phân tích tệp ví dụ là những gì bạn mong đợi. Bạn có thể xóa phần này để bạn có thể ... Tôi không biết, phản ứng nhanh hơn khi bên thứ ba thay đổi định dạng tệp? Điều đó không xảy ra thường xuyên đủ. Nhiều khả năng họ sẽ thay đổi thành một API hoàn toàn mới và bạn sẽ loại bỏ trình phân tích cú pháp cũ và cắm một API mới phù hợp với cùng một API và voila, bạn đã hoàn thành.

Trường hợp nhanh và bẩn trở thành vấn đề là khi kiến ​​trúc của bạn nhanh và bẩn. Đối tượng miền lõi của bạn cần phải được suy nghĩ kỹ và các giao diện của bạn, nhưng các cạnh của hệ thống của bạn thường có thể lộn xộn mà không bao giờ phải trả tiền cho piper.

Đây là một câu chuyện về một lập trình viên nhanh và bẩn mà tôi biết.

Tôi đã biết một người liên quan đến việc kiểm tra đơn vị một cách lãng phí thời gian. Sau nhiều tranh luận, cuối cùng anh cũng viết một. Nó bao gồm một phương thức dài được rắc && và || và trả về một boolean để assertTrue. Câu lệnh trải dài 20 dòng. Sau đó, một lần nữa, ông đã viết một lớp trong đó mỗi phương thức có một dòng và một dòng chính có hơn 1000 dòng không có khoảng trắng. Đó là một bức tường của văn bản. Khi tôi xem lại mã của anh ấy và chèn một số dòng mới, anh ấy hỏi 'tại sao'. Tôi nói 'Vì dễ đọc'. Anh thở dài và xóa chúng đi. Anh ấy đặt một bình luận lên trên "Đừng chạm vào nó, nó hoạt động!"

Lần trước tôi nói chuyện với anh ta, anh ta đã mã hóa một trang web cho một công ty. Anh ta đang cố gắng tìm một lỗi. Ông đã dành 3 ngày cuối cùng để làm điều đó trong 8 giờ một ngày. Một lát sau tôi nói chuyện với anh ta một lần nữa, và hóa ra đồng đội của anh ta đã thay đổi giá trị của một nghĩa đen và không cập nhật nó ở đâu khác. Đó không phải là một hằng số. Vì vậy, anh ấy đã thay đổi các chữ khác để lỗi của mình được sửa. Anh ta phàn nàn về mã spaghetti của đồng đội. Anh ấy nói với tôi 'Haha, không phải tất cả chúng ta đều biết việc thức suốt đêm với trình gỡ lỗi như thế nào, không ngủ với một lỗi khó chịu "Anh ấy nghĩ rằng đây là điều mà các lập trình viên thực sự giỏi và anh ấy thực sự cảm thấy tốt về điều đó.

Ngoài ra, ông nghĩ rằng đọc sách lập trình và blog là vô ích. Anh ta nói, 'hãy bắt đầu lập trình'. Anh ấy đã làm điều đó trong 12 năm và anh ấy nghĩ rằng anh ấy là một lập trình viên xuất sắc. / facepalm

Đây là một số nữa.

Một lần khác, chúng tôi đã viết một lớp DatabaseManager cho ứng dụng web của chúng tôi. Ông đặt tất cả các cuộc gọi cơ sở dữ liệu trong đó. Đó là một lớp Chúa với hơn 50 phương pháp cho mọi thứ có thể tưởng tượng được. Tôi đề nghị chúng tôi chia nó thành các lớp con vì không phải mọi bộ điều khiển đều cần biết về mọi phương thức cơ sở dữ liệu. Anh ấy không đồng ý, vì thật dễ dàng khi chỉ có một lớp cho toàn bộ cơ sở dữ liệu và thật nhanh chóng để thêm một phương thức mới bất cứ khi nào chúng tôi cần. Cuối cùng, DatabaseManager có hơn 100 phương thức công khai từ xác thực người dùng đến sắp xếp vị trí địa điểm khảo cổ.

Bài học của tôi về việc tránh nhanh chóng và bẩn thỉu là khi tôi có sáu tháng để cung cấp những gì được ước tính (ước tính thấp) để trở thành công việc đáng giá trong một năm. Tôi quyết định nghiên cứu phương pháp luận trước khi bắt đầu công việc. Cuối cùng, tôi đã đầu tư ba tháng nghiên cứu và có thể giao hàng trong ba tháng còn lại.

Chúng tôi đã đạt được lợi nhuận lớn bằng cách xác định chức năng chung và xây dựng các thư viện cần thiết để xử lý các yêu cầu đó. Tôi vẫn thấy các lập trình viên viết mã riêng của họ khi có các thói quen thư viện có sẵn. Các lập trình viên này thường viết lại, hoặc tốt nhất là cắt và dán, cùng một mã khi họ cần giải quyết cùng một vấn đề sau này. Sửa lỗi luôn luôn chỉ bắt một số bản sao mã.

Một nhà phát triển đã trả lời khi tôi yêu cầu anh ta sử dụng mã thư viện: "Không phải là gian lận sao? Tôi phải viết tất cả mã của mình ở trường."

Trong một số trường hợp, tôi đoán có thể có một bộ lớn các biến hồi quy sẽ tìm thấy "tất cả" lỗi và xác minh hành vi, do đó cho phép một kỹ thuật mã hóa nhanh và bẩn. Nhưng chủ yếu chỉ là vấn đề lập kế hoạch dự án tồi và một người quản lý nghĩ rằng việc thực hiện nó quan trọng hơn là hoàn thành công việc.

Và quên đi "làm sạch nó sau", điều đó không bao giờ xảy ra. Trong những trường hợp hiếm hoi xảy ra, lập trình viên sẽ quên hầu hết các mã làm cho công việc trở nên đắt đỏ hơn so với lần đầu tiên anh ta thực hiện nó.

Các sản phẩm tàu.

Mã không tồn tại trong chân không. Tôi đã phải chịu đựng nỗi đau không thể kể xiết khi chữa cháy hậu quả của việc mã hóa nhanh và bẩn và cao bồi. Nhưng đôi khi hoàn thiện sản phẩm là ưu tiên, không tìm ra cách viết mã tốt nhất. Cuối cùng, nếu sản phẩm vận chuyển và hoạt động đủ tốt, người dùng và khách hàng sẽ không biết hoặc quan tâm đến việc mã "bên trong" tệ đến mức nào và tôi sẽ thừa nhận đã có lúc tôi không quan tâm đến việc "lấy nó" đúng "miễn là tôi lấy nó ra khỏi cửa.

Vâng, điều này trong một vấn đề tổ chức và "không bao giờ nên xảy ra." Nhưng nếu bạn tình cờ viết mã trong một tổ chức được quản lý kém và có thời hạn cao, thì ở cấp độ lập trình viên cá nhân sẽ bị hạn chế.

Tôi không nghĩ họ có thể thành thật nói rằng họ hiểu đúng nếu điều đó không dễ bảo trì. Nếu họ thừa nhận họ phải "dọn dẹp nó sau", thì có khả năng họ đã nghĩ đủ rồi. Kiểm tra nó kỹ lưỡng sẽ chỉ thực sự phát hiện ra bất kỳ vấn đề với mã bẩn.

Cá nhân tôi sẽ không đặt mục tiêu phát triển kỹ năng "viết mã bẩn" và tự tin về tính đúng đắn của nó. Tôi thà viết mã thích hợp lần đầu tiên.

Làm thế nào để họ biết họ đã hiểu đúng? Kiểm tra là câu trả lời đơn giản.

Nếu mã của họ đã được kiểm tra kỹ lưỡng bởi một nhóm QA tốt và nó sẽ vượt qua, thì tôi sẽ nói họ đã hiểu đúng.

Viết mã nhanh và bẩn không phải là việc nên làm theo thói quen nhưng đồng thời, có những lúc bạn có thể dành 20 phút để viết mã có thể được phân loại là bẩn hoặc 4 giờ tái cấu trúc rất nhiều mã để thực hiện đúng. Trong thế giới kinh doanh đôi khi 20 phút là tất cả những gì có sẵn để thực hiện công việc và khi bạn đối mặt với thời hạn nhanh chóng và bẩn thỉu có thể là lựa chọn duy nhất.

Tôi đã ở cả hai đầu của điều này, tôi đã phải sửa mã bẩn và phải tự viết để khắc phục những hạn chế của hệ thống mà tôi đang phát triển. Tôi sẽ nói rằng tôi tin tưởng vào mã tôi đã viết bởi vì mặc dù nó bẩn và một chút hack đôi khi tôi đã chắc chắn rằng nó đã được kiểm tra kỹ lưỡng và có rất nhiều lỗi được xử lý, vì vậy nếu có lỗi xảy ra, nó sẽ không phá hủy phần còn lại của hệ thống.

Khi chúng ta xem thường những lập trình viên nhanh và bẩn này, chúng ta cần phải nhớ một điều, một khách hàng thường không trả tiền cho đến khi họ có sản phẩm, nếu nó xuất xưởng và họ đi kiểm tra UAT và tìm ra các lỗi từ mã nhanh và bẩn đó là ít có khả năng họ sẽ rút ra khi họ có một sản phẩm gần như đang hoạt động trước họ, nhưng nếu họ không có gì và bạn đang nói với họ "bạn sẽ có nó ngay, chúng tôi sẽ sửa x" hoặc "nó bị trì hoãn vì chúng tôi phải lấy y làm việc hoàn hảo "họ có nhiều khả năng từ bỏ và đi với một đối thủ cạnh tranh.

Tất nhiên như hình ảnh này chứng tỏ không ai nên đánh giá thấp sự nguy hiểm của mã nhanh và bẩn!

Tôi không nghĩ bạn thậm chí nên bắt đầu đi vào con đường đó. Nhanh chóng và bẩn thỉu có thể mang lại cho bạn lợi ích tạm thời của việc hoàn thành nhanh hơn, nhưng cuối cùng bạn luôn phải trả gấp mười lần để thực hiện việc này.

Theo tôi, học cách đánh giá mã Q & D cho chính xác không phải là một kỹ năng đáng để phát triển vì nó chỉ là thực hành tồi. Đây là lý do tại sao:

Tôi không nghĩ "nhanh và bẩn" và "thực hành tốt nhất" đi đôi với nhau. Nhiều lập trình viên (bao gồm cả tôi) đã tìm ra mã nhanh và bẩn do kết quả của một sai lệch trong ba ràng buộc . Khi tôi phải làm điều đó, nó thường là kết quả của phạm vi creep kết hợp với thời hạn tiếp cận. Tôi biết mã mà tôi đang kiểm tra bị hút, nhưng nó nhổ ra các đầu ra thích hợp với một bộ đầu vào. Rất quan trọng đối với các bên liên quan của chúng tôi, chúng tôi vận chuyển đúng thời gian.

Nhìn vào Báo cáo CHAOS ban đầu cho thấy khá rõ rằng Q & D không phải là một ý tưởng hay và sẽ giết chết ngân sách sau này (trong bảo trì hoặc trong quá trình mở rộng). Học cách đánh giá nếu mã Q & D đúng là một sự lãng phí thời gian. Như Peter Drucker đã nói, "Không có gì vô dụng bằng việc làm một cách hiệu quả mà không nên làm gì cả."

Tôi không thể biết mã mới của mình có đúng không nếu nó quá bẩn.

"Bẩn" có nghĩa là những thứ khác nhau cho những người khác nhau. Đối với tôi, điều đó chủ yếu có nghĩa là dựa vào những thứ mà bạn biết có lẽ bạn không nên dựa vào, nhưng bạn cũng biết rằng bạn có thể mong đợi làm việc trong thời gian tới. Ví dụ: giả sử rằng một nút cao 20 pixel thay vì tính chiều cao; mã hóa cứng một địa chỉ IP thay vì phân giải tên; đếm trên một mảng được sắp xếp bởi vì bạn biết rằng đó là, mặc dù phương thức cung cấp mảng đó không đảm bảo cho nó.

Mã bẩn rất dễ vỡ - bạn có thể kiểm tra nó và biết rằng nó hoạt động ngay bây giờ , nhưng một điều khá tốt là nó sẽ bị hỏng vào một thời điểm nào đó trong tương lai (hoặc nếu không thì buộc mọi người phải đi trên vỏ trứng vì sợ phá vỡ nó).

Có nguy cơ gây ra một chút tranh cãi, tôi cho rằng không ai thực sự BIẾT rằng mã của họ đúng 100% và 100% không có lỗi. Ngay cả khi bạn có phạm vi kiểm tra thực sự tốt và bạn đang áp dụng nghiêm ngặt các thực hành BDD / TDD tốt, bạn vẫn có thể phát triển mã có lỗi và vâng, thậm chí có thể chứa các tác dụng phụ!

Chỉ cần viết mã và giả sử nó hoạt động ngụ ý sự tự tin quá mức đối với khả năng của chính nhà phát triển về khả năng của chính nhà phát triển đó và khi có vấn đề phát sinh (chắc chắn họ sẽ), nỗ lực gỡ lỗi và duy trì mã sẽ tốn kém, đặc biệt là nếu nhà phát triển khác cần để duy trì mã sau này. Sự khác biệt thực sự được tạo ra bằng cách áp dụng các thực hành kỹ thuật phần mềm tốt, đảm bảo rằng bạn có thể tin tưởng thực sự rằng mã của bạn có khả năng hoạt động hầu hết thời gian và nếu bạn gặp phải lỗi, có nhiều khả năng dễ gỡ lỗi hơn và ít tốn kém hơn nhiều để thay đổi và duy trì bất kể người nào làm việc với mã đó sau này.

Điểm nổi bật là mã được kiểm tra tốt và được kiểm tra tốt sẽ cho phép OTHERS có niềm tin vào mã của bạn, điều này trong hầu hết các trường hợp quan trọng hơn sự tự tin của chính bạn.

Nếu mã bẩn được kiểm tra tốt, nó có thể được tin cậy. Vấn đề là, đơn vị đó kiểm tra mã bẩn thường rất khó khăn và cồng kềnh. Đây là lý do tại sao TDD rất tốt; nó tiết lộ và loại bỏ bụi bẩn và mùi. Ngoài ra, kiểm tra đơn vị thường là điều đầu tiên phải chịu đựng niềm vui thời gian. Vì vậy, nếu anh chàng sạch nhất từng tạo ra mã sạch nhất anh ta từng làm, tôi vẫn sẽ không tin nó một chút nào, nếu anh ta bỏ qua các bài kiểm tra đơn vị do sự đảm bảo về thời gian.

Các lập trình viên giỏi (Quick & Dirty và mặt khác) không có sự kiêu ngạo để cho rằng họ đã hiểu đúng. Họ cho rằng tất cả các hệ thống lớn đều có lỗi và sai sót, nhưng đến một lúc nào đó có thể được kiểm tra và xem xét đủ để có rủi ro đủ thấp hoặc chi phí thất bại đủ thấp mà mã có thể gửi đi.

Vậy tại sao những thứ này, được gọi là Quick & Dirty, lập trình viên, tồn tại? Giả thuyết của tôi là lựa chọn của Darwin. Các lập trình viên vận chuyển mã khả thi nhanh, đôi khi giao hàng trước khi tàu cạnh tranh hoặc hết ngân sách hoặc công ty phá sản. Do đó, các công ty của họ vẫn đang kinh doanh sử dụng các lập trình viên mới để phàn nàn về sự lộn xộn phải được dọn dẹp. Vì vậy, được gọi là tàu mã sạch, nhưng không đủ khác biệt để khiến các lập trình viên Quick & Dirty bị tuyệt chủng.

Mọi người có thể nghĩ rằng một phần không tối ưu của mã có thể không tạo ra sự khác biệt, vì thời gian tồn tại ngắn, ít ảnh hưởng trong kinh doanh hoặc ít thời gian để hoàn thành nó. Câu trả lời đúng là bạn không thực sự biết. Mỗi khi tôi nghe ai đó nói rằng "đây là một tính năng nhỏ" hoặc "hãy làm cho nó nhanh và đơn giản nhất có thể" và dành không đủ thời gian để suy nghĩ về thiết kế phù hợp, chỉ có hai điều thực sự xảy ra là:

1-) Dự án trở nên lớn hơn và động lực nhóm thấp hơn, làm việc với mã đầy "khâu". Trong trường hợp đó, dự án sẽ có khả năng chuyển làn nhanh sang hỗn loạn.

2-) Dự án được biết đến là một giải pháp không tối ưu và việc sử dụng nó bắt đầu không được khuyến khích, ủng hộ một giải pháp mới hoặc tái cấu trúc đắt tiền như một giải pháp mới.

Cố gắng luôn luôn để làm mã tốt nhất bạn có thể. Nếu bạn không có đủ thời gian, hãy giải thích lý do tại sao bạn cần nhiều hơn. Đừng đặt mình vào nguy cơ với công việc kém cỏi. Hãy luôn là một chuyên gia tốt hơn. Không ai có thể trừng phạt bạn vì điều này nếu bạn hợp lý. Nếu họ làm như vậy, đó không phải là nơi bạn nên quan tâm để làm việc.

Thảo luận với cấp cao và đánh giá tác động của thất bại nếu có. Ví dụ, một tình huống mà bạn có thể khắc phục sự cố bẩn mất 1 ngày và một mã mạnh mẽ yêu cầu thay đổi thiết kế và kiến ​​trúc có thể mất từ ​​4 đến 6 tháng + thời gian xác nhận bổ sung để xác thực hoàn toàn tất cả các quy trình công việc bị ảnh hưởng với thay đổi thiết kế.

Chúng tôi cũng phải đưa ra quyết định dựa trên Thời gian + Năng lực + Ưu tiên trong danh sách. Một cuộc thảo luận tốt trong nhóm với người cao niên hoặc những người có kinh nghiệm cao hơn có thể giúp đưa ra quyết định phù hợp nhất với nhóm và có thể giao được.

Mã sạch là cách tiếp cận đầu tiên và quan trọng nhất trong đó là mã bẩn để lưu các mức leo thang, quyết định đi / không đi của khách hàng, hiển thị nút chặn, danh tiếng của tổ chức tại cọc và nhiều hơn nữa khi mã bẩn biến nó thành mã sạch.