Làm thế nào để bạn đối phó với mã xấu xí mà bạn đã viết? [đóng cửa]

Vì vậy, khách hàng của bạn yêu cầu bạn viết một số mã, vì vậy bạn làm. Sau đó, anh ấy thay đổi thông số kỹ thuật về bạn, như bạn mong đợi, và bạn chăm chỉ thực hiện các tính năng mới của anh ấy như một chàng trai tốt. Ngoại trừ ... các tính năng mới là loại xung đột với các tính năng cũ, vì vậy bây giờ mã của bạn là một mớ hỗn độn. Bạn thực sự muốn quay lại và sửa nó, nhưng anh ấy cứ yêu cầu những thứ mới và mỗi khi bạn hoàn thành việc dọn dẹp thứ gì đó, nó lại nổi lên một mớ hỗn độn.

Bạn làm nghề gì? Ngừng là một kẻ điên OCD và chỉ chấp nhận rằng mã của bạn sẽ gây ra một mớ hỗn độn bất kể bạn làm gì, và cứ tiếp tục sử dụng các tính năng cho sự quái dị này? Tiết kiệm vệ sinh cho phiên bản 2?

Nhận một công việc khác và để người khác giải quyết nó. Muahahahhahahaa.

.....

Đùa thôi. :)

Nhưng trong tất cả sự nghiêm túc: đệm ước tính là bạn của bạn. Tôi thường làm một ước tính thực tế phong nha, sau đó tăng gấp đôi nó. Điều này nghe có vẻ quá đáng, và đôi khi là như vậy, nhưng tốt hơn hết là đánh giá quá cao một chút và thậm chí đôi khi trông hơi chậm - hơn là để lại ấn tượng xấu bằng cách bật mã lỗi và luôn thổi ước tính của bạn. Và tất nhiên, bạn phải gánh chịu khoản nợ kỹ thuật bằng cách để codebase bị hack.

Một mẹo khác (có liên quan): Luôn ước tính dường như rất nhỏ, không có nhiệm vụ thông minh nào cho một khối có kích thước khá. Ví dụ, giả sử - một mục mà bạn gần như chắc chắn sẽ chỉ là một thay đổi đơn giản trong một dòng 30 giây - cho nó 1 giờ (hoặc có thể là bất kỳ khối thời gian thấp nhất nào trên bảng thời gian hoặc hệ thống CR của bạn, ví dụ 15 phút / 0,25 giờ) . Và đưa ra các khối nửa ngày hoặc 1 ngày cho các mặt hàng lớn hơn một chút nhưng vẫn tương đối tầm thường.

Lý do cho điều này chủ yếu là do tâm lý: Tôi thấy rằng nếu bạn có thói quen nhanh chóng hack những thay đổi nhỏ, công việc cảm thấy vội vã, và bạn không bao giờ kết thúc việc ngồi lại, lấy cổ phiếu và tái cấu trúc những thứ cần được tái cấu trúc. Ngoài ra, ở mức độ thực tế: đôi khi những thay đổi nhỏ nhưng không tầm thường xảy ra và bạn không muốn liên tục cảm thấy như mình bị chậm tiến độ và dập tắt các lỗi. Đó là một phần và phần của lý do tại sao các cơ sở mã bị hack theo thời gian.

Cuối cùng, hãy luôn nhớ rằng mọi người không cần phải biết rằng bạn đang đệm phần nào ước tính của mình. Miễn là bạn là một nhà phát triển có năng lực và bạn đang hoàn thành công việc với tốc độ tốt, phần đệm này sẽ không được chú ý. tức là đừng nói với PHB "Ước tính ban đầu của tôi là sẽ mất hai giờ, nhưng hãy cho tôi nửa ngày". Chỉ cần nói với anh ta "Tôi nghĩ rằng sẽ mất khoảng nửa ngày." và để nó ở đó.

Cố tình đánh giá quá cao thời gian cần thiết cho các tính năng tiếp theo của bạn. Sử dụng thêm thời gian để làm sạch.

