it-swarm-vi.com

Làm thế nào tôi có thể thuyết phục ban quản lý xử lý nợ kỹ thuật?

Đây là một câu hỏi mà tôi thường tự hỏi khi làm việc với các nhà phát triển. Cho đến nay tôi đã làm việc tại bốn công ty và tôi nhận thấy sự thiếu chú ý trong việc giữ sạch mã và xử lý nợ kỹ thuật cản trở tiến trình trong tương lai trong một ứng dụng phần mềm. Ví dụ, công ty đầu tiên tôi làm việc đã viết một cơ sở dữ liệu từ đầu thay vì sử dụng một cái gì đó như MySQL và điều đó đã tạo ra địa ngục cho nhóm khi tái cấu trúc hoặc mở rộng ứng dụng. Tôi đã luôn cố gắng trung thực và rõ ràng với người quản lý của mình khi anh ấy thảo luận về các dự đoán, nhưng quản lý dường như không quan tâm đến việc sửa chữa những gì đã có và thật kinh khủng khi thấy tác động của nó đối với tinh thần đồng đội.

Suy nghĩ của bạn về cách tốt nhất để giải quyết vấn đề này là gì? Những gì tôi đã thấy là mọi người đóng gói và rời đi. Công ty sau đó trở thành một cánh cửa quay vòng với các nhà phát triển ra vào và làm cho mã trở nên tồi tệ hơn. Làm thế nào để bạn truyền đạt điều này đến quản lý để khiến họ quan tâm đến việc phân loại nợ kỹ thuật ?

164
Desolate Planet

Khi tôi gặp ông chủ của mình để thảo luận về vấn đề này, ông nói rằng tôi nên bao gồm việc tái cấu trúc trong tất cả các ước tính của mình. Anh ấy nói đó không phải là vấn đề anh ấy muốn nghĩ đến. Thay vào đó, tôi nên xử lý nó.

Đây không phải là một vấn đề mà quản lý nói chung muốn nghĩ đến. Họ không phải là kỹ sư. Chỉ cần biến điều này thành một phần chưa được nói trong tất cả các ước tính của bạn và bạn sẽ thấy rằng nợ kỹ thuật giảm.

Nó sẽ không bao giờ hoàn hảo mặc dù. Nợ kỹ thuật, giống như nợ thẻ tín dụng, là một khoản đầu tư để có được khách hàng nhanh hơn và giành thị phần so với đối thủ của bạn nhanh hơn. Giống như tín dụng, nếu được quản lý đúng cách, nó có thể khiến bạn khá thành công.

194
jmort253

Giống như Gandhi đã nói khi được hỏi liệu chiến thuật của anh ta có hiệu quả với một người như Hitler không. Ông nói, "Nó sẽ khó khăn." Nhưng tôi nghĩ có một lập luận công bằng rằng câu trả lời thực sự là "Không". Đáng buồn thay, tôi không nghĩ những gì bạn đang cố gắng có thể được thực hiện. Không phải là tôi đang cố tỏ ra bi quan, mà là tôi đang cố thành thật.

Vấn đề với tôi không phải là các nhà quản lý cần thuyết phục. Những người tốt hơn đã hiểu rằng nợ có thể là một kẻ giết người nếu không được quản lý. Nhưng cho dù họ có hiểu hay không, dù họ là người quản lý tốt hay xấu, tất cả họ đều phải đối mặt với áp lực giao hàng, và việc giao hàng đó được đánh giá bởi ông chủ của họ trước một ngày. Chất lượng chỉ quan trọng nếu nó cực kỳ tệ, trong trường hợp đó là lỗi của nhà phát triển, hoặc cực kỳ tốt, trong trường hợp đó là sự sáng chói trong quản lý đã khiến điều đó xảy ra. Chất lượng chỉ cần là "đủ tốt."

Tôi nghĩ rằng tôi thích những gì Renesis nói trong câu trả lời của anh ấy, bởi vì đó là một trong số ít người hiểu rằng quản lý nghĩ rất khác so với kỹ thuật. Và tôi nghĩ rằng tất cả chúng ta đã thấy sự phát triển của các công ty để trở thành định hướng theo ngày và được quản lý dự án nhiều hơn so với khách hàng và chất lượng tập trung. Bằng cách này, ý tôi là các công ty điển hình, không phải là những công ty thực sự mạnh mẽ có can đảm để nói "Nó sẽ được thực hiện khi nó hoàn thành" (như Apple Phần mềm máy tính hoặc id - và vâng, tôi hiểu rằng đôi khi mọi người không được tự do thực hiện phương pháp đó).

