Điều chỉnh quy tắc hướng đạo nam và tái cấu trúc cơ hội bằng các đánh giá mã

Tôi là một người tin tưởng tuyệt vời vào Quy tắc Hướng đạo nam :

Luôn luôn kiểm tra một mô-đun sạch hơn so với khi bạn kiểm tra nó. "Cho dù tác giả ban đầu là ai, nếu chúng ta luôn nỗ lực, dù nhỏ đến đâu, để cải thiện mô-đun. Kết quả sẽ thế nào? Tôi nghĩ nếu chúng ta Tất cả đều tuân theo quy tắc đơn giản đó, chúng ta sẽ thấy sự kết thúc của sự suy giảm không ngừng của các hệ thống phần mềm của chúng ta. Thay vào đó, các hệ thống của chúng ta sẽ dần dần tốt hơn khi chúng phát triển. Chúng ta cũng sẽ thấy các nhóm chăm sóc toàn bộ hệ thống. hơn là chỉ những cá nhân chăm sóc cho phần nhỏ bé của riêng họ.

Tôi cũng là một người tin tưởng tuyệt vời vào ý tưởng liên quan đến Tái cấu trúc cơ hội :

Mặc dù có những nơi cho một số nỗ lực tái cấu trúc theo lịch trình, tôi thích khuyến khích tái cấu trúc như một hoạt động cơ hội, được thực hiện bất cứ khi nào và bất cứ nơi nào mã cần được làm sạch - bởi bất cứ ai. Điều này có nghĩa là bất cứ lúc nào ai đó thấy một số mã không rõ ràng như vậy, họ nên tận dụng cơ hội để sửa nó ngay tại đó và sau đó - hoặc ít nhất là trong vài phút

Đặc biệt lưu ý đoạn trích sau từ bài viết tái cấu trúc:

Tôi cảnh giác với bất kỳ thực tiễn phát triển nào gây ra xích mích cho tái cấu trúc cơ hội ... Ý thức của tôi là hầu hết các đội không thực hiện tái cấu trúc đủ, vì vậy điều quan trọng là phải chú ý đến bất cứ điều gì khiến mọi người không khuyến khích. Để giúp loại bỏ điều này, hãy chú ý bất cứ lúc nào bạn cảm thấy nản lòng khi thực hiện một phép tái cấu trúc nhỏ, một điều mà bạn chắc chắn sẽ chỉ mất một hoặc hai phút. Bất kỳ rào cản như vậy là một mùi nên nhắc nhở một cuộc trò chuyện. Vì vậy, hãy ghi lại sự chán nản và đưa nó lên với đội. Ít nhất nó nên được thảo luận trong quá trình hồi tưởng tiếp theo của bạn.

Nơi tôi làm việc, có một thực tiễn phát triển gây ra ma sát nặng nề - Đánh giá mã (CR). Bất cứ khi nào tôi thay đổi bất cứ điều gì không nằm trong phạm vi "nhiệm vụ" của tôi, tôi đều bị những người đánh giá của tôi khiển trách rằng tôi đang thực hiện thay đổi khó hơn để xem xét. Điều này đặc biệt đúng khi tái cấu trúc có liên quan, vì nó làm cho việc so sánh khác biệt "theo từng dòng" trở nên khó khăn. Cách tiếp cận này là tiêu chuẩn ở đây, có nghĩa là tái cấu trúc cơ hội hiếm khi được thực hiện và chỉ tái cấu trúc "theo kế hoạch" (thường là quá ít, quá muộn), nếu có.

Tôi cho rằng các lợi ích là xứng đáng và 3 người đánh giá sẽ làm việc chăm chỉ hơn một chút (để thực sự hiểu mã trước và sau, thay vì nhìn vào phạm vi hẹp của các dòng thay đổi - bản thân đánh giá sẽ tốt hơn do chỉ có một mình ) để 100 nhà phát triển tiếp theo đọc và duy trì mã sẽ được hưởng lợi. Khi tôi trình bày lập luận này, những người đánh giá của tôi, họ nói rằng họ không có vấn đề gì với việc tái cấu trúc của tôi, miễn là nó không nằm trong cùng một CR. Tuy nhiên tôi khẳng định đây là một huyền thoại:

(1) Hầu hết các lần bạn chỉ nhận ra điều gì và cách bạn muốn cấu trúc lại khi bạn đang ở giữa nhiệm vụ. Như Martin Fowler nói:

Khi bạn thêm chức năng, bạn nhận ra rằng một số mã bạn đang thêm chứa một số trùng lặp với một số mã hiện có, vì vậy bạn cần cấu trúc lại mã hiện có để dọn dẹp mọi thứ ... Bạn có thể làm việc gì đó, nhưng nhận ra rằng nó sẽ hoạt động tốt hơn nếu sự tương tác với các lớp hiện tại đã được thay đổi. Hãy nắm lấy cơ hội đó để làm điều đó trước khi bạn xem xét bản thân mình.

(2) Không ai sẽ có vẻ thuận lợi khi bạn phát hành CR "tái cấu trúc" mà bạn không cần phải làm. CR có một chi phí nhất định và người quản lý của bạn không muốn bạn "lãng phí thời gian" vào việc tái cấu trúc. Khi nó đi kèm với thay đổi mà bạn phải làm, vấn đề này được giảm thiểu.

