Những cám dỗ có hại trong lập trình

Chỉ tò mò, những loại cám dỗ trong lập trình hóa ra thực sự có hại trong các dự án của bạn?

Giống như khi bạn thực sự cảm thấy thôi thúc phải làm một cái gì đó và bạn tin rằng nó sẽ mang lại lợi ích cho dự án nếu không bạn sẽ tự lừa mình tin vào điều đó, và sau một tuần bạn nhận ra rằng bạn đã giải quyết bất kỳ vấn đề thực sự nào mà thay vào đó tạo ra những vấn đề mới hoặc thay vào đó , trong trường hợp tốt nhất, làm hài lòng con thú bên trong của bạn mà không có tác động rõ ràng.

Cá nhân, tôi thấy rất khó để không cấu trúc lại mã xấu. Tôi làm việc với rất nhiều mã kế thừa xấu và phải hít một hơi thật sâu để không chạm vào nó khi tôi không có bài kiểm tra nào để chứng minh việc tái cấu trúc của mình không phá vỡ bất cứ điều gì.

Một con quỷ khác đối với tôi trong giao diện người dùng, tôi thực sự có thể dành hàng giờ để thay đổi bố cục UI chỉ vì tôi thích làm việc đó. Đôi khi tôi tự nhủ mình đang làm việc với khả năng sử dụng, nhưng sự thật chỉ là tôi thích di chuyển các nút xung quanh.

Quỷ lập trình của bạn là gì, và làm thế nào để bạn tránh chúng?

Tổng quát hóa sớm là lỗi lớn của tôi; thay vì giải quyết vấn đề trước và chờ đợi cho đến khi có nhu cầu thực sự cần giải quyết cho trường hợp chung, tôi luôn theo dõi vụ việc chung trước và viết lên một tấn mã phức tạp hơn mức cần thiết.

Cập nhật:

Xem " Tội lỗi số 1 - Tổng quát hóa sớm " để biết mô tả chuyên sâu.

"Chúng tôi sẽ quay lại vấn đề này và sửa nó sau. Chúng tôi chỉ cần nó hoạt động ngay bây giờ!"

Hạn chót là rất xa, tôi có quá nhiều thời gian để làm điều đó, vậy tại sao không dành một chút thời gian để lướt web?

"Đây chỉ là mã bằng chứng khái niệm vứt đi. Một khi họ thích nó, tôi sẽ thực sự làm cho nó tốt."

1. Tái cấu trúc một phần của mã một vài ngày trước khi phát hành.
2. Internet: Sự phân tâm lớn nhất của tất cả.
3. Công nghệ mới : Không thể rời tay khỏi công nghệ mới.
4. Tối ưu hóa: Tối ưu hóa, Tối ưu hóa. .. và tối ưu hóa hơn nữa
5. Sự hoàn hảo : Không bao giờ hài lòng với mã.
6. TODO: Thiếu todos thời gian sẽ không bao giờ được thực hiện.
7. Ước tính thời gian: Nhiều PM không coi đây là "ước tính". Họ coi như thực tế.
8. Lời hứa: Đưa ra quá nhiều lời hứa.

Trở thành con mồi để cố gắng xây dựng mọi thứ trong nhà, khi có các khung và thư viện hiện có.

Quỷ tái phát của tôi: Tối ưu hóa sớm và áp đảo.

Và tôi vẫn không thể tránh họ 100% ...

Ước tính quá lạc quan

Khi người quản lý của bạn đang nhìn chằm chằm xuống bạn và bạn cảm thấy cảm giác nóng bỏng muốn đưa ra ước tính thấp hơn so với ruột của bạn đang nói với bạn ... đừng làm điều đó!

Rốt cuộc, ruột của bạn có lẽ đã quá thấp rồi!

Để sử dụng một công nghệ / công cụ / ngôn ngữ trong dự án của bạn hoàn toàn vì bạn vừa mới học nó.

Để cố gắng chứng minh bạn là một nhà phát triển giỏi như thế nào.

Để xem xét mã bạn đã viết là của bạn.

Tôi sẽ nghỉ ngơi và xem stackoverflow.com;)

Sự cám dỗ tồi tệ nhất:

Oh, tốt .. Tôi đoán một mẹo nhỏ / hack / sửa chữa bẩn sẽ không bị tổn thương.

Đoán xem, nó có đau không. :)

