Làm thế nào tôi có thể thực hiện tái cấu trúc một ưu tiên cho nhóm của mình?

Cơ sở mã mà tôi làm việc hàng ngày không có kiểm tra tự động, đặt tên không nhất quán và hàng tấn bình luận như "Tại sao lại ở đây?", "Không chắc chắn nếu điều này là cần thiết" hay "Phương pháp này không được đặt tên đúng" và mã này bị vấy bẩn "Changelogs" mặc dù thực tế chúng tôi sử dụng kiểm soát nguồn. Chỉ cần nói rằng, cơ sở mã của chúng tôi có thể sử dụng tái cấu trúc.

Chúng tôi luôn có các nhiệm vụ để sửa lỗi hoặc thêm các tính năng mới, vì vậy không có thời gian để dành cho mã tái cấu trúc để trở nên tốt hơn và nhiều mô-đun hơn và dường như đó không phải là ưu tiên cao.

Làm thế nào tôi có thể chứng minh giá trị của tái cấu trúc sao cho nó được thêm vào danh sách nhiệm vụ của chúng tôi? Có đáng để chỉ tái cấu trúc khi tôi đi, yêu cầu sự tha thứ chứ không phải là sự cho phép?

"Thà xin tha thứ còn hơn xin phép" là đúng.

Tại sao phải lo lắng về nó? Chỉ cần cấu trúc lại những phần kinh khủng nhất.

Bạn đã biết những lỗi tốn kém nhất là gì, phải không?

Nếu bạn không, thì bước 1 là xác định một cách tích cực và rõ ràng mã vấn đề tốn kém nhất, phức tạp, có lỗi, bị lỗi.

Xác định số lượng vé rắc rối, giờ gỡ lỗi và các chi phí rất cụ thể, rất có thể đo lường khác .

Sau đó sửa một cái gì đó trong danh sách các vấn đề chi phí cao .

Khi bạn phải yêu cầu sự tha thứ, bạn có thể chỉ ra việc giảm chi phí.

Trong trường hợp bạn không biết, tái cấu trúc yêu cầu kiểm tra đơn vị để chứng minh rằng các hành vi trước và sau khớp với nhau. Lý tưởng nhất, đây phải là một bài kiểm tra tự động, được mã hóa, ví dụ, một bài kiểm tra đơn vị.

Điều này có nghĩa là chọn một điều. Viết một bài kiểm tra đơn vị. Sửa một điều đó. Bạn đã thực hiện hai cải tiến. (1) đã viết một bài kiểm tra và (2) đã sửa mã.

Lặp đi lặp lại.

Thực hiện theo quy tắc trinh sát cậu bé: rời khỏi khu cắm trại (mã) tốt hơn một chút so với bạn tìm thấy nó. Tôi chưa bao giờ nghe nói về việc ai đó được viết ra để thực hiện các cải tiến mã nhỏ "trong khi họ ở đó".

Tôi sẽ có một quan điểm có lẽ quá cay độc.

Tái cấu trúc là một viên thuốc khó nuốt. Bạn nhận trách nhiệm và đổ lỗi, và thành quả lao động của bạn thường thuộc về người khác xây dựng trên cơ sở mã sạch của bạn.

Tôi sẽ nói rằng nếu thực hành kỹ thuật như vậy đã trở thành văn hóa tại công ty của bạn, bạn có thể cần phải chiến đấu ở cấp độ cao hơn. Bạn không thực sự đấu tranh để tái cấu trúc, bạn đang chiến đấu vì sự xuất sắc của kỹ thuật và đó là loại thay đổi chỉ làm sáng tỏ quản lý khi nó đánh vào mặt họ. Trong kịch bản đó, có lẽ họ sẽ tìm kiếm một vị hoàng đế thực hành tốt nhất và tất cả những ý tưởng tuyệt vời của bạn sẽ được giảm bớt.

Xem xét tham gia một công ty khác, nơi họ thực hiện kỹ thuật nghiêm túc hơn.

