Bị mắc kẹt do người biết quá nhiều người [đã đóng]

Lưu ý thảo luận thêm tại http://news.ycombinator.com/item?id=4037794

Tôi có một nhiệm vụ phát triển tương đối đơn giản, nhưng mỗi lần tôi cố gắng tấn công nó, tôi lại bị cuốn theo những suy nghĩ sâu sắc - làm thế nào nó có thể mở rộng tương lai, những khách hàng thế hệ 2 sẽ cần gì, nó ảnh hưởng đến "phi chức năng" như thế nào các khía cạnh (ví dụ: Hiệu suất, ủy quyền ...), cách tốt nhất để kiến ​​trúc sư cho phép thay đổi ...

Tôi nhớ bản thân mình một thời gian trước, trẻ hơn và, có lẽ, háo hức hơn. "Tôi" lúc đó tôi sẽ không nghĩ gì về tất cả những điều đó - anh ấy sẽ đi trước và viết một cái gì đó, sau đó viết lại, sau đó viết lại (và một lần nữa ...). Cái "tôi" hôm nay ngập ngừng hơn, cẩn thận hơn.

Hôm nay tôi thấy việc ngồi lên kế hoạch và hướng dẫn và hướng dẫn người khác cách làm mọi thứ dễ dàng hơn là thực sự đi trước và tự mình thực hiện - không phải vì tôi không thích viết mã - ngược lại, tôi thích! - nhưng bởi vì mỗi lần tôi ngồi vào bàn phím, tôi lại ở cùng một nơi khó chịu.

Điều này có sai không? Đây có phải là một sự tiến hóa tự nhiên, hoặc tôi đã tự lái xe vào một lối mòn?

Tiết lộ công bằng - trước đây tôi là một nhà phát triển, ngày nay chức danh của tôi là một "kiến trúc sư hệ thống". Chúc may mắn tìm ra ý nghĩa của nó - nhưng đó là tiêu đề.

Ồ Tôi thực sự không mong đợi câu hỏi này sẽ tạo ra nhiều câu trả lời. Tôi sẽ cố gắng để tổng hợp nó.

Lý do:

1. Phân tích tê liệt / Quá kỹ thuật / mạ vàng / (bất kỳ "suy nghĩ quá nhiều về phía trước có thể làm tổn thương bạn").
2. Quá nhiều kinh nghiệm cho nhiệm vụ nhất định.
3. Không tập trung vào những gì quan trọng.
4. Không đủ kinh nghiệm (và nhận ra điều đó).

Giải pháp (không phù hợp với lý do):

1. Thử nghiệm đầu tiên.
2. Bắt đầu mã hóa (+ cho vui)
3. Một để vứt đi (+ một API để vứt đi).
4. Đặt các ràng buộc thời gian.
5. Lột bỏ lông tơ, ở lại với các công cụ.
6. Tạo mã linh hoạt (loại ngược lại với "một để vứt đi", không?).

Cảm ơn tất cả mọi người - Tôi nghĩ rằng lợi ích chính ở đây là nhận ra rằng tôi không đơn độc trong trải nghiệm này. Tôi thực sự đã bắt đầu viết mã và một số thứ quá lớn đã rơi ra, một cách tự nhiên.

Vì câu hỏi này đã bị đóng, tôi sẽ chấp nhận câu trả lời với hầu hết các phiếu bầu cho đến ngày hôm nay. Khi / nếu nó thay đổi - Tôi sẽ cố gắng làm theo.

Suy nghĩ về những điều này chắc chắn là tốt, nhưng đừng để nó ngăn cản bước tiến của bạn.