Nhưng đây là điều: các công ty thực hiện phương pháp chất lượng đầu tiên ... bạn chú ý điều gì về họ? Đúng vậy, họ được điều hành bởi các kỹ sư, không phải nhân viên bán hàng, tiếp thị, quản lý dự án hoặc kế toán. Hãy nghĩ về HP, Apple, id, Google, Microsoft và IBM. Tất cả bắt đầu và thành công bởi các kỹ sư, không phải nhân viên bán hàng, mặc dù nhân viên bán hàng chắc chắn đã đóng góp một phần và tôi chắc chắn nhiều người sẽ tranh luận về việc Microsoft có liên quan đến chất lượng :). Và trong số đó, những người đã xuống dốc đã thoát khỏi sự lãnh đạo theo hướng kỹ thuật. Mặc dù vậy, có rất nhiều tranh luận trong tuyên bố đó, vì có rất nhiều công ty kỹ thuật cuối cùng đã thất bại do không thể thích nghi với việc thay đổi thời gian và quản lý sự tăng trưởng của chính họ. Tôi không thấy lãnh đạo dựa trên kỹ thuật là nguyên nhân cho những thất bại đó, với tôi đó là vấn đề về kỹ năng và sự nhạy bén trong kinh doanh, độc lập với ai đó là nhà phát triển hoặc kế toán. Tôi nghĩ nói chung, tuy nhiên, có một sự cống hiến trong kỹ thuật cho sự nghiêm ngặt của trách nhiệm và kỷ luật có lợi cho các công ty nơi kỹ thuật là một thành phần.

Nghiêm túc, nhìn xung quanh. Lãnh đạo CNTT đang rất thiếu. Tập trung luôn là chi phí và thời gian, và hiếm khi về chất lượng miễn là nó đủ tốt. Các nhà lãnh đạo CNTT hiếm khi báo cáo với CEO nữa, giờ đây luôn là CFO. CNTT bị mắc kẹt trong việc hỗ trợ sản xuất và ngày càng chú ý đến các nhà quản lý dự án, những người tập trung vào các phần nhỏ hơn, dễ tiêu hóa hơn và có thể đo lường được, không thay đổi đáng kể giá trị cách mạng (không phải điều này là sai; chia rẽ và chinh phục là một điều tốt, nhưng tầm nhìn cần phải có mặt cho bức tranh lớn).

Xin lỗi vì mất quá nhiều thời gian cho bài đăng này, nhưng cuối cùng tôi nghĩ câu hỏi của bạn, về cách làm cho quản lý quan tâm đến nợ kỹ thuật, thường được giải quyết tốt hơn bằng cách tìm đúng người lãnh đạo, thay vì thay đổi người hiện có. Giải thích nợ kỹ thuật cho các nhà tư tưởng tiêu chuẩn có nghĩa là thay đổi trọng tâm thành tiền và chi phí, như Renesis đã nói, và tôi nghĩ rằng mất rất nhiều trong dịch thuật; ngay cả khi bạn đã thành công với nó, nó sẽ chỉ quan trọng nếu nhà lãnh đạo cao nhất trong công ty mua nó. Thuyết phục người quản lý cấp trung của bạn làm điều đúng đắn có lẽ sẽ chỉ khiến anh ta bị sa thải.

48
Bernard Dy

Điều đầu tiên cần làm là thay đổi từ ngữ. Gọi nó là "nợ kỹ thuật" mang lại cho ban lãnh đạo ý tưởng cho phép nó là một khoản đầu tư thuộc loại nào đó - khi thực sự nó giống như một loại virus. (Tôi thích Dave Ramsey về nợ kỹ thuật.)

Cho phép nó không được trả tiền đi kèm với một chi phí lớn không thể nhìn thấy hoặc dễ dàng định lượng.

Liệt kê các vấn đề như sau để quản lý:

  • Ước tính tính năng mới cao hơn mức cần thiết. Hoặc, không thể hoàn toàn.
  • Mã xấu sinh ra nhiều mã xấu hơn
  • Danh sách lỗi phát triển ngay cả khi các nhà phát triển luôn sửa chúng
  • Các thành viên trong nhóm đang rời đi (điều này có thể cho thấy có một vấn đề như được giải thích trong câu trả lời xuất sắc này )
