Làm cách nào tôi có thể đề xuất một cách khéo léo các cải tiến đối với mã được thiết kế xấu trong khi xem xét?

Tôi là một người tin tưởng tuyệt vời vào mã sạch và thủ công mã, mặc dù hiện tại tôi đang làm một công việc mà điều này không được coi là ưu tiên hàng đầu. Đôi khi tôi thấy mình trong một tình huống mà mã của đồng nghiệp bị đánh đố với thiết kế lộn xộn và rất ít quan tâm đến việc bảo trì trong tương lai, mặc dù nó có chức năng và không có nhiều lỗi.

Làm thế nào để bạn đi về đề xuất cải tiến trong đánh giá mã khi bạn tin rằng có rất nhiều nhu cầu thay đổi, và có thời hạn sắp tới? Hãy nhớ rằng đề xuất cải tiến được thực hiện sau thời hạn có thể có nghĩa là chúng sẽ được ưu tiên hoàn toàn khi các tính năng mới và sửa lỗi xuất hiện.

1. Kiểm tra lại động lực của bạn. Nếu bạn nghĩ rằng mã nên được thay đổi, bạn nên có thể nói rõ một số lý do tại sao bạn nghĩ rằng nó nên được thay đổi. Và lý do đó nên cụ thể hơn là "tôi sẽ làm nó khác đi" hoặc "nó xấu xí". Nếu bạn không thể chỉ ra một số lợi ích đến từ thay đổi được đề xuất của bạn, thì sẽ không có nhiều thời gian dành (thay vì tiền) để thay đổi nó.

2. Mỗi dòng mã trong dự án là một dòng phải được duy trì. Mã phải được miễn là nó cần phải hoàn thành công việc và dễ hiểu, và không còn nữa. Nếu bạn có thể rút ngắn mã mà không làm mất đi sự rõ ràng, điều đó tốt. Nếu bạn có thể làm điều đó trong khi tăng độ rõ ràng, điều đó tốt hơn nhiều.

3. Mã giống như cụ thể: khó thay đổi hơn sau khi ngồi được một lúc. Đề xuất thay đổi của bạn sớm nếu bạn có thể, để giảm thiểu chi phí và rủi ro thay đổi.

4. Mỗi thay đổi đều tốn tiền. Viết lại mã hoạt động và không cần phải thay đổi có thể bị lãng phí công sức. Tập trung sự chú ý của bạn vào các phần có nhiều chủ đề để thay đổi hoặc quan trọng nhất đối với dự án.

5. Hình thức theo chức năng, và đôi khi ngược lại. Nếu mã lộn xộn, có nhiều khả năng nó cũng chứa lỗi. Tìm kiếm những lỗi đó và chỉ trích các chức năng thiếu sót hơn là sự hấp dẫn thẩm mỹ của mã. Đề xuất các cải tiến làm cho mã hoạt động tốt hơn và làm cho hoạt động của mã dễ xác minh hơn.

6. Phân biệt giữa thiết kế và thực hiện. Một lớp quan trọng với giao diện crappy có thể lây lan qua một dự án như ung thư. Nó sẽ không chỉ làm giảm chất lượng của phần còn lại của dự án, mà còn làm tăng khó khăn trong việc sửa chữa thiệt hại. Mặt khác, một lớp học với giao diện được thiết kế tốt nhưng việc triển khai tệ hại không phải là vấn đề lớn. Bạn luôn có thể thực hiện lại lớp để có hiệu suất hoặc độ tin cậy tốt hơn. Hoặc, nếu nó hoạt động chính xác và đủ nhanh, bạn có thể để nó một mình và cảm thấy an toàn khi biết rằng hành trình của nó được gói gọn.

Để tóm tắt tất cả các điểm trên: Đảm bảo rằng các thay đổi được đề xuất của bạn thêm giá trị.

Có một điểm ngọt để tăng thêm giá trị thông qua tái cấu trúc. Thay đổi cần phải hoàn thành ba điều:

• cải thiện mã có khả năng thay đổi
• tăng sự rõ ràng
• tốn ít công sức nhất

Cân nhắc:

1. Chúng tôi biết rằng mã sạch sẽ ít tốn kém hơn để viết và duy trì, và sẽ vui hơn khi làm việc. Công việc của bạn là bán ý tưởng đó cho mọi người trong công ty của bạn. Hãy suy nghĩ như một người bán hàng, không giống như một nhóm kiêu ngạo (tức là không giống tôi).
2. Bạn không thể thắng, bạn chỉ có thể thua ít hơn.
3. Tập trung vào việc thêm giá trị thực - không chỉ là vẻ đẹp. Tôi thích mã của tôi trông đẹp, nhưng đôi khi phải chấp nhận rằng vấn đề rẻ tiền hơn.
4. Một cách tốt để tìm thấy điểm ngọt ngào là tuân theo Nguyên tắc Hướng đạo của Boy - khi bạn làm việc trên một khu vực mã, luôn để nó ở trạng thái tốt hơn bạn đã tìm thấy.
5. Một cải tiến nhỏ tốt hơn là không cải thiện.
6. Sử dụng tốt các công cụ tự động. Ví dụ, các công cụ chỉ cần dọn dẹp một chút định dạng có thể tạo ra một thế giới khác biệt.
7. Bán các ý tưởng khác mà tình cờ cải thiện rõ ràng mã. Ví dụ, kiểm thử đơn vị khuyến khích phân tách các phương thức lớn thành các phương thức nhỏ hơn.

Nếu mã hoạt động mà không có lỗi nghiêm trọng và thời hạn chính (như trong hiệu ứng P & L hoặc PR công ty) sắp xảy ra, thì đã quá muộn để đề xuất các cải tiến đòi hỏi phải thay đổi lớn. Ngay cả những cải tiến về mã cũng có thể tạo ra rủi ro cho việc triển khai dự án. Thời gian để cải tiến là sớm hơn trong dự án, khi có nhiều thời gian hơn để đầu tư vào sự mạnh mẽ trong tương lai của cơ sở mã.

Đánh giá mã phục vụ 3 mục đích:

1. Kiểm tra lỗi

2. Kiểm tra xem mã có thể được cải thiện ở đâu

3. Công cụ giảng dạy cho bất cứ ai viết mã.

Đánh giá chất lượng thiết kế / mã tất nhiên là về # 2 và # 3.

Theo như # 2:

• Làm cho nó RẤT rõ ràng những lợi ích từ các thay đổi được đề xuất so với chi phí để sửa chữa. Như bất kỳ quyết định kinh doanh nào, điều này nên là về phân tích chi phí / lợi ích.

  Ví dụ: "Cách tiếp cận thiết kế X sẽ giảm đáng kể khả năng xảy ra lỗi Y khi xảy ra thay đổi Z và chúng tôi biết đoạn mã này trải qua các thay đổi của loại Z cứ sau 2 tuần. Chi phí xử lý sự cố ngừng sản xuất từ ​​lỗi Y + tìm ra lỗi + sửa chữa và phát hành bản sửa lỗi + chi phí cơ hội từ việc không cung cấp bộ kỳ công tiếp theo là $A; trong khi đó chi phí làm sạch mã bây giờ và chi phí cơ hội (ví dụ: giá vận chuyển trễ hoặc có ít tính năng hơn) $B. có trưởng nhóm / quản lý của bạn - đánh giá $Avs $Bvà quyết định.

  • Điều này sẽ giúp đội ngũ thông minh dẫn đến quản lý hiệu quả điều này. Ví dụ, họ sẽ đưa ra quyết định hợp lý bằng cách sử dụng thông tin ĐẦY ĐỦ

  • Điều này sẽ (đặc biệt là nếu bạn nói tốt điều này) nâng cao địa vị CỦA BẠN - ví dụ: bạn là người đủ thông minh để thấy được lợi ích của thiết kế tốt hơn, VÀ đủ thông minh để không yêu cầu tôn giáo mà không cân nhắc kinh doanh.

  • VÀ, trong trường hợp có khả năng xảy ra lỗi Z, bạn sẽ có được nhiều đòn bẩy hơn nhiều cho các đề xuất tiếp theo.

Theo như # 3:

• RẤT phân định rõ ràng "phải sửa" các lỗi / vấn đề từ "Đây là cách thực hành tốt nhất và thực sự cần phải sửa chữa NẾU chúng ta có thể tiết kiệm tài nguyên - xem các cải tiến thiết kế pro / con đính kèm" (tùy chỉnh nội dung được mô tả cho # 2 ở trên) vs " Đây là những hướng dẫn chung mà tôi nghĩ sẽ giúp bạn cải thiện độ mạnh của mã để bạn có thể dễ dàng duy trì mã hơn "các thay đổi tùy chọn. Vui lòng lưu ý từ ngữ - không phải là "tạo mã của bạn như những gì tôi muốn" - đó là "nếu bạn làm điều này, BẠN có được lợi ích a, b, c". Các giai điệu và cách tiếp cận vấn đề.

Chọn các trận đánh của bạn, nếu thời hạn sắp tới thì không làm gì cả. Lần tới khi người khác đang xem xét hoặc duy trì mã và họ tiếp tục gặp rắc rối với nó, sau đó tiếp cận họ với ý tưởng rằng với tư cách là một nhóm bạn nên tập trung hơn vào chất lượng mã khi xem lại mã để sau này bạn sẽ không gặp nhiều rắc rối.

Họ nên xem giá trị trước khi làm thêm.

Tôi luôn bắt đầu bình luận của mình bằng "Tôi sẽ", điều đó báo hiệu rằng tôi chỉ đơn giản là một trong nhiều quan điểm.

Tôi cũng luôn luôn bao gồm một lý do.

" Tôi sẽ trích xuất khối này thành một phương thức vì dễ đọc."

Tôi nhận xét về mọi thứ; lớn và nhỏ. Đôi khi tôi đưa ra hơn một trăm bình luận về một sự thay đổi, trong trường hợp đó tôi cũng khuyên bạn nên lập trình theo cặp và tự cho mình là người có cánh.

Tôi đang cố gắng thiết lập một ngôn ngữ chung vì lý do; khả năng đọc, DRY, SRP, v.v.

Tôi cũng đã tạo một bài thuyết trình về Clean Code và Tái cấu trúc giải thích lý do và chỉ ra cách thức mà tôi tổ chức cho các đồng nghiệp của mình. Tôi đã giữ nó ba lần cho đến nay và một tư vấn chúng tôi đang sử dụng đã yêu cầu tôi giữ lại cho họ.

Nhưng một số người sẽ không lắng nghe. Sau đó, tôi rời đi với thứ hạng kéo. Tôi là trưởng nhóm thiết kế. Mã chất lượng là trách nhiệm của tôi. Thay đổi này sẽ không thông qua đồng hồ của tôi trong trạng thái hiện tại.

Xin lưu ý rằng tôi rất sẵn lòng ủng hộ bất kỳ bình luận nào tôi đưa ra; vì lý do kỹ thuật, thời hạn, nguyên mẫu, v.v. Tôi vẫn còn nhiều điều để tìm hiểu về mã hóa và sẽ luôn lắng nghe lý do.

Ồ, và gần đây tôi đã đề nghị mua bữa trưa cho người đầu tiên trong nhóm của tôi, người đã gửi một thay đổi không hề nhỏ mà tôi không có bất kỳ bình luận nào . (Này, bạn cũng phải có niềm vui. :-)

Đôi khi tôi thấy mình trong một tình huống mà mã của đồng nghiệp bị đánh đố với thiết kế lộn xộn và rất ít quan tâm đến việc bảo trì trong tương lai, mặc dù nó có chức năng và không có nhiều lỗi.

Mã này được thực hiện. Tại một thời điểm nhất định, thiết kế lại trở nên quá tốn kém để biện minh. Nếu mã đã hoạt động với ít hoặc không có lỗi, thì đây sẽ là một bán không thể. Đề xuất một vài cách để làm sạch điều này trong tương lai và tiếp tục. Nếu / khi mã bị hỏng trong tương lai, hãy đánh giá lại giá trị của thiết kế lại sau đó. Nó có thể không bao giờ phá vỡ, đó sẽ là tuyệt vời. Dù bằng cách nào, bạn đang ở thời điểm hợp lý để đánh bạc rằng nó sẽ không bị phá vỡ, vì chi phí sẽ giống nhau ngay bây giờ hoặc sau này: rút ra, thiết kế lại khủng khiếp.

Những gì bạn cần làm trong tương lai là lặp đi lặp lại phát triển chặt chẽ hơn. Nếu bạn đã có thể xem lại mã này trước khi tất cả các công việc sửa lỗi đã được đầu tư, thì sẽ có ý nghĩa khi đề xuất thiết kế lại. Về cuối, sẽ không bao giờ có ý nghĩa để thực hiện tái cấu trúc lớn trừ khi mã được viết theo cách cơ bản không thể nhầm lẫn và bạn biết chắc chắn rằng mã sẽ cần phải được thay đổi ngay sau khi phát hành.

Đưa ra lựa chọn giữa hai tùy chọn (tái cấu trúc hoặc không tái cấu trúc), hãy suy nghĩ về âm thanh nào giống như bán thông minh hơn:

Này ông chủ, chúng tôi đã lên lịch và có mọi thứ hoạt động, nhưng bây giờ chúng tôi sẽ xây dựng lại rất nhiều thứ để chúng tôi có thể thêm tính năng X trong tương lai.

hoặc là

Này ông chủ, chúng tôi đã sẵn sàng để phát hành. Nếu chúng ta phải thêm tính năng X, chúng ta có thể mất thêm một vài ngày nữa.

Nếu bạn nói một trong hai, sếp của bạn có thể sẽ nói:

Ai nói gì về tính năng X?

Điểm mấu chốt là đôi khi một chút nợ kỹ thuật có ý nghĩa, nếu bạn không thể sửa một số sai sót nhất định khi nó rẻ (lặp lại sớm). Có thiết kế mã chất lượng có lợi nhuận giảm dần khi bạn đến gần hơn với một tính năng hoàn thành và thời hạn.

[Câu trả lời này rộng hơn một chút so với câu hỏi ban đầu, vì đây là chuyển hướng cho rất nhiều câu hỏi khác về đánh giá mã.]

Dưới đây là một số nguyên tắc tôi thấy hữu ích:

Chỉ trích riêng tư, khen ngợi công khai. Hãy cho ai đó biết về một lỗi trong mã của họ. Nếu họ đã làm một điều gì đó xuất sắc hoặc nhận một nhiệm vụ không ai muốn, hãy khen ngợi họ tại một cuộc họp nhóm hoặc trong một email gửi cho nhóm.

Chia sẻ những sai lầm của riêng bạn. Tôi chia sẻ câu chuyện về bài đánh giá mã đầu tiên tai hại của tôi (đã nhận được) với các sinh viên và đồng nghiệp cơ sở. Tôi cũng cho sinh viên biết rằng tôi đã bắt được lỗi của họ rất nhanh vì tôi đã tạo ra nó trước chính mình. Trong một đánh giá mã, điều này có thể xuất hiện như sau: "Tôi nghĩ rằng bạn đã sai các biến chỉ số ở đây. Tôi luôn kiểm tra xem vì đã đến lúc tôi nhận được các chỉ mục của mình sai và đưa xuống một trung tâm dữ liệu." [Vâng, đây là một câu chuyện có thật.]

Hãy nhớ bình luận tích cực. Một câu ngắn gọn "tốt đẹp!" hoặc "mánh khóe gọn gàng!" có thể làm cho ngày của một lập trình viên cơ sở hoặc không an toàn.

Giả sử người khác thông minh nhưng đôi khi bất cẩn. Đừng nói: "Làm thế nào để bạn mong đợi người gọi nhận được giá trị trả lại nếu bạn không thực sự trả lại?!" Nói: "Có vẻ như bạn đã quên tuyên bố trở lại." Hãy nhớ rằng bạn đã viết mã khủng khiếp trong những ngày đầu của bạn. Như ai đó đã từng nói, "Nếu bạn không xấu hổ về mã của mình từ một năm trước, thì bạn đã không học."

Lưu những lời mỉa mai / chế giễu cho bạn bè không ở nơi làm việc của bạn. Nếu mã là khủng khiếp khủng khiếp, hãy nói đùa về nó ở nơi khác. (Tôi thấy thuận tiện khi kết hôn với một lập trình viên đồng nghiệp.) Ví dụ, tôi sẽ không chia sẻ các phim hoạt hình sau (hoặc phim này ) với các đồng nghiệp của mình.

Khi một thìa đường giúp thuốc đi xuống và những gì sai có thể được diễn đạt ngắn gọn - không có 20 điều sai - tôi sẽ dẫn đến một hình thức gợi ý rằng tôi không có cổ phần, không có bản ngã đầu tư vào những gì tôi muốn được lắng nghe Thông thường đó là một cái gì đó như:

Tôi tự hỏi liệu có tốt hơn để ...

hoặc là

Liệu nó có ý nghĩa gì với ...

Nếu lý do khá rõ ràng, tôi không nói rõ. Điều này cho người khác cơ hội nhận một số quyền sở hữu trí tuệ của đề xuất, như trong:

"Vâng, đó là một ý tưởng tốt, bởi vì < lý do rõ ràng của bạn ở đây >."

Nếu sự cải thiện khá rõ ràng, nhưng không nhiều đến mức khiến tôi trông như một thằng ngốc vì không nghĩ đến nó, và lý do để thực hiện nó phản ánh một giá trị được chia sẻ với người nghe, thì đôi khi tôi thậm chí không đề xuất nó:

Tôi tự hỏi nếu có một cách để ... <tuyên bố giá trị được chia sẻ ở đây>

Điều này chỉ để đối phó với những người thực sự cảm động - với hầu hết các đồng nghiệp của tôi, tôi chỉ để họ có nó!

Đánh giá mã không phải luôn luôn nhằm mục đích cải thiện.

Một đánh giá gần cuối của một dự án dường như là trường hợp ở đây chỉ là để mọi người biết bắt đầu tìm kiếm ở đâu khi có lỗi (hoặc cho một dự án được thiết kế tốt hơn có thể có sẵn để sử dụng lại sau này). Dù kết quả của đánh giá là gì, đơn giản là không có thời gian để thay đổi bất cứ điều gì.

Để thực sự thay đổi, bạn cần thảo luận về mã và thiết kế sớm hơn nhiều trong dự án - mã dễ thay đổi hơn rất nhiều khi nó chỉ tồn tại như nói về các cách tiếp cận có thể.

Câu hỏi của bạn là "Làm thế nào để mã xem lại mã được thiết kế xấu?":

Câu trả lời IMO rất đơn giản. Nói về THIẾT KẾ mã và cách thiết kế bị lỗi hoặc không đáp ứng yêu cầu. Nếu bạn chỉ ra một thiết kế thiếu sót hoặc "không đáp ứng yêu cầu" thì nhà phát triển sẽ buộc phải thay đổi mã của mình vì nó không làm những gì nó cần làm.

Nếu mã "đủ chức năng" và / hoặc "đáp ứng thông số kỹ thuật" và / hoặc "đáp ứng yêu cầu":

Nếu bạn là người ngang hàng với nhà phát triển này, bạn không có bất kỳ quyền lực trực tiếp nào cho phép bạn "nói với anh ấy" để thực hiện thay đổi.

Có một vài lựa chọn còn lại cho bạn:

1. Bạn phải sử dụng "ảnh hưởng" cá nhân của riêng bạn (một dạng "sức mạnh" gián tiếp) và / hoặc khả năng của bạn là "thuyết phục"
2. tham gia vào nhóm "quy trình mã" của tổ chức của bạn và bắt đầu đặt "bảo trì mã" thành ưu tiên cao hơn.
3. Cắn viên đạn và tìm hiểu cách đọc mã crappy nhanh hơn / trôi chảy hơn để bạn không bị gác máy (có vẻ như bạn tiếp tục bị treo hoặc bị chậm khi gặp mã crappy) trên mã crappy.
   • Điều này cũng sẽ làm cho bạn một lập trình viên mạnh mẽ hơn.
   • Và nó sẽ cho phép bạn sửa mã crappy khi bạn đang làm việc với mã crappy.
   • Và điều này cũng sẽ cho phép bạn làm việc trên nhiều dự án hơn vì nhiều dự án có mã crappy có chức năng ... nhưng rất nhiều mã crappy.
4. Dẫn bằng ví dụ. Làm cho mã của bạn tốt hơn ... nhưng đừng cố gắng trở thành người cầu toàn.
   • Bởi vì sau đó bạn sẽ trở thành "kẻ chậm chạp không thể đáp ứng thời hạn, luôn chỉ trích và nghĩ rằng anh ta tốt hơn những người khác".

Tôi thấy không có viên đạn bạc. Bạn phải sử dụng cả ba và bạn phải sáng tạo trong cách sử dụng cả ba.

Trong trường hợp thiết kế tồi tệ, bạn nên tập trung vào việc tối đa hóa việc đóng gói . Theo cách đó, việc thay thế các lớp / tệp / chương trình con bằng các lớp được thiết kế tốt hơn sẽ trở nên dễ dàng hơn.

Tập trung vào việc đảm bảo rằng các giao diện công cộng của các thành phần được thiết kế tốt và các hoạt động bên trong được che giấu cẩn thận. Ngoài ra, các trình bao bọc lưu trữ dữ liệu là rất cần thiết. (Một lượng lớn dữ liệu được lưu trữ có thể rất khó thay đổi, vì vậy nếu bạn bị "triển khai chảy máu" vào các khu vực khác của hệ thống, bạn sẽ gặp rắc rối).

Khi bạn đã vượt qua các rào cản giữa các thành phần, hãy tập trung vào các thành phần có khả năng gây ra sự cố lớn nhất.

Lặp lại cho đến khi thời hạn hoặc cho đến khi hệ thống "hoàn hảo".

Thay vì chỉ trích trực tiếp về mã của ai đó, tốt hơn hết là bạn nên thể hiện trong các nhận xét của chúng tôi trong quá trình xem xét mã.

Một cách mà tôi làm theo là

1. nó sẽ là tối ưu nếu chúng ta làm theo cách này
2. Viết nó theo cách này sẽ làm cho nó chạy nhanh hơn.
3. Mã của bạn sẽ dễ đọc hơn nhiều nếu bạn thực hiện "này" "này" và "này"

Nhận xét như vậy sẽ được thực hiện nghiêm túc mặc dù thời hạn của bạn đang đến. Và có lẽ sẽ được thực hiện trong chu kỳ phát triển tiếp theo.

Đánh giá mã phải được tích hợp với chu trình phát triển và văn hóa để hoạt động. Không có khả năng lên lịch đánh giá mã lớn vào cuối quá trình phát triển tính năng X sẽ hoạt động. Trước hết, thực hiện các thay đổi sẽ khó hơn và ai đó có thể cảm thấy xấu hổ - tạo ra sự kháng cự đối với hoạt động.

Bạn nên có các cam kết sớm và thường xuyên, cùng với các đánh giá ở cấp độ cam kết. Với các công cụ phân tích mã tại chỗ, hầu hết các đánh giá sẽ nhanh chóng. Các công cụ phân tích / đánh giá mã tự động như FindBugs và PMD sẽ giúp bạn nhận được một lớp lớn các lỗi thiết kế ngoài cửa. Tuy nhiên, họ sẽ không giúp bạn giải quyết các vấn đề về cấp độ kiến ​​trúc để bạn phải có một thiết kế chắc chắn và đánh giá hệ thống tổng thể chống lại thiết kế đó.

Tăng chất lượng của các đánh giá mã.

Ngoài chất lượng của mã được xem xét, còn có một chất lượng như chính mã đánh giá:

• Là những thay đổi được đề xuất thực sự là một cải tiến so với hiện tại?
• Hay chỉ là vấn đề quan điểm?
• Trừ khi một cái gì đó rất rõ ràng, người đánh giá đã giải thích đúng, tại sao ?
• Mất bao lâu? (Tôi đã thấy các đánh giá kéo dài trong nhiều tháng, với nhà phát triển đang xem xét phụ trách để giải quyết tất cả các xung đột hợp nhất).
• Tấn?

Nó dễ dàng hơn nhiều để chấp nhận một đánh giá mã chất lượng tốt hơn so với một số chải chuốt bản ngã chủ yếu là nghi vấn.

Có hai vấn đề đáng chú ý trong câu hỏi, phần khéo léo và thời hạn sắp tới . Đây là những vấn đề riêng biệt - đầu tiên là một câu hỏi về truyền thông và động lực nhóm, thứ hai là một câu hỏi về lập kế hoạch và ưu tiên.

Chiến thuật . Tôi giả sử bạn muốn tránh bản ngã bị đẩy và phản hồi tiêu cực chống lại các đánh giá. Một số gợi ý:

• Có một sự hiểu biết chia sẻ về các tiêu chuẩn mã hóa và các nguyên tắc thiết kế.
• Không bao giờ chỉ trích hoặc đánh giá nhà phát triển , chỉ mã . Tránh từ "bạn" hoặc "mã của bạn", chỉ nói về mã đang được xem xét, tách ra khỏi bất kỳ nhà phát triển nào.
• Đặt niềm tự hào của bạn vào chất lượng của mã hoàn thành , để nhận xét đánh giá giúp cải thiện kết quả cuối cùng được đánh giá cao.
• Đề xuất cải tiến hơn là nhu cầu. Luôn có một cuộc đối thoại nếu bạn không đồng ý. Cố gắng hiểu quan điểm khác khi bạn không đồng ý.
• Có các đánh giá đi cả hai cách. Tức là có người bạn đã xem xét xem lại mã của bạn tiếp theo. Đừng có đánh giá "một chiều".

Phần thứ hai là ưu tiên . Bạn có nhiều đề xuất cải tiến, nhưng vì thời hạn đang đến gần nên chỉ có thời gian để áp dụng một vài.

Vâng, đầu tiên bạn muốn tránh điều này xảy ra ở nơi đầu tiên! Bạn làm điều này bằng cách thực hiện đánh giá liên tục, gia tăng. Đừng để nhà phát triển làm việc trong nhiều tuần trên một tính năng và sau đó xem lại tất cả vào lúc cuối cùng. Thứ hai, đánh giá mã và thời gian để thực hiện các đề xuất đánh giá nên là một phần của kế hoạch và ước tính thường xuyên cho bất kỳ nhiệm vụ nào. Nếu không có đủ thời gian để xem xét đúng, một cái gì đó đã sai trong kế hoạch.

Nhưng hãy giả sử có điều gì đó không ổn trong quy trình và hiện bạn đang phải đối mặt với một số nhận xét đánh giá và bạn không có thời gian để thực hiện tất cả. Bạn phải ưu tiên. Sau đó, hãy tìm những thay đổi sẽ khó nhất và rủi ro nhất để thay đổi sau này nếu bạn trì hoãn nó.

Việc đặt tên định danh trong mã nguồn là vô cùng quan trọng đối với khả năng đọc và bảo trì, nhưng nó cũng khá dễ dàng và ít rủi ro để thay đổi trong tương lai. Tương tự với định dạng mã. Vì vậy, đừng tập trung vào những thứ đó. Mặt khác, sự tỉnh táo của các giao diện tiếp xúc công khai nên được ưu tiên cao nhất, vì chúng thực sự khó thay đổi trong tương lai. Dữ liệu liên tục khó thay đổi - nếu bạn lần đầu tiên bắt đầu lưu trữ dữ liệu không nhất quán hoặc không đầy đủ trong cơ sở dữ liệu thì thực sự khó khắc phục trong tương lai.

Các khu vực được bao phủ bởi các bài kiểm tra đơn vị có rủi ro thấp. Bạn luôn có thể sửa những cái đó sau. Các khu vực không, nhưng có thể được thử nghiệm theo đơn vị có rủi ro thấp hơn các khu vực không thể được thử nghiệm theo đơn vị.

Giả sử bạn có một đoạn mã lớn mà không có kiểm tra đơn vị và tất cả các loại vấn đề về chất lượng mã bao gồm cả sự phụ thuộc được mã hóa cứng vào một dịch vụ bên ngoài. Thay vì tiêm phụ thuộc này, bạn làm cho đoạn mã có thể kiểm tra được. Điều này có nghĩa là trong tương lai bạn có thể thêm các bài kiểm tra và sau đó khắc phục phần còn lại của các vấn đề. Với sự phụ thuộc được mã hóa cứng, bạn thậm chí không thể thêm các bài kiểm tra. Vì vậy, đi sửa chữa này đầu tiên.

Nhưng hãy cố gắng tránh kết thúc trong kịch bản này ngay từ đầu!