Một cách tiếp cận hoạt động thực sự tốt (đặc biệt là với sự phát triển lặp lại) là thực hiện một giải pháp đơn giản và sau đó tái cấu trúc khi cần thiết sau này. Điều này giữ cho mã càng đơn giản càng tốt và tránh được kỹ thuật quá mức. Hầu hết các thay đổi về hiệu suất hoặc kiến ​​trúc mà bạn dự tính có lẽ sẽ không được yêu cầu, vì vậy đừng bận tâm viết chúng cho đến khi chúng chính thức trở nên cần thiết. Ví dụ: đừng lo lắng về hiệu suất cho đến khi một trình hồ sơ đã nói với bạn rằng đã đến lúc cải thiện hiệu suất.

Một điều bạn có thể làm để giúp bạn điều chỉnh là đặt giới hạn thời gian khó về thời gian bạn nghĩ về điều gì đó trước khi viết mã. Hầu hết thời gian, mã sẽ trở nên tốt hơn nếu bạn suy nghĩ một chút, viết nó, nhận ra lỗi sai của mình và sau đó sửa chúng bằng cách tái cấu trúc.

Có một sự cân bằng được đánh ở đây. Bạn không nên nhảy vào đầu và không nghĩ về hậu quả, nhưng bạn cũng không nên cố gắng thiết kế quá mức mã của mình.

Wikipedia đặt tên cho nó là "Phân tích tê liệt" trong phần mềm. Công thức là bám vào các phương pháp nhanh. Có nghĩa là bất kỳ hoạt động hoặc hành động cá nhân nào có giá trị hơn nhiều so với nỗ lực thiết lập thực tiễn hoặc chính sách. Mỗi người đóng góp trong nhóm đều có giá trị, bất kể khả năng của người đó phù hợp với lý tưởng kiến ​​trúc tốt đến mức nào. Trong nhanh nhẹn, cá nhân, bản ngã là đầu tiên, các chính sách là cuối cùng.

Câu trả lời yêu thích của tôi là "Architecture is verb". Ngừng suy nghĩ, bắt đầu hành động, bất kể bạn và nhóm sẽ cảm thấy không hoàn hảo và kém hiệu quả như thế nào. Có thể những hành động đầu tiên có thể được dỡ bỏ các chính sách không phù hợp.

40 năm trước Fred Brooks đã viết về điều này "Viết một cái để vứt đi, dù sao bạn cũng sẽ như vậy." Không có gì thay đổi........

Điều này có sai không? Đây có phải là một sự tiến hóa tự nhiên, hoặc tôi đã tự lái xe vào một lối mòn?

Nó phụ thuộc. Điều này có xu hướng là một bước phổ biến trên con đường của một nhà phát triển.

1. Bắt đầu ném tào lao cùng nhau, bị nó cắn vào mông
2. Bắt đầu thiết kế quá mức địa ngục sống ra khỏi mọi thứ, nhận ra rằng YAGNI
3. Giải quyết trên một số nền tảng thực dụng, nơi các công cụ dễ dàng được ghép lại với nhau và các công cụ khó / có khả năng thay đổi được cung cấp đủ kỹ thuật để làm cho nó đủ dễ dàng để làm việc với / thay đổi.

Nó chỉ là một lối mòn nếu bạn ở số 2.

Một trong những điều tôi luôn muốn ghi nhớ là câu nói "tương lai không như trước đây".

Với một lượng kinh nghiệm nhất định, việc tin rằng bạn có thể dự đoán tương lai sẽ trở nên hấp dẫn, nhưng bạn không thể. Thật dễ dàng để hình dung các tính năng mà khách hàng / người dùng trong tương lai / bất cứ điều gì có thể muốn, nhưng điều đó không có nghĩa là họ sẽ muốn chúng ngay lập tức. Điều đó cũng không có nghĩa là họ sẽ muốn họ qua một số tính năng xung đột khác. Vì vậy, bạn thực sự cần phải giới hạn bao nhiêu thời gian bạn dành ngày hôm nay để lập kế hoạch cho tương lai. Bạn đặc biệt cần giới hạn thời gian bạn dành để xây dựng những thứ hôm nay sẽ chỉ được sử dụng trong tương lai.

