Làm thế nào để chứng minh một ứng dụng được xây dựng trên một cơ sở mã xấu?

Tôi hiện đang xem xét một hệ thống được xây dựng bởi một số nhà phát triển trước đây làm việc. Hệ thống hoạt động khá tốt theo quan điểm của người dùng, nhưng khi đi sâu vào xem xét mã, nó là một mớ hỗn độn. Tôi tin chắc rằng cách thức xây dựng ứng dụng sẽ không theo kịp các bản cập nhật trong tương lai, chứ đừng nói đến việc tăng mức sử dụng cao.

Vấn đề là tôi biết nó tệ như thế nào, nhưng cấp trên của tôi thì không. Làm cách nào tôi có thể chứng minh điều đó với người quản lý của mình để anh ta thực sự nhìn thấy vấn đề và có thể bị thuyết phục để thực hiện việc xử lý tối thiểu trên cơ sở mã hiện tại và trong tương lai gần bắt đầu một dòng phát triển mới cho phiên bản tiếp theo của ứng dụng?

"Nhưng nó hoạt động ngay bây giờ" là phản ứng quản lý tiêu chuẩn đối với sự thất vọng chính đáng của các kỹ sư phần mềm. Điều đầu tiên tôi sẽ làm là biên dịch tài liệu (nếu có) và sử dụng nó để chứng minh mâu thuẫn giữa mã và tài liệu.

Nếu bạn có thể, hãy tập hợp một bộ bài kiểm tra đơn vị toàn diện. Chạy chúng với mọi thay đổi để bạn có thể ghi lại các hồi quy có thể đổ lỗi cho cơ sở mã hiện có.

Cuối cùng, nếu bạn có thể lôi kéo một nhà phát triển từ một bộ phận khác có công việc mà bạn tin tưởng, hãy lấy một đôi mắt thứ hai về mã. Một nhà phát triển nói rằng 'đây là chuyện tào lao' thì dễ bị bác bỏ hơn so với khi một nhà phát triển cấp cao, người đã từng làm chứng từ cho anh ta và nói, 'Không, Jim, anh ta đúng. Đây là tào lao trên một cracker crap. '

Tất nhiên, tất cả phụ thuộc vào môi trường, quy mô công ty của bạn, v.v.

Tôi luôn khuyên bạn nên xem qua Lập trình viên thực dụng Nếu bạn chưa đọc nó. Không chỉ cần đọc cho mọi chuyên gia phần mềm, mà nó còn có một số gợi ý tốt để xử lý quản lý, đồng nghiệp, người dùng, v.v., những người không xem công nghệ phần mềm là một nghề thủ công.

Từ quan điểm của quản lý, hệ thống không có gì sai và bạn chỉ phàn nàn vì [bạn chỉ muốn viết lại / bạn không hiểu những gì các kỹ sư trước đây đã làm / bạn muốn công việc của mình trở nên dễ dàng]. Một chút của một người đàn ông rơm, nhưng khi một người ở trên đỉnh thấy rằng mọi thứ đang hoạt động tốt ngay bây giờ, họ không thích nhìn thấy một cuộc khủng hoảng nơi bạn làm (tôi chắc chắn có một câu chuyện ngụ ngôn về biến đổi khí hậu ở đâu đó ...) .

Ở một mức độ nào đó, họ có một điểm. Quản lý thấy vấn đề khi các bản phát hành vượt xa ước tính ban đầu của họ, ước tính dường như quá cao cho công việc đang được thực hiện, "điều này là không thể đối với cơ sở mã hiện tại của chúng tôi" và các lỗi xuất hiện cao đã xảy ra trong QA. Nếu mọi thứ đang diễn ra tốt đẹp, thật dễ dàng để vỗ nhẹ vào đầu bạn và bảo bạn cố gắng hết sức, vì điều đó không ảnh hưởng đến điểm mấu chốt.

Phải làm gì phụ thuộc vào tổ chức của bạn và chính phần mềm. Về cơ bản, mặc dù, tôi đề nghị ghi lại mọi sự phức tạp xuất hiện do kết quả của mã di sản xấu. Khi ước tính các nhiệm vụ, hãy làm rõ cho quản lý lý do tại sao bạn nghĩ rằng sẽ mất nhiều thời gian như vậy, với các giải thích chi tiết về các khía cạnh của cơ sở mã cũ đang thêm chi phí này. Khi các lỗi được đưa vào mã, bao gồm các lý do tại sao lỗi này có thể xảy ra và cách các vấn đề trong cơ sở mã cũ chịu trách nhiệm.