Bạn sẽ không bao giờ có thể biện minh cho việc bảo trì và khách hàng cần nó bất kể, vì vậy hãy cung cấp cho họ thuốc đắng (chi phí tăng nhẹ cho các tính năng tiếp theo) để họ có thể trở nên tốt hơn.

Cố gắng thiết kế lại phù hợp trong khi tích hợp các tính năng mới. Không có sau này. Không có thiết kế lại, bạn liên tục thêm nhiều ma sát để thay đổi hơn nữa và các tính năng mới.

Tại một số điểm, bạn sẽ dừng lại ở gần nơi mọi thứ dường như mất nhiều thời gian. Hầu hết các công ty có thể sẽ viết lại lớn vào thời điểm này, phiên bản 2. Nó có kinh tế khá kém và là thời điểm tốt để khách hàng của bạn thử một bữa tiệc phát triển khác nếu họ cảm thấy nghiêng.

Thiết kế lại / tái cấu trúc đúng cách có thể bảo vệ đầu tư của khách hàng của bạn và giữ cho mọi thứ bền vững. Bạn cần xây dựng cái này trong. Tối ưu hóa cho sự thay đổi, ánh sáng du lịch.

Với tất cả các ý kiến ​​về việc ước tính quá mức, tôi nghĩ rằng có một số điểm khiêm tốn (cơ hội tốt) bị bỏ lỡ.

Nó không phải là về việc ước tính thời gian thực hiện thay đổi (chỉ) và sau đó thêm một số, mà là ước tính thời gian cần thiết để sửa đổi mã (tái cấu trúc!) Để đưa nó đến điểm mà thay đổi có thể được thực hiện một cách an toàn và sau đó thực hiện thay đổi (có lẽ hơi munged với nhau). Ok, điều này tương tự như vậy ... nhưng không có vấn đề gì về việc làm mờ hoặc kéo dài hoặc ước tính quá mức, nó chỉ đơn giản là một vấn đề để nói rằng để làm điều này trước tiên tôi cần phải làm điều đó và phải mất bao lâu Tổng cộng. Điều quan trọng ở đây là bạn làm việc trên những phần của hệ thống mà sự thay đổi phụ thuộc và không còn nữa - nếu có mã khủng khiếp ở nơi khác ... khó khăn, hãy nắm bắt nó khi bạn ở đó.

Để trở lại câu hỏi ban đầu một chút - sau nhiều năm, điều này đã xảy ra với tôi, khi bạn thực hiện một cái gì đó trừ khi bạn biết (không tin, không mong đợi (nghi ngờ?), Không nghĩ nhưng biết ) rằng công cụ bổ sung là cũng yêu cầu sau đó bạn nên làm những gì bạn cần để thực hiện yêu cầu đó và không còn phải gọn gàng và thanh lịch một cách thời trang như bạn có thể.

Khi bạn đến để thực hiện điều tiếp theo - một thời gian sau - bạn thực hiện các bước cần thiết để đưa cơ sở mã (và cơ sở dữ liệu và bất cứ điều gì) đến trạng thái cần thiết để thực hiện chức năng đó một cách gọn gàng và thanh lịch nhất có thể. Tái cấu trúc này là nơi bạn xử lý các mớ hỗn độn phát sinh một cách tự nhiên khi một dự án phát triển - và hy vọng tránh tạo ra nhiều mớ hỗn độn hơn (hoặc ít nhất là giữ mức độ nhất quán).

Một trong những lĩnh vực thảo luận ở đây là "Nợ kỹ thuật" - giống như một khoản thấu chi, bạn phải trả lại và bạn càng để lại nhiều tiền lãi (trong trường hợp này cần phải sửa), bạn sẽ tích lũy - điều này mang lại cho bạn một khoản tốt lập luận cho việc dành một số thời gian của bạn để giảm thiểu các khoản nợ kỹ thuật.

