Làm cách nào để thuyết phục người quản lý của bạn rằng dự án của bạn cần tái cấu trúc?

Question

Tôi đã tham gia một dự án đường ray làm nhà thầu. Dự án đã kéo dài hơn một năm. Mã này được viết bởi khoảng 10 nhà phát triển khác nhau và hầu hết trong số họ là nhà thầu. Họ có phong cách mã khác nhau. Một số trong số họ đến từ Java. Mã có điểm số khủng khiếp với metric_fu. Nhiều chức năng rất dài (100 - 300 dòng). Một số hàm có số lượng chi nhánh, vòng lặp và các lần thu thập hợp lý. Mỗi yêu cầu tạo ra một tấn truy vấn sql. Hiệu suất là rất xấu. Nhiều mã lỗi thời không bao giờ được sử dụng nhưng không bao giờ có cơ hội được dọn dẹp. Kiến trúc cốt lõi là sai hoặc sai. Độ bao phủ mã chỉ khoảng 25%. Lượt xem và partials là hỗn loạn và khủng khiếp để đọc và hiểu.

Người quản lý ở vị trí cố gắng làm hài lòng Giám đốc điều hành bằng cách liên tục thêm các tính năng mới, tuy nhiên các tính năng mới ngày càng khó thực hiện đúng cách mà không vi phạm điều gì khác. Ông biết mã là xấu, nhưng không muốn đặt quá nhiều nỗ lực trong việc sửa chữa chúng như tái cấu trúc sẽ mất quá nhiều thời gian.

Là nhà thầu/nhà phát triển, cách tốt nhất để xóa tình huống này và thuận tiện cho Người quản lý hoặc Giám đốc điều hành phân vùng một thời gian để tái cấu trúc là gì?

Câu hỏi liên quan

How can I convince skeptical management and colleagues to allow refactoring of awful code?

How to refactor on a budget

Dealing with illogical managers

Answer 1

Trong experiance hạn chế của tôi:

1. Nó không thể thuyết phục một người quản lý rằng đó là cần thiết để dành thời gian để cấu trúc lại. Bạn có thể làm cho anh ta nhận thức được nó, và củng cố điểm mỗi khi bạn chạy vào một vấn đề vì mã xấu. Sau đó, chỉ cần di chuyển trên. Hy vọng rằng sếp của bạn sẽ tìm ra.

2. Khá phổ biến khi tham gia vào một dự án đang chạy và nghĩ "đây là tổng số rác". Cho nó một chút thời gian. Bạn có thể bắt đầu thấy một khuôn mẫu trong sự điên rồ.

Answer 2

Tôi đã ở trong tình trạng tương tự. Về cơ bản có chỉ có hai lựa chọn:

• Bạn nhận được một chút thời gian thư giãn và bạn có thể được cấp thời gian để cấu trúc lại một cái gì đó
• Do mã phát triển hơn nữa xấu của một số thành phần nói đến một gian hàng. Bạn không thể tiến hành thêm bất cứ thứ gì vì mọi thay đổi nhỏ đều khiến mọi thứ khác ngừng hoạt động. Trong trường hợp khẩn cấp này, bạn sẽ nhận được một "đi" với refactoring.

Tôi vừa trả lời trong một số câu hỏi khác, câu chuyện kinh dị của tôi:

https://stackoverflow.com/questions/1333077/dirty-coding-tricks-to-deliver-project-on-time/1333095#1333095

Tôi đã làm việc trên một dự án mà thủ đoạn bẩn là nguyên tắc lái xe chính của sự phát triển. Kim nói, sau một thời gian, những thủ đoạn này đã bắt đầu mâu thuẫn với nhau. Trong một thành phần phân tích, chúng tôi đã phải thực hiện thủ thuật rất bẩn thỉu khác - để che giấu những giá trị được tính toán đó do các mánh khóe xung đột không được tính toán đúng cách. Sau đó, các thủ đoạn cấp hai bắt đầu xung đột và chúng tôi phải tạo ra các thủ thuật để đối phó với những điều đó. Kể từ đó, ngay cả việc nhắc đến thành phần này cũng khiến tôi cảm thấy sợ hãi vì tôi có thể phải làm việc trên nó một lần nữa.

Đó chính xác là tình huống thứ hai khi tái cấu trúc là cách duy nhất.