43
Nicole

Quản lý của tôi đã thực sự bắt đầu nỗ lực nghiêm túc để giải quyết nợ kỹ thuật, đó là một trong những lý do tôi thích làm việc ở đó, nhưng đó là một nỗ lực lâu dài và không bao giờ đau lòng để nhắc nhở họ tại sao nỗ lực đó đáng giá.

Một cách để tôi duy trì áp lực là bất cứ khi nào tôi được yêu cầu ước tính và thời gian có thể được tiết kiệm nếu tôi không phải giải quyết các vấn đề nợ kỹ thuật cụ thể, Tôi bao gồm điều đó trong ước tính của mình. Ví dụ: " Lỗi này sẽ khiến tôi mất 2-3 ngày để theo dõi, nhưng nếu chúng tôi đã xử lý 2 lỗi 'ưu tiên thấp' khác này đã tồn tại mãi mãi, thì nó sẽ tồn tại mãi mãi có thể mất ít hơn một. "Thông thường, phản hồi sẽ là tiếp tục và sửa những cái khác trong khi bạn đang ở đó.

Tôi cũng đồng ý với các câu trả lời khác về việc chỉ xem xét cải thiện một phần công việc của bạn và thực hiện chúng khi bạn đi nếu nó không quá đột phá. Nhiệm vụ hiện tại của tôi liên quan đến việc bổ sung một số mã được thiết kế rất kém. Thay vì thêm vào mớ hỗn độn bằng cách viết mã mới của mình để khớp, tôi dành một chút thời gian để củng cố chức năng chung, vì vậy việc gửi gói trở thành một cuộc gọi chức năng một dòng thay vì liên tục lặp lại 15 dòng sao chép và sửa đổi một chút dán nồi hơi.

Tôi biết thực tế là nó sẽ cứu được sự tỉnh táo của một số người bảo trì hơn nữa trên đường. Tôi biết bởi vì tôi là người duy trì ngày hôm nay. Tuy nhiên, tôi cũng tin rằng nó sẽ tăng tốc nhiệm vụ hiện tại của riêng tôi là đưa tính năng này vào và gỡ lỗi ngay bây giờ.

Một kỹ thuật khác mà tôi đã sử dụng trong quá khứ và nên làm lại là giữ một nhánh tái cấu trúc DVCS xung quanh trong một cây làm việc riêng trong thời gian đó khi bạn biên dịch, chờ một bài kiểm tra dài hoặc chỉ cần thay đổi tốc độ một chút khi bạn bị lỗi. Miễn là bạn thỉnh thoảng hợp nhất từ ​​thượng nguồn để bạn không phân kỳ quá xa, bạn có thể mất bao lâu bạn muốn tái cấu trúc các thay đổi với rất ít nỗ lực cận biên. 15 phút ở đây và mỗi ngày có thể thực sự cộng dồn theo thời gian.

30
Karl Bielefeldt

Bạn có thể thử tương tự thẻ tín dụng. Hỏi họ "bạn có cảm thấy thoải mái khi để sao kê thẻ tín dụng của mình không được thanh toán trong một khoảng thời gian dài không?"

Các nhà quản lý hiểu chi phí và lợi ích, nhưng (thường) không phải là các thuật ngữ kỹ thuật được sử dụng bởi các nhà phát triển của chúng tôi. Thuật ngữ "nợ kỹ thuật" đã được phát minh để giúp vượt qua rào cản giao tiếp này, nhưng bạn có thể cần phải nói rõ hơn. Hầu hết các nhà quản lý đều biết rất rõ (thường là từ kinh nghiệm của chính mình) rằng các khoản thanh toán bằng thẻ tín dụng quá hạn tăng với mức lãi suất khủng khiếp nên đa khiến họ không được trả tiền. Điều này có thể giúp họ có được sự nghiêm trọng của vấn đề liên quan đến entropy phần mềm.

Nhưng nếu điều này không thuyết phục được họ, hãy cố gắng thu thập bằng chứng thực tế và thực hiện một số tính toán. Ví dụ. Chi phí cho công ty là bao nhiêu - cả bằng tiền mặt cứng và mất thời gian - để thay thế một nhân viên rời đi.

20
Péter Török