Tôi nhận thấy rằng nhiều áp phích ở đây dường như bị thuyết phục rằng vấn đề trong quản lý - trong khi câu hỏi không đề cập đến điều đó.

Tôi sẽ đi xa hơn thế: theo tôi, một cơ sở mã tệ hại gần như không bao giờ là lỗi trực tiếp của quản lý. Quản lý đã không viết mã đó, các nhà phát triển đã làm (có một số trường hợp ngoại lệ tại công ty của tôi, nơi một số quản lý hiện tại của chúng tôi thực sự đã viết cơ sở mã ban đầu). Do đó, vấn đề văn hóa nằm ở các nhà phát triển - nếu họ muốn văn hóa thay đổi, chính họ sẽ phải thay đổi.

Tôi cũng cố gắng mang lại nhận thức này và thay đổi thái độ đối với các nhà phát triển "của tôi". Bất cứ khi nào họ hỏi tôi "khi nào chúng ta sẽ có thời gian để cấu trúc lại?", Tôi tỏ ra ngạc nhiên và trả lời "bạn nên tái cấu trúc mọi lúc!". Cách duy nhất tôi tin rằng bạn có thể giữ cho một cơ sở mã khỏe mạnh là ba lần:

1. Chỉ bao giờ thêm mã lành mạnh.
2. Luôn luôn sửa mã không lành mạnh ngay khi bạn nhìn thấy nó.
3. Nếu vì lý do thời hạn, bạn không thể thực hiện 1 hoặc 2, hãy luôn có một danh sách các vấn đề "khắc phục ngay sau thời hạn" và không chấp nhận bất kỳ lý do nào để không làm việc trong danh sách đó sau thời hạn.

Luôn luôn nhận xét tiếp theo từ các nhà phát triển là "nhưng làm thế nào để chúng ta có thời gian để làm điều này - chúng ta không có thời gian bây giờ?". Câu trả lời đúng duy nhất (một lần nữa IMHO) là "bạn không có thời gian KHÔNG làm điều này." Nếu bạn không giữ codebase khỏe mạnh, bạn sẽ thấy thời gian quay vòng ngày càng dài hơn, lịch trình trở nên khó lường hơn, lỗi ngày càng khó khăn và giá trị ngày càng thấp.

Sự thay đổi thái độ lớn nhất bạn cần có trong nhóm phát triển là "chất lượng" không phải là thứ bạn làm vào một thời điểm cụ thể ("khi chúng ta có thời gian để tái cấu trúc") - đó là điều bạn phải làm TẤT CẢ mọi lúc.

Cuối cùng, một câu chuyện cảnh báo. Nếu bị ép, tôi sẽ phủ nhận điều này từng xảy ra. Tại một công ty tôi làm việc cho một ứng dụng lâu đời với một cơ sở mã lớn, có nguồn gốc từ hơn 10 năm trước. Rất nhiều nhà phát triển bao gồm cả tôi tin rằng cơ sở mã di sản này là xấu hoặc ít nhất là lỗi thời, không phải là hiện đại. Vì vậy, chúng tôi vận động cho một dự án tái cấu trúc lớn thành công và bắt đầu dự án viết lại sau đó chúng tôi tin rằng mọi thứ sẽ tốt hơn.
Chúng tôi đã làm việc lâu dài và chăm chỉ thực hiện hầu hết mọi thứ theo một cách mới và hiện đại, sử dụng các thư viện mới, các tính năng ngôn ngữ mới. Gần cuối, chúng tôi đã nỗ lực hết sức để kết hợp mọi thứ lại với nhau để cho phép phát hành mới ứng dụng lâu đời với cơ sở mã mới và được cải tiến.
Như dự kiến, bản phát hành mới có một số vấn đề về mọc răng, vì các thư viện mới mà chúng ta chưa quen thuộc và một số tương tác trong mã của chúng tôi mà chúng tôi không lường trước được. Tuy nhiên, cuối cùng chúng tôi đã có được bản phát hành theo cùng tiêu chuẩn với bản phát hành trước đó và ra khỏi cửa. Chúng tôi thở phào nhẹ nhõm trước "thành công" của mình. Sau đó, một nhóm các nhà phát triển đã quay lại quản lý, yêu cầu một dự án tái cấu trúc mới bởi vì mã mới của chúng tôi không phải là viên đạn bạc mà họ mong đợi, và họ đã thấy một số cơ hội để viết lại một số thứ ...