Câu hỏi mà tôi đặt ra khiến tôi luôn đi thẳng và hẹp là "việc xây dựng tính năng này sẽ khó hơn bao nhiêu so với việc xây dựng hỗ trợ cho tính năng đó bây giờ?" Thông thường, câu trả lời là nỗ lực trong tương lai là như nhau hoặc có thể gấp đôi những gì nó sẽ làm bây giờ. Trong trường hợp đó, vì tôi không thể dự đoán được tương lai, tôi không có vấn đề gì khi không xây dựng nó ngay bây giờ. Nếu câu trả lời lên tới 10 lần hoặc hơn, thì tôi sẽ bắt đầu hỏi xung quanh về khả năng mọi người nghĩ rằng chúng ta sẽ cần điều này trong một hoặc hai năm tới. Ngay cả sau đó, trừ khi có thỏa thuận rộng rãi, tôi chỉ đơn giản là giới hạn bản thân mình để đảm bảo rằng không cần thiết phải hoàn tác những việc chúng ta đang làm hôm nay để đạt được mục tiêu đó trong tương lai.

Ví dụ, tôi đã làm việc trong một vài dự án mà chúng tôi đã dành nhiều thời gian để trừu tượng hóa thực tế rằng chúng tôi đang sử dụng Hibernate như một truy cập dữ liệu sau này. (Chưa bao giờ tôi thấy dự án được xây dựng trên Hibernate ngừng sử dụng nó, vì vậy thật lãng phí thời gian để bắt đầu, nhưng hãy đặt nó sang một bên.) Ngay cả khi đó là khả năng hợp lý mà chúng tôi có thể muốn thay đổi sau này, bởi vì chúng tôi cũng đang sử dụng một mẫu đối tượng truy cập dữ liệu, sẽ không khó để xây dựng tính linh hoạt để thay đổi Hibernate và thay đổi nó cùng lúc khi chúng tôi cần nó hơn là xây dựng tính linh hoạt ngay từ đầu. Đối mặt với một tình huống như bây giờ, tôi sẽ bỏ qua sự linh hoạt đó cho đến khi chúng tôi thực sự cần nó.

Trừ khi bạn đang lập kế hoạch chiến lược cho một tập đoàn lớn, thậm chí không đáng để nghĩ về các vấn đề kiến ​​trúc cách đây hơn hai hoặc ba năm, bởi vì công nghệ đang thay đổi quá nhanh. Tính năng bạn có thể nghĩ về việc xây dựng ngày nay có thể được cung cấp miễn phí trong nguồn mở trong hai hoặc ba năm. Hầu như chắc chắn phân tích lợi ích chi phí sẽ thay đổi.

Giới hạn bản thân trong việc xây dựng một hệ thống làm những gì bạn cần ngày hôm nay, điều mà bạn tự hào và rằng bạn sẽ rất vui khi làm việc trong một vài tháng bất kể vòng thay đổi tiếp theo mang lại điều gì. Thực sự đó là điều tốt nhất bạn có thể làm.

Đây là quá trình loại bỏ cá nhân của tôi đối với các thiết kế điên rồ mà (trong phiên bản đầu tiên của chúng) có thể không thực tế và làm hỏng một dự án từ quan điểm kinh doanh.