Vấn đề trở nên trầm trọng hơn bởi Resharper, vì mỗi tệp mới tôi thêm vào thay đổi (và tôi không thể biết trước chính xác tệp nào sẽ thay đổi) thường bị vấy bẩn bởi các lỗi và đề xuất - hầu hết đều được phát hiện và hoàn toàn xứng đáng sửa chữa

Kết quả cuối cùng là tôi thấy mã khủng khiếp, và tôi chỉ để nó ở đó. Trớ trêu thay, tôi cảm thấy rằng việc sửa mã như vậy không những không giúp cải thiện vị trí của tôi, mà còn thực sự hạ thấp họ và coi tôi là anh chàng "không tập trung", lãng phí thời gian để sửa chữa những thứ không ai quan tâm thay vì làm công việc của mình. Tôi cảm thấy tồi tệ về điều đó bởi vì tôi thực sự coi thường mã xấu và không thể đứng xem nó, chứ đừng nói đến việc gọi nó từ phương thức của tôi!

Bất kỳ suy nghĩ về làm thế nào tôi có thể khắc phục tình trạng này?

OK, vì vậy bây giờ có nhiều điều ở đây hơn là phù hợp cho một nhận xét.

tl; dr

Trực giác của bạn về những gì bạn nên làm (tái cấu trúc khi bạn đi) là chính xác.

Khó khăn của bạn khi thực hiện điều này - do bạn phải làm việc xung quanh một hệ thống đánh giá mã kém - gặp khó khăn khi thao túng mã nguồn và VCS của bạn. Nhiều người đã nói rằng bạn có thể và nên chia các thay đổi của mình (có, ngay cả trong các tệp) thành nhiều cam kết, nhưng bạn dường như gặp khó khăn khi tin vào điều này.

Bạn thực sự có thể làm điều này. Đó thực sự là những gì chúng tôi đề xuất. Bạn thực sự nên học cách tận dụng tối đa các công cụ chỉnh sửa, thao tác nguồn và kiểm soát phiên bản. Nếu bạn đầu tư thời gian vào việc học cách sử dụng chúng tốt, nó sẽ giúp cuộc sống dễ dàng hơn nhiều.

Vấn đề chính trị công việc / văn phòng

Về cơ bản, tôi đưa ra khuyến nghị giống như GlenH7 rằng bạn tạo hai cam kết - một cam kết chỉ tái cấu trúc và (rõ ràng hoặc rõ ràng) không có thay đổi chức năng và một với các thay đổi chức năng được đề cập.

Tuy nhiên, có thể hữu ích nếu bạn tìm thấy nhiều lỗi, để chọn một loại lỗi duy nhất để sửa trong một CR. Sau đó, bạn có một cam kết với một nhận xét như "mã khấu trừ", "sửa lỗi loại X" hoặc bất cứ điều gì. Bởi vì điều này tạo ra một loại thay đổi duy nhất, có lẽ ở nhiều nơi, nên nó không đáng để xem xét. Điều đó có nghĩa là bạn không thể sửa chữa mọi lỗi bạn tìm thấy, nhưng có thể làm cho nó bớt đau đớn hơn khi chuyển qua.

Các vấn đề về VCS

Việc chia các thay đổi được thực hiện cho nguồn làm việc của bạn thành nhiều cam kết không phải là một thách thức. Bạn chưa nói những gì bạn đang sử dụng, nhưng quy trình công việc có thể là:

1. nếu bạn đang sử dụng git, bạn có các công cụ tuyệt vời cho việc này

   • bạn có thể sử dụng git add -iđể dàn tương tác từ dòng lệnh
   • bạn có thể sử dụng git guivà chọn từng dòng và dòng riêng lẻ để tạo giai đoạn (đây là một trong số ít các công cụ GUI liên quan đến VCS tôi thực sự thích dòng lệnh, cái còn lại là trình soạn thảo hợp nhất 3 chiều)
   • bạn có thể thực hiện nhiều cam kết nhỏ (thay đổi riêng lẻ hoặc sửa cùng một loại lỗi ở nhiều nơi) và sau đó sắp xếp lại chúng, hợp nhất chúng hoặc chia chúng với rebase -i

2. nếu bạn không sử dụng git, VCS của bạn vẫn có thể có công cụ cho loại điều này, nhưng tôi không thể khuyên mà không biết bạn sử dụng hệ thống nào

   Bạn đã đề cập đến việc bạn đang sử dụng TFS - mà tôi tin là tương thích với git kể từ TFS2013. Có thể đáng thử nghiệm với việc sử dụng bản sao git cục bộ của repo để làm việc. Nếu điều này bị vô hiệu hóa hoặc không hoạt động cho bạn, bạn vẫn có thể nhập nguồn vào repo git cục bộ, làm việc ở đó và sử dụng nó để xuất khẩu cam kết cuối cùng của bạn.