Không ai sẽ đưa tiền cho việc thay thế một cái gì đó hoạt động bằng thứ khác mà (với bất kỳ may mắn nào) cũng hoạt động.

Những gì bạn có thể làm là đề xuất thay thế nó bằng một thứ gì đó còn hơn thế, tức là bó dịch vụ nợ công nghệ vào một bản nâng cấp mang lại lợi ích kinh doanh tức thời và hữu hình.

Tất nhiên bạn nên cởi mở về nó, chúng tôi không nói về việc "lén lút" trong một dự án mới ở đây.

Tôi thấy mặt khác, khó xử lý hơn của các nhà phát triển. Về cơ bản, nó hiểu rõ điều này: đối với một số nhà phát triển, đảm bảo mã của bạn là mã tốt nhất có thể bạn có thể là một vấn đề đáng tự hào chuyên nghiệp. Đối với những người khác, đây chỉ là một công việc khác và mục đích là để hoàn thành nó nhanh chóng và về nhà.

Không có sức thuyết phục nào sẽ thay đổi tình huống đó và nếu bạn đưa ra một tiêu chuẩn chất lượng mã bắt buộc, các nhà phát triển chín đến năm của bạn sẽ tìm ra cách để làm việc với hệ thống, trong khi các nhà phát triển chuyên dụng của bạn chắc chắn sẽ bị làm phiền bởi toàn bộ quy trình Không nhắm vào họ, nhưng bạn không thể nói rằng nhà phát triển X phải tuân thủ các quy tắc, trong khi Y có thể làm bất cứ điều gì anh ta muốn).

Những gì hoạt động, nhưng vẫn có thể rất bực bội là để các nhà phát triển tận tâm và hiểu biết hơn của bạn giám sát cơ sở mã, có lẽ là một sự đánh đổi tốt giữa việc tiến lên và thu dọn những gì ở đó.

12
biziclop

Thực tế là, trong rất nhiều công ty, đặc biệt với tình hình kinh tế hiện tại, mỗi giờ phải được lập hóa đơn cho ai đó.

Hoặc họ đi xuống, nhanh.

Trừ khi các khách hàng hiện tại sẵn sàng trả tiền cho việc tái cấu trúc, điều này rất khó xảy ra trừ khi nó đi kèm với hiệu suất hoặc tính năng được nâng cấp đáng kể. Sau đó, nó sẽ không xảy ra trên các cơ sở mã cũ. Bạn có thể lẻn vào ngân sách cho các dự án mới hơn, nếu khách hàng có túi sâu, nhưng trừ khi bạn không cần thay đổi API trong tái cấu trúc, nó sẽ không được sử dụng cho các dự án cũ hơn và cũng có thể giới thiệu tình hình mà công ty đang hỗ trợ hai cơ sở mã hóa, điều này gây ra đau đầu và chi phí hơn nữa.

Là một kỹ sư, tôi rất thích cấu trúc lại mã cũ, không còn thực sự phù hợp với mục đích, mỗi khi một thứ gì đó trở nên lỗi thời hoặc không được dùng nữa. Nhưng như các MD của tôi trong tất cả các công ty tôi từng làm việc đã nói với tôi: "Ai sẽ trả tiền?"

12
Orbling

Tôi luôn cố gắng dọn dẹp khi tôi đi. Tôi không được thực hiện cho đến khi mã sạch. Vấn đề với nợ kỹ thuật là hầu hết mọi người không hiểu nó. Cách tốt nhất để giải quyết nó là không tích lũy bất kỳ của nó. Nếu người quản lý của bạn tin tưởng các nhà phát triển của bạn quyết định cách giải quyết vấn đề, bạn có thể biến vệ sinh mã thành một phần của mọi tác vụ lập trình. Nếu bạn không bao giờ kiểm tra mã xấu, bạn không tích lũy nợ. Nếu bạn cũng tuân theo Quy tắc hướng đạo nam (luôn để mã sạch hơn bạn tìm thấy), khoản nợ hiện tại của bạn sẽ biến mất từ ​​từ.

Tôi không thấy tái cấu trúc là một nhiệm vụ tách biệt với việc thực hiện các tính năng. Nó là một phần không thể thiếu của nó.

12
EricSchaefer