Đây cũng là lúc thử nghiệm đơn vị và thử nghiệm tự động khác bắt đầu xuất hiện (nếu tôi có thể làm tốt như tôi nói tôi khá chắc chắn tôi sẽ là một người hạnh phúc hơn!) Kết hợp với một máy chủ xây dựng phù hợp (có thể chạy ít nhất một số các bài kiểm tra của bạn). Kết hợp với những thứ đó - nhưng có giá trị trong chính chúng - là các mô hình như tiêm phụ thuộc và đảo ngược kiểm soát (không bao giờ chắc chắn hai "cái đó" giống nhau đến mức nào) bởi vì chúng giúp thay đổi hệ thống ống nước dễ dàng hơn và do đó xử lý các thay đổi trong sự cô lập.

Cuối cùng - hãy nhớ, nếu nó không bị hỏng, đừng sửa nó. Làm sạch mã của bạn hoàn toàn vì mục đích làm sạch nó có thể thỏa mãn nhưng đó cũng là cơ hội để đưa ra các lỗi vì vậy trong khi có thể đau đớn nếu bạn không cần phải thay đổi và không nên xây dựng nó. một mình - cơ hội để sửa chữa hoặc thay thế sẽ quay vòng cuối cùng!

1) Kiểm soát thay đổi phù hợp là bạn của bạn

Nếu khách hàng thay đổi thông số kỹ thuật thì tốt, đó là quyền của anh ta, tuy nhiên đó là thay đổi và cần phải trả phí (hoặc chi phí theo bất kỳ cách nào phù hợp với cấu trúc / mối quan hệ của dự án).

Ước tính cho sự thay đổi đó nên bao gồm chi phí tái cấu trúc cần thiết . Khách hàng có thể rất bực mình với chi phí cao nhưng tại thời điểm đó bạn cần phải giải thích với anh ta rằng vì mã đã được viết một nửa, có những yếu tố cần được viết lại để đảm bảo nó mạnh mẽ và có thể hỗ trợ trong tương lai và điều đó nếu nó không được thực hiện thì có khả năng anh ta sẽ gặp vấn đề với sự hỗ trợ hoặc thay đổi trong tương lai thậm chí còn trở nên đắt đỏ hơn.

2) Tái cấu trúc nên được thực hiện như vậy Điều đó mang lại lợi ích lâu dài chính hãng cho khách hàng

Khi xem xét tái cấu trúc, bạn luôn cần xem xét những gì thực sự cần thiết và những gì quan trọng và đảm bảo rằng công việc tái cấu trúc cung cấp giá trị lâu dài thực sự cho tiền.

Rốt cuộc, chúng ta nên làm những điều này để mã vẫn có thể mở rộng và có thể hỗ trợ trong trung hạn / dài hạn để đảm bảo rằng khoản đầu tư của khách hàng vẫn hợp lệ thay vì ra khỏi bất kỳ động lực nào cho sự hoàn hảo về mặt lý thuyết. Tái cấu trúc công việc (và các ước tính tương ứng) nên được thực hiện với phạm vi này, và không chỉ bởi vì bây giờ bạn nghĩ rằng có thể có một cách tốt hơn để làm điều đó.

Một số lập trình viên đề nghị rằng một cách để kiểm soát vấn đề đó với khách hàng là phải có dấu hiệu khách hàng và ủy quyền cho đặc tả ban đầu. THÌ, khi họ yêu cầu thay đổi yêu cầu không có trong thông số ban đầu, bạn nói với họ rằng bạn cần thông qua hợp đồng và thời gian biểu dự án để tính thêm chi phí và thời gian trì hoãn, sau đó lập phụ lục cho hợp đồng. Rõ ràng nó làm điều kỳ diệu trong việc ngăn chặn khách hàng nhấn mạnh vào các tính năng mới (không dự đoán được).

Tôi có nhận xét sau trong một cơ sở mã mà tôi hiện đang làm việc:

/*
 * Every time I see this function, I want to take a shower.
 */

Tôi biết, rất tốt tình huống bạn đang mô tả. Những gì tôi làm là cố gắng (hết sức mình) để đợi cho đến khi mọi thứ lắng xuống và bất kỳ loại 'creep' nào đã 'len lỏi' tất cả những gì nó sẽ làm. Vào thời điểm đó, bạn có thể có một cái gì đó có thể sử dụng được phát hành, và bạn có thể dành chút thời gian để dọn dẹp mọi thứ và thực hiện công cụ khác đi một chút.