Đạo đức của câu chuyện: thường mọi thứ gần như không bị phá vỡ như chúng có vẻ như, và 'bắt đầu lại' thường có nghĩa là bạn sẽ trao đổi một tập hợp các vấn đề đã biết với một tập hợp các vấn đề ít nhất là không rõ ràng. Tái cấu trúc một phần tại một thời điểm!

Ai đó đã từng nói với tôi rằng khi tôi đi phỏng vấn, tôi không nên quên rằng tôi cũng đang phỏng vấn công ty. Đây có phải là nơi tôi muốn làm việc không? Họ có đánh giá mã không? Họ có kiểm tra tích hợp tự động? Bài kiểm tra đơn vị? Họ nghĩ gì về lập trình cặp? Cá nhân tôi sẽ tìm một công việc khác và đừng quên hỏi một số câu hỏi quá lần này.

Tìm một công ty khác, trung thực. Những cải tiến như vậy đối với quá trình phát triển đòi hỏi những bước nhảy lớn về văn hóa mà sẽ mất nhiều thời gian trước khi mọi người vào cùng một trang và sau đó bạn sẽ không được quan tâm nhiều.

Nếu bạn cảm thấy như bạn vẫn còn một số trận chiến trong bạn và chưa đi đến đâu, thì hãy thực hiện một cú hích cuối cùng. Cố gắng nhận được nhiều sự hỗ trợ từ các thành viên trong nhóm có cùng chí hướng, tiết lộ sự mệt mỏi của bạn với cấp trên, những người quan tâm đến sức khỏe của bạn, bỏ qua hoàn toàn và tránh xa bất cứ ai có thể phản đối niềm tin của bạn và cố gắng đẩy mạnh một số giờ tái cấu trúc bắt buộc lên kế hoạch mới dự án / tính năng.

Nếu bạn đam mê những gì bạn làm và quan tâm đến công ty của bạn, đó sẽ là một nỗ lực đáng khen ngợi về phía bạn. Nếu nó không được đánh giá cao, thì hãy tôn trọng chính mình và bảo lãnh trước khi bạn biến thành một lập trình viên rỗng.

Nếu tôi phải giới thiệu một thực hành để làm cho mọi thứ tốt hơn trong loại bối cảnh này, đó sẽ là các đánh giá mã. Mã đánh giá là

• thường được các nhà phát triển chấp nhận một cách trực giác như một yếu tố để mã tốt hơn, ít lỗi hơn, v.v.
• hợp tác và dân chủ
• không quá tốn thời gian nếu bạn timebox chúng đúng cách
• một nơi tốt để thực hiện tái cấu trúc nếu bạn không có thời gian để làm như vậy trong quá trình phát triển "bình thường"
• một con ngựa thành Troia khá hiệu quả để dần dần giới thiệu tất cả các loại thực tiễn tốt nhất về thiết kế mã, thử nghiệm đơn vị ...

Bạn không phải thực hiện đánh giá mã một cách có hệ thống, chỉ khi cam kết các phần mã lớn / phức tạp lúc đầu.

Tất nhiên, nếu bạn cảm thấy cần chứng thực chính thức trước khi đưa ra các đánh giá mã, bạn có thể phải thuyết phục sếp của mình trước rằng cơ sở mã có khả năng sụp đổ nếu mọi thứ còn lại như cũ.

Dưới đây là những gì tôi làm trong những tình huống như vậy (trong 15 năm làm nghề phát triển tôi đã bắt gặp mã như vậy mỗi ngày)

