Tôi đang lên kế hoạch làm việc / bắt đầu một vài dự án cá nhân có thể kết thúc như công việc hàng ngày của tôi. Nó làm tôi suy nghĩ, tôi nên bắt đầu con đường nào?

• Nguyên mẫu chỉ viết bằng cách viết mã cơ bản có thể khiến tôi mất hàng tấn thời gian để tối ưu hóa và tái cấu trúc để dễ dàng mở rộng.

• Viết mã sạch, tối ưu hóa và tài liệu ngay từ đầu, hãy nhớ rằng nếu sau một thời gian nó sẽ không hiệu quả về mặt chi phí, nó sẽ bị loại bỏ.

Cập nhật: Kết hợp YAGNI với sunpech và câu trả lời của M.Sameer có ý nghĩa hoàn hảo với tôi :) cảm ơn mọi người đã giúp đỡ.

Có một tùy chọn thứ ba ... viết mã sạch thông qua phát triển dựa trên thử nghiệm để thực hiện các yêu cầu cần thiết hiện nay vì YAGNI.

Sự cám dỗ để viết mã không cần thiết vào lúc này nhưng có thể trong tương lai phải chịu một số nhược điểm ... từ Bạn sẽ không cần nó :

• Thời gian sử dụng được lấy từ việc thêm, kiểm tra hoặc cải thiện chức năng cần thiết.
• Các tính năng mới phải được gỡ lỗi, ghi lại và hỗ trợ.
• Bất kỳ tính năng mới nào cũng áp đặt các ràng buộc đối với những gì có thể được thực hiện trong tương lai, do đó, một tính năng không cần thiết bây giờ có thể ngăn việc triển khai một tính năng cần thiết sau này.
• Cho đến khi tính năng này thực sự cần thiết, thật khó để xác định đầy đủ những gì nó nên làm và kiểm tra nó. Nếu tính năng mới không được xác định và kiểm tra đúng cách, nó có thể không hoạt động chính xác, ngay cả khi cuối cùng là cần thiết.
• Nó dẫn đến sự phình to mã; phần mềm trở nên lớn hơn và phức tạp hơn. Trừ khi có thông số kỹ thuật và một số loại kiểm soát sửa đổi, tính năng này có thể không được biết đến đối với các lập trình viên có thể sử dụng nó.
• Thêm tính năng mới có thể đề xuất các tính năng mới khác. Nếu các tính năng mới này cũng được triển khai, điều này có thể dẫn đến hiệu ứng quả cầu tuyết đối với chủ nghĩa kỳ công leo.

Do đó, bạn không nên chỉ tạo nguyên mẫu ... cũng không nên viết mã sạch, tối ưu hóa và tài liệu ngay từ đầu, hãy nhớ rằng nếu trong một thời gian, nó sẽ không hiệu quả về mặt chi phí - nó sẽ bị loại bỏ.

Viết mã mà bạn cần bây giờ biết rằng bạn có thể đáp ứng tốt nhất nhu cầu của ngày hôm nay và ngày mai.

như thường lệ...

Nó phụ thuộc

Nếu bạn đang tạo mẫu để giảm thiểu rủi ro hoặc phơi bày một ẩn số, chỉ cần mã hóa nó và hy vọng sẽ loại bỏ nó khi bạn hoàn thành

Nếu bạn đang tạo nguyên mẫu cho sàng lọc lặp, chỉ cần mã hóa nó và mong đợi sửa đổi và cấu trúc lại nó thường xuyên

Nếu bạn đang bắt đầu viết sản phẩm thực tế nhưng gọi nó là nguyên mẫu để bạn có thể lười biếng , thì đừng lười biếng, và hãy viết nó ngay lần đầu tiên

Nếu bạn đang tạo mẫu, tại sao bạn nghĩ về mã sạch? Ý tưởng của việc tạo mẫu là nó có nghĩa là để chứng minh một khái niệm hoặc ý tưởng và sau đó sẽ bị ném đi.

Tôi sẽ không đồng ý với hầu hết mọi người ở đây bằng cách nói rằng nếu bạn đã suy nghĩ về sự lựa chọn giữa việc viết mã sạch hoặc hoàn thành một cái gì đó nhanh chóng để tạo mẫu, hãy chọn cái sau. Đặc biệt là khi bạn đang nói về sự phát triển giai đoạn đầu. Tôi không nói đừng bao giờ viết mã sạch, tôi đang nói lấy ý tưởng ra, thấy rằng đó là hướng đi, sau đó quay lại dọn dẹp nó - tái cấu trúc.