Nói chung, nhiều người quản lý không có nền tảng kỹ thuật (thực ra, những người đến từ các lập trình viên xấu) cũng không quan tâm và hiểu giá trị của mã chất lượng và kiến ​​trúc tốt. Bạn không thể làm cho họ lắng nghe cho đến khi một cái gì đó làm gián đoạn kế hoạch của họ, như một đòn "không thể thực hiện" các tính năng, tăng và tái phát sinh lỗi, yêu cầu của khách hàng mà không thể hài lòng và như vậy.Chỉ sau đó sự hiểu biết về các vấn đề mã có thể đến lần đầu tiên. Thông thường, đã quá muộn rồi.

Answer 3

Tôi sẽ lấy một phần nhỏ của ứng dụng và được cấu trúc lại và tối ưu hóa nó 'cho đến khi nó tỏa sáng (và tôi sẽ làm điều đó trong thời gian cá nhân của mình để không làm phiền người quản lý của tôi). Sau đó, bạn sẽ có thể hiển thị người quản lý/Giám đốc điều hành của bạn kết quả tốt về tái cấu trúc và tối ưu hóa SQL.

Answer 4

Nếu có nhu cầu tái cấu trúc thì mã sẽ tự nói lên. Tái cấu trúc nhỏ có thể tiếp tục trong quá trình phát triển. Nếu bạn không thể thuyết phục người quản lý thì có lẽ bạn nên suy nghĩ lại nếu nó cần thiết.

Tuy nhiên, nếu điều đó là hoàn toàn cần thiết thì hãy xây dựng số liệu về hoạt động phát triển và lợi ích sẽ thuyết phục người quản lý.

Answer 5

Tôi nghĩ rằng một trong các tùy chọn sẽ là làm nổi bật Nếu dự án dự kiến ​​sẽ chạy dài hạn thì việc thực hiện các thay đổi ngay bây giờ sẽ giúp bạn tiết kiệm rõ ràng và các nhà phát triển khác trong tương lai.

Tốt nhất để sử dụng ví dụ về tính năng bạn đã làm việc để ước tính thời gian thực hiện nếu bạn có mã sạch hơn để hoạt động ngay từ đầu. Chúc may mắn!

Answer 6

Một điều khó khăn, gần đây tôi đã làm việc trong một công ty như vậy ... họ luôn luôn thúc đẩy những điều mới, một lần nữa họ biết điều đó là xấu, nhưng dù tôi có đẩy nó thế nào đi chăng nữa xác minh những phát hiện của tôi - họ thấy nó như một sự lãng phí thời gian.

Cuối cùng họ nhìn thấy ánh sáng ... nó chỉ mất nhiều sự cố máy chủ và tại một thời điểm gần như toàn bộ 8 ngày không có trang web để thuyết phục họ.

Thậm chí tại thời điểm đó, họ vẫn khẳng định 'phải' là dịch vụ lưu trữ.

Điều quan trọng là phải thử và định lượng khoảng thời gian trang web của họ sẽ kéo dài trước khi nó bẻ khóa và nhận được một số xác minh bên ngoài để giúp bạn trở lại - 'họ' luôn tin tưởng những người bên ngoài không biết gì về ứng dụng của bạn! Ngoài ra, hãy thử - nếu bạn có thể - để đưa ra một kế hoạch liên quan đến việc thay thế dần dần ở mức tồi tệ nhất, và một kế hoạch mất bao lâu để thực hiện theo cách đó. Ngoài ra một kế hoạch cho nếu 1 hoặc 2 cơ quan đã làm việc trên một viết lại hoàn toàn hwo dài nó có thể mất - nhưng phải thực tế quá hoặc nó sẽ bit bạn trong bum! Nếu bạn đi tuyến đường đó (đó là những gì chúng tôi đã làm) bạn vẫn có thể có một số công việc trên trang web hiện tại miễn là bạn kết hợp nó vào mới.

Answer 7

Tôi khuyên bạn nên tập trung vào những thứ mà họ có thể tự nhìn thấy, đó là, họ chắc chắn sẽ nhận thấy rằng ứng dụng chậm trong một số chức năng, vì vậy hãy chọn một trong số đó và nói điều gì đó như "Tôi có thể giảm thời gian chờ đợi ở đây, tôi có thể dành chút thời gian để cải thiện điều cụ thể này không? " (nhiều hơn cũng nói, nhưng bạn có điểm: P).Cũng xem xét rằng 10 nhà phát triển trước khi bạn không cấu trúc lại mã cơ sở, điều này có nghĩa là nó là một nhiệm vụ đơn điệu, có khả năng làm cho tình hình tồi tệ hơn, trong tình huống này nếu có điều gì đó sai sau khi tái cấu trúc, nó sẽ là của bạn lỗi nếu chương trình không hoạt động đúng cách nữa. Chỉ là một mặc dù, nhưng đáng xem xét.