Quên rằng viết mã là biện pháp cuối cùng để giải quyết vấn đề .

Creep tính năng

Lập một kế hoạch, bám sát và triển khai. Và sau đó quay lại và thêm những thứ mà mọi người đang yêu cầu.

Tôi đã thấy điều này nhiều lần. Bạn ngồi xuống, thiết kế và bắt đầu viết mã. Người dùng nghe thấy một số điều vô nghĩa nhầm lẫn về tính năng yêu thích của họ bị "mất tích" và họ bắt đầu vận động hành lang cho nó. Sếp của bạn yêu cầu bạn thêm nó vào giờ thứ 11, nó phạm lỗi khi triển khai, nó giới thiệu các lỗi ở khắp mọi nơi và 3 tháng sau, khi mọi người đã ổn định, bạn sẽ được yêu cầu xóa nó, bởi vì không ai có thể hiểu tại sao bạn đặt tính năng retro nhảm nhí ở nơi đầu tiên! Bạn không thể nói rằng phần còn lại của thiết kế làm cho nó vô nghĩa?

1. Thêm nhiều tính năng

2. Cuộc thi có tính năng này. Vì vậy, đây là một tính năng phải có do đó lập trình nhiều hơn là phân tích chiến lược, định vị, v.v.

3. Cuộc thi KHÔNG có tính năng này. Vì vậy, đây là một tính năng khác biệt do đó lập trình nhiều hơn là phân tích chiến lược, định vị, v.v.

4. Giải quyết một vấn đề kinh doanh với lập trình nhiều hơn. ví dụ, chuyên môn tốt hơn trong việc quản trị máy chủ linux, trang web của bạn được lưu trữ trên không thể có được thông qua lập trình nhiều tính năng hơn. Đôi khi bạn chỉ cần học cách khắc phục sự cố thay vì mã hóa lại toàn bộ vào C # .Net

5. Giải quyết một vấn đề tiếp thị với lập trình nhiều hơn. ví dụ: lạm dụng khái niệm con bò tím của Seth Godin rằng bạn đang gián tiếp giải quyết vấn đề tiếp thị bằng cách lập trình thêm các tính năng vào sản phẩm của bạn để biến nó thành "con bò tím". Đôi khi, nó chỉ là một con quái vật đột biến.

6. Giải quyết vấn đề năng suất với việc lập trình nhiều hơn cho chính mình rằng thời gian viết kịch bản này sẽ được lưu lại trong vài giờ trong tương lai thay vì thực sự lập trình những thứ thực sự quan trọng

7. Lập kế hoạch để mã nhưng chưa mã hóa vì bạn muốn "làm cho đúng"

8. Mã hóa một phiên bản bẩn và hứa rằng bạn sẽ "làm cho nó tốt hơn sau này" nhưng không bao giờ quay lại để "làm cho nó tốt hơn"

9. Không thực hiện một mockup hoặc sơ đồ trang web vì nó "quá rắc rối". Tôi chỉ có thể chụp màn hình các trang của đối thủ cạnh tranh cho mockup và vẽ sơ đồ trang web "sau này" không bao giờ có. Và sau đó chỉ cần đi thẳng vào lập trình trang đầu tiên tôi hình dung trong đầu.

Thú nhận: Cá nhân tôi đã mắc lỗi 1, 3, 7, 8. Tôi cũng đã mắc 2, 4, 5, 6 nhưng thường tự lừa dối bản thân mình rằng tôi đã không làm.

Tôi hiện đang khắc phục 9.

EDIT Không nhận ra câu hỏi yêu cầu chúng tôi đưa ra giải pháp.

1) Thêm nhiều tính năng Chỉ cần không làm điều đó. Làm việc với doanh nghiệp, tiếp thị, người sáng lập, cố vấn, v.v. và tước ứng dụng của bạn chỉ còn 1 điều.

Hãy đọc về twitter, Groupon , v.v ... về cách họ chỉ loại bỏ mọi thứ xuống chỉ còn 1 điều dẫn đến thành công của họ.

Nếu bạn nghĩ rằng nó chỉ hoạt động nếu bạn muốn xây dựng các công ty lớn, hãy nghĩ lại. Ctrl + F cho dòng này "Tôi càng thêm nhiều tính năng vào phần mềm, nó càng bán kém hơn (Điều này, không cần phải nói, rất không trực quan đối với hầu hết các nhà phát triển phần mềm.)" Trong liên kết này