Là nhà phát triển phần mềm, lần đầu tiên chúng tôi bị cuốn vào việc làm mọi thứ đúng đắn và sạch sẽ, đến nỗi chúng tôi không nhận ra rằng đó không phải là mã chúng tôi đang phân phối, đó là một giải pháp cho một vấn đề .

Tôi nghĩ về mã hóa như tôi sẽ viết một bài báo:

Khi viết một bài báo, chúng tôi bắt đầu ở đâu đó, phác thảo ý tưởng, phác thảo, v.v. Nó sẽ không chứa tất cả các chi tiết hoặc có bất kỳ cái nhìn hoàn chỉnh nào về nó - về cơ bản là bản nháp đầu tiên, tiếp theo là một giây, v.v. Phần lớn sẽ được viết lại, thay thế và / hoặc thậm chí loại bỏ trên đường đến một tờ giấy hoàn thiện và hoàn thiện hơn. (Rõ ràng sự tương tự này không đi xa đến mức nói rằng mã thực sự chưa bao giờ hoàn thành hay cuối cùng giống như một tờ giấy.)

Có hai loại tạo mẫu:

• Nguyên mẫu tiến hóa tiếp tục phát triển thông qua các cải tiến và sửa lỗi để trở thành sản phẩm cuối cùng.
• Nguyên mẫu dùng một lần chỉ tồn tại để thu thập yêu cầu và phản hồi của khách hàng hiệu quả hơn trong giai đoạn đầu của dự án và sau đó bị loại bỏ hoàn toàn và việc phát triển sản phẩm cuối bắt đầu từ đầu.

Theo Capers Jones, các nguyên mẫu tiến hóa tạo ra các sản phẩm chất lượng thấp sẽ đòi hỏi nhiều nỗ lực hơn và thời gian lâu hơn để đạt được sự ổn định.

Vì vậy, nếu bạn đang suy nghĩ về việc tạo mẫu để khách hàng có thể thấy một cái gì đó càng nhanh càng tốt để giúp bạn có ý tưởng tốt hơn và biết thêm chi tiết về các yêu cầu, tốt hơn là trở thành một nguyên mẫu dùng một lần và phát triển mã sạch sau này. Nếu bạn không đủ khả năng đó, hãy viết mã sạch ngay từ đầu và duy trì cẩn thận nhưng vì những người khác đã đề nghị không tối ưu hóa quá mức và không thêm những thứ cho đến khi bạn cần chúng.

Tôi miễn cưỡng bào chữa cho mã hóa bẩn vì bất kỳ lý do. Theo kinh nghiệm của tôi, những người tuyên bố nhanh & bẩn là một cái cớ để tạo mẫu có thái độ đó đối với bất kỳ mã nào, bao gồm cả sản xuất. Nếu ai đó tạo ra một nguyên mẫu lộn xộn, anh ta tạo ra mớ hỗn độn trong bất kỳ mã nào. Tạo mẫu không có nghĩa là mã hóa bẩn, nó có nghĩa là các giả định đơn giản hóa để kiểm tra các trường hợp sử dụng quan trọng nhất. Mã này có thể không được kiểm tra chính thức, hoặc quan tâm đến tất cả các chi tiết, nhưng nó vẫn phải được thiết kế tốt và được triển khai tốt. Sự sạch sẽ là một dấu hiệu của năng lực, các lập trình viên có năng lực cảm thấy ghê tởm tự nhiên đối với mã lộn xộn, bất kể mục đích của nó là gì.

Viết mã sạch, tối ưu hóa và tài liệu ngay từ đầu. Tôi không có khả năng tự làm điều đó và đó là một vấn đề thực sự. Tôi không phải là lập trình viên, nhưng tôi đã làm việc cho các công ty phát triển phần mềm trong vai trò quản lý khách hàng với số tiền khá lớn và vì họ cho tôi rất nhiều ý tưởng hay, tôi thỉnh thoảng xây dựng một nguyên mẫu cho một cái gì đó. Gần như mỗi lần nguyên mẫu đó được trao cho một nhà phát triển đã "dọn sạch" và biến nó thành một sản phẩm vận chuyển. Khi tôi kiểm tra nguồn, nó vẫn sẽ là 80-90% mã tào lao của tôi.