Tôi đề nghị phrasing mối quan tâm của bạn cho các bên liên quan theo cách cho thấy phần mềm đã vượt xa thiết kế ban đầu của nó và hiện đang gặp vấn đề để tiếp tục tăng cường.

Có nhiều công cụ khác nhau có thể thực hiện bảo hiểm mã và xem xét mã. Các công cụ của Google phù hợp với công nghệ của bạn, đây thường là các công cụ tiêu chuẩn công nghiệp. Tôi sẽ đề nghị bạn sử dụng các công cụ này và đưa ra báo cáo chất lượng mã và trình bày cho Trình quản lý. Hãy chắc chắn rằng những lời chỉ trích của bạn là trái ngược và phi chính trị.

Chọn một ví dụ dễ hiểu nơi quản lý sẽ nghĩ rằng đó là một yêu cầu thay đổi đơn giản, nhưng vì thiết kế hiện có nên khó khăn hơn nhiều.

Bạn không muốn họ thực hiện theo yêu cầu cụ thể, nhưng hãy chắc chắn rằng bạn cho họ biết rằng đây là những gì BẤT K request yêu cầu thay đổi sẽ diễn ra như thế nào. Không ai muốn được vẽ ở một góc với một ứng dụng. Các nhà phát triển tin vào YAGNI, nhưng ban quản lý tin vào CYA.

Các đề xuất cho thử nghiệm tải có thể là một cách tiếp cận tốt, nhưng chúng có thể không tin rằng mối quan tâm sử dụng tăng lên đáp ứng bất kỳ tiềm năng tăng trưởng thực tế nào (Công ty sẽ không tăng gấp đôi trong một năm.).

Tất cả mọi thứ chỉ là tương đối. Họ có thể không muốn đưa tài nguyên vào dự án này khi họ có kế hoạch cho các dự án quan trọng hơn để dành thời gian của bạn. Đừng để bị dán nhãn là không nhìn thấy bức tranh lớn.

Khi bạn nói về việc chứng minh điều gì đó, tất cả những thứ phương pháp khoa học đó đều có tác dụng, và một phần của điều đó có nghĩa là nếu bạn sẽ chấp nhận các tiêu chuẩn khách quan để quyết định điều gì là đúng, bạn phải chấp nhận khả năng, khi điều tra, những sự thật phiền phức đó Hóa ra không đứng về phía bạn.

Trong trường hợp của bạn, tôi nghĩ có 2 điều cần chứng minh.

Đầu tiên, rằng cơ sở mã hiện tại là "xấu". Những gì bạn có thể có thể chứng minh là "ý kiến ​​chuyên môn của gần như tất cả các nhà phát triển kiểm tra mã này là nó xấu".

Thứ hai, rằng công ty sẽ tốt hơn khi viết lại codebase. Đây là một vấn đề bởi vì ngay cả khi điểm đầu tiên là đúng, thì điểm thứ hai có thể không. Ngoài ra, bạn không biết đủ để đưa ra quyết định này. Đây là công việc của quản lý và nếu bạn muốn họ tôn trọng đánh giá chuyên môn của bạn về điểm đầu tiên, bạn nên tôn trọng họ về điểm thứ hai.

Nhưng họ không thể đưa ra quyết định về điểm thứ hai mà không có thông tin bạn cung cấp. Bạn cần truyền đạt những gì bạn biết về cách các vấn đề trong mã sẽ ảnh hưởng đến doanh nghiệp và những gì bạn biết về cách viết lại sẽ ảnh hưởng đến doanh nghiệp. Điều này là khó khăn, vì cả hai liên quan đến việc dự đoán một tương lai có nhiều điều không chắc chắn.