1. Xác định tâm chấn : Hãy nghĩ về dự án của bạn như một quầy bán xúc xích, tâm chấn sẽ là những con chó nóng. Bạn có thể lấy mọi gia vị / nước sốt / rau khác ra khỏi gian hàng của mình và vẫn có thể bán xúc xích. Mục đích chính của phần mềm của bạn là gì? Cô lập mọi bổ sung và / hoặc giá trị gia tăng khác từ nó và tập trung đầu tiên vào tâm chấn.
2. Tiếp tục lặp lại với chính mình "làm điều đó sau có nghĩa là làm điều đó tốt hơn" : xem nó có ý nghĩa gì và ghi chú "cho lần sau" vào đó. Nếu bạn làm tốt và suy nghĩ về việc sử dụng trong thế giới thực của nó, bạn sẽ có cùng một thiết kế nhưng được ưu tiên trong một lộ trình.
3. Diminish-Decouple-Discard : Bất kể thiết kế mô-đun nào bạn có làm cho nó đơn giản / thiết yếu / thuần túy / phổ quát nhất có thể (đôi khi điều này có thể được thực hiện mà không cần loại bỏ các tính năng). Khi bạn không thể đơn giản hóa hơn nữa, hãy bắt đầu tách rời các yếu tố có thể tự sống và có mục đích. Cuối cùng, nếu bạn vẫn còn một ít chất béo trong đó, bạn sẽ có thể cắt bỏ nó.
4. Tách "mã thư viện" khỏi "mã sản xuất" : Sẽ luôn có mã không thể được sử dụng lại, nhưng nó luôn tạo thêm nhiễu cho thiết kế. Mã này là một trong đó có các quy tắc kinh doanh. Bạn sẽ thấy rằng đôi khi một số quy tắc kinh doanh chỉ dễ dàng và nhanh chóng thay đổi ( cực kỳ quan trọng ) so với một thiết kế mạnh mẽ. Bạn sẽ tìm thấy mã mà bạn có thể dựa vào và mã mà khách hàng cần để thay đổi hoặc thực hiện lại trong tương lai. Bạn sẽ muốn những thứ đó được giữ riêng biệt nhất có thể.

Và BTW, bước 0 là: "phát điên với thiết kế". Điều này giúp tôi thoát khỏi hệ thống của mình và thường tìm thấy những hàm ý mới, các yêu cầu ẩn và thậm chí các tính năng mới nổi.

Tôi lấy 1 & 2 từ Rework .

Viết các bài kiểm tra. Bạn đã hoàn thành khi tất cả các bài kiểm tra vượt qua: không phải trước đó và chắc chắn không lâu sau đó trong giai đoạn sử thi về kỹ thuật. Có một bộ các bài kiểm tra cho mã bạn đang viết sẽ cung cấp cho bạn một người quan sát độc lập, không thiên vị cho bạn biết khi nào bạn có thể dừng lại.

Khi bạn còn trẻ, bạn không thấy rủi ro (có thể là lý do các chính trị gia trẻ tuổi đáng sợ), nhưng khi bạn già đi, những trải nghiệm tồi tệ của bạn làm tê liệt bạn mọi lúc (có thể là lý do các chính trị gia cao cấp bị trì trệ). Áp dụng phương pháp tiếp cận hướng dẫn sử dụng dao cạo của Occam - tìm giải pháp có ít nhu cầu nhất và sau đó phát triển từ đó.

Chỉ có hai điều bạn thực sự cần ghi nhớ khi viết và thiết kế phần mềm: khả năng bảo trì và tính chính xác.

Sự đúng đắn là quan trọng nhất trong ngắn hạn và có thể dễ dàng được chứng minh bằng các xét nghiệm.

Bảo trì sẽ giúp sau này trong quá trình phát triển nhưng khó khăn hơn để xác định.

Chiến lược hiện tại của tôi là trước tiên lấy một bằng chứng nguyên khối về khái niệm và sau đó tách UI khỏi mô hình (đảm bảo mô hình không biết gì về UI) một khi tôi hài lòng rằng nó khả thi. Nếu tôi chờ đợi quá lâu cho bước này, tôi sẽ nhận được một thứ không thể nhầm lẫn. Nếu tôi bắt đầu với các lớp riêng biệt, tôi dường như không thể bắt đầu khi tôi gặp khó khăn về những gì UI cần biết về mô hình.

