Làm thế nào tôi có thể được trả tiền để giảm nợ kỹ thuật?

Tôi hiện đang làm việc cho một công ty nhỏ có ít sản phẩm phức tạp về mặt kỹ thuật. Tôi là nhà phát triển duy nhất và duy nhất cho một trong số họ. Khoảng một năm trước, tôi đã có phiên bản kế thừa của sản phẩm và bắt đầu "hỗ trợ" nó.

Khách hàng chỉ nói về tính năng mới, giá trị kinh doanh và những thứ khác. Vấn đề là, mặc dù mã nằm trong C #, nhưng nó khá thủ tục. Không có sự trừu tượng hóa, các lớp chỉ được sử dụng khi Visual Studio yêu cầu chúng - ví dụ: Biểu mẫu. Việc triển khai các lớp này thực sự khủng khiếp và mã thực sự khó duy trì.

Trong cả năm nay, tôi dành thời gian riêng cho việc tái cấu trúc. Trong phiên bản mới nhất, có khá trừu tượng và như vậy. Tôi đã phải thực hiện lại một số thành phần từ đầu và tôi thực sự cảm thấy rằng việc thêm tính năng mới hoặc thay đổi hành vi cho các thành phần này dễ dàng hơn nhiều so với các thành phần khác.

Vấn đề là, tôi dành thời gian của riêng mình. Tôi thực sự thích kết quả, nhưng tôi không thích làm việc 12 giờ mỗi ngày. Bạn đã bao giờ đến tình huống tương tự? Tôi nên thử cái gì? Tôi đã thử thảo luận về nó, nhưng vẫn không thành công.

Tôi chỉ sợ thời điểm chúng tôi quyết định triển khai tính năng mới đòi hỏi nhiều thay đổi đối với mã kế thừa. Điều đó chỉ có thể gây sốc cho khách hàng: tại sao bạn cần 8 giờ để thay đổi các biểu tượng này? Khách hàng không quan tâm rằng có 500 địa điểm trong mã mà tôi cần thay đổi. Và tôi cũng nên tìm tất cả 500 địa điểm này trước.

Có ý kiến ​​gì không?

Bước 1: Ngừng làm việc ngoài giờ không được trả lương.

Bạn đã đào tạo khách hàng và người quản lý của mình trong một năm để tin rằng tốc độ phát triển hiện tại là điều nên được mong đợi. Đây là một phần lý do tại sao họ không hiểu tại sao một việc "đơn giản" có thể mất cả ngày để làm. Bạn không cần phải giữ chúng làm con tin và cố gắng làm tổn thương dự án. Nhưng bạn cần giải thích rằng kỳ vọng của họ quá cao và bạn cần một nhà phát triển khác hoặc nhiều thời gian hơn trước thời hạn. Đặt một điểm cần đề cập cụ thể đến người quản lý của bạn rằng bạn đã làm việc ngoài giờ không được trả lương và đang lên kế hoạch không làm việc đó nhiều như vậy. Ngay cả khi bạn cắt nó xuống còn 9 giờ, sự khác biệt sẽ được chú ý. Nếu người quản lý của bạn hỏi bạn tại sao bạn không hoàn thành công việc của mình, bạn có thể chỉ ra thực tế rằng bạn đã đưa ra một điểm để cảnh báo anh ta rằng đây sẽ là trường hợp.

Bước 2: Ghi chú

Chỉ vì bạn không có thời gian để thực hiện công việc, không có nghĩa là bạn không thể làm cho nó dễ dàng hơn khi công việc (hy vọng) được hoàn thành. Theo dõi các ý tưởng bạn có để sửa mã và đưa chúng vào các cuộc họp để những người khác nhận thức được mối quan tâm của bạn. Cuối cùng, bạn sẽ đạt được một bản vá chậm hoặc mọi người sẽ bắt đầu hiểu mối quan tâm của bạn có giá trị. Khi thời điểm này đến, bạn sẽ có một số ý tưởng cơ bản về những việc cần làm thay vì đến lúc khô ráo vì bạn đã không xem xét một phần mã trong một thời gian.

... Mã thực sự rất khó để duy trì.

Đây là cách của bạn trong quản lý. Chứng minh rằng chi phí "chỉ" sửa lỗi và thêm chức năng mới lớn hơn chi phí tái cấu trúc và viết lại mã.