Nếu bạn đang làm việc với những người quản lý phi kỹ thuật, sẽ rất hữu ích nếu bạn có thể đưa cuộc thảo luận của mình thành những điều họ hiểu. Nếu bạn có thể xây dựng một trường hợp thực tế cho ROI dương trên công việc đã bỏ ra để trả nợ kỹ thuật, bạn có thể nhận được ở đâu đó. Bài tập đó sẽ phụ thuộc vào hoàn cảnh của bạn, nhưng một ví dụ có thể giống như thế này:

Phân tích thời gian các nhà phát triển buộc phải dành bao nhiêu thời gian để hỗ trợ Hỗ trợ các vấn đề sản xuất, sau đó đưa ra trường hợp sửa mã cũ bị hỏng sẽ A. giảm số lượng vấn đề hỗ trợ, B. giúp Hỗ trợ giải quyết vấn đề dễ dàng hơn mà không leo thang đến Phát triển và C. giảm thời gian Phát triển dành cho các vấn đề sản xuất khi chúng phát sinh. Đặt nó dưới dạng đô la tiết kiệm bằng cách không có nhà phát triển bị ràng buộc làm công việc hỗ trợ. Ngoài ra, hãy chỉ ra rằng mỗi giờ nhà phát triển dành hỗ trợ là một "gấp đôi" bởi vì bạn không chỉ trả tiền cho nhà phát triển để hỗ trợ mà còn đốt chi phí cơ hội cho những gì nhà phát triển có thể làm (thêm tính năng mới, v.v. .)

Vâng, một số con số sẽ là voodoo/khói và gương ... không sao, bí mật quản lý bẩn thỉu là chúng biết rằng phần lớn các con số chúng lảng vảng là tổng số B.S. Chỉ cần bạn cung cấp cho họ thứ gì đó có vẻ cụ thể để làm việc cùng, để họ có thể lấy nó trong đầu, bạn có cơ hội chiến đấu.

7
mindcrime

Sau lời giải thích về nợ kỹ thuật này, ban quản lý của bạn nên được thuyết phục để trả hết:

Hãy tưởng tượng rằng bạn có một nhà bếp rất bẩn đầy rác rưởi. Trước khi chuẩn bị một bữa ăn, trước tiên bạn phải dành một giờ để làm sạch. Và nó là như thế mỗi khi bạn muốn ăn. Ngoài ra, khi chuẩn bị một bữa ăn, bạn phải hết sức cẩn thận, để đảm bảo rằng crap không rơi vào bữa ăn của bạn.

Nhà bếp là mã của bạn, bữa ăn là sản phẩm của bạn, và ăn là bán sản phẩm của bạn.

Nếu họ có thể đủ khả năng chờ đợi lâu hơn để thay đổi được thực hiện, mà không có mạng lưới kiểm tra đơn vị an toàn, thì có điều gì đó sai trong công ty của bạn.

6
BЈовић

Đó phải là một lập luận rất thuyết phục, về mặt sản phẩm và trường hợp kinh doanh ban đầu, rằng tôi không thể sử dụng số tiền đó bây giờ để làm điều gì đó quan trọng hơn với tôi. Dù muốn hay không, quản lý của bạn hoặc khách hàng của bạn đang trả tiền cho việc này và bạn cần có khả năng bán hàng để thuyết phục họ.

Hãy viết lại điều này để định vị mình là khách hàng. Tốt vai cũ.

Giả sử bạn đang mua tủ lạnh. Và bạn có thể mua một tủ lạnh với giá 1000 đô la hoạt động tốt từ Acme Corp Hoặc một tủ lạnh với giá 2000 đô la từ Acme Deluxe Fridges trông giống nhau ở bên ngoài và có cùng thông số kỹ thuật, nhưng chi phí bảo trì thấp hơn do kiến ​​trúc bên trong sạch hơn.

Là một khách hàng, bạn sẽ tự mua?

Và các kỹ sư của Acme Deluxe nghĩ gì là câu trả lời tốt hơn?

4
jasonk

" Nợ kỹ thuật " có thể là một chủ đề khó đưa ra cho quản lý vì họ có thể không thấy sự cần thiết của nó. Câu hỏi có thể được đặt ra là liệu có một nhà vô địch trong công ty hay không, "Hãy nhìn xem, chúng tôi đang dành X% thời gian để xử lý các khoản nợ kỹ thuật ở đây. Hãy cho chúng tôi 3 tháng để cho bạn thấy điều này hoạt động tốt", hoặc một cái gì đó giống. Có một yêu cầu đối với quyền tự chủ ở đó nhưng cũng có khung thời gian vì nếu không thì ban quản lý có thể tự hỏi bao lâu cho đến khi họ thấy một số kết quả là lãnh thổ khá nguy hiểm.