1. Dẫn dắt bằng ví dụ - Tôi đảm bảo tính lại mã mà tôi chạm vào. Tôi tàn nhẫn xóa mã nhận xét cũ và các đoạn bình luận lớn.
2. Yêu cầu bao thanh toán lại mỗi khi tôi được yêu cầu xem lại thay đổi mã, mà không có tôi không chấp nhận đánh giá mã.
3. Mọi người dần dần nhìn thấy sự thay đổi, khi mã trở nên gọn gàng hơn, dễ đọc hơn và do đó ít lỗi hơn. Phải mất thời gian nhưng dần dần cả nhóm đánh giá cao và áp dụng thực hành.

Ban quản lý không bao giờ dành thời gian cho việc tái xác nhận mã (họ không bao giờ có đủ tài nguyên!), Vì vậy thực hiện nó chậm và đều đặn là một cách tiếp cận đúng đắn.

Có quản lý làm một số nghiên cứu về "nợ kỹ thuật". Cũng tham khảo chúng cho "Lý thuyết cửa sổ bị vỡ", cả hai hiệu ứng này đều có tác động trực tiếp đến hiệu quả, chất lượng và tinh thần.

"Một nơi làm việc sạch sẽ là một nơi làm việc an toàn và hiệu quả", và mọi đóng góp cho một mớ hỗn độn tạo thành mớ hỗn độn theo kiểu hàm mũ, không phải là tuyến tính.

Nếu tình huống không được xử lý, cuối cùng bạn sẽ vượt qua điểm không thể quay lại, nơi nó trở nên không khả thi về mặt kinh tế, bằng cách xử lý dần dần trước khi điều đó xảy ra, lợi ích sẽ tăng trở lại, giúp bạn có thêm nhiên liệu để giải quyết vấn đề khi bạn đi.

Có vẻ như vấn đề của bạn là chung chung hơn.
Vấn đề tái cấu trúc vừa là một triệu chứng vừa là một cứu cánh tiềm năng từ một phần của vấn đề.

Trưởng nhóm phần mềm và Nhóm phân bổ thời gian của nhóm

Từ kinh nghiệm của tôi, tôi nghĩ rằng bạn có thể gặp phải một vấn đề mà tôi gọi là "mọi người đều là người quản lý phần mềm." Người quản lý sản phẩm, người quản lý dự án và đôi khi là kỹ sư hệ thống và người kiểm tra có thể nổi tiếng vì đã cố gắng quản lý các nhà phát triển vi mô có thể đã có người quản lý phần mềm có kinh nghiệm. Bạn thậm chí có thể có một vài thành viên trong nhóm của bạn tin rằng vai trò của họ là quản lý.

Nếu bạn là người quản lý phần mềm, hãy thực hiện các bài tập cho việc tái cấu trúc mà bạn muốn hoặc tốt hơn là yêu cầu nhóm của bạn đề xuất tái cấu trúc cho bạn để bạn chấp thuận. Vì vậy, để không vi mô, bạn có thể có các hướng dẫn về tuổi / tác giả / kích thước / bối cảnh của mã được tái cấu trúc có thể được tái cấu trúc tự do so với cần phê duyệt. Nếu một thành viên trong nhóm của bạn muốn tái cấu trúc ồ ạt bốn lớp mã cũ phức tạp mà anh ta không viết mà không phải là một phần của tính năng của anh ta, thì việc chuyển hướng hai tuần của anh ta là vấn đề của bạn, vì vậy bạn cần có cơ hội để nói không.