Khi tôi bị mắc kẹt trong những tình huống như thế này, tôi thấy rằng điều đó giúp ích cho việc tưởng tượng rằng tôi là người dùng cuối sử dụng chương trình giả định để hoàn thành một việc khá tầm thường. Sau đó, tôi cố gắng tập trung vào những điểm nhập cảnh theo chương trình cần thiết để hỗ trợ những hành động đó là gì, cố gắng hết sức có thể để bỏ qua các khía cạnh khác của hệ thống. Từ đây, thường có thể xây dựng một 'danh sách nhỏ' các tính năng của hệ thống đã hoàn thành và viết một số mã không thực tế bắt đầu thực hiện điều đó. Sau bài tập đó, tôi thường được bắt đầu và phần còn lại của hệ thống bắt đầu trở nên rõ ràng hơn. Đó là tất cả về điểm vào - và điểm vào của đại đa số phần mềm là hành động ban đầu của người dùng cuối với một chương trình.

Tôi nghĩ rằng đó là một syndrom rằng các nhiệm vụ bạn đang làm là quá dễ dàng cho bạn.

Một vài năm trước, chanllenge cho bạn là viết một mã sẽ hoàn thành nhiệm vụ nhất định. Đây là những gì tham gia đầy đủ tâm trí của bạn. Bây giờ, tâm trí của bạn (kinh nghiệm của bạn, v.v.) đang hoạt động hiệu quả hơn và thực hiện cùng một nhiệm vụ chỉ cần một phần năng lượng cần thiết trước đây. Đây là lý do tại sao bạn kết thúc trong vòng xoáy của những suy nghĩ sâu sắc. Tâm trí của bạn đang tự bảo vệ mình khỏi thói quen và đang chiến đấu cho thử thách.

Tôi nghĩ bạn nên xem xét thay đổi công việc của bạn. Có lẽ bạn nên học một ngôn ngữ lập trình mới.

Tôi đã có cùng một vấn đề 15 năm trước. Tôi muốn viết mã hoàn hảo, có thể tái sử dụng, phổ quát, .... làm cho giải pháp phức tạp hơn nhiều so với cần thiết. Hôm nay tôi thấy đây là mạ vàng . Điều giúp tôi rất nhiều là một lời khuyên của một đồng nghiệp:

• nếu bạn có ý tưởng về những gì có thể cải thiện chức năng, hãy làm cho nó trở nên phổ biến hơn, ... viết ý tưởng này thành một tệp văn bản riêng biệt "idea.txt" nhưng không thực hiện điều này ngay bây giờ .
• tiếp tục thực hiện các nhiệm vụ khẩn cấp.
• sau sáu tháng, hãy xem lại "idea.txt" của bạn và phân tích những thay đổi nào trong số những thay đổi này thực sự có lợi cho dự án.

Điều này chỉ đơn giản là tê liệt bằng phân tích. Nó xảy ra với nhiều người trong nhiều lĩnh vực. Bạn có thể vượt qua nó.

Câu trả lời là - CHỈ BẮT ĐẦU VỚI NÓ ;-)

Tôi đăng bài trên một diễn đàn thể dục và nhiều lần mọi người đăng bài về các thói quen khác nhau, cố gắng tìm ra cách hoàn hảo chính xác cho họ. Vì vậy, chúng tôi nói với họ chỉ cần bắt đầu đào tạo và làm việc đó khi bạn đi cùng. Bạn muốn trở nên mạnh mẽ hơn, thực hiện một số bài tập mạnh mẽ và sau đó điều chỉnh mọi thứ khi bạn đi.

Khi bạn có một chương trình lớn và bộ não của bạn hoạt động quá giờ - trước tiên chỉ cần viết mã cho các trường hợp đơn giản. Ban đầu chương trình phải chạy, sau đó phải nhập liệu, v.v.
Thách thức của bạn là để mọi thứ dễ dàng cập nhật và cấu trúc lại sau này nhưng mã PHẢI không phức tạp hơn mức cần thiết để thực hiện nhiệm vụ trong tay.