2) Cuộc thi có tính năng này. Vì vậy, đây là một tính năng phải có

Xem giải pháp 1

3) Cuộc thi KHÔNG có tính năng này. Vì vậy, đây là một tính năng khác biệt

Xem giải pháp 1

4) Giải quyết một vấn đề kinh doanh với lập trình nhiều hơn.

Nếu bạn cần thuê một ai đó để dạy bạn, tư vấn, hoặc làm điều đó cho bạn và sau đó ghi lại cách anh ấy đã làm, để bạn có thể tự làm điều đó vào lần tới. CỨ LÀM ĐI!! Không viết lại mã, không vượt qua GO, không thu 200 đô la.

5) Giải quyết một vấn đề tiếp thị với lập trình nhiều hơn.

Nếu mọi người không hiểu những gì bạn đang bán, thì đó là một vấn đề tiếp thị. Quay trở lại giải pháp 1 và trục.

6) Giải quyết vấn đề năng suất với nhiều chương trình hơn

Chờ đợi.

Đợi cho đến khi bạn cảm thấy rằng năng suất của bạn đã gặp phải một vấn đề năng suất cụ thể trong khoảng thời gian dài hơn 2 tuần và điều đó hợp lý sẽ xảy ra trong 2 tuần nữa.

Bây giờ, hãy đánh giá lượng thời gian dành để lập trình một kịch bản để giải quyết vấn đề này. Hãy nhớ lấy ước tính tồi tệ nhất của bạn và nhân với 2.

Nhân ước tính của bạn với tỷ lệ hàng giờ của bạn.

Bây giờ hãy xem xét các giải pháp thay thế: thuê ngoài, mua một giải pháp sẵn có, không làm gì về nó, v.v.

Chọn giải pháp hiệu quả nhất.

Dính vào nó.

7) Lập kế hoạch viết mã nhưng chưa mã hóa vì bạn muốn "làm cho đúng"

Đi tập thể dục. Bạn sẽ cảm thấy một lượng endorphin sẽ thúc đẩy mông của bạn và khiến bạn có kế hoạch hành động. Tôi biết điều này bởi vì tôi vừa mới tập 5x5 và squats 5x5.

8) Viết mã phiên bản bẩn và hứa rằng bạn sẽ "làm cho nó tốt hơn sau" nhưng không bao giờ quay lại để "làm cho nó tốt hơn"

Thiết lập hệ thống tập tin tickler trong GTD. và tích cực theo dõi. Thực hiện theo tất cả các lời hứa với bản thân và những người khác.

9) Không thực hiện một mockup hoặc sơ đồ trang web vì nó "quá rắc rối".

Hãy chi 75 USD cho phiên bản máy tính để bàn balsamiq mockups. Tôi biết điều này bởi vì tôi đã mua nó 3 tuần trước. Nó đã làm cho tôi làm lại các mockup của mình bởi vì tôi cảm thấy như một nghệ sĩ, kiến ​​trúc sư và người có tầm nhìn tất cả trong 1 mặc dù bản vẽ của tôi trong thế giới thực rất tệ. Phông chữ được sử dụng trong balsamiq vô thức nhắc nhở bạn rằng đây chỉ là một mockup, không được đặt trong đá giúp bạn trong RAD.

Kết thúc EDIT

Một vài loại bia sẽ giúp tôi làm việc tốt hơn và lâu hơn.

"Vâng, tôi có thể tái cấu trúc mớ hỗn độn khổng lồ gồm 2000 dòng mì spaghetti trong một ngày ..."

"Tôi có thể nhận được mà không cần kiểm tra cho điều đó. Thật khó để kiểm tra."

và đó là anh trai độc ác,

"Tôi phải có một bài kiểm tra cho điều đó, bất kể bài kiểm tra đó khó viết hay hiểu như thế nào."

Chần chừ và ước tính nhiệm vụ lạc quan là tội lỗi lớn nhất của tôi.

Kéo dài, chống đẩy hoặc kéo tạ (hoặc bất kỳ bài tập thể chất nào khác) cho lần đầu tiên và tâm trạng bi quan trước khi đưa ra ước tính cho lần thứ hai.

"Thật dễ dàng hơn nhiều để thực hiện lại chức năng từ đầu hơn là hiểu mã hiện có."

