Giữ nó đơn giản bây giờ, hoặc chương trình với tương lai trong tâm trí?

Tôi hiện đang mã hóa một ứng dụng mới cho công ty của mình có liên quan. Để đáp ứng thời hạn, chức năng đã được giảm xuống khá nhiều để chúng tôi có thể có một cái gì đó sẵn sàng để ra mắt.

Tôi đã được giao nhiệm vụ đưa phiên bản 1 lên và chạy vào cuối tháng. Tôi đang đi được một nửa chặng đường phát triển và tôi đã đi đến điểm rằng bây giờ đã có kết thúc.

Hôm qua, tôi đã dành một chút thời gian để đưa ra một giải pháp dễ dàng rất tốt cho một trong những yêu cầu và khá tự hào về cách nó bật ra. Sáng nay, tài liệu phiên bản 2 đã được gửi đi, và có một yêu cầu trong đó sẽ yêu cầu mã tôi đã viết ngày hôm qua phải bị rút ruột, hoặc bị thay đổi nghiêm trọng. Nó sẽ đòi hỏi rất nhiều công việc trong tương lai nếu tôi để nó như vậy. Bây giờ tôi có thể mất thêm một ngày để làm cho giải pháp hiện tại của mình mạnh mẽ hơn để tính năng v2 có thể được thêm vào với ít nỗ lực hơn, nhưng điều đó sẽ khiến tôi chậm hơn một chút cho mã hóa bổ sung mà nó yêu cầu.

Tôi không biết nếu tôi sẽ làm v2. Đó có thể là tôi hoặc có thể là đồng nghiệp, hoặc thậm chí là thực tập sinh.

Nếu bạn ở trong đôi giày của tôi, bạn sẽ dành thời gian ngay bây giờ để làm cho nó dễ dàng hơn trong tương lai, hoặc bạn sẽ rời khỏi giải pháp của mình và giải quyết nó khi thời gian đến?

Nếu thời hạn là Khắc trong đá, chỉ cần hoàn thành những gì bạn phải đáp ứng. Hãy chắc chắn rằng bạn tăng các ước tính cho v2 để bổ sung cho các thay đổi mã cho yêu cầu mới. Ngoài ra, hãy chắc chắn ghi lại ngắn gọn những gì bạn nghĩ sẽ cần thay đổi cho các tính năng v2 mới để đồng nghiệp có thể nhận nó nếu bạn được gán lại cho thứ khác.

Nếu có đủ độ linh hoạt trong thời hạn (1 ngày, bằng âm thanh của nó, vì vậy hãy nhắm đến gia hạn 2,5 ngày), thì chắc chắn, hãy tiếp tục và viết mã cho tương lai đã biết!

Tránh rơi con mồi (sớm) vào Hiệu ứng hệ thống thứ hai . Dưới đây là một số kỹ thuật tốt để áp dụng:

1. Chắc chắn tránh loại bỏ lan can phiên bản 1 chỉ vì những gì bạn thấy trong phiên bản 2. Lập kế hoạch trước là tốt, nhưng người tạo ra thông số kỹ thuật v2 phải chịu trách nhiệm cho sự thất bại của v2, chứ không phải v1.
2. (Nếu có thể) hãy xem liệu bạn có thể yêu cầu người tạo thực hiện lại các yêu cầu cho phiên bản 2 không yêu cầu thay đổi lớn hơn bây giờ không - và sau đó lên kế hoạch cho chúng sau, có thể cho v3.
3. Hãy ghi nhớ YAGNI , nhưng cố gắng mã hóa cho khả năng mở rộng - tránh các số ma thuật, giá trị mã hóa cứng, viết các bài kiểm tra đơn vị tốt hoặc hợp đồng mã, v.v. Áp dụng các kỹ thuật tốt từ sớm sẽ giúp tái cấu trúc và thay đổi mã ít gây đau đớn hơn.