Bạn có thể lén lút, nhưng tôi nghĩ tốt hơn là chỉ nên xây dựng các ước tính của mình một cách cẩn thận với thời gian để phân tích, thiết kế, mã hóa, nhiều hình thức kiểm tra (ít nhất là đơn vị và tích hợp), tái cấu trúc và rủi ro như được đánh giá trong lịch sử và do thiếu kinh nghiệm hoặc sự rõ ràng liên quan đến nhiệm vụ. Nếu bạn đã quá cởi mở về hoạt động của nhóm của bạn (hoặc có thành viên trong nhóm của bạn), có lẽ nên thu hẹp các kênh liên lạc để họ đi qua bạn và thảo luận về tài nguyên và kết quả, chứ không phải phương pháp.

Lựa chọn dự án sớm Tạo ra một chu kỳ hữu ích cho tái cấu trúc

Bảo trì phần mềm là khó. Thật khó khăn gấp đôi nếu những người khác trong tổ chức đang đưa ra lựa chọn bằng chi phí của bạn. Điều này là sai, nhưng nó không phải là mới. Nó đã được giải quyết bởi Barry Boehm, một trong những nhà văn phần mềm tuyệt vời của chúng tôi, người đưa ra một mô hình quản lý mà ông mô tả là Theory W.

http://csse.usc.edu/csse/TECHRPTS/1989/usccse89-500/usccse89-500.pdf

Thông thường các nhà phát triển phần mềm bị cấm sản xuất theo phương pháp quản lý Theory-X nói rằng công nhân về cơ bản là lười biếng và sẽ không thực hiện trừ khi bị dồn nén. Boehm tóm tắt và đối chiếu mô hình đề xuất của mình như sau:

"Thay vì mô tả người quản lý là người chuyên quyền (Theory X), huấn luyện viên (Theory Y) hoặc người điều phối (Theory Z), Theory W mô tả vai trò chính của người quản lý là người đàm phán giữa các khu vực bầu cử khác nhau của anh ấy và người đóng gói các giải pháp dự án Với điều kiện thắng cho tất cả các bên. Ngoài ra, người quản lý còn là người thiết lập mục tiêu, theo dõi tiến trình hướng tới mục tiêu và là nhà hoạt động trong việc tìm kiếm các xung đột dự án thắng-thua hoặc thua-thua hàng ngày, đối đầu với họ, và thay đổi chúng thành các tình huống đôi bên cùng có lợi. "

Nhanh và bẩn thường chỉ là bẩn

Boehm tiếp tục chỉ ra lý do mọi thứ rất tồi tệ cho các nhà phát triển trong nhóm bảo trì.

"Xây dựng một sản phẩm nhanh và cẩu thả có thể là một trò chơi win win ngắn hạn, chi phí thấp cho nhà phát triển phần mềm và khách hàng, nhưng nó sẽ là một '' mất '' cho người dùng và người bảo trì." Xin lưu ý rằng trong mô hình của Boehm, khách hàng là quản trị viên hợp đồng nhiều hơn là người dùng cuối. Trong hầu hết các công ty, hãy nghĩ về người quản lý sản phẩm như một người thay thế khách hàng, hoặc có lẽ là người mua sản phẩm cho danh sách tính năng của nó.

Giải pháp của tôi là không phát hành nhóm phát triển ban đầu (hoặc ít nhất là khách hàng tiềm năng ban đầu) cho đến khi mã được tái cấu trúc để ít nhất đáp ứng các tiêu chuẩn mã hóa.

Đối với khách hàng, tôi nghĩ thật hợp lý khi coi người quản lý sản phẩm là người thay thế khách hàng và nhóm người được khen thưởng vì đã cung cấp một thứ gì đó nhanh chóng và bẩn thỉu chắc chắn có thể được mở rộng, do đó có một cử tri lớn để làm mọi thứ sai cách.

Tái cấu trúc không phải là Thỏa thuận