Bạn không thể chạy xung quanh dọn dẹp nhiều mớ hỗn độn nhiều lần. Điều đó chỉ làm tăng gấp ba công việc của bạn, và sự thất vọng. Đợi nó trở nên lớn hơn, nhưng hầu như không di chuyển lộn xộn và sau đó bạn có thể làm gì đó với nó.

Sở thích của tôi là tránh tình huống này ngay từ đầu.

Tất cả phụ thuộc vào CÁCH BẠN đọc thông số kỹ thuật. Thật dễ dàng để nghĩ về chúng như những viên đá, nhưng trong thực tế hầu hết các thông số kỹ thuật thay đổi. Khi bạn thiết kế mã của mình, hãy xem khả năng mỗi phần của thông số kỹ thuật sẽ thay đổi. Theo thời gian, bạn sẽ khá giỏi trong việc dự đoán điều này.

Có được vào mớ hỗn độn, kinh nghiệm và phán đoán là rất quan trọng. Bạn đang viết lỗi mới vì mã spaghetti này? Có phải mất nhiều thời gian hơn để thực hiện? những điều này sẽ chỉ ra một nhà tái cấu trúc chiến thuật.

trong tương lai, có vẻ như bạn cần hợp tác với khách hàng của mình. Nói với họ, "nhìn sản phẩm này đang mở rộng đáng kể so với thông số ban đầu. Trong khi thiết kế ban đầu tốt cho cấp độ đó, mở rộng nó theo hướng X và hướng Y cần một số cấu trúc lại trong thiết kế" và bạn thậm chí sẽ nhận được khách hàng trả tiền cho nó.

Sạc theo giờ và nếu anh ta muốn thay đổi nói rằng điều đó là tốt nhưng kết hợp thời gian cần thiết để viết mã tốt vào phương trình. Cũng nên nhớ viết mã gọn gàng hơn trong thời gian dài khi bạn phải duy trì nó. Tiết kiệm thời gian bây giờ có thể chi phí bạn sau này.

Tôi nghĩ rằng viết phần mềm cần phải đi đôi với nhu cầu kinh doanh. Nếu đó là một dự án vứt đi (như một nguyên mẫu cần được xây dựng trong một tuần, với các đầu vào mới xuất hiện mỗi ngày), thì không cần phải lo lắng về khả năng duy trì mã và các thứ khác - thời gian là rất quan trọng và bạn chỉ cần đẩy mã của bạn ra khỏi cửa càng nhanh càng tốt.

Nhưng nếu bạn đang viết một ứng dụng dài hạn, thì nên xem xét tất cả những điều này, bởi vì có một tác động khá lớn đến việc mất bao lâu để xây dựng các tính năng mới, để sửa các lỗi hiện có, để tích hợp vào các ứng dụng khác và các thứ khác - và điều này chuyển thành tác động kinh doanh (vì cần nhiều thời gian hơn sau này và chi phí nhiều hơn).

Vì vậy, tốt hơn là nên nhạy cảm với người ra quyết định với chi phí thực tế của việc không tái cấu trúc mã bất cứ khi nào cần thiết - theo kinh nghiệm của tôi, nếu tác động của chi phí và thời gian của cả hai tùy chọn được giải thích theo thuật ngữ có thể đo lường được cho chủ sở hữu quyết định, thì quyết định có thể là không có trí tuệ. Đừng mong mọi người nói với bạn rằng "hãy tiếp tục viết mã đẹp, mặc dù nó tốn gấp đôi thời gian và không mang lại cho tôi thêm lợi ích nào". Nó không hoạt động theo cách đó.

Biến nó thành một phần của quá trình của bạn, tôi gọi nó là "tái cấu trúc cực độ" và nó sẽ rất lớn! ;) Chỉ cần làm công cụ nhanh chóng và khi đủ các tính năng mới được thêm vào là có mô sẹo, hãy cấu trúc lại nó. Liên tục tự hỏi "Bây giờ nếu tôi đã bắt đầu từ đầu, tôi sẽ làm như thế nào"