Hầu hết các dự án phần mềm phát triển như thành phố đều thành công trong thời gian dài. Kế hoạch tiến hóa chỉ trong tương lai hạn chế cho phép phần mềm của bạn phát hành đúng thời hạn và với các chức năng cần thiết khi phát hành - và không còn nữa. Xem đoạn trích này từ Carl Sagan:

Sự sắp xếp [của một thành phố] có thể hiệu quả hơn nếu tất cả các hệ thống dân sự được xây dựng song song và thay thế định kỳ (đó là lý do tại sao các vụ hỏa hoạn thảm khốc xảy ra ở London và Chicago, ví dụ, đôi khi là một sự trợ giúp trong quy hoạch thành phố). Nhưng việc bồi đắp chậm các chức năng mới cho phép thành phố hoạt động liên tục ít nhiều trong nhiều thế kỷ.

• Carl Sagan, Vũ trụ : http://www.eridanus.info/genesis.html

Không thêm mã ngày hôm nay cho yêu cầu của tháng tới. Hôm nay bạn nên viết mã sạch nhất bạn có thể cho các yêu cầu bạn có. Tôi nghi ngờ rằng một ngày làm việc sẽ tiết kiệm nhiều ngày sau đó. Tôi đã nghe những tuyên bố như vậy và không thể nhớ lại một trường hợp nào là đúng. Bạn có thể thuyết phục tôi bằng cách hiển thị một số mã, nhưng kinh nghiệm của tôi cho tôi biết điều đó là không thể.

Để nguyên như nó là.

Các nhà phát triển thực sự CHẤP NHẬN một dự án kế thừa thực hiện những gì nó được cho là phải làm và không còn nữa.

Điều gì, ngày hôm nay, có vẻ như là một ý tưởng tốt để "dàn dựng" cơ sở mã để đáp ứng yêu cầu "tương lai", trong tất cả khả năng sẽ đóng vai trò là một trở ngại để hiểu mã trong tương lai. Không ai thích đối phó với chức năng được thực hiện một phần và dấu tích của các yêu cầu ảo bị lãng quên. Tôi không nói rằng đó sẽ là trường hợp, nhưng mọi thứ thường diễn ra theo cách đó mặc dù có ý định tốt nhất.

Câu trả lời tốt. Tôi chỉ nói thêm - những gì tôi làm trong trường hợp như thế này là một sự khác biệt tốt để tôi có thể nắm bắt những gì tôi đã làm và thu dọn nó ở một nơi an toàn. Sau đó, nếu cơ hội đến để làm điều đó một lần nữa trong phiên bản tiếp theo, nó sẽ dễ dàng.

Nói chung, một nhà phát triển giỏi dự đoán các yêu cầu trong tương lai, nhưng khi thời hạn sắp hết, đã đến lúc trả lời các lỗi trong những gì bạn đã có và không "đá thuyền".

Nó phụ thuộc. Có một quy tắc lỗi thời: đối xử với người khác như bạn muốn được đối xử với chính mình. Bạn sẽ làm gì nếu đó là dự án của riêng bạn và bạn biết tất cả các ưu tiên?

Nếu v2 chắc chắn là bắt buộc và thời hạn chỉ là mong muốn chứ không phải là khó khăn thì đừng tạo ra nợ kỹ thuật và sửa chữa cánh buồm của bạn trong khi thời tiết tốt. Ngay cả khi người khác sẽ làm v2, họ sẽ đánh giá cao tầm nhìn xa.

Nếu có bất kỳ nghi ngờ nào về sự cần thiết của v2 thì hãy gắn bó với YAGNI. Ngoài ra, nếu bạn ở phía bên kia của quang phổ và có một trong những khách hàng liên tục spam bạn với ý tưởng của họ trước khi chúng hình thành thì hãy kiểm tra email của bạn chỉ 2 hoặc 3 lần mỗi ngày và đừng vội vã hành động, bạn sẽ ngạc nhiên có bao nhiêu "vấn đề" và yêu cầu trở nên không liên quan trước khi bạn đọc chúng.