Cầu toàn có thể tốt và xấu khi lập trình.
Hãy bình luận nếu câu hỏi không rõ ràng.
Câu trả lời:
KISS và YAGNI , đặc biệt là YAGNI.
Chỉ thiết kế một giải pháp cho những điều bạn biết bạn sẽ cần sớm. Đừng thiết kế nó cho những thứ có thể cần trong hai năm, bởi vì rất có thể bạn sẽ cần những thứ rất khác nhau và dù sao cũng sẽ phải thiết kế lại nó.
Khoảnh khắc bạn bắt đầu nói về "với thiết kế này vào một thời điểm nào đó trong tương lai chúng ta có thể làm X, hoặc thậm chí là Y", thay vì "thiết kế này cho phép chúng tôi thực hiện yêu cầu khách hàng Z trong phiên bản tiếp theo", đó là khi bạn nhận được vào thiên văn kiến trúc.
Đáp lại các ý kiến:
YAGNIcho đến ngày hôm nay.
Sử dụng một cách tiếp cận lặp đi lặp lại và vấn đề này chủ yếu biến mất. Mã của bạn nên chạy vào ngày đầu tiên và gần như mỗi ngày sau đó. Đáp ứng các yêu cầu tối thiểu trước và thêm nhiều hơn khi bạn có thời gian. Không bao giờ đi lạc thay đổi lớn, nơi bạn không thể chạy mã của bạn trong một thời gian dài.
Một giải pháp là quá mức khi có thêm thời gian để hoàn thành nó đáng giá hơn tác động tiêu cực tiềm ẩn từ khi giải pháp dễ dàng kết thúc đến khi nó sẽ được nâng cấp / sửa đổi một cách tự nhiên.
Về cơ bản bạn đang giao dịch thời gian với thời gian sau này. Nếu bạn dành nhiều thời gian hơn bây giờ thì bạn sẽ tiết kiệm sau, bạn đang làm sai. Nếu bạn thực sự quá kỹ thuật, bạn đang dành thời gian mà không ảnh hưởng đến bao nhiêu thời gian (hoặc thậm chí làm cho nó nhiều hơn) bạn dành sau này.
Bạn trở nên tốt hơn khi làm việc này với nhiều kinh nghiệm hơn bạn có. Cách tốt nhất để thực hiện mọi thứ (từ kinh nghiệm của tôi) là làm những gì bạn cần bây giờ, nhưng theo cách dễ dàng nhất được tăng cường nên sau này yêu cầu đòi hỏi nó. Làm việc ra sao để làm điều đó là một chút khó khăn.
Tôi từng rất cầu toàn (dành thời gian tạo khung chứ không phải giải pháp).
Nhưng điều thực sự giúp tôi tăng tốc sản xuất là học và tuân theo các nguyên tắc của BDD / TDD, bao gồm cả nguyên tắc bên ngoài (điều mà tôi thấy rất khó để học để nắm lấy).
Điều này thực sự dạy tôi không viết một dòng mã nào trước khi có một bài kiểm tra cho nó. Nhưng các bài kiểm tra đơn vị không tồn tại trước khi kiểm tra chấp nhận tồn tại cho nó. Và các bài kiểm tra chấp nhận xuất phát từ nhu cầu người dùng thực sự.
Vì vậy, tất cả các dòng mã bắt nguồn từ một nhu cầu người dùng thực sự.
Nếu bạn không quen thuộc với bên ngoài về nguyên tắc, điều đó cho thấy rằng bạn bắt đầu viết bài kiểm tra cho lớp ngoài cùng trong ứng dụng của mình (tức là GUI trong hầu hết mọi trường hợp) bằng cách sử dụng kiểm tra nhân đôi để mô phỏng hành vi của các lớp thấp hơn. Sau đó, bạn thực hiện vừa đủ để các bài kiểm tra vượt qua. Việc triển khai lớp trên cùng sau đó ra lệnh cho các bài kiểm tra bạn cần viết cho lớp tiếp theo, v.v., cho đến khi bạn nhấn vào lớp dưới cùng của ứng dụng.
Tôi nhận thấy tôi trở nên tốt hơn về điều này bằng kinh nghiệm.
Khi còn trẻ, tôi luôn tìm giải pháp hoàn hảo nhất, không thỏa hiệp. Bây giờ tôi tốt hơn trong việc giữ những thứ như ngân sách và thời gian trong tâm trí.
Giới hạn thời gian vẽ đường này khá rõ ràng.
Ông chủ của tôi thực sự :)
Tôi phải thừa nhận rằng tôi đang trở nên tốt hơn, nhưng tôi vẫn không có nhiều sự thỏa hiệp. Rất may tôi đã có ông chủ của tôi để giúp tôi trở lại;)
Tuy nhiên, tôi muốn đưa ra một vấn đề khác ngoài việc áp đảo, vì việc áp đảo là khá dễ dàng để phát hiện.
Vấn đề chính của tôi là với tái cấu trúc. Vấn đề là hầu hết mọi lúc, mặc dù tôi đã cố gắng viết mã tốt nhất có thể, tôi không biết lại những gì tôi biết bây giờ (đã thấy nhiều mã hơn, nhiều mẫu hơn, thành ngữ mới, vấn đề mới, mới các giải pháp). Và vì vậy, mặc dù nó hoạt động, bây giờ tôi biết cách tốt hơn để làm điều đó:
Tuy nhiên, nó hoạt động như nó vốn có, và do đó tái cấu trúc nó không phải là ưu tiên hàng đầu, và sự thật là nó cằn nhằn tôi; Tôi hiểu lý do kinh tế và tôi hiểu những kỳ vọng của khách hàng (họ không thấy mã và thích các tính năng mới và sửa lỗi), nhưng tôi ước mình vẫn còn thời gian để làm việc với nó.
Hiện tại, tôi chỉ làm theo lệnh của sếp, nhưng tôi phải thừa nhận rằng tôi cảm thấy không yên tâm khi biết rằng mã được đưa vào sản xuất không phải là thứ tốt nhất tôi có thể nghĩ ra bây giờ. Cầu toàn, tôi đoán vậy.
Cả về chuyên môn và cá nhân, tiêu chuẩn tôi cố gắng áp dụng cho bản thân là:
Hãy hài lòng với chiến thắng.
Nếu mã của tôi giải quyết được vấn đề thì nó có nghĩa là giải quyết và không tạo ra bất kỳ vấn đề mới nào *, rất có thể đã đến lúc phải tiếp tục. Khi bạn học cách đặt thanh cao đến mức cần thiết, "Đủ tốt" sẽ trở thành, tốt, đủ tốt.
Sự hoàn hảo giống như tốc độ của ánh sáng: bạn sẽ không bao giờ đến đó, nhưng không có giới hạn đối với năng lượng bạn có thể dành để thử.
(* - Lưu ý rằng "Buggy" và "Khó bảo trì" đều nằm trong tiêu đề của "Các vấn đề mới". Vì vậy, tôi không gọi nó là hoàn chỉnh cho đến khi mã được kiểm tra, đã cắt các bit thừa và đã cắt các tài liệu nhận xét / API được cập nhật.)
Với kinh nghiệm tôi đã nhận ra rằng sự hoàn hảo thậm chí không thể xảy ra cho đến khi tôi đã có ít nhất vài năm dưới vành đai trong bất kỳ bối cảnh cụ thể nào (ngôn ngữ, khung, nền tảng, tiêu chuẩn). Là một người mới, sẽ có tất cả các loại idiosyncrasies mà bạn sẽ không nhận ra (thoát, ưu tiên, từ dành riêng, đường cú pháp, thời gian chờ, cuộc gọi không đồng bộ, tính năng & lỗi không có giấy tờ), vì vậy tôi chỉ thử một giải pháp tốt trong khi học càng nhiều càng tốt Điều quan trọng, tôi luôn cố gắng làm cho nó đơn giản để cấu trúc lại kết quả - Kiến trúc mô đun, nhận xét khi cần và không có thủ thuật thông minh .
Tôi, giống như nhiều lập trình viên khác, có rất nhiều mã kế thừa để duy trì. Sự cám dỗ để làm lại tất cả sẽ luôn ở đó, nhưng về cơ bản, tôi đã đun sôi nó theo một nguyên tắc:
Tôi (hoặc người khác) sẽ phải tìm ra điều này một lần nữa ?
Điều đó thường chăm sóc rất nhiều mã spaghetti thành mã spaghetti-chunk dễ quản lý hơn. Tóm tắt một số khối, ném vào các bài kiểm tra của bạn, và bây giờ nó không cần quá nhiều sự hoàn hảo.