Vui lòng không rút lui khỏi vai trò là người quản lý phần mềm. Bạn nên có thẩm quyền và toàn quyền sử dụng thời gian của nhóm trong quá trình cải tiến sản phẩm và quy trình. Trong vai trò đó, bạn có thể cần phải thương lượng các lựa chọn của mình để làm cho nhóm của bạn chuyên nghiệp hơn. Tuy nhiên, liên quan đến quá trình, đừng đàm phán với tiếp thị, bởi vì theo kinh nghiệm của tôi, đó là một trò chơi thua. Đàm phán với quản lý kỹ thuật. Nó cho thấy bạn có tầm nhìn. Xây dựng một nhóm phần mềm chuyên nghiệp là một phần mở rộng vai trò của họ, và nhiều khả năng được coi là một chiến thắng cùng có lợi.

Bạn luôn luôn có thể chờ đợi nó ra. Cuối cùng, nhóm sẽ bỏ lỡ đủ thời hạn và tạo ra phần mềm đủ lỗi, quản lý đó sẽ giơ tay và nói rằng bởi Chúa, một cái gì đó đã thay đổi tốt hơn!

Được rồi, đó là một đề xuất rủi ro. Nhưng đó thực sự là những gì đã xảy ra tại cửa hàng của chúng tôi vài năm trước (một phần khó khăn trong việc liên lạc với quản lý về thời hạn, nhưng đó là một câu chuyện khác), và đó là lý do chúng tôi hiện có hàng chục ngàn bài kiểm tra tự động, quyền sở hữu mã được chia sẻ, tự do tái cấu trúc, sẵn sàng xóa mã chết và các bản phát hành chất lượng cao nhất mà chúng tôi từng có.

Có lẽ đáng ngạc nhiên nhất, không ai mất việc trong quá trình này - điều mà tôi tin tưởng vào ông chủ của chúng tôi đến với chúng tôi, và một nhà tư vấn đã tranh luận về trường hợp tái cấu trúc và liên tục thay mặt chúng tôi. Nó luôn luôn có vẻ thuyết phục hơn khi có ai đó từ bên ngoài nói điều đó.

Tôi nghĩ câu trả lời cho cách tìm thời gian phụ thuộc vào lý do tại sao bạn muốn cấu trúc lại mã.

Nếu nó hoạt động, không cần bộ tái cấu trúc đặc biệt và bạn có thể làm điều đó khi bạn chạm vào phần mã đó. Vì vậy, bạn không cần thời gian đặc biệt cho việc đó.

Nếu nó làm chậm sự phát triển nhóm của bạn, bạn cần nói chuyện với trưởng nhóm về điều đó và tạo ra nhiệm vụ đặc biệt để tái cấu trúc và bạn sẽ có thời gian.

Tương tự đối với tốc độ chạy và các trường hợp khác, nếu bộ tái cấu trúc có thể cải thiện một cái gì đó và không chỉ "tìm kiếm mã tốt" hoặc ý kiến ​​của bạn về cách thức mã, và cung cấp lợi ích thực sự, tạo nhiệm vụ hoặc nói chuyện với ai đó chịu trách nhiệm về điều đó.

Tôi đã cười một chút về cách bạn mô tả mọi thứ vì nghe có vẻ khá giống với cơ sở mã mà tôi làm việc nên tôi nghĩ các tình huống của chúng tôi khá giống nhau. May mắn thay, trong tình huống của tôi, tôi có một người quản lý có tư duy tiến bộ đã quyết định cách tốt nhất để làm cho cơ sở mã tốt hơn là thông qua mô đun hóa bằng cách sử dụng khung phát triển web hiện đại thay vì chỉ cấu trúc lại toàn bộ cơ sở mã. Bằng cách này, các điểm rắc rối của ứng dụng chính có thể được viết lại thành các mô-đun riêng biệt và sau đó được tích hợp vào ứng dụng chính (nhưng về cơ bản vẫn độc lập). Đây có thể là một cách tiếp cận mà bạn muốn đưa ra vì nó sẽ không yêu cầu tái cấu trúc toàn bộ cơ sở mã (có lẽ lớn?) Mà bạn đang làm việc.