Hãy nhớ trong tương lai, việc tái cấu trúc mã để đáp ứng các ưu tiên mới là điều tốt. Bạn không thể dự đoán tất cả chúng ở phía trước vì vậy đừng thử.

Mã cho nhiệm vụ tiếp theo - CHỈ. Mã đơn giản và tốt vì vậy rất dễ dàng để cấu trúc lại nếu bạn cần. Hãy chắc chắn rằng chương trình hoạt động. Nói lại.

Vì bạn đang bị "mắc kẹt" khi nghĩ quá nhiều về các tình huống sử dụng của người dùng cuối có thể xảy ra, nên có một điều cần xem xét ở đây nếu bạn sẽ xuất bản API và hy vọng rằng những người chưa biết đến bạn sẽ sử dụng API đó. Sau khi API được xuất bản, bạn phải tiếp tục hỗ trợ nó, mặc dù sau đó bạn nhận ra bản phát hành đầu tiên của mình tệ đến mức nào hoặc bạn phải phá vỡ mã của mọi người, có thể là bạn không biết, người đã viết chống lại nó vì vậy có nguy cơ xa lánh chúng cho tất cả thời gian trong tương lai.

Giải pháp tiêu chuẩn là xuất bản với quy định rằng API có thể thay đổi theo bất kỳ cách nào vào bất cứ lúc nào cho đến khi bạn hiểu được người dùng của bạn cần gì và người tiêu dùng API đang làm gì.

Trong giải pháp đó tôi nghĩ là giải pháp của riêng bạn. Viết chỉ một vài điều nhỏ mà làm một hoặc hai điều, có thể chúng chỉ ổn, giữ cho bản thân hiểu rằng bất cứ điều gì bạn làm có thể thay đổi trong tương lai.

Không thể có được tất cả, hoặc trong một số trường hợp, ngay cả BẤT K of điều gì đúng, khi bạn bắt đầu vì thiết kế thực sự là một hành trình khám phá; đó là lần cuối cùng xuất hiện, không phải là điều đầu tiên phải hoàn thành.

Bạn không thể thiết kế API ngay lập tức và không bao giờ phải phá vỡ nó cho người tiêu dùng của bạn. Bạn nhận được tại sao đó là. Tương tự như vậy, bạn không thể viết phần mềm và không cần phải vứt bỏ tất cả và bắt đầu lại với một cách tiếp cận mới.

Tôi không nghĩ rằng bạn có một vấn đề theo nghĩa là bạn đã vô tình phát triển thành một thứ gì đó kém sáng tạo, năng suất hoặc mong muốn. Tôi nghĩ rằng bạn có tiêu chuẩn cao mà bạn vô tình áp dụng sai cho tình huống của mình-- một lỗi phổ biến trong suy nghĩ của mọi người.

Kinh nghiệm không bao giờ được tính vào bạn trừ khi bạn trở thành một người hiểu biết cay độc, hoàn thành tất cả, và điều đó thực sự nghe có vẻ trái ngược với tình huống của bạn.

Tôi có một vài hình ảnh mà tôi giữ trong tâm trí khi tôi đi lớn. Một là chơi với Lego. Tôi đặt nó lại với nhau và tách nó ra theo ý muốn. Những gì tôi bắt đầu thực hiện có thể không phải là những gì tôi kết thúc. Tôi đang lướt web và tận dụng những khả năng xuất hiện trong tâm trí khi tôi đi cùng, thường tái tạo các mục tiêu của mình hoàn toàn tại chỗ trong nháy mắt cảm hứng ... đó là sự sáng tạo.

Hình ảnh khác là một sự tương tự tôi nghe nói mô tả làm khoa học thực sự. Bạn đang mò mẫm trong một căn phòng tối để tìm một con mèo đen có thể không ở đó. Chỉ đáng sợ nếu bạn coi mình là một kẻ thất bại vì không tìm thấy con mèo đó. Không có cách nào khác để tìm mèo đen. Đó là hoạt động duy nhất từng định vị chúng. Bất cứ điều gì khác là một số hình thức đã có những gì bạn bị cáo buộc đang tìm kiếm.