3. bạn có thể thực hiện thủ công trong mọi VCS nếu bạn có quyền truy cập vào các công cụ cơ bản như diffvà patch. Nó đau đớn hơn, nhưng chắc chắn là có thể. Quy trình công việc cơ bản sẽ là:

   1. thực hiện tất cả các thay đổi của bạn, kiểm tra, vv
   2. sử dụng diffđể tạo tệp vá (ngữ cảnh hoặc hợp nhất) với tất cả các thay đổi kể từ lần xác nhận cuối cùng
   3. phân vùng thành hai tệp: bạn sẽ kết thúc với một tệp vá chứa tái cấu trúc và một tệp có thay đổi chức năng
      • điều này không hoàn toàn tầm thường - các công cụ như chế độ khác biệt của emacs có thể giúp ích
   4. sao lưu mọi thứ lên
   5. trở lại cam kết cuối cùng, sử dụng patchđể phát lại một trong các tệp vá, cam kết những thay đổi đó
      • Lưu ý nếu bản vá không được áp dụng sạch, bạn có thể cần phải sửa chữa các khối bị lỗi bằng tay
   6. lặp lại 5 cho tệp vá thứ hai

Bây giờ bạn có hai cam kết, với các thay đổi của bạn được phân vùng thích hợp.

Lưu ý có thể có các công cụ để quản lý bản vá này dễ dàng hơn - Tôi chỉ không sử dụng chúng vì git làm điều đó cho tôi.

Tôi sẽ giả định rằng Yêu cầu thay đổi là lớn và chính thức tại công ty của bạn. Nếu không, chỉ cần thực hiện các thay đổi (nếu có thể) thành nhiều cam kết nhỏ (như bạn được yêu cầu).

Bất kỳ suy nghĩ về làm thế nào tôi có thể khắc phục tình trạng này?

Tiếp tục làm những gì bạn đang làm?

Ý tôi là, tất cả những suy nghĩ và suy luận của bạn là hoàn toàn chính xác. Bạn nên sửa những thứ bạn nhìn thấy. Mọi người không lên kế hoạch tái cấu trúc đủ. Và lợi ích đó cho cả nhóm quan trọng hơn là làm phiền đến một số ít.

Những gì có thể giúp đỡ là ít chiến đấu. Các đánh giá về mã không nên mang tính chiến đấu "Tại sao bạn lại làm thế?", Họ nên hợp tác "Này các bạn, trong khi tôi ở đây tôi đã sửa tất cả những thứ này!". Làm việc (với người lãnh đạo / quản lý của bạn nếu có thể) để thay đổi văn hóa đó là khó khăn, nhưng khá quan trọng để tạo ra một nhóm phát triển chức năng cao.

Bạn cũng có thể làm việc (với người lãnh đạo / quản lý của mình nếu có thể) để nâng cao tầm quan trọng của những ý tưởng này với các đồng nghiệp của bạn. Làm cho bạn hỏi "tại sao các bạn không quan tâm đến chất lượng?" thay vì họ hỏi "tại sao bạn luôn làm những việc vô ích này?".

Tôi có nhiều thiện cảm với hoàn cảnh của bạn, nhưng ít gợi ý cụ thể. Nếu không có gì khác, có lẽ tôi sẽ thuyết phục bạn rằng tình huống tồi tệ như vậy, nó có thể tồi tệ hơn. Nó có thể LUÔN tệ hơn. :-)

Đầu tiên, tôi nghĩ bạn có (ít nhất) hai vấn đề với văn hóa của bạn, không chỉ một. Một vấn đề là cách tiếp cận tái cấu trúc, nhưng các đánh giá mã có vẻ như là một vấn đề khác biệt. Tôi sẽ cố gắng tách suy nghĩ của tôi.

Nhận xét mã

Tôi đã ở trong một nhóm mà mã HATED đánh giá. Nhóm được thành lập bằng cách sáp nhập hai nhóm từ các bộ phận riêng biệt của công ty. Tôi đến từ nhóm đã thực hiện đánh giá mã trong nhiều năm, với kết quả chung tốt. Hầu hết chúng ta tin rằng đánh giá mã là một cách sử dụng tốt thời gian của chúng tôi. Chúng tôi hợp nhất thành một nhóm lớn hơn và gần như chúng tôi có thể nói, nhóm "khác" đó thậm chí chưa bao giờ nghe về các đánh giá mã. Bây giờ tất cả chúng tôi đã làm việc trên cơ sở mã "của họ".

Mọi thứ đã không tốt khi chúng tôi sáp nhập. Các tính năng mới đã trễ 6-12 tháng, năm này qua năm khác. Các tồn đọng lỗi là rất lớn, đang phát triển và cạn kiệt cuộc sống. Quyền sở hữu mã là Mạnh, đặc biệt là trong số các "bậc thầy" cao cấp nhất. "Các nhánh tính năng" đôi khi kéo dài nhiều năm và kéo dài một vài bản phát hành; đôi khi NOBODY nhưng một nhà phát triển đã thấy mã trước khi nó chạm vào nhánh chính. Trên thực tế "nhánh tính năng" là sai lệch, vì nó cho thấy mã nằm ở đâu đó trong kho lưu trữ. Thông thường, nó chỉ có trên hệ thống cá nhân của nhà phát triển.

Ban quản lý đồng ý rằng chúng tôi cần phải "làm một cái gì đó" trước khi chất lượng trở nên thấp không thể chấp nhận được. :-) Câu trả lời của họ là Code Reviews. Code Reviews đã trở thành một mục "Thou Shalt" chính thức, trước mỗi lần đăng ký. Công cụ chúng tôi sử dụng là Bảng đánh giá.