Answer 8

Tôi đang ở cùng vị trí ngay bây giờ, nhưng với thỏa thuận với người quản lý rằng, khi tính năng mới nên được triển khai trong một số mô-đun hiện có để tái yếu tố mô-đun (nếu cần tính lại), chúng tôi đấu tranh ngay bây giờ với mã được tạo ra cách đây 4-5 năm và chắc chắn tôi phát hiện ra rằng việc mã hóa lại mã của người khác không phải là tầm thường cũng không thú vị, nhưng rất hữu ích cho việc tái sử dụng trong tương lai.

Answer 9

Mọi người đều đang thiếu một điểm ở đây:

Refactoring là một phần của chu trình phát triển phần mềm cuộc sống.

đây không chỉ là RoR hoặc bất kỳ dự án cụ thể nào mà là bất kỳ dự án phát triển phần mềm nào khác.

Nếu bằng cách nào đó bạn có thể thuyết phục PM why it is important to refactor cơ sở mã hiện tại của mình trước khi thêm bất kỳ tính năng mới nào, bạn đã hoàn tất. Bạn nên nói rõ với PM của bạn rằng bất kỳ bổ sung thêm tính năng mới mà không cần bất kỳ tái cấu trúc sẽ mất nhiều thời gian hơn yêu cầu. Và ngay cả khi tính năng được thêm vào, bằng cách nào đó, lỗi giải quyết các phiên sẽ mất nhiều thời gian hơn kể từ khi mã là rất bloat và unmaintainable.

Tôi thực sự không hiểu tại sao mọi người quên nguyên tắc tối ưu hóa sau này. Tối ưu hóa sau này cũng bao gồm refactor sau IMHO.

Một điều nữa, khi quyết định thiết kế, bạn nên nói với hậu quả, tốt hay xấu đối với PM của bạn rất rõ ràng.

Bạn có thể tạo một nhánh khác (giả sử bạn đang dùng git) để tái cấu trúc và bắt đầu thêm tính năng mới vào một số nhánh khác nếu PM của bạn nhấn mạnh thêm tính năng mới cùng với tái cấu trúc.

Answer 10

Mã tái cấu trúc mà hút là một phần của mã hóa, vì vậy bạn không cần phải được sự chấp thuận của bất kỳ ai trừ khi người quản lý của bạn đang xem mã và giờ RẤT chặt chẽ. Thời gian tôi lưu cấu trúc lại ngày hôm nay là thời gian mà tôi không phải lập hóa đơn để thực hiện các thủ thuật điên rồ để nhận mã bình thường để làm việc vào ngày mai (vì vậy nó hoạt động, cuối cùng).

Làm bùng nổ các phương thức thành các phương thức nhỏ hơn và xóa các phương pháp không được sử dụng là một phần công việc của bạn. Giảm cuộc gọi DB, trong mã mà bạn gọi, cũng là cần thiết để mã của bạn không hút. Một lần nữa, không thực sự tái cấu trúc, chỉ là mã hóa bình thường.

Thuyết phục người quản lý của bạn phụ thuộc vào các yếu tố khác, bao gồm (nhưng không giới hạn) khả năng thuyết phục của họ và khả năng thuyết phục của bạn.

Dù sao, việc tái cấu trúc khối lượng lớn trong RoR là gì? Ngay cả khi "kiến trúc lõi chỉ đơn giản là sai," nó thường có thể được thẳng ra từng chút một. Hãy chắc chắn rằng bạn phá vỡ nó thành khối/sử dụng các chi nhánh, do đó bạn không phá vỡ bất cứ điều gì trong khi bạn đang bận rộn sửa chữa.

Nếu điều này là không thể, sau đó bạn quay lại câu hỏi xã hội về cách thuyết phục người quản lý của bạn. Đó là một câu hỏi đơn giản để tìm ra những nút bấm của anh ta, và đẩy họ ra mà không bị sa thải hay bị bắt giữ.Shaming, giữ lại thức ăn, trao giải thưởng, là một người bạn, vô danh bắt cóc các mối đe dọa nơi bạn bước vào và tiết kiệm trong ngày ... Nó khá đơn giản, thực sự: sự sáng tạo là chìa khóa!