Điểm đầu tiên là liệu họ có coi đây là một vấn đề hay không. Nếu người có thị lực kém không biết gì về kính mắt và họ có thể cung cấp những loại thay đổi nào, làm sao họ hiểu tại sao xét nghiệm mắt có thể có giá trị? Cùng một ý tưởng ở đây, nơi chủ đề khá kỹ thuật và không dễ dàng định lượng không may.

3
JB King

Bạn chỉ nên ngừng phàn nàn về nó.

Đây là lý do tại sao:

  1. Họ không bao giờ có kế hoạch sử dụng phần mềm lâu hơn một năm
  2. sẽ thật lãng phí thời gian để điều chỉnh nó nếu kế hoạch của họ là đổ nó sau đó
  3. có một số vấn đề thực sự cần khắc phục ngay bây giờ
  4. lập trình viên chỉ cần học cách đối phó với bảo trì, ngay cả khi nó không phải lúc nào cũng vui
  5. phàn nàn rằng bạn biết rõ hơn những gì cần phải làm là kiêu ngạo - người khác đưa ra quyết định và bạn nên hài lòng về điều đó
  6. Dù sao họ cũng tin tưởng bạn viết mã tốt

Vì vậy, cách tốt nhất về phía trước là:

  1. Khi họ giao cho bạn nhiệm vụ mới, hãy cố gắng thực hiện nó tốt nhất có thể trong thời gian nhất định
  2. Viết nó hoàn hảo lần đầu tiên. Nếu bạn cần thay đổi nó sau đó, bạn đã mắc lỗi lần đầu tiên và mọi thay đổi luôn đi sai hướng - và đó là cơ hội học tập cho các lập trình viên khi bạn mắc lỗi.
  3. Đừng hỏi thêm thời gian cho nó, bạn sẽ không nhận được nó, có những thời hạn bạn biết.
2
tp1

Tôi cho rằng bạn chưa bao giờ tham gia vào một dự án để viết lại/thay thế hoặc thậm chí nâng cấp và hệ thống hiện có.

Đây là một số dự án khó nhất để hoàn thành thành công. Một số vấn đề bạn sẽ gặp phải là:

  1. Quy tắc kinh doanh bị mất trong thời gian.
  2. Tài liệu và thực hiện là hoàn toàn không đồng bộ.
  3. Những gì bạn thấy là một lỗi mà người dùng xem là một tính năng.
  4. Ngược lại, nhiều "tính năng" sẽ được người dùng xem là khiếm khuyết.
  5. Bạn sẽ không khiến người dùng mua vào - họ sẽ coi "tìm hiểu thực tế" của bạn là "những người mọt sách hỏi những câu hỏi ngu ngốc", họ sẽ coi nỗ lực thử nghiệm là một sự lãng phí thời gian, họ sẽ nhấn mạnh vào việc thêm các tính năng mới do đó sẽ kéo dài dự án đã bị chậm tiến độ.
  6. Cơ hội là mã nguồn không khớp 100% với tệp thực thi đang chạy.
  7. Trong khi bộ phận của bạn đang loay hoay xoay quanh việc tái cấu trúc phát triển, doanh nghiệp thực sự muốn không được thực hiện.
  8. Rất có thể là việc bao thanh toán lại của bạn sẽ liên quan đến "giao diện được cải thiện sạch hơn", do đó kéo các dự án khác vào vũng lầy giao hàng trễ và các thử nghiệm thất bại.
  9. Sau khi dự án được đóng hộp (hơn 50% những nỗ lực này thất bại hoàn toàn), bạn sẽ mất tất cả tín dụng - bạn sẽ cần chuyển đến một công ty khác ở một thị trấn khác để tìm ai đó chuẩn bị lắng nghe bạn.
  10. Nếu dự án "thành công", mọi người sẽ nhớ đó là cơn ác mộng - bạn sẽ .......

Tôi khuyên bạn nên tránh mọi dự án viết lại/tái cấu trúc như bệnh dịch hạch, chúng có thể là một trong những kinh nghiệm thú vị nhất trong bất kỳ sự nghiệp chuyên nghiệp nào.