Bạn không biết quá nhiều; bạn không biết đủ! Và gần đây bạn mới nhận ra điều đó.

Đừng nghĩ về lựa chọn thiết kế của bạn là điều gì đó mà bạn phải có "đúng", bởi vì không có "đúng" - có nhiều "sai", nhưng cũng có sự đánh đổi (về tốc độ thực thi, thời gian để hoàn thành mã hóa nhiệm vụ, mở rộng, vv). Mã bạn viết nếu được quan niệm tốt sẽ vẫn có những điểm mạnh và điểm yếu khác nhau.

Mục tiêu nên là đi đến điểm hiểu được những điểm mạnh và điểm yếu này trong bối cảnh sử dụng và bảo trì hiện tại và tương lai không khó hơn nhiều so với việc viết mã ở nơi đầu tiên.

Vì vậy, đừng tránh những suy nghĩ sâu sắc, nhưng hãy nhớ rằng bạn cần kinh nghiệm, không chỉ là suy nghĩ, để trở thành bậc thầy trong kiểu thiết kế này. Hãy suy nghĩ cho đến khi bạn đạt đến một điểm mà bạn không tự tin về một lựa chọn cụ thể, sau đó thực hiện những gì bạn hy vọng là tốt nhất, thử nó và học hỏi từ cách nó đã đi.

Thực hành mã hóa. Hãy đến với các bài tập hoặc tìm chúng trực tuyến, và cố gắng hoàn thành chúng một cách chính xác nhanh nhất có thể. Khi bạn tăng tốc, hãy thêm các cân nhắc như khả năng bảo trì và hiệu suất. Bạn sẽ nhận ra rằng việc làm mới các công cụ mã sẽ không được sản xuất và nó có thể giúp bạn thoát khỏi nỗi sợ mã hóa.

Làm mã hóa trong thời gian rảnh rỗi của bạn, như cách bạn đã làm 10 năm trước, với ít lo lắng hơn và chỉ là niềm vui.

Trở thành người quản lý nhóm và phát triển trực tiếp trẻ hơn - những người hiện đang ở trong trạng thái tinh thần giống như bạn 10 năm trước.

Không, bạn chưa biết đủ.

Làm giàu kiến ​​thức của bạn, ví dụ như bằng các quy tắc đơn giản sau:

• KISS: Giữ cho nó nhỏ và đơn giản.
• YAGNI: Bạn sẽ không cần nó.
• Tệ hơn là tốt hơn: Một số giải pháp tồi tệ hơn thực sự tốt hơn về mặt bảo trì.

Đừng áp đảo. Hãy sẵn sàng để thay đổi bằng cách có các kỹ năng tái cấu trúc, nhưng không mã hóa mọi thay đổi có thể có trong mã. Nếu bạn thấy rằng theo thời gian, một lớp hoặc hàm phát triển quá lớn, hãy thay đổi nó. Phân chia và chinh phục. Sử dụng giao diện, sử dụng nhiều chức năng hơn. Nếu bạn cảm thấy rằng bạn đã chia quá nhiều (nghĩa là nó trở nên dễ hiểu hơn, nhưng ít đọc hơn), hãy hoàn tác thay đổi cuối cùng của bạn.

Tóm lại: Làm cho mã của bạn đủ linh hoạt, nhưng không nhiều hơn. Thay vào đó, hãy tự làm cho mình linh hoạt, mua một cuốn sách về tái cấu trúc.

Hai điều:

1. Nó không đủ để biết nhiều. Bạn phải có ý kiến ​​về những gì đáng thực hiện. Cá nhân tôi thấy TDD là một cái nạng cho phép kiến ​​trúc xấu. Với số lượng lớn ý kiến ​​phổ biến chống lại tôi về vấn đề này, tôi có thể sai, nhưng liệu có nên triển khai TDD trong JavaScript không là vấn đề tôi nghĩ, bởi vì gỡ lỗi chưa bao giờ là vấn đề đau đầu đối với tôi và hey, Đây không phải là lần đầu tiên ý kiến ​​phổ biến trong cộng đồng phát triển sau đó được coi là thiếu sót nhiều năm sau đó. Vì vậy, học cách trở thành một người kiêu ngạo. Ít nhất là ở bên trong. Bạn có thể sai nhưng ít nhất là bạn cam kết với những thứ phù hợp với bạn hơn là những thứ quá mức có thể không.

2. Có vẻ như bạn đang bắt đầu với vi mô. Bắt đầu với macro. Đầu tiên các công cụ bạn cần để làm những thứ mà ứng dụng của bạn cần làm. Phần đó sẽ đến đủ dễ dàng. Sau đó bắt đầu với các mối quan tâm về kiến ​​trúc / giao diện. Làm thế nào hệ thống ống nước kết nối và những gì nó kết nối thực sự chỉ nên là những mảnh mỏng manh trên đầu của tất cả mọi thứ mà bạn có thể chỉ cần vuốt sang một bên và thay thế trên một ý thích. Tương tự như vậy với các chi tiết về cách mọi thứ được thực hiện. Bao bọc đúng cách những cái này có thể được thay thế / chỉnh sửa một cách dễ dàng.

nhưng mỗi lần tôi cố gắng tấn công nó, tôi lại suy nghĩ sâu sắc

Không có gì sai. Bạn chỉ nhận thấy rằng đã đến lúc cải thiện quy trình của mình: trong trường hợp này là quá trình suy nghĩ của bạn.

Nhiều người bị lạc trong phân tích hoặc đi lạc hướng theo những cách khác và thậm chí không bao giờ nhận thấy nó. Bạn đã nhận thấy để bạn có thể thay đổi quá trình suy nghĩ của mình để đi đúng hướng.

Có nhiều giải pháp cho vấn đề này, và giải pháp tốt nhất tôi thấy ở trên là đặt ra một hạn chế về thời gian. Trước khi bắt đầu, hãy quyết định bạn sẽ dành bao lâu để phân tích và suy nghĩ về nó. Đặt hẹn giờ.

Sau đó, khi bộ đếm thời gian tắt, bắt đầu mã hóa. Nếu bạn thấy mình suy nghĩ về mọi thứ quá lâu một lần nữa, hãy đưa ra quyết định ngay lập tức. Bất cứ điều gì bạn quyết định tại thời điểm đó là quyết định chính xác. Bạn luôn có thể thay đổi và cải tiến sau này.

Bên cạnh đó, môi trường của chúng ta luôn thay đổi. Chúng ta thường cần cập nhật mã của mình để xử lý các yêu cầu mới, công nghệ mới, phần cứng mới, cập nhật ngôn ngữ và hệ thống, v.v.

Vâng, kinh dị mã hóa này xảy ra ngay cả đối với tôi. Bắt với Stack Overflow. Mã hóa chi tiết cho một ứng dụng nhỏ. Nhưng khi đó là một dự án thuê ngoài, nó không ăn nhiều thời gian vì hạn chế về thời gian. Và tôi cũng làm việc với một nhóm người mới có thể vượt qua chuyện này.

Bạn không đủ tàn nhẫn

http://playswithfire.com/blog/2012/02/19/you-are-not-ruthless-enough/

Chỉnh sửa: Quan điểm của bài viết này là chú ý đến các chi tiết nhỏ khi phát triển, nhưng tôi đã thấy nó giúp tiếp cận bất kỳ nhiệm vụ đơn giản hoặc phức tạp nào với thái độ tàn nhẫn để tìm ra giải pháp hiệu quả nhất có thể và chỉ cần hoàn thành công việc.