Làm thế nào nó hoạt động trong văn hóa tôi mô tả? Tốt hơn là không có gì, nhưng thật đau đớn và mất hơn một năm để đạt được mức độ tuân thủ tối thiểu. Một số điều chúng tôi quan sát:

1. Công cụ bạn sử dụng có xu hướng tập trung đánh giá mã theo những cách nhất định. Đây có thể là một vấn đề. Bảng đánh giá cung cấp cho bạn các khác biệt đẹp, nhiều màu sắc và cho phép bạn đính kèm nhận xét vào một dòng. Điều này làm cho hầu hết các nhà phát triển bỏ qua tất cả các dòng không thay đổi. Điều đó tốt cho những thay đổi nhỏ, bị cô lập. Điều này không tốt cho những thay đổi lớn, khối lớn mã mới hoặc mã có 500 trường hợp của một chức năng được đổi tên trộn với 10 dòng chức năng mới.
2. Mặc dù chúng tôi đã ở trong một cơ sở mã cũ, bệnh hoạn mà hầu như chưa bao giờ được xem xét trước đó, nó trở nên "bất lịch sự" đối với người đánh giá nhận xét về bất cứ điều gì KHÔNG phải là một dòng thay đổi, thậm chí chỉ ra một lỗi rõ ràng. "Đừng làm phiền tôi, đây là một đăng ký quan trọng và tôi không có thời gian để sửa lỗi."
3. Mua một người đánh giá "dễ dàng". Một số người sẽ xem xét đánh giá 10 tệp với 2000 dòng thay đổi trong 3 phút và nhấp vào "Gửi nó!". Mọi người nhanh chóng biết những người đó là ai. Nếu bạn thực sự không muốn mã của mình được xem xét ở vị trí đầu tiên, hãy gửi mã cho người đánh giá "dễ dàng". Bạn đăng ký sẽ không bị chậm lại. Bạn có thể trả lại sự ủng hộ bằng cách trở thành người đánh giá "dễ dàng" cho mã của mình.
4. Nếu bạn ghét đánh giá mã, chỉ cần bỏ qua các email bạn nhận được từ Bảng đánh giá. Bỏ qua các theo dõi từ các thành viên trong nhóm của bạn. Cho vài tuần. Cho đến khi bạn có 3 tá đánh giá mở trong hàng đợi của bạn và tên của bạn xuất hiện trong các cuộc họp nhóm một vài lần. Sau đó trở thành một người đánh giá "dễ dàng" và xóa tất cả các đánh giá của bạn trước giờ ăn trưa.
5. Tránh gửi mã của bạn đến một người đánh giá "cứng". (Loại nhà phát triển sẽ hỏi hoặc trả lời một câu hỏi như thế này.) Mọi người nhanh chóng biết ai là người đánh giá "khó", giống như họ học những câu hỏi dễ. Nếu đánh giá mã là Lãng phí thời gian (™), thì đọc phản hồi chi tiết về mã mà bạn sở hữu vừa là Lãng phí thời gian (™) vừa là một sự xúc phạm.
6. Khi đánh giá mã là đau đớn, mọi người bỏ chúng đi và tiếp tục viết thêm mã. Bạn nhận được ít đánh giá mã hơn, nhưng mỗi cái là LỚN. Bạn cần nhiều hơn, đánh giá mã nhỏ hơn, có nghĩa là nhóm cần tìm ra cách làm cho chúng không đau nhất có thể.

Tôi nghĩ rằng tôi sẽ viết một vài đoạn về Code Reviews, nhưng hóa ra tôi chủ yếu viết về văn hóa. Tôi đoán nó hiểu rõ điều này: đánh giá mã có thể tốt cho một dự án, nhưng một nhóm chỉ nhận được những lợi ích mà họ xứng đáng nhận được.

Tái cấu trúc

Có phải nhóm của tôi coi thường việc tái cấu trúc thậm chí còn hơn cả việc đánh giá mã không? Tất nhiên! Đối với tất cả các lý do rõ ràng đã được đề cập. Bạn đang lãng phí thời gian của tôi với một bài đánh giá mã icky và bạn thậm chí không thêm một tính năng hoặc sửa lỗi!

Nhưng mã vẫn rất cần tái cấu trúc. Làm thế nào để tiến hành?