Nhưng bạn có thể cố gắng nêu vấn đề trong điều khoản kinh doanh. Bao nhiêu thời gian thêm dành cho những thay đổi và hồi quy? Điều gì sẽ viết lại chi phí? Chi phí của hệ thống hiện tại sẽ tăng nhanh theo thời gian như thế nào nếu không được viết lại? Điều gì xảy ra nếu có sự gia tăng trong sử dụng, khả năng xảy ra thảm họa là gì nếu mã hiện tại được giữ? Bạn thực sự không thể biết bất kỳ điều này, nhưng bạn có thể đoán tốt hơn bất kỳ ai khác. Đưa ra một phạm vi, hoặc một cái gì đó để truyền đạt chính xác như thế nào bạn nghĩ rằng bạn có thể dự đoán những điều này.

Hầu hết các nhà phát triển không thích duy trì mã tệ hại. Đó là lý do tại sao có thể không may là mã không có trí tuệ để viết lại từ góc độ nhà phát triển có thể không đáng để viết lại từ góc độ kinh doanh.

Ví dụ, ngay cả khi việc viết lại kết thúc có lợi nhuận, nó có thể có giá trị thấp hơn chi phí cơ hội của việc chi tiêu tiền ở nơi khác trong công ty. Hoặc cơ sở mã xấu có thể mất nhiều thời gian hơn để thay đổi và có nhiều hồi quy hơn, nhưng không đủ để tạo ra lợi nhuận viết lại. Họ có thể đang tìm cách mua hết trong vài tháng tới và chi tiền cho việc viết lại sẽ hiển thị trên sách nhưng phần mềm lỗi sẽ không.

Hãy thử nghĩ về nó từ quan điểm kinh doanh và đừng nấu những con số để đạt được điều bạn muốn. Một viết lại lớn gần như không bao giờ là không có trí tuệ từ quan điểm kinh doanh. Nếu bạn muốn chứng minh điều gì đó không thể chứng minh trực tiếp, hãy cố gắng hết sức để từ chối nó. Nếu bạn tiếp tục cố gắng hết sức để tìm ra một cách không phải viết lại từ đầu nhưng không có gì bạn đưa ra có ý nghĩa, có lẽ sau đó nó thực sự thời gian để viết lại từ đầu. Và nỗ lực đó sẽ cho quản lý của bạn thấy rằng bạn nghiêm túc trong việc đại diện cho lợi ích của công ty, chứ không phải của riêng bạn (bạn đại diện cho lợi ích của công ty, không phải của riêng bạn, phải không?).

Tôi đoán nó phụ thuộc vào những gì xấu về cơ sở mã. "Không phải là cách tôi sẽ làm" không có nghĩa đó là một cơ sở mã xấu.

Những thứ thực sự tạo ra một cơ sở mã xấu:

• Lỗ hổng an ninh

  Các sự cố khiến Máy chủ, ứng dụng và / hoặc dữ liệu dễ bị tổn thương. Đặc biệt là bất cứ điều gì khiến dữ liệu của công ty, khách hàng hoặc khách hàng nhạy cảm có nguy cơ. Đây phải là tài liệu dễ dàng.

• Làm việc bị hỏng

  Nó chỉ hoạt động vì bạn xoa bóp dữ liệu và thực hiện bảo trì trên ứng dụng gần như liên tục để giữ cho nó hoạt động. Nếu bạn đã rời đi và không ai nhận lấy sự chậm chạp thì nó sẽ không còn hoạt động nữa. - Tài liệu bạn dành bao nhiêu thời gian để làm việc này. Và lưu ý bạn có thể tiết kiệm được bao nhiêu. Thông thường, các quy trình này cũng không hiệu quả đối với người dùng và bạn cũng có thể ghi lại điều đó.

• Không thực sự làm việc

  Nó xuất hiện để làm việc nhưng kết quả không chính xác. Điều này thường gây ra sự cố xuống dòng như số không khớp, tỷ lệ lỗi cao, v.v.

Codebase không tệ (chỉ không tốt):

• Viết về công nghệ không được hỗ trợ lỗi thời. (VB6, COBOL, .net1.1, v.v.)

Lưu ý những lợi thế của việc chuyển sang một công nghệ mới. Cố gắng tìm một đường di chuyển di chuyển từng mảnh một để bạn có thể giảm thiểu rủi ro và tạo niềm tin cho người dùng và quản lý. Hãy chắc chắn rằng logic hoạt động về cơ bản giống như bản gốc.

• Mã không có giấy tờ / định dạng kém

