Khi nào nó trở nên quá mức cần thiết?

Trước hết, tôi xin lỗi vì tôi không biết cách tạo ra một chủ đề cộng đồng; vậy ai đó giúp tôi với.

Là một nhà phát triển, trên nhiều nền tảng, công nghệ và thậm chí ở cấp độ cơ sở hạ tầng; Tôi luôn thấy mình tự hỏi, khi nào tôi làm quá nhiều?!?

Đó là một quá trình học tập không bao giờ kết thúc, kể từ khi tôi bắt đầu. Một (1) điều tôi học được là các yêu cầu hầu như không có giá trị trong một khoảng thời gian dài, và vì một tầm nhìn xa như vậy có thể đi một chặng đường dài.

Nhưng số dư ở đâu và làm thế nào để bạn biết khi nào bạn mất thời gian, không đạt được nó?!

Bạn đang làm quá nhiều khi nhà phát triển trung bình không thể hiểu những gì bạn đã làm bằng cách đọc mã của bạn.

• Thực hiện đánh giá mã thường xuyên với nhóm của bạn.
• Thảo luận với các kiến ​​trúc, công nghệ hoặc các mẫu bạn dự định sử dụng. (trong các cuộc họp độc lập hàng ngày nếu bạn có chúng)

Tôi chiến đấu với tất cả các "kiến trúc sư" CV mà tôi gặp phải. Tôi muốn mái vòm tồn tại! ;)

Tôi tin rằng thế giới đang lãng phí một đống tiền khổng lồ mà chúng ta có thể sử dụng để cải thiện cuộc sống (lập trình viên) của mình.

Khi các quá trình vượt qua kết quả.

Đã nhiều lần chúng ta thấy rằng nếu các nhà phát triển tập trung nhiều hơn vào quy trình hơn là kết quả (như về chất lượng, làm cho thời hạn, v.v.) thì những điều tồi tệ bắt đầu.

Đây là lý do tại sao không bao giờ nên quên rằng mục đích của đánh giá mã, mẫu thiết kế, v.v. là để làm cho mã tốt hơn, nhưng bản thân chúng không phải là mục tiêu.

Đối với tôi, tôi thích cách tiếp cận mà Kent Beck đưa ra trong XP (không chắc đó là ý tưởng "của anh ấy" hay của người khác nhưng đó là nơi tôi nghe thấy lần đầu tiên):

Nó đủ khó để giải quyết các vấn đề ngày nay mà không cố gắng tìm ra vấn đề của ngày mai là gì và cũng giải quyết chúng.

Các nhà phát triển có thể dành nhiều thời gian cho các giải pháp cho các yêu cầu không tồn tại, các trường hợp cạnh sẽ không bao giờ xảy ra hoặc thậm chí là các vấn đề thực sự trong đó tác động của vấn đề thấp hơn đáng kể so với chi phí ngăn chặn.

Đây là thời gian có thể được đưa vào những thứ mà người dùng sẽ thực sự muốn và sử dụng, những thứ sẽ mang lại cho họ những lợi ích sẽ lớn hơn nhiều so với sự bất tiện sẽ xảy ra trong trường hợp không thể xảy ra khi một trong những điều này thực sự xảy ra.

Ngoài kết quả không tối ưu này cho người dùng, tác động đối với nhà phát triển kỹ thuật quá mức theo cách này có xu hướng vượt qua mã phức tạp, khó hỗ trợ hơn và khó tăng cường hơn.

Vì vậy, đối với tôi nếu bạn biết, hoặc có thể khá chắc chắn, rằng một cái gì đó là một yêu cầu hoặc sẽ gây ra vấn đề thì hãy giải quyết nó, nếu không thì không.

Bạn có thể phải quay lại và làm lại khi nhận ra rằng có một yêu cầu rộng hơn so với bạn đã thực hiện ban đầu, nhưng nhìn chung tổng nỗ lực bạn bỏ ra trong dự án vẫn sẽ thấp hơn vì trong hầu hết các trường hợp sẽ không xảy ra.

Câu hỏi của bạn khá mở, vì vậy tôi sẽ hiểu nó là "làm quá nhiều cho một phần của dự án":

Đối với tôi, thật dễ dàng để dành quá nhiều thời gian cho một cái gì đó không thực sự mang lại nhiều lợi ích cho khách hàng. Thông thường, đó là những điều nhỏ bé như "Chà, nó hoạt động, nhưng không hoàn toàn giống như tôi muốn", nơi khách hàng có thể sẽ không quan tâm nếu nó hoạt động theo cách này hay cách khác.

Khi điều đó xảy ra, tôi nên dừng nó lại và dành thời gian cho những thứ quan trọng hơn. Tốt hơn là sản phẩm hoạt động tốt hơn không nhưng bạn có những bộ phận nhỏ hơn hoạt động hoàn hảo.

Viết mã theo dõi (từ Code Complete ) có lẽ là một ý tưởng tốt để tránh điều này: Bạn bắt đầu dự án của mình bằng cách viết mã kết nối toàn bộ mã - từ GUI (hoặc gần với nó) cho đến phần phụ trợ và sau đó quay lại. Bằng cách đó, bạn luôn có thứ gì đó hoạt động và bạn không dành thời gian để hoàn thiện những thứ nhỏ nhặt cho đến khi toàn bộ hoạt động.

Nhưng vẫn là một vấn đề kỷ luật và ưu tiên.

Khi tôi trả lời không cho "tôi sẽ nổi điên tôi đã không làm điều này sau đó và nó đã cắn tôi ..

Các hạn chế về tài nguyên và thời gian của IRL thường giúp tôi trước khi tôi phải hỏi câu hỏi này nhiều. Tại thời điểm đó, bạn chỉ cần tập trung vào các bit quan trọng nhất / có thể đạt được và hy vọng điều tốt nhất.

một quá trình học tập không bao giờ kết thúc thực sự! ... Và tôi nghĩ nó vẫn như vậy! Sự cân bằng là khi mọi thứ đủ hiệu quả và bạn có thời gian để làm một cái gì đó khác ngoài lập trình. Tôi sẽ đồng ý với gablin "một vấn đề kỷ luật và ưu tiên" và jim hopkins về việc nó sẽ trở thành bản năng sau một thời gian. Tôi biết rằng hoàn thiện các bộ phận nhỏ là điều khiến chúng tôi hạnh phúc nhưng cuối cùng tất cả chỉ là điều khiến người dùng cuối hài lòng. vì vậy tôi muốn nói rằng sự cân bằng (hoặc có thể là sự thỏa hiệp) sẽ làm cho người dùng cuối / khách hàng / khách hàng hài lòng trước (nên là kế hoạch A) và sau đó nếu có thời gian để hoàn thiện - làm cho "các bộ phận nhỏ" của bạn hiệu quả hơn và / hoặc mọi thứ khác bạn vui lòng. Đến một lúc nào đó bạn phải nói "đủ" mặc dù vậy :) nếu không, nó sẽ trở thành quá mức cần thiết!

trường hợp xấu nhất dĩ nhiên là khi người dùng cuối / khách hàng / khách hàng là bạn! :)