Tất nhiên, tôi có thể hơi lạc lõng với những gì bạn đang nói vì có lẽ cơ sở mã của bạn không tệ như tôi làm việc cùng, trong trường hợp đó tôi sẽ nói tại sao không thực hiện tối ưu hóa khi bạn đi cùng? Các nhà phát triển trong nhóm của tôi không gặp vấn đề gì trong việc loại bỏ những bình luận ngu ngốc hoặc lỗi thời và những thứ thuộc về bản chất đó và tôi không nghĩ rằng đó là thứ cần phải có từ quản lý vì thông thường các nhà phát triển được trao quyền để tối ưu hóa mọi thứ khi cần.

Nếu cơ sở mã thực sự mong manh thì bạn cần phải cẩn thận và đây có thể là lý do tại sao họ không muốn theo đuổi tái cấu trúc lớn vì điều này có thể sẽ biến thành một dự án dài hàng tháng và có thể sẽ yêu cầu phân nhánh dự án và đưa dev vào đó dự án và lấy đi từ các nhiệm vụ phát triển khác, như sửa lỗi ngay lập tức có thể khiến họ mất khách hàng, v.v.

Tất cả mọi thứ được xem xét, theo như những người khác nói bạn nên bỏ, v.v., tôi nghĩ nó phụ thuộc vào cách quản lý nhìn nhận mọi thứ, nếu họ hiểu tình hình và nhận ra lý do tại sao một số thứ có thể mất nhiều thời gian hơn họ, thì mọi thứ có thể ổn xa như môi trường làm việc, nhưng nếu họ liên tục làm phiền bạn về một công việc tồn đọng, điều đó có thể trở nên bất lợi theo thời gian. Tôi may mắn có được quản lý về cơ bản nhận ra ứng dụng này là một thứ nhảm nhí, nhưng nó có rất nhiều khách hàng và mang lại tiền, vì vậy nó vẫn có giá trị và đáng để sửa lỗi, ngay cả khi chỉ trong thời gian ngắn .

Vấn đề chính của bạn là các mã không đủ tầm nhìn.

Tôi cố gắng sử dụng một công cụ tích hợp liên tục như Jenkins và một công cụ analisys mã tĩnh được tích hợp với nó để đo độ phức tạp theo chu kỳ, tiêu chuẩn đặt tên, độ dài mã, v.v.

Khi một lập trình viên cam kết thay đổi, Jenkins sẽ chạy các bài kiểm tra đơn vị, chạy công cụ analisys mã tĩnh trên đó và tạo một báo cáo web mà mọi người có thể nhìn thấy, với trạng thái màu giống như đèn giao thông.

Khi chất lượng mã được hiển thị cho tất cả mọi người (đặc biệt là người quản lý nhóm và ông chủ) và kiểm soát phiên bản và kiểm tra đơn vị sẽ có mặt sau của bạn ... mọi người cảm thấy được khuyến khích tái cấu trúc.

Mã có cách này từ từ qua nhiều thay đổi nhỏ. Nó sẽ cần phải sửa theo cách đó quá.

Bạn có thể làm điều này khi bạn thực hiện, trước hết - tăng tất cả các ước tính lên 10% để cho phép tăng cường mã và bảo trì dài hạn. Nếu bất cứ ai phàn nàn hãy hỏi họ rằng tốt hơn nên kiểm tra dầu trong động cơ xe mỗi tuần hoặc đợi cho đến khi động cơ hoàn toàn khóa lại.

Có một cuộc họp và xác định các tiêu chuẩn mã hóa nhất quán.

Giới thiệu các quy tắc cơ bản để sử dụng khi bạn đi cùng:

Bất cứ khi nào mã mới được đưa vào một lớp kiểm tra tự động phải được viết để chứng minh lớp hoạt động (không chỉ mã mới).

Bất cứ khi nào một lỗi được sửa lỗi, các bài kiểm tra tự động phải được viết để chứng minh lớp hoạt động (không chỉ là mã cố định).