Những người nghĩ rằng họ có thể thiết kế và suy nghĩ về mọi thứ ở phía trước chủ yếu là tự đánh lừa mình, bạn (và khách hàng của bạn) luôn học hỏi mọi thứ khi bạn đi cùng. Sử dụng những bài học.

Khi bạn là một lập trình viên giỏi, bạn sẽ có thể cấu trúc lại khá nhanh và khi bạn thực hiện liên tục, mã sẽ bắt đầu trở thành "hình thức phù hợp", nghĩa là nó sẽ trở nên linh hoạt hơn với ít phụ thuộc hơn.

Khách hàng có thể bị đánh lừa nếu họ biết bạn đang "lãng phí thời gian" làm lại công cụ để giúp không hỏi / nói và thực sự nhanh chóng về việc đó.

Mã được phát triển theo cách này sẽ giúp bạn tiết kiệm được rất nhiều thời gian cuối cùng và sẽ giúp việc thêm các tính năng mới ngày càng dễ dàng hơn.

Tôi cũng nói rằng một trong những lý do lớn nhất cho mã xấu là nỗi sợ hãi của một số lập trình viên khi thực hiện tái cấu trúc cấu trúc lớn hơn và bạn càng chờ đợi lâu thì nó càng tệ.

Dựa vào sức mạnh cao hơn

Tôi không có ý cầu nguyện. Ý tôi là, hãy chắc chắn rằng có một anh chàng kinh doanh (tức là người quản lý dự án hoặc tương đương) mà bạn có thể đặt làm đệm giữa bạn và khách hàng. Nếu khách hàng đòi hỏi quá nhiều, hãy để anh chàng kinh doanh đặt chân xuống và sẵn sàng sử dụng "điều đó là có thể nhưng tôi không chắc liệu điều đó có phù hợp với phạm vi của đặc điểm kỹ thuật hay không, xem [anh chàng kinh doanh]".

Trong một luồng dự án bình thường, đặc tả chung nên được đóng băng trước khi diễn ra nghiêm túc.

Nhiều khách hàng sẽ tiếp tục lái xe để thay đổi / cải tiến / cải tiến miễn là bạn cho phép họ. Nhiều người sẽ lạm dụng khả năng đó đến mức tối đa vì điều đó khiến họ cảm thấy như họ đang kiếm được nhiều tiền nhất (ngay cả khi nó phá hoại dự án của bạn).

Có một người chuyên hoàn thiện và đóng băng đặc điểm kỹ thuật sớm và thực thi nó sau này.

Không có gì sai khi làm thêm một chút cho một chút nghiệp tốt với khách hàng nhưng sẵn sàng trì hoãn đến một quyền lực cao hơn khi họ ra khỏi tầm tay. Nếu đặc điểm kỹ thuật yêu cầu số lượng thay đổi vô lý, có lẽ đã đến lúc quay lại vòng lặp kinh doanh và đánh giá lại hợp đồng và / hoặc thêm các bổ sung vào hợp đồng (có bồi thường bằng tiền).

Thực tế là bạn đang gặp vấn đề này ít liên quan đến cách bạn viết mã. Đó là một dấu hiệu cho thấy người quản lý dự án của bạn không được sử dụng đúng mức cho dự án (cho dù đó là lỗi của bạn, lỗi của anh ấy hay cả hai).

Giống như những người khác đã nói trong nhiều câu trả lời, việc thêm bộ đệm thời gian cho các trường hợp dự phòng cũng là cần thiết cho bất kỳ dự án nào nhưng xác định rằng nên quyết định đằng sau cánh cửa đóng kín trước khi đặc tả được đóng băng và giao cho khách hàng bởi PM.

Thiết kế phù hợp ban đầu có thể giúp tránh vấn đề. Và gần như không thể (hoặc rất rất khó) để xem xét tất cả các yêu cầu "có thể" trong tương lai. Vì vậy, sau một thời gian, bao thanh toán lại sẽ đến. Và giải pháp tốt nhất là viết lại mọi thứ.