Có rất nhiều sự khôn ngoan trong câu "Nếu nó không bị hỏng thì đừng sửa nó".

2
James Anderson

Đã từng tham gia viết lại chính, (không chỉ tái cấu trúc), tôi có thể đồng ý rằng việc các nhân viên tài chính đồng ý với dự án là một trong những rào cản lớn. Vượt qua rào cản đó đòi hỏi tôi phải viết, trình bày và bảo vệ một báo cáo chỉ ra một số vấn đề có nghĩa là việc kinh doanh của các công ty sẽ bị chết trong nước trong thời gian gần đến trung hạn.

Các yếu tố chính để có được thỏa thuận đi trước:

  • Mã hiện tại nằm trong chuỗi công cụ không còn được hỗ trợ, (MicroPower Pascal), chỉ chạy trên nền tảng phát triển gần như không hỗ trợ, (PDP11-23).
  • Tìm kiếm các nhà phát triển có thể làm việc trên các công cụ và mục tiêu đã trở nên gần như không thể.
  • Phần cứng mục tiêu không còn khả dụng nếu cần phụ tùng và nhà sản xuất ngày càng không muốn cung cấp dịch vụ sửa chữa.
  • Các vấn đề trong mã đã dẫn đến sự không hài lòng của khách hàng và chi phí phục vụ trực tiếp dễ nhận biết.
  • Việc thêm các tính năng mới hoặc thậm chí sửa lỗi đã trở nên gần như không thể do các hạn chế của phần cứng đích dẫn đến việc phải cấu trúc lại các khu vực khác để cung cấp không gian khi giải quyết các vấn đề.
  • Với thời gian xây dựng 8 giờ để phát triển và thử nghiệm mọi thay đổi đều tốn kém.

Báo cáo nêu chi tiết các vấn đề, với ước tính chi phí liên tục và đưa ra 3 tùy chọn:

  1. Đóng băng nơi chúng tôi đã có thể thậm chí không sửa lỗi trong tương lai gần.
  2. Tối ưu hóa mã chỉ cho không gian, không liên quan đến khả năng bảo trì, chỉ ra rằng bất kỳ ai cố gắng duy trì mã được tối ưu hóa sẽ phải thông minh hơn bất kỳ ai đã tối ưu hóa.
  3. Thực hiện lại, với khả năng kiểm tra và khả năng bảo trì là các yếu tố cao, trong một tiêu chuẩn công nghiệp, được dạy rộng rãi, ngôn ngữ, (ANSI C), trên phần cứng COTS mới, chi phí thấp, (PC-104), với nhiều nhà cung cấp có sẵn trong nhà thiết kế thẻ giao diện để cho phép nó hoạt động với phần cứng hiện có còn lại. Thêm một bộ tính năng mới hạn chế như một phần của sự phát triển, chẳng hạn như bộ lưu trữ không bay hơi, bộ hẹn giờ theo dõi để cung cấp tự động khởi động lại trong tình trạng lỗi một số đơn vị đã gặp sự cố nhiều lần trong ngày và yêu cầu dịch vụ £ 40 ra để thiết lập lại, chẩn đoán tốt hơn trong quá trình.

Có được sự lựa chọn thứ 3 cho hợp đồng 3 tháng, hợp đồng 3 tháng của tôi biến thành 3 năm làm việc rất chăm chỉ, cả phát triển phần mềm và phần cứng mới, nhưng với kết quả rất tốt.

Đối với các trường hợp có nợ kỹ thuật ít cực đoan hơn, tôi có xu hướng áp dụng cái mà tôi gọi là tái cấu trúc du kích:

Khi có sự cố với một mô-đun cụ thể:

  1. Viết một tập hợp các bài kiểm tra chứng minh vấn đề cũng có khả năng thất bại mà không tái cấu trúc
  2. Tái cấu trúc như là một phần của sự phát triển chỉ ra rằng các thử nghiệm vẫn không thành công.
2
Steve Barnes

Đối với cuộc sống của tôi, tôi không thể hiểu tại sao một số người lại sợ thay đổi một cách mù quáng - nó thiếu tự tin vào khả năng của chính bạn.

Tôi đã xem một chương trình tối qua trên Công viên quốc gia Yosemite và nhận xét rằng từ năm 1940 đến cuối những năm 1990, không một cây Sequoia mới nào mọc lên. Người ta phát hiện ra rằng lý do tại sao có một chính sách nghiêm ngặt chống lại cháy rừng và nón thông Sequoia cần nhiệt từ lửa để mở và giải phóng hạt giống của họ.

