Có phải là bình thường khi nghĩ về một vấn đề thiết kế trong nhiều ngày mà không có mã được viết? [đóng cửa]

Đôi khi tôi nhìn chằm chằm vào không gian hoặc phác thảo ý tưởng và viết một số mã giả trên giấy. Sau đó, tôi gãi nó ra và bắt đầu lại, sau đó khi tôi nghĩ rằng tôi có giải pháp chính xác cho vấn đề tôi bắt đầu viết mã.

Có phải là bình thường để suy nghĩ trong nhiều ngày mà không viết bất kỳ mã? Đây có phải là một dấu hiệu cho thấy tôi đang tiếp cận vấn đề hoàn toàn sai? Nó khiến tôi lo lắng khi không nhận được bất kỳ mã hữu hình nào được viết trong IDE của mình.

Tùy thuộc vào vấn đề bạn đang cố gắng giải quyết, giai đoạn thiết kế có thể mất hàng tuần và hàng tháng (nếu không phải là năm), không chỉ vài ngày.

Cần có kinh nghiệm để không bắt đầu bash mã ngay lập tức. Suy nghĩ về kiến ​​trúc và thiết kế cấp cao sẽ mất nhiều ngày nếu không lâu hơn - chắc chắn là điều gì đó sẽ xảy ra trước khi bạn bắt đầu viết mã.

Điều này thường được gọi là "Paralysis phân tích"

Nó phổ biến nhưng sai. Tại một số điểm, bạn cần thử nghiệm các ý tưởng khác nhau để xem những gì sẽ làm việc tốt nhất cho bạn, sau đó cải thiện dần dần về nó.

Đề nghị đọc lập trình viên thực dụng Chương 2, phần "Tracer Bullets"

Điều này là hoàn toàn phổ biến. Tuy nhiên, nếu bạn thực hiện phương pháp "Thử nghiệm trước" hoặc TDD, nó ít phổ biến hơn và có thể giúp bạn hình thành ý tưởng của mình tốt hơn.

Thói quen thường là kết quả của các cách tiếp cận thử nghiệm và lỗi đối với mọi thứ và tiếp tục những gì mang lại cho chúng ta kết quả mong muốn và tránh những gì không. Làm những gì chúng ta thích và tránh những gì chúng ta không thích cũng xuất hiện. Điều đó hoạt động đến một điểm vì cuối cùng, chúng tôi sẽ làm một cái gì đó chúng tôi không thích để được trả tiền thuê.

Nó phụ thuộc vào những gì dẫn bạn đến điều này và lý do của bạn. Ở đây có một ít:

• Quá thường xuyên, bạn đã phải thay đổi mã vì thay đổi thiết kế
• Bạn không thay đổi thiết kế kém vì giải pháp ít hơn đã được mã hóa
• Bạn thà vẽ và thiết kế hơn là viết mã chần chừ
• phải lo lắng về cú pháp và chi tiết của mã hóa, khiến bạn mất tập trung khi nghĩ về các thiết kế tốt hơn.

Hy vọng rằng, bạn đã phát hiện ra rằng nếu bạn thiết kế lâu hơn, mã của bạn sẽ tốt hơn. Nếu bạn có thể nhìn lại và thấy rằng không quan trọng bạn dành bao nhiêu thời gian cho thiết kế, bạn có thể muốn thay đổi. Một cân nhắc khác là tần suất bạn phát hiện ra các vấn đề sau khi bạn viết mã so với làm việc với các thiết kế của bạn. Nếu bạn không tìm thấy vấn đề cho đến khi bạn viết một số mã, bạn nên xem xét số dư và nhận được mã hóa một cái gì đó sớm hơn là sau này. Có lẽ cách tiếp cận này có thể được áp dụng cho việc sử dụng các công nghệ mới hơn hoặc một tính năng rất phức tạp.

Tôi không biết liệu tôi có kỷ luật để gắn bó với cách tiếp cận này hay cách khác ngay cả khi tôi phát hiện ra cách này hiệu quả hơn phương pháp kia. Đôi khi tôi cảm thấy cần phải đi đến bảng trắng; những người khác bàn phím.

Nó rất phổ biến và tôi cảm thấy đó là cách tốt hơn để xử lý và hiểu mọi thứ. Trong khi làm việc trên một dự án, tôi bị mắc kẹt nhiều lần và phải mất một hoặc hai ngày để hiểu làm thế nào tôi có thể tiếp cận nó tốt hơn. Ngay cả sau khi vấn đề được giải quyết, tôi vẫn chờ một ngày trôi qua. Điều này làm cho tôi được làm mới và đi.

Đó là một hiện tượng tự nhiên và tốt cho một nhà phát triển để ngăn chặn thời gian tâm trí của anh ta và giữa.