Một cám dỗ gây hại ồ ạt mà dự án tôi đang phải chịu là 'Hiệu ứng nền tảng bên trong'. Đây là một cách tiếp cận mà Kiến trúc sư, người đã mất từ ​​lâu, đã đặt ra trí tuệ vô hạn của họ, người đã tạo ra một dự án tạo ra khoảng 20 triệu đô la mỗi năm nhưng tốn 60 triệu để cập nhật và duy trì (rõ ràng là con số lớn nhưng đây là mức độ lớn của vấn đề).

NIH - Không được phát minh ở đây

Tôi có một thời gian thực sự khó khăn để cho các giải pháp của bên thứ ba một cơ hội công bằng. Mọi người nên nghi ngờ một cách tự nhiên về các giải pháp của bên thứ ba không phù hợp với họ, nhưng tôi gặp khó khăn khi phải khách quan 100% về nó.

Tiết kiệm thời gian có thể quá lớn đến nỗi ngay cả khi 9 lần trong số 10 giải pháp của bên thứ ba nên tránh, tôi cần phải khách quan, đủ để nhận ra một điều đó sẽ làm việc.

Thiết kế, mã hóa và hoặc kiểm tra đơn vị đối với "dữ liệu mẫu" được cung cấp thay vì phân tích một bản sao của cơ sở dữ liệu thực tế của khách hàng. Thời hạn là ngắn và họ cứ nói rằng nó sẽ đến nhưng nó không bao giờ làm được. Khi nó được triển khai, vụ nổ là ngoạn mục. Thực sự, ai có thể mong đợi một khách hàng có 3 khách hàng mẹ.

Tôi sẽ không bao giờ bắt đầu một dự án nữa cho đến khi tôi có một bản sao của dữ liệu thực .

Các Có phải là người ngồi một thư viện nào đó ở đâu đó hội chứng.

liên quan chặt chẽ đến

Plugin Focco

Chủ nghĩa cầu toàn giết chết; có lẽ các dự án lý do lớn nhất không thành công.

Vâng, đôi khi lập trình đưa tôi đến chai.

Viết lại thay vì tái cấu trúc.

Suy nghĩ phải có một cách tốt hơn để làm điều này. Tôi sẽ không giải quyết cho một cái gì đó có thể là "đủ tốt." Tôi không lấy gì ngoài sự hoàn hảo! Thông thường điều này được tránh bằng cách nói chuyện với những người khác có thể có quan điểm khác về một vấn đề hoặc nhìn thấy giải pháp từ một góc độ khác.

Tự động hóa mọi thứ đến mức dành nhiều thời gian hơn cho việc duy trì các công cụ hơn là công việc thực tế.

Giải pháp: giống như với tối ưu hóa mã, trước tiên hãy tìm các tắc nghẽn năng suất và chỉ sau khi chúng được phát hiện, hãy chữa chúng bằng một số tự động hóa tốt .

Quỷ lập trình của bạn là gì?

Ngoài những gì một số người khác đã đề cập.

Ưu tiên : Bỏ qua công việc ưu tiên cao đối với dự án và làm việc khác trong dự án trước vì, chúng thú vị hơn!

Làm thế nào để bạn tránh chúng?

Với một chút kỷ luật tự hơn. Nghiêm túc, kỷ luật tự giác và động lực bản thân để làm điều đúng giúp tránh hầu hết các "con quỷ".

Chúng tôi chưa nhận được sự chấp thuận từ khách hàng nhưng thời hạn đang đến gần, vì vậy đây là một số comps sơ bộ để bạn có thể bắt đầu ...

Sau đó, sau khi bạn hoàn thành việc xây dựng dự án để phù hợp với ...

Ồ, đây là bản sửa đổi của khách hàng, họ chỉ muốn thay đổi một vài điều nhỏ *

(* chức năng chính là hoàn toàn khác nhau)

Sau đó, bạn tiếp tục tái cấu trúc mã gốc của mình, dựa trên mô hình thiếu sót ban đầu thay vì chỉ bắt đầu từ đầu vì bạn đang chịu áp lực của thời hạn ngắn và cho rằng đó là những sửa đổi cuối cùng.

Tôi nhận được một chút bởi điều này tất cả các thời gian. Thật khó để tránh là một nhà phát triển web. Lời khuyên tốt nhất của tôi là thúc đẩy thêm thời gian để bạn có thể thực hiện các thay đổi một cách chính xác.