Bạn thấy đấy, một đám cháy cứ sau mười năm là lành mạnh. Nó đã dọn sạch tất cả số gỗ chết và tích lũy để giữ cho cây khỏe mạnh (quy trình) và nhường chỗ cho những cái mới (tính năng).

Tôi đang có một dự án ngay bây giờ có một trường hợp rõ ràng để xây dựng lại: Phần mềm kế thừa được viết hoàn toàn bằng cách sử dụng các biểu mẫu web .NET. Hầu như tất cả logic nghiệp vụ được kết hợp với logic xem thẻ HTML/máy chủ và không thể mở rộng sang các ứng dụng khác mà doanh nghiệp đã phát triển.

Quản lý đứng đằng sau nhiệm vụ bởi vì họ có một sự tin tưởng thích hợp vào các nhà phát triển của họ, mà tôi nhận ra, đó là một sự xa xỉ hiếm có.

Vâng, hãy tự hỏi nếu xây dựng lại là thực sự cần thiết. Làm hết sức mình để sử dụng lại mã hiện có hoạt động ở nơi bạn có thể. Tích hợp mã đó vào việc xây dựng lại nếu cần thiết. Đừng để ai thuyết phục bạn rằng sợ thực hiện những thay đổi táo bạo là cách duy nhất để tồn tại như một nhà phát triển phần mềm.

Chúc may mắn!

1
Matt Cashatt

Bạn cần cung cấp cho ban quản lý của mình một lý do tài chính để xử lý nợ kỹ thuật và khung quản lý giảm nợ kỹ thuật đó.

Duy trì một lộ trình công nghệ là một khung như vậy. Bắt đầu với một lộ trình sẽ giúp bạn tránh khỏi tình trạng nợ kỹ thuật và cũng có thể giúp bạn giảm nợ hiện tại.

Nhiều dự án dài hạn thành công đã liên kết với các ban chỉ đạo và lộ trình để định hướng phát triển. Điều này đặc biệt hữu ích khi có nhiều nhóm phát triển và các bên liên quan.

Đề nghị của tôi là bạn thảo luận về chiến lược này với các nhà quản lý của bạn (và nếu có thể những người đưa ra quyết định về nơi tiền được chi tiêu).

Cách tiếp cận chung để tạo và quản lý lộ trình rất đơn giản, nhưng nó cần có sự hỗ trợ của đội ngũ quản lý của bạn. Đầu tiên, xác định một mục tiêu. Xác định các yếu tố của nợ kỹ thuật và phát triển kiến ​​trúc hệ thống mục tiêu làm giảm các yếu tố của nợ kỹ thuật của bạn. Hãy nhớ rằng, nó không cần phải hoàn hảo, hoàn toàn khả thi và tốt hơn những gì bạn đang có. Hãy tính đến phần mềm, công cụ phát triển, nền tảng phần cứng, các tính năng mới quan trọng có thể được thêm vào hệ thống. Làm một phân tích chi phí. Nếu bạn có kiến ​​trúc mong muốn, những lợi ích hữu hình của việc thực hiện tái cấu trúc là gì? (Lợi ích sẽ bao gồm giảm thời gian thử nghiệm, các sản phẩm phần mềm đáng tin cậy hơn, chu kỳ phát triển dễ dự đoán hơn, v.v.) Nếu bạn có thể hiển thị đủ lợi ích để thực hiện tái cấu trúc, bạn có thể nhận hỗ trợ quản lý.

Khi bạn có lộ trình và hỗ trợ quản lý, hãy phát triển một loạt các bước (còn gọi là kế hoạch) mà bạn cần thực hiện để đến trạng thái mong muốn này. Có thể là một ý tưởng tốt để thành lập một ban chỉ đạo duy trì lộ trình, đào tạo và giáo dục các nhóm phát triển về lộ trình và định kỳ xem xét các thay đổi về tính toàn vẹn của kiến ​​trúc.

Lộ trình thực sự hữu ích và có lẽ câu hỏi thứ 13 trong Bài kiểm tra Joel là "Bạn có lộ trình không?"

Đây là video về giờ đầu tiên của phiên lộ trình Red Hat Linux gần đây .

1
Jay Elston