Khi tôi tham gia một khóa học về quản lý dự án, một trong những điều mà người hướng dẫn liên quan đến chúng tôi về kế hoạch, bị mắc kẹt trong đầu tôi, đó là quy tắc ngón tay cái mà họ dạy trong quân đội là chiếm 1/3 thời gian lập kế hoạch . Vì vậy, nếu bạn đã có một hoạt động yêu cầu bạn phải hoàn thành 3 tháng kể từ bây giờ, hãy tính đến việc dành một tháng để lên kế hoạch trước khi bạn bắt đầu thực hiện.

Theo quan điểm của tôi, có ba cách tiếp cận, mỗi cách phù hợp với một tình huống mã hóa cụ thể

1. Tôi đã thấy một vấn đề tương tự trước đây vì vậy tôi có một ý tưởng khá hay về các mẫu để áp dụng, và rõ ràng cách giải pháp nên ứng xử và ứng phó.

   => Sử dụng BDD / TDD bắt đầu từ các giải pháp mong muốn và làm việc với mã. (Ok, đôi khi tôi gian lận và viết một chút mã và sau đó là bài kiểm tra - cách tiếp cận 2. -> 1. lồng nhau).

2. Tôi có một ý tưởng tốt về các mẫu để áp dụng, nhưng tôi không chắc giải pháp sẽ như thế nào.

   => Nguyên mẫu để xem những loại điều thú vị bật ra. Di chuyển đến 1. khi tôi tìm ra những điều thú vị được mong muốn.

3. Tôi không chắc chắn nên áp dụng mô hình nào.

   => Hãy suy nghĩ về vấn đề này và cách các cách tiếp cận vấn đề khác nhau ảnh hưởng đến mã. Di chuyển đến 2) hoặc 1) tùy thuộc vào kết quả của bài tập đó.

Nói cách khác, câu trả lời là yêu thích của kỹ sư: Nó phụ thuộc.

Tốt hơn là dành một tháng để suy nghĩ và thiết kế hơn là làm cho một nguyên mẫu nhanh chóng dựa trên một thiết kế không đạt tiêu chuẩn mà sau đó bạn phải đánh bại thành hình. Đặc biệt nếu bạn ở trong một đội; một khi những người khác bắt đầu tùy thuộc vào mã của bạn, việc thực hiện một thiết kế tốt hơn với một API khác sẽ khó hơn nhiều.

Tôi đồng ý với các câu trả lời khác rằng, về nguyên tắc, dành thời gian để suy nghĩ thông qua một vấn đề / giải pháp là một ý tưởng tốt. Tuy nhiên, nếu bạn cảm thấy như bị mắc kẹt, tôi có một vài đề xuất về các cách để quy trình lập kế hoạch mạch lạc hơn một chút:

• Tạo các thiết kế tạo tác. Vậy nếu bạn không viết mã thì sao? Có lẽ bạn chỉ cần viết ra một tạp chí về những suy nghĩ của bạn. Hoặc một bản phác thảo của một giải pháp chung. Hoặc thậm chí chỉ là một bản tóm tắt thực sự tốt về vấn đề mà bạn tinh chỉnh theo thời gian. Khi bạn xem xét các ý tưởng và chấp nhận / từ chối chúng, hãy ghi lại lý do của bạn về chủ đề này. Bằng cách này, vào cuối ngày, bạn vẫn có thể chỉ ra các sản phẩm giao trong thế giới thực như là bằng chứng về lao động của bạn.

• Nói chuyện với mọi người! Không có gì giống như sống, hít thở con người với ai để thảo luận về ý tưởng. Nếu bạn nghĩ rằng bạn đang bị mắc kẹt, hãy nói chuyện với ai đó. Lấy ai đó - bất cứ ai! - và giải thích vấn đề cho họ. Phác thảo suy nghĩ của bạn về cách giải quyết vấn đề. Ngay cả khi tất cả những gì họ làm là hít vào, thở ra và chớp mắt trong mười phút khi bạn bập bẹ, rất có thể bạn sẽ khám phá ra cái nhìn sâu sắc mới chỉ trong quá trình giải thích vấn đề .

Như Satchel Paige đã nói, "Đôi khi tôi ngồi và suy nghĩ, và đôi khi tôi chỉ ngồi."

Tôi đoán những gì anh ấy nhận được là đôi khi thật tốt để giải tỏa tâm trí của bạn vì điều đó có thể khiến bạn suy nghĩ về vấn đề của mình theo một cách khác. Vì vậy, nếu bạn không sử dụng mã, bạn có thể đưa ra một giải pháp hoặc ý tưởng có thể khiến bạn lảng tránh. Vì vậy, vâng, đó là bình thường và là một thực hành tốt để không nhảy ngay vào mã hóa.