1. Không bao giờ trộn một thay đổi tái cấu trúc với một thay đổi chức năng. Một số người đã đề cập đến điểm này. Nếu đánh giá mã là một điểm ma sát, đừng tăng ma sát. Đó là công việc nhiều hơn, nhưng bạn nên lập kế hoạch đánh giá riêng và đăng ký riêng.
2. Khởi đầu nhỏ. Rất nhỏ. Thậm chí nhỏ hơn thế. Sử dụng các phép tái cấu trúc rất nhỏ để dần dần dạy mọi người rằng tái cấu trúc và đánh giá mã không phải là tội ác thuần túy. Nếu bạn có thể lẻn vào một lần tái cấu trúc nhỏ mỗi tuần mà không quá đau đớn, trong một vài tháng, bạn có thể thoát khỏi hai lần mỗi tuần. Và chúng có thể lớn hơn một chút. Có còn hơn không.
3. Về cơ bản chúng tôi KHÔNG có bài kiểm tra đơn vị. Vì vậy, tái cấu trúc bị cấm, phải không? Không cần thiết. Đối với một số thay đổi, trình biên dịch là bài kiểm tra đơn vị của bạn. Tập trung vào tái cấu trúc mà bạn có thể kiểm tra. Tránh thay đổi nếu chúng không thể được kiểm tra. Có thể dành thời gian viết bài kiểm tra đơn vị thay thế.
4. Một số nhà phát triển sợ tái cấu trúc vì họ sợ TẤT CẢ các thay đổi mã. Phải mất một thời gian dài tôi mới nhận ra loại này. Việc viết một đoạn mã, mân mê nó cho đến khi nó "hoạt động", và sau đó KHÔNG BAO GIỜ muốn thay đổi nó. Họ không nhất thiết phải hiểu TẠI SAO nó hoạt động. Thay đổi là rủi ro. Họ không tin tưởng bản thân để làm BẤT K change thay đổi nào và chắc chắn họ sẽ không tin bạn. Tái cấu trúc được cho là về những thay đổi nhỏ, an toàn không làm thay đổi hành vi. Có những nhà phát triển mà ý tưởng về "thay đổi không thay đổi hành vi" là không thể tưởng tượng được . Tôi không biết phải đề nghị gì trong những trường hợp này. Tôi nghĩ bạn phải cố gắng làm việc trong những lĩnh vực mà họ không quan tâm. Tôi đã rất ngạc nhiên khi biết rằng loại này có thể tồn tại lâu,

Tại sao bạn không làm cả hai, nhưng với các cam kết riêng biệt?

Đồng nghiệp của bạn có một điểm. Đánh giá mã nên đánh giá mã đã được thay đổi bởi người khác. Bạn không nên chạm vào mã mà bạn đang xem xét cho người khác vì điều đó làm sai lệch vai trò của bạn với tư cách là người đánh giá.

Nhưng nếu bạn thấy một số vấn đề rõ ràng, có hai lựa chọn bạn có thể làm theo.

1. Nếu đánh giá mã là tốt, phần cho phép phần bạn đã đánh giá được cam kết và sau đó cấu trúc lại mã theo đăng ký thứ hai.

2. Nếu đánh giá mã có vấn đề cần sửa, hãy yêu cầu nhà phát triển cấu trúc lại dựa trên các khuyến nghị của Resharper.

Cá nhân tôi ghét ý tưởng về bài viết đánh giá mã cam kết. Đánh giá mã nên xảy ra, khi bạn thực hiện thay đổi mã. Tất nhiên những gì tôi đang nói ở đây là lập trình cặp. Khi bạn ghép nối, bạn nhận được đánh giá miễn phí và bạn nhận được đánh giá mã tốt hơn. Bây giờ, tôi đang bày tỏ ý kiến ​​của mình ở đây, tôi biết những người khác chia sẻ điều này, có lẽ có những nghiên cứu chứng minh điều này.

Nếu bạn có thể khiến người đánh giá mã của mình ghép nối với bạn, yếu tố chiến đấu của đánh giá mã sẽ bốc hơi. Khi bạn bắt đầu thực hiện một thay đổi không được hiểu rõ, câu hỏi có thể được nêu ra tại điểm thay đổi, thảo luận và các lựa chọn thay thế được khám phá có thể dẫn đến tái cấu trúc tốt hơn. Bạn sẽ nhận được đánh giá mã chất lượng cao hơn vì cặp này sẽ có thể hiểu phạm vi thay đổi rộng hơn và không tập trung quá nhiều vào thay đổi từng dòng, đó là những gì bạn nhận được khi so sánh mã bên cạnh.

Tất nhiên đây không phải là câu trả lời trực tiếp cho vấn đề tái cấu trúc nằm ngoài phạm vi của sự thay đổi đang diễn ra nhưng tôi hy vọng rằng đồng nghiệp của bạn sẽ hiểu rõ hơn lý do đằng sau những thay đổi nếu họ ở đó khi bạn thực hiện thay đổi.

Bên cạnh đó, giả sử bạn đang thực hiện TDD hoặc một số hình thức tái cấu trúc màu xanh lá cây màu đỏ, một cách để đảm bảo rằng bạn có được sự tham gia từ bạn bè của mình là sử dụng kỹ thuật ghép nối bóng bàn. Giải thích một cách đơn giản là trình điều khiển được xoay theo từng bước của chu trình RGR, tức là cặp 1 viết một bài kiểm tra không thành công, cặp 2 sửa nó, cặp 1 bộ tái cấu trúc, cặp 2 viết một bài kiểm tra thất bại .... v.v.

Có lẽ vấn đề này phản ánh một vấn đề lớn hơn nhiều với văn hóa tổ chức. Mọi người dường như quan tâm đến việc làm "công việc của mình" hơn là làm cho sản phẩm tốt hơn, có lẽ công ty này có văn hóa "đổ lỗi" thay vì văn hóa thông tục và mọi người dường như quan tâm đến việc che đậy bản thân hơn là có tầm nhìn toàn bộ sản phẩm / công ty .

Theo tôi, bạn hoàn toàn đúng, những người xem lại mã của bạn hoàn toàn sai nếu họ phàn nàn vì bạn "chạm" vào những thứ bên ngoài "nhiệm vụ của bạn", hãy cố gắng thuyết phục những người đó nhưng đừng bao giờ chống lại nguyên tắc của bạn, đối với tôi đây là chất lượng quan trọng nhất của một chuyên gia thực sự.