Bất cứ khi nào lập trình viên sửa đổi một tệp, anh ta phải sửa tất cả các cảnh báo của trình biên dịch trong tệp đó và cập nhật mã để nó đáp ứng các tiêu chuẩn mã hóa mới.

Sau một thời gian, mã được sử dụng nhiều nhất sẽ được cập nhật và được bao phủ bởi các thử nghiệm tự động. Mã cũ hơn sẽ được cập nhật khi nó được thay đổi, nếu nó không bao giờ thay đổi thì bạn không bao giờ phải lo lắng về nó.

Điều quan trọng là xây dựng những thói quen này thành các nhiệm vụ mã hóa tiêu chuẩn để không ai trong số họ mất một khoảng thời gian lớn để làm việc 'thực sự' nhưng tất cả đều mang lại lợi ích thực sự. Đừng cố gắng thực hiện một dự án từ việc tái cấu trúc mã cũ, đó là một nỗi đau khủng khiếp, nhàm chán, khó hiểu sẽ trông giống như rất nhiều thời gian lãng phí cho những người không có kỹ thuật!

Cách để có được tài nguyên (thời gian) bạn cần là tập trung vào khả năng sắp xếp và mong muốn. Sếp của bạn được điều khiển bởi các mục tiêu (thường là lợi nhuận hoặc thời gian giao hàng cho các tính năng mới) và anh ta thấy tái cấu trúc khi các kỹ sư lãng phí thời gian và ăn vào các mục tiêu đó. Bạn cần tìm cách thuyết phục anh ta rằng các mục tiêu sẽ được đáp ứng và vượt quá nếu bạn dành thời gian tái cấu trúc.

Vì vậy, bước đầu tiên là tìm hiểu nỗi đau mà ông chủ của bạn đang cảm thấy. Xác định những vấn đề lớn nhất của anh ấy là gì. Sau đó tìm hiểu làm thế nào những gì bạn muốn làm phù hợp với việc khắc phục vấn đề của anh ấy, và trình bày một trường hợp kinh doanh mạnh mẽ để làm điều đó. Sử dụng bạn khiếm khuyết theo dõi và hệ thống lập kế hoạch dự án (vượt thời gian) để cung cấp bằng chứng về vấn đề nằm ở đâu. Bạn cần sự thật, không phải cảm xúc. Không có số liệu (số lỗi / mô-đun, chi phí để sửa những lỗi này), tái cấu trúc chỉ là một lập trình viên chơi với chi phí của ai đó. Sếp của bạn sẽ chỉ cung cấp cho bạn các tài nguyên cần thiết nếu bạn có thể hiển thị trường hợp kinh doanh mạnh mẽ để thực hiện.

Mã crap thường không quá đắt để sửa. Không có kiểm tra hồi quy tự động, chi phí kiểm tra mã tái cấu trúc là cực kỳ cao.

Hầu hết tôi đã thấy mã xấu trong nhu cầu tái cấu trúc thực sự, có một số lượng lớn các tính năng và sự phức tạp không có giấy tờ trong các yêu cầu không thể hiểu được ngay từ đầu. Đó không phải là một công việc nhỏ và kinh nghiệm của tôi là một thứ tự lớn hơn để ước tính chi phí của một công việc tái cấu trúc hơn là thêm một tính năng mới.

Tôi sẽ không tiếp tục tiến lên và làm điều đó phía sau các ông chủ của bạn (Nếu nó không bị hỏng và bạn đã phá vỡ nó, trông nó thế nào) - sửa mã cần thay đổi, nhưng nếu nó không bị hỏng, đừng ' T sửa nó.

Kỳ lạ thay, không ai đề cập đến điều này:

Để làm cho mọi thứ được ưu tiên, làm cho chúng dễ dàng: Có được một công cụ tái cấu trúc tốt.

Có những công cụ tái cấu trúc tuyệt vời ngoài kia (ít nhất là cho .NET afaik). Ồ, và đừng quên viết bài kiểm tra đơn vị trước đó (như những người khác đã chỉ ra).

Chúc may mắn!