Nói cách khác: thay vì lắp một tháp pháo vào chiếc Ferrari màu đỏ, hãy xem xét lại các yêu cầu và chế tạo xe tăng.

Giết nó bằng lửa.

Aka tái cấu trúc càng sớm càng tốt: ví dụ: khi mã xấu đến từ thời hạn cuối cùng, tôi sẽ tái cấu trúc sau thời hạn vì bạn không thể (hoặc không nên ít nhất) thêm nhiều tính năng cho đến khi mã hiện có được duy trì nó sẽ làm cho việc gỡ lỗi các mã trong tương lai trở nên khó khăn hơn nhiều.

Viết các bài kiểm tra đơn vị cho các dự án của bạn để kiểm tra trạng thái hiện tại và sau đó cấu trúc lại khi bạn có thời gian, theo cách này bạn tránh phá vỡ dự án của mình trong khi bạn đang cố gắng dọn sạch nó.

Câu trả lời đơn giản nhất. Tôi sẽ ngừng mã hóa dưới bất kỳ hình thức nào, cho đến khi anh ấy có thông số cuối cùng cho chính xác những gì anh ấy / cô ấy muốn bây giờ.

Sau đó, họ cần ưu tiên danh sách các tính năng đó, v.v., để xác nhận những mục nào phải có ngay bây giờ và những mục nào có thể được thực hiện sau ....

Sử dụng kinh nghiệm của bạn để xác định thời gian / chi phí của mỗi tính năng, sau đó cho họ biết, nếu họ muốn điều này, sẽ mất x lượng thời gian và tiền bạc.

Việc bạn đối phó với tội ác lớn về phạm vi tính năng, và họ sẽ tiếp tục bổ sung các tính năng, cho đến khi không có gì được thực hiện hoặc hoàn thành quá kém.

Nói với họ khi bạn có một danh sách cuối cùng, rằng bạn sẽ thực hiện các sửa đổi trong tương lai, tùy theo họ muốn, nhưng cần tập trung vào top 15/20 mà họ phải có ngay bây giờ.

Sau đó, dựa trên thời gian để hoàn thành, hãy nói với họ, rằng sau khi điều này được phát hành, thì bạn sẽ sẵn sàng thảo luận / động não phiên bản tiếp theo.

Khi đã có quyết định cuối cùng về những gì sẽ được thực hiện cho phiên bản hiện tại, tất cả các cuộc thảo luận / ý tưởng / đề xuất phải được dừng lại 100%.

Nếu anh ấy có được ý tưởng không ngừng, hãy bảo anh ấy / cô ấy viết chúng ra, trong danh sách tính năng của chúng cho phiên bản tiếp theo và để bạn tập trung vào việc cung cấp các tính năng quan trọng nhất mà chúng muốn ngay bây giờ.

Nếu họ tiếp tục lãng phí thời gian của bạn tiếp tục thay đổi tâm trí của họ. Sau đó, tôi sẽ ngừng làm việc với dự án và làm việc với các dự án khác, cho đến khi họ hoàn thành quyết định của mình ..

Thật khó để làm, nhưng tính năng creep phạm vi rất hủy hoại thời gian, năng lượng, động lực và suy nghĩ rõ ràng.

Từ quan điểm hoàn thành dự án:

Tìm hiểu từ mã với nhóm của bạn, xem những gì có thể được tái cấu trúc và tái sử dụng vào lần tới, sau đó đi uống bia.

Từ góc độ phát triển:

Kiên nhẫn giải thích lý do tại sao sự phát triển đã dừng lại và giải thích lý do tại sao nó không thể tiếp tục cho đến khi tất cả các thông số kỹ thuật nằm trên bàn và được hiểu. Sau đó, đi uống bia.

Từ góc độ lập kế hoạch:

Yêu cầu tất cả các thông số kỹ thuật lên phía trước và làm việc với mọi người để có sự hiểu biết rõ ràng về con đường phát triển. Thu hút khách hàng / các bên liên quan càng chặt chẽ càng tốt để đảm bảo mọi người trên cùng một trang. Sau đêm đó, mọi người uống bia. Ngày mai, bắt đầu dự án.