Và nếu làm điều đúng đắn mang lại cho bạn những con số tồi trong cách đánh giá công việc ngu ngốc của bạn, thì vấn đề là gì?, Ai muốn "chiến thắng" trò chơi đánh giá này trong một công ty điên rồ?, Hãy thử thay đổi nó! bạn mệt mỏi, tìm một nơi khác, nhưng không bao giờ, không bao giờ trái với nguyên tắc của bạn, là điều tốt nhất bạn có.

Đôi khi, tái cấu trúc là một điều xấu. Tuy nhiên, không phải vì những lý do mà người đánh giá mã của bạn đưa ra; có vẻ như họ không thực sự quan tâm về chất lượng của mã này, và bạn làm cẩn thận, đó là tuyệt vời. Nhưng có hai lý do khiến bạn không thể tái cấu trúc : 1. Bạn không thể kiểm tra các thay đổi bạn đã thực hiện bằng kiểm tra tự động (kiểm tra đơn vị hoặc bất cứ điều gì) hoặc 2. Bạn đang thực hiện thay đổi đối với một số mã mà bạn không hiểu lắm tốt; tức là, bạn không có kiến ​​thức cụ thể về tên miền để biết những thay đổi bạn nên thực hiện.

1. Không tái cấu trúc khi bạn không thể kiểm tra các thay đổi bạn đã thực hiện bằng các kiểm tra tự động.

Người thực hiện đánh giá mã của bạn cần có khả năng chắc chắn rằng những thay đổi bạn đã thực hiện không phá vỡ bất cứ điều gì đã từng làm việc. Đây là lý do lớn nhất để lại mã làm việc một mình. Vâng, chắc chắn sẽ tốt hơn khi cấu trúc lại hàm dài 1000 dòng (đó thực sự là một sự ghê tởm!) Thành một loạt các chức năng, nhưng nếu bạn không thể tự động hóa các bài kiểm tra của mình thì thật khó để thuyết phục người khác rằng bạn đã làm mọi thứ đúng. Tôi chắc chắn đã phạm sai lầm này trước đây.

Trước khi tái cấu trúc, đảm bảo có các bài kiểm tra đơn vị. Nếu không có bài kiểm tra đơn vị, hãy viết một số! Sau đó, tái cấu trúc đi và người đánh giá mã của bạn sẽ không có lý do (hợp pháp) nào cho việc buồn bã.

Đừng cấu trúc lại các đoạn mã yêu cầu kiến ​​thức về Miền cụ thể mà bạn không có.

Nơi tôi làm việc có rất nhiều kỹ thuật hóa học - mã nặng. Cơ sở mã sử dụng các thành ngữ phổ biến cho các kỹ sư hóa học. Không bao giờ thực hiện các thay đổi là thành ngữ cho một lĩnh vực. Nó có vẻ như là một ý tưởng tuyệt vời để đổi tên một biến gọi xđến molarConcentration, nhưng đoán những gì? Trong tất cả các văn bản hóa học, nồng độ mol được biểu thị bằng một x. Đổi tên nó làm cho khó khăn hơn để biết những gì đang thực sự xảy ra trong mã cho những người trong lĩnh vực đó.

Thay vì đổi tên các biến thành ngữ, chỉ cần đặt bình luận giải thích chúng là gì. Nếu chúng không phải là thành ngữ, xin vui lòng đổi tên chúng. Đừng rời khỏi i, j, k, x, y,, vv nổi xung quanh khi tên tốt hơn sẽ làm việc.

Quy tắc viết tắt cho chữ viết tắt: nếu, khi mọi người đang nói, họ sử dụng một từ viết tắt, thì có thể sử dụng chữ viết tắt đó trong mã. Ví dụ từ cơ sở mã tại nơi làm việc:

Chúng tôi có các khái niệm sau đây mà chúng tôi luôn viết tắt khi nói về chúng: "Khu vực quan tâm" trở thành "AOC", "Vụ nổ đám mây Vapor" trở thành VCE, đại loại như thế. Trong cơ sở mã của chúng tôi, ai đó đã tái cấu trúc tất cả các trường hợp được gọi là aoc thành AreaOfConcern, VCE thành steamCloudExplumping, nPlanes để confiningPlanesCount ... khiến mã này thực sự khó đọc hơn đối với những người có kiến ​​thức về miền cụ thể. Tôi cũng có tội khi làm những việc như thế này.

Điều này có thể không thực sự áp dụng trong tình huống của bạn, nhưng có những suy nghĩ của tôi về vấn đề này.

Câu hỏi này hiện có hai vấn đề riêng biệt - dễ dàng xem xét các thay đổi trong đánh giá mã và thời gian dành cho tái cấu trúc.

Nơi tôi làm việc, có một thực tiễn phát triển gây ra ma sát nặng nề - Đánh giá mã (CR). Bất cứ khi nào tôi thay đổi bất cứ điều gì không nằm trong phạm vi "nhiệm vụ" của tôi, tôi đều bị những người đánh giá của tôi khiển trách rằng tôi đang thực hiện thay đổi khó hơn để xem xét.