Ví dụ: nếu với mã hiện tại, một tính năng mới sẽ mất 2 tuần để thêm và sau đó một lượng thời gian đáng kể để duy trì (ví dụ: 1 ngày một tuần), cho thấy rằng với việc tái cấu trúc trong một tuần, bạn có thể hoàn thành việc phát triển trong 1 1/2 tuần nhưng bạn sẽ cắt giảm bảo trì xuống còn 1 ngày một tháng (hoặc ít hơn). Những con số này sẽ cho thấy rằng những gì bạn đang làm là hiệu quả chi phí trong trung và dài hạn mặc dù có một chi phí ngắn hạn.

Mặc dù công ty có thể không thích tiêu tiền ngay bây giờ, nhưng họ sẽ thấy rằng lợi ích tiềm năng sẽ lớn hơn nhiều - tức là bạn sẽ làm việc hiệu quả hơn khi tạo ra nhiều mã hơn trong thời gian ngắn hơn và mã đó sẽ có chất lượng tốt hơn.

Áp dụng Quy tắc Hướng đạo Nam : Giữ mã gọn hơn một chút (nghĩa là có ít nợ kỹ thuật hơn) mỗi khi bạn chạm vào nó.

Dành thời gian để làm điều này trong tất cả các ước tính bạn đưa ra. Sau đó, kỳ diệu thay, theo thời gian, nợ kỹ thuật sẽ biến mất và bạn sẽ được trả tiền để làm điều đó.

Cách tiếp cận này là nhiều dễ dàng hơn một cách rõ ràng cố gắng để carve ra thời gian (và do đó thuyết phục khách hàng / quản lý được hưởng lương bổng) cho nợ kỹ thuật. Nó mang lại cho bạn cảm giác chuyên nghiệp hơn rất nhiều và "công việc được hoàn thành tốt". Và cuối cùng, khách hàng và người quản lý của bạn sẽ cảm ơn bạn vì điều đó trong thời gian dài, ngay cả khi họ không hiểu điều đó xảy ra như thế nào .....

Điều này ít nhiều là thực tế đáng buồn của lập trình bảo trì. Bạn bị mắc kẹt với những gì bạn được chỉ định duy trì và nếu người trả các hóa đơn không muốn trả cho những gì anh ta coi là thay đổi mà không có lợi ích, thì những thay đổi đó có xu hướng không được thực hiện.

Nếu bạn muốn thực hiện trường hợp nhận được các thay đổi này được tài trợ, thì hãy ghi nhật ký tất cả các địa điểm mà bạn phải thay đổi để cập nhật ngay cả đơn giản nhất. Sau một vài thay đổi, thảo luận về nhật ký đó với người quản lý của bạn. Nếu bạn có thể ghi lại nó, có một cơ hội (mặc dù rất mỏng) rằng người có chuỗi ví sẽ nhận ra rằng nó thực sự rẻ hơn trong thời gian dài để làm sạch mã ngay bây giờ vì nó sẽ làm thay đổi trong tương lai rẻ hơn.

Cơ hội bán hàng của bạn tăng lên càng lâu sản phẩm này dự kiến ​​sẽ được sử dụng. Tỷ lệ cược cũng tăng nếu một thất bại trong sản phẩm có khả năng gây ra vấn đề quan hệ công chúng cho khách hàng hoặc làm mất tiền của khách hàng.

Chặn điều đó, tìm hiểu những gì bạn có thể và chuyển sang một vị trí khác với ít bảo trì hơn.

Bạn cần cho quản lý của bạn thấy việc tái cấu trúc và cải thiện sản phẩm sẽ mang lại lợi ích gì cho công ty.

Khách hàng sẽ không quan tâm mã đó đẹp hay xấu miễn là nó hoạt động và quản lý sẽ không sẵn lòng giải thích cho khách hàng rằng những gì họ đã trả tiền được thiết kế kém và được triển khai kém. Đồng thời, ban quản lý sẽ không muốn ăn chi phí thời gian phát triển mà không cải thiện sản phẩm theo một cách có thể nhìn thấy (có thể xuất hóa đơn).

Vì vậy, ... bạn phải thuyết phục ban quản lý rằng những thay đổi bạn đề xuất sẽ giúp công ty:

• Cho họ thấy rằng một kiến ​​trúc tốt hơn sẽ cho phép bạn thêm các tính năng mới nhanh hơn.
• Giải thích rằng bằng cách tiếp tục đi dọc theo con đường hiện tại, họ sẽ vẽ mình vào một góc.
• Cho ví dụ về các thay đổi rất tốn kém để thực hiện trong hệ thống hiện tại, nhưng sẽ đơn giản và rẻ tiền với thiết kế tốt hơn.
• Theo dõi thời gian dành cho việc duy trì mã kế thừa so với việc thêm các tính năng có thể bán được. - Giúp họ giải thích cho khách hàng hiện tại và tương lai rằng mặc dù hệ thống hiện tại khá tốt, kiến ​​trúc mới, hiện đại hóa sẽ cho phép nhiều cải tiến mới tuyệt vời, độ tin cậy tốt hơn, v.v.
• Giảm thiểu rủi ro liên quan đến những thay đổi bạn đề xuất. Các nhà quản lý không thích rủi ro và việc quét các thay đổi đối với một hệ thống hiện có dường như có rủi ro.
  • Ưu tiên hiện đại hóa các thành phần khác nhau theo chi phí và lợi ích, và đảm bảo rằng quản lý đồng ý với các ưu tiên của bạn.
  • Sử dụng thử nghiệm đơn vị để giúp đảm bảo rằng các thành phần được hiện đại hóa sẽ tương thích với mã kế thừa còn lại.
• Theo dõi tiến trình của nỗ lực hiện đại hóa. Hiển thị lợi ích ngay khi bạn có thể hợp lý, nhưng nhắc nhở tất cả các bên rằng có nhiều việc phải làm.

Bạn có thể không nhận ra điều đó, nhưng Johnny Cash đã dự đoán phong trào tái cấu trúc và viết một bài hát về cách tốt nhất để tái cấu trúc một cơ sở mã lớn hiện có.

Tất nhiên, anh ta phải bọc nó trong một phép ẩn dụ ô tô để khán giả của anh ta có thể liên quan đến nó.

"One Piece tại một thời điểm" - Johnny Cash

Có vẻ như bạn có thể tính phí cho khách hàng trong thời gian thay đổi "nên" thực hiện và vẫn đưa ra CÁCH trước mắt trong thời gian dài.

Nếu bạn thích làm sạch mã (và có vẻ như bạn làm ít nhất một chút) thì hãy tiếp tục và tiếp tục làm nhưng đừng tự làm hỏng nó. Điều đó không làm bạn, công ty của bạn, hoặc khách hàng khác của bạn bất kỳ tốt.

Đảm bảo rằng quản lý của bạn và bất kỳ ai làm việc với khách hàng đều biết rằng mã không ở trạng thái tốt nhất để họ có thể đưa ra quyết định sáng suốt - chỉ vì bạn sở hữu mã đó không có nghĩa là bạn nên đưa ra quyết định kinh doanh về nó, nếu họ không nhận thức được các vấn đề với mã thì họ không thể thực hiện công việc của mình.

Mặc dù ứng dụng của khách hàng có một số nợ kỹ thuật, nhưng đừng quên, có lẽ họ đã bị tính phí với mức chiết khấu nhẹ. Họ có thể không nhận thức được điều này, nhưng đó là những gì xảy ra khi bạn trả giá thấp nhất.

Họ cần quyết định xem họ có muốn trả giá đầy đủ cho các thay đổi tính năng hoặc thực hiện mà không có chúng. Đó là sự lựa chọn của họ. Bạn có thể để họ đưa ra quyết định hoặc tiếp tục làm việc miễn phí. Bạn có thể thử và đề cập đến công việc dọn dẹp bạn đã làm và giảm giá nhẹ cho công việc đã hoàn thành. Một lần nữa, đó là sự lựa chọn của họ.

Cách tôi sẽ tiếp cận điều này là bắt đầu với việc giải thích khái niệm nợ kỹ thuật cho các ông chủ của bạn để đảm bảo họ có được nó. Tiếp cận nó từ một dòng dưới cùng, quan điểm kinh doanh. Mỗi lần họ yêu cầu một tính năng mới, khoản nợ kỹ thuật tích hợp trong sản phẩm sẽ ảnh hưởng đến hiệu quả của bạn và do đó, mỗi tính năng sẽ phải trả thêm một chút do khoản nợ này.

Khi họ hiểu bạn đang nói về điều gì, hãy cố gắng thương lượng một chút thời gian của bạn để giảm bớt nợ kỹ thuật. Tại công ty của tôi, chúng tôi đã thành công một cách hợp lý với việc kiến ​​nghị 10% thời gian của mỗi nhà phát triển để làm việc giảm nợ kỹ thuật.

Khi bạn đã dành thời gian để giải quyết vấn đề này, hãy đảm bảo rằng bạn thực sự sử dụng nó (và đừng chỉ làm thêm 10% để làm việc đó - hãy kiên trì với súng của bạn). Tạo một danh mục các khoản nợ kỹ thuật và ưu tiên chúng và bắt đầu khắc phục. Bạn phải ăn một con voi một lúc.

Và đừng quên yếu tố trong các công cụ tốt hơn. Resharper là một công cụ tái cấu trúc tuyệt vời cắm vào Visual Studio.