Một đồng nghiệp của tôi nhiệt tình tán thành việc tạo mẫu lặp đi lặp lại, với lời cảnh báo rằng người ta phải có đủ kỷ luật để ném từng nguyên mẫu đi và viết lại từ đầu - và không chỉ vậy, đảm bảo rằng người ta không bị ảnh hưởng bởi các chi tiết thực hiện được quyết định trong lần trước , như những gì người ta kết thúc là viết cùng một nguyên mẫu theo một phong cách khác thường nhiều lần. Ông nghiêm túc đề nghị rằng nếu bạn thực sự gắn bó với một đoạn mã tuyệt vời mà bạn không thể loại bỏ, thì bạn nên in nó ra, xóa kho điều khiển nguồn và đăng bản in cho chính mình - nó sẽ biến mất đủ lâu để nó không thể xâm nhập vào lần lặp tiếp theo.

Bạn luôn có thể bắt đầu bằng cách làm cho nó hoạt động (tất cả), sau đó sửa lại để làm cho nó sạch sẽ, và sau đó làm cho nó nhanh / nhỏ nếu nó có ý nghĩa kinh tế để làm điều đó. Tôi sẽ bắt đầu với một số thí nghiệm bạn vứt đi, sau đó TDD trở lại sự tồn tại khi bạn nắm được những gì hoạt động.

Cả hai đều tốt. Cả tôi đều thích. Họ không mâu thuẫn với nhau.

Tôi thích nguyên mẫu. Prototyping đang phát triển kỹ năng sáng tạo của tôi. Tôi đang thử nghiệm nhiều giải pháp khả thi. Làm điều đó nhanh chóng cho tôi một khả năng để kiểm tra rất nhiều cách có thể để giải quyết vấn đề.

Tôi thích viết sạch, mã kiểm tra tốt. Nó phát triển các kỹ năng cốt lõi của tôi. Tôi thường chọn một trong các nguyên mẫu và cải thiện nó hoặc viết lại từ đầu.

Nhưng bạn không bao giờ nên nhầm lẫn nguyên mẫu từ mã sản xuất. Nguyên mẫu không bao giờ nên đi vào sản xuất. Nó phải luôn được đánh dấu là nguyên mẫu. Tốt nhất làm tất cả các nguyên mẫu trong chi nhánh của riêng bạn.

Tôi có xu hướng nói rằng cực đoan hầu như luôn luôn xấu.

Tôi khuyên nên giữ sự cân bằng giữa sạch sẽ, tài liệu tốt và tạo mẫu. Khi bạn phát triển cho một thư viện hoặc nền tảng, bạn không có kinh nghiệm với tôi đi sâu hơn vào hướng tạo mẫu. Điều đó đặc biệt đúng ở thời điểm bắt đầu và đối với các nền tảng, ví dụ như Android hoặc container, đưa bạn vào corset của họ. Điều đó có nghĩa là bạn thực hiện giao diện của họ và họ gọi cho bạn.

Theo kinh nghiệm của riêng tôi, hầu hết các mã không tồn tại được lâu. Điều đó nói rằng, hãy đi nhanh bằng cách thực hiện tính năng của bạn. Khi sớm hay muộn (hầu hết thời gian sớm hơn), bạn cần phải làm lại / cấu trúc lại mã hiện tại của mình vì tính năng tiếp theo bạn dọn dẹp đặc biệt là các phần phức tạp khi làm việc. Hãy chú ý để có các bài kiểm tra tự động thích hợp để thực hiện tái cấu trúc không rắc rối. Xác nhận các nền tảng được đề cập ở trên như Android: thường thì họ thực hiện kiểm tra tự động không dễ dàng vì khớp nối chặt chẽ và không có thiết kế để kiểm tra. Sau đó, bạn có thể nâng cơ sở kiểm tra của mình lên mức cao hơn, ví dụ: kiểm tra tích hợp.

Tôi đã viết một bài viết có thể đưa ra một số gợi ý về việc bắt đầu: https://medium.com/@ewaldbenes/start-lean-why-its-best-to-split-your-next-coding-project-by-feature-70019290036d