Như các câu trả lời khác đã nói - bạn có thể tách các đăng ký tái cấu trúc khỏi các đăng ký thay đổi mã (không nhất thiết phải là các đánh giá riêng biệt) không? Tùy thuộc vào công cụ bạn đang sử dụng để thực hiện đánh giá mã, bạn sẽ chỉ có thể xem các khác biệt giữa các phiên bản cụ thể (Atlassian's Crucible chắc chắn thực hiện điều này).

(2) Không ai sẽ có vẻ thuận lợi khi bạn phát hành CR "tái cấu trúc" mà bạn không cần phải làm. CR có một chi phí nhất định và người quản lý của bạn không muốn bạn "lãng phí thời gian" vào việc tái cấu trúc. Khi nó đi kèm với thay đổi mà bạn phải làm, vấn đề này được giảm thiểu.

Nếu việc tái cấu trúc đơn giản và làm cho mã dễ hiểu hơn (đó là tất cả những gì bạn nên làm nếu nó chỉ là tái cấu trúc) thì việc đánh giá mã không nên mất nhiều thời gian để hoàn thành và nên lấy lại chi phí tối thiểu khi có ai đó phải đến và xem lại mã trong tương lai. Nếu các ông chủ của bạn không thể mò mẫm điều này thì bạn có thể cần nhẹ nhàng đưa họ tới một số tài nguyên thảo luận về lý do tại sao Quy tắc Hướng đạo nam dẫn đến mối quan hệ hiệu quả hơn với mã của bạn. Nếu bạn có thể thuyết phục họ rằng "lãng phí [thời gian] của bạn" bây giờ sẽ tiết kiệm gấp hai, năm hoặc mười lần sau này khi bạn / người khác quay lại để thực hiện nhiều công việc hơn về mã đó thì vấn đề của bạn sẽ biến mất.

Vấn đề trở nên trầm trọng hơn bởi Resharper, vì mỗi tệp mới tôi thêm vào thay đổi (và tôi không thể biết trước chính xác tệp nào sẽ thay đổi) thường bị vấy bẩn bởi các lỗi và đề xuất - hầu hết đều được phát hiện và hoàn toàn xứng đáng sửa chữa.

Bạn đã thử đưa những vấn đề này đến sự chú ý của đồng nghiệp và thảo luận về lý do tại sao chúng đáng để sửa chữa chưa? Và bất kỳ trong số chúng có thể được sửa chữa tự động (giả sử bạn có đủ phạm vi kiểm tra để xác nhận rằng bạn không bị hỏng đồ với tái cấu trúc tự động)? Đôi khi nó không "xứng đáng với thời gian của bạn" để thực hiện tái cấu trúc nếu nó thực sự là một thứ kén chọn. Toàn bộ nhóm của bạn có sử dụng ReSharper không? Nếu họ làm như vậy, bạn có chính sách chia sẻ về những cảnh báo / quy tắc nào đang được thi hành không? Nếu họ không, một lần nữa có lẽ bạn nên chứng minh nơi công cụ đang giúp bạn xác định các khu vực của mã là nguồn đau đớn có thể xảy ra trong tương lai.

Tôi có thể nhớ mã "dọn dẹp" 25 năm trước mà tôi tình cờ làm việc cho các mục đích khác, chủ yếu bằng cách định dạng lại các khối nhận xét và sắp xếp theo cột / sắp xếp cột để làm cho mã gọn gàng và do đó dễ hiểu hơn (không có thay đổi chức năng thực tế) . Tôi tình cờ thích mã đó gọn gàng và có trật tự. Vâng, các nhà phát triển cao cấp đã rất tức giận. Hóa ra họ đã sử dụng một số loại so sánh tệp (diff) để xem những gì đã thay đổi, so với các bản sao cá nhân của tệp, và bây giờ nó đã đưa ra tất cả các loại dương tính giả. Tôi nên đề cập rằng thư viện mã của chúng tôi nằm trên máy tính lớn và không có kiểm soát phiên bản - về cơ bản bạn đã ghi đè lên bất cứ thứ gì ở đó, và đó là nó.

Noi dung chinh cua cau chuyen? Tôi không biết. Tôi đoán rằng đôi khi bạn không thể làm hài lòng bất cứ ai trừ chính bạn. Tôi đã không lãng phí thời gian (trong mắt tôi) - mã được làm sạch dễ đọc và dễ hiểu hơn. Chỉ là các công cụ kiểm soát thay đổi nguyên thủy được sử dụng bởi những người khác đặt thêm một số công việc một lần vào chúng. Các công cụ quá thô sơ để bỏ qua không gian / tab và bình luận được chỉnh lại.

Nếu bạn có thể chia thay đổi được yêu cầu và bộ tái cấu trúc không được yêu cầu thành (rất nhiều) các cam kết riêng biệt, như được lưu ý bởi @Usless, @Telastyn và những người khác, thì đó là cách tốt nhất bạn có thể làm. Bạn vẫn sẽ làm việc trên một CR duy nhất mà không cần chi phí quản trị để tạo "tái cấu trúc". Chỉ cần giữ cam kết của bạn nhỏ và tập trung.

Thay vì cung cấp cho bạn một số lời khuyên trong cách thực hiện, tôi muốn chỉ cho bạn một lời giải thích lớn hơn nhiều (trên thực tế, một cuốn sách) từ một chuyên gia. Bằng cách này, bạn sẽ có thể học được nhiều hơn nữa. Đọc làm việc hiệu quả với Bộ luật kế thừa (của Michael Feathers) . Cuốn sách này có thể dạy bạn cách thực hiện tái cấu trúc, xen kẽ với các thay đổi chức năng.

Các chủ đề được bảo hiểm bao gồm:

• Hiểu các cơ chế thay đổi phần mềm: thêm tính năng, sửa lỗi, cải thiện thiết kế, tối ưu hóa hiệu suất
• Lấy mã kế thừa vào khai thác thử nghiệm
• Viết bài kiểm tra bảo vệ bạn khỏi giới thiệu các vấn đề mới
• Các kỹ thuật có thể được sử dụng với bất kỳ ngôn ngữ hoặc nền tảng nào với các ví dụ trong Java, C ++, C và C #
• Xác định chính xác nơi cần thay đổi mã
• Đối phó với các hệ thống cũ không hướng đối tượng
• Xử lý các ứng dụng dường như không có cấu trúc nào

Cuốn sách này cũng bao gồm một danh mục gồm hai mươi bốn kỹ thuật phá vỡ sự phụ thuộc giúp bạn làm việc với các yếu tố chương trình một cách cô lập và thực hiện các thay đổi an toàn hơn.

Tôi cũng là một người tin tưởng tuyệt vời vào Quy tắc Boyscout và Tái cấu trúc cơ hội. Vấn đề thường là trong việc mua quản lý. Tái cấu trúc đi kèm với cả rủi ro và chi phí. Những gì quản lý thường bỏ qua là nợ kỹ thuật cũng vậy.

Đó là bản chất con người. Chúng ta đã quen xử lý các vấn đề thực sự, không cố gắng ngăn chặn chúng. Chúng tôi phản ứng, không chủ động.

Phần mềm là vô hình và vì vậy thật khó để hiểu rằng, giống như một chiếc xe hơi, nó cần được bảo dưỡng. Không có người hợp lý sẽ mua một chiếc xe hơi và không bao giờ phục vụ nó. Chúng tôi chấp nhận rằng sơ suất như vậy sẽ làm giảm tuổi thọ của nó và về lâu dài, sẽ tốn kém hơn.

Mặc dù thực tế là nhiều nhà quản lý hiểu điều này, họ phải chịu trách nhiệm cho những thay đổi đối với mã sản xuất. Có những chính trị làm cho nó dễ dàng để lại một mình đủ tốt. Thường thì người cần sự thuyết phục thực sự ở trên người quản lý của bạn và anh ta chỉ đơn giản là không muốn đấu tranh để đưa "ý tưởng tuyệt vời" của bạn vào sản xuất.

Thành thật mà nói, người quản lý của bạn không phải lúc nào cũng bị thuyết phục rằng phương thuốc của bạn, trên thực tế, tuyệt vời như bạn nghĩ. (Dầu rắn?) Có kỹ năng bán hàng. Đó là công việc của bạn để giúp anh ta thấy được lợi ích.

Quản lý không chia sẻ ưu tiên của bạn. Đội mũ quản lý của bạn và nhìn bằng con mắt quản lý. Bạn sẽ có nhiều khả năng tìm thấy góc phù hợp. Kiên trì. Bạn sẽ thay đổi nhiều hơn bằng cách không cho phép phản hồi tiêu cực đầu tiên ngăn cản bạn.

Nếu bạn có thể chia thay đổi được yêu cầu và bộ tái cấu trúc không được yêu cầu thành hai yêu cầu thay đổi riêng biệt, như được lưu ý bởi @ GlenH7, thì đó là cách tốt nhất bạn có thể làm. Sau đó, bạn không phải là "chàng trai lãng phí thời gian" mà là "chàng trai làm việc chăm chỉ gấp đôi".

Nếu bạn thường thấy mình trong tình huống không thể phân tách chúng, bởi vì công việc được yêu cầu bây giờ cần bộ tái cấu trúc chưa được yêu cầu để biên dịch, tôi khuyên bạn nên nhấn mạnh vào việc có các công cụ để tự động kiểm tra các tiêu chuẩn mã hóa, sử dụng các đối số được nêu ở đây (Resharper cảnh báo về bản thân họ có thể là một ứng cử viên tốt, tôi không quen với nó). Các đối số đó đều hợp lệ, nhưng có một điểm bổ sung mà bạn có thể sử dụng cho lợi thế của mình: có các thử nghiệm đó ngay bây giờ khiến bạn có nhiệm vụ phải vượt qua các thử nghiệm trên mỗi cam kết.

Nếu công ty của bạn không muốn "lãng phí thời gian cho việc tái cấu trúc" (một dấu hiệu kém về phía họ), thì họ nên cung cấp cho bạn tệp "triệt tiêu cảnh báo" (mỗi công cụ có cơ chế riêng) để bạn không còn khó chịu nữa cảnh báo như vậy. Tôi nói điều này để cung cấp cho bạn các tùy chọn cho các tình huống khác nhau, thậm chí là trường hợp xấu nhất. Nó cũng tốt hơn để có các thỏa thuận được nêu rõ ràng giữa bạn và công ty của bạn, cũng về chất lượng mã dự kiến, thay vì các giả định ngầm định ở mỗi bên.