Có hai cách tôi tự làm quá trình này. Tôi tạo một thư mục nơi tôi có một tệp văn bản và bất kỳ bản vẽ nào liên quan đến dự án. Tôi ghi lại những ý tưởng của mình ở đó và cố gắng và lưu toàn bộ quá trình suy nghĩ một cách tốt nhất có thể. Tôi cũng sẽ tạo một dự án Scratchpad nơi tôi có thể nhanh chóng thử nghiệm các ý tưởng đơn giản từ thuật toán đến bố cục CSS.

Chương trình = Thuật toán + Cấu trúc dữ liệu

IMHO, thiết kế (giải quyết vấn đề) quy trình hoàn toàn. Thực hiện (vấn đề kỹ thuật) chi tiết theo và giải quyết một cách tự nhiên.

Đây là trường hợp suy nghĩ của tôi.

1. Bắt đầu từ đầu Trước tiên, một ý tưởng sơ bộ về những gì bạn muốn là bắt buộc. Cố gắng để có được một danh sách một số yêu cầu, hoặc tạo ra chúng. Sẽ mất một chút thời gian để tìm hiểu mọi thứ ở đây. Một khi bạn có ít nhất một mảnh mà bạn tự tin bạn muốn, biết hầu hết giao diện của mảnh đó, sau đó bắt đầu mã hóa.

2. Khắc phục sự cố với mã hiện tại Trước hết, theo dõi sự cố. Điều này có thể cần một thời gian để không viết mã thực (Một số mã gỡ lỗi có thể được viết, nhưng điều này thường sẽ không được lưu giữ). Khi bạn tìm thấy vấn đề, tùy thuộc vào độ phức tạp, hãy bắt đầu viết mã để thử và sửa nó. Ít suy nghĩ nên được yêu cầu một khi lỗi được biết đến. Nếu vấn đề xảy ra là một lỗ hổng thiết kế lớn, hãy xem phần tiếp theo.

3. Thay đổi thiết kế / tính năng chính Đây rất có thể là thứ sẽ đòi hỏi nhiều suy nghĩ nhất. Thiết nghĩ để bảo tồn cấu trúc, khả năng tương thích ngược, vv phải được đưa vào. Suy nghĩ về sự thay đổi tốt nhất có thể tiết kiệm một thời gian đáng kể, nhưng thông thường đối với tôi không quá vài ngày.

4. Thêm một tính năng đơn giản Nếu không cần thay đổi thiết kế quan trọng, thì chỉ cần mã trong tính năng của bạn, sử dụng một số thử nghiệm / lỗi. Điều này không cần nhiều thời gian nói chung.

Tôi sẽ không đồng ý với sự đồng thuận về điều này. Tôi thà bắt đầu tạo mẫu một cái gì đó ngay khi tôi có ý tưởng được viết một cách mơ hồ nhất về cách tôi muốn hệ thống của mình hoạt động. Tôi gần như không thể nghĩ ra tất cả các chi tiết nhỏ có thể gây ra vấn đề trừ khi tôi chỉ định mọi thứ theo một cách rất chính xác. Nếu tôi chỉ thảo luận về thiết kế với mọi người, thì quá dễ dàng để chỉ truyền tay xung quanh một số vấn đề phức tạp hơn. Khi tôi chỉ định những thứ như thế này, nó cũng có thể trực tiếp trong mã nguồn chứ không phải là một số phương tiện biểu đạt khác chính xác và chính thức nhưng không thể được biên dịch và thực thi.

Nó phụ thuộc vào những gì bạn có nghĩa là "bình thường" . Nói về bản thân, tôi nghĩ mã là một công cụ học tập tuyệt vời. Vì vậy, khi gặp một vấn đề phức tạp, tôi đã phác thảo trên giấy nhưng tôi cũng thực hiện một số mã hóa theo hướng Test. Mã cho tôi nghĩ rằng một bảng trắng không thể nói và ngược lại, và có thể kết quả là sự thấu hiểu hoặc cần thêm một vài câu hỏi cho chuyên gia tên miền.

Vì vậy, lời khuyên thực sự là: "Sử dụng mọi công cụ học tập cần thiết để tiến gần hơn đến định nghĩa vấn đề" , nhưng cũng "hãy nhớ rằng đây là những công cụ học tập, vì vậy đừng yêu chúng" cả mã và phác thảo đều có nghĩa là vứt bỏ .

Trong kỷ nguyên của RAD và lập trình nhanh, bạn nên bắt đầu phát triển ngay khi bạn có thể xác định các phần chính của hệ thống, chi tiết sẽ xuất hiện. Vì Phần mềm ngày càng lớn hơn, việc tập trung sớm vào từng chi tiết sẽ không dẫn bạn đến đâu.