Đây là cách dễ nhất để bạn khắc phục vì nhìn chung bạn có thể thêm nhận xét và sửa định dạng mà không thực sự ảnh hưởng đến mã. Nhưng nó không yêu cầu viết lại. Nếu bạn cảm thấy điều này được kết hợp với các vấn đề khác, điều đầu tiên cần làm là khắc phục điều này để bạn có thể đánh giá tốt hơn khả năng tồn tại của mã.

Bạn đã trả lời câu hỏi của riêng bạn một cách.

Cách để thuyết phục họ chi tiền cho hệ thống là đợi cho đến khi nó không hoạt động tốt cho người dùng. Nếu bạn nghĩ rằng nó sẽ không mở rộng quy mô, hãy đợi điều đó xảy ra hoặc thực hiện kiểm tra tải để chứng minh điều đó.

Sau đó, một đề xuất đơn giản về việc làm sạch quy mô này sẽ tốn X giờ.

Đây là một tình huống khó khăn vì hiện tại từ quan điểm của người dùng, mọi thứ đều ở mức chấp nhận được và ổn định. Chủ yếu với các nhà quản lý phi kỹ thuật, hiện tại không có gì phải lo lắng, nhưng yêu cầu viết lại codebase là một quyết định to lớn và không nên xem nhẹ, đặc biệt là về quan điểm và nỗ lực của một người đàn ông (chính bạn) .

Vì vậy, bạn đang ở trong một thời điểm khó khăn khi cố gắng tạo ra một trường hợp để viết lại vì nợ kỹ thuật quá lớn (theo ý kiến ​​của bạn, chúng tôi không có bất kỳ ví dụ nào và phải lấy lời của bạn cho nó) cũng như ở trong tình huống khó khăn gặp khó khăn trong việc duy trì và thêm các tính năng vào hệ thống này.

Ước tính của bạn cho các tính năng mới sẽ cao, chứng minh những con số cao này bằng sự thật, chứng minh rằng những điều này thực sự sẽ mất rất nhiều thời gian. Nếu bạn không truyền đạt điều này đúng thì người quản lý của bạn có thể cho rằng bạn không đủ năng lực và bạn chắc chắn không muốn điều đó. Khi anh ta đặt câu hỏi về các ước tính cao sau đó giải thích lý do tại sao bạn cảm thấy khoản nợ kỹ thuật tích lũy đang cản trở khả năng thêm nhanh chóng và rẻ tiền các tính năng vào phần mềm hiện tại. Nếu người quản lý của bạn có hai tế bào não cọ xát với nhau, anh ta sẽ bắt đầu hiểu rất nhanh.

Vấn đề là bạn không nên cố gắng thuyết phục người quản lý của mình, nhưng chỉ đạo người quản lý của bạn với thông tin phù hợp (và được lựa chọn cẩn thận) để anh ấy / cô ấy có thể thuyết phục bản thân rằng viết lại là một khóa học có thể chấp nhận được. Bạn phải làm cho người quản lý nghĩ rằng đó là ý tưởng của anh ấy / cô ấy.

Đầu tiên xác định nợ kỹ thuật tích lũy trong cơ sở mã của bạn. Sau đó hãy xem câu hỏi và câu trả lời này , nơi nó được giải thích làm thế nào để thuyết phục ban quản lý trả hết nợ kỹ thuật trước khi tiếp tục.

Có lý do tại sao tất cả các phần mềm trưởng thành trông giống như lộn xộn:

1. Tất cả các mớ hỗn độn đang mã hóa logic quan trọng mà doanh nghiệp dựa vào. Không có nó không có gì hoạt động. Mỗi bit cần thiết để giải quyết vấn đề người dùng.
2. Đó là sử dụng công nghệ hơi lỗi thời. Các lập trình viên hiện tại dường như nghĩ rằng nếu nó không sử dụng một số phép thuật mẫu, thì đó chỉ là một mớ hỗn độn. Đây là xem hỏng. Bất cứ ai đến muộn với bất kỳ dự án lớn hơn sẽ có giai đoạn này trong khi tìm hiểu tất cả các chi tiết.
3. Các yêu cầu quan trọng một thời gian trước đây không còn quá quan trọng. Điều này là do phần mềm đã khắc phục những vấn đề đó. Đến muộn với dự án, có vẻ như phần mềm rất phức tạp mà không có lý do chính đáng - vấn đề không còn tồn tại, nhưng sự phức tạp trong mã vẫn còn đó.