Tôi đang viết lại mã của mình khoảng 10 lần trước khi kết thúc. Điều này có sai không?

Question

Khi tôi bắt đầu viết một cái gì đó phức tạp, tôi thấy rằng khởi động lại văn bản như 10 lần trước khi tôi kết thúc với những gì tôi muốn, thường loại bỏ hàng trăm dòng mã.

Tôi đang làm điều gì đó sai, hoặc làm những người khác có quy trình công việc như thế này?

EDIT: Hiện tại, tôi đang làm việc trên trình biên dịch mô-đun. Dự án cuối cùng tôi đang làm là một máy chủ trong java. Trước đó nó là một số công cụ tương tranh.

Tôi làm một chút công bằng về lập kế hoạch và tôi không bao giờ bắt đầu viết mã trước khi tôi có giao diện cho mọi thứ.

Cho rằng, có bình thường khi chỉ xóa sạch đá phiến liên tục không?

Answer 1

Loại bỏ nhiều dòng mã thường là một khía cạnh tích cực của việc tái cấu trúc. Thật tuyệt. Nhưng bắt đầu hơn mười lần có nghĩa là bạn có thể chưa phân tích vấn đề và giải pháp của mình. Bạn có thể quay lại và đôi khi bắt đầu lại nhưng không thường xuyên như vậy. Bạn nên đặt ra mã của bạn theo cách mà khi bạn quay lại và tái cấu trúc, bạn giữ hầu hết những gì bạn tạo ra bởi vì nó sẽ tồn tại trong các đoạn độc lập và hợp lý. (Sử dụng ngôn ngữ mơ hồ vì ngôn ngữ lựa chọn không được chỉ định.)

Từ bình luận của tác giả:

Thông thường tôi khởi động lại vì tôi nhận được nhầm lẫn bởi tất cả những thứ đang diễn ra trong mã của tôi.

Nghiên cứu thủ công của bạn và sử dụng tốt các mẫu thiết kế và các triết lý lập trình tốt nhất để cho vay mã của bạn một cấu trúc được xác định rõ ... thứ bạn sẽ nhận ra hàng tháng và thậm chí cả ngày.

Answer 2

Trên một vấn đề phức tạp, điều này là phổ biến. Nếu bạn không hoàn toàn đâm vào bóng tối, nó thực sự giúp phác họa ý tưởng của chúng tôi trước, nhưng sau đó một lần nữa bạn chỉ cần di chuyển 'retries' từ mã này sang giấy khác.

Nếu nó giúp bạn đạt được giải pháp tốt, nó có thể sai như thế nào?

Answer 3

Điều đó tùy thuộc vào mức độ hiểu biết của tôi về không gian vấn đề. Nếu đó là lãnh thổ quen thuộc, thì tôi sẽ lo lắng nếu nó mất 10 lần lặp lại. Nếu nó là lãnh thổ không quen thuộc, thì có thể mất đến 10 lần lặp lại, nhưng ít nhất một số trong số chúng sẽ bị giảm xuống nguyên mẫu - hoặc một nỗ lực ở nguyên mẫu - trước khi bị loại bỏ.

Answer 4

Hoàn toàn bình thường. Cho dù tôi dự tính bao nhiêu, tôi thường có một "Aha!" thời điểm khi bàn tay chạm vào bàn phím.

Thường thì đó là "Tôi đang nghĩ cái quái gì vậy?" chốc lát.

Tất cả đều tốt. Bạn đang tạo mã tốt hơn.

Answer 5

Nếu bạn đang bắt đầu một cái gì đó phức tạp, một chút kế hoạch trước khi bạn bắt đầu viết có vẻ là một ý tưởng tốt.

Thiết kế trước tiên.

Answer 6

Nếu bạn đang học điều gì đó với mỗi lần lặp lại thì có lẽ đó không phải là vấn đề. Thời hạn và những điều kỳ quái như thế có thể làm cho cuộc sống của bạn trở nên khó khăn hơn một chút. :)

Khi tôi đang làm việc về một vấn đề mới, tôi muốn giả mã nó trong các chú thích trong trình xử lý hàm thực tế, như là một phần của việc tạo sơ khai cho TDD của tôi. Sau đó, thêm mã vào từng bước mà tôi có trong phần bình luận của thân hàm.

Điều này giúp tôi tiếp tục tập trung vào những vấn đề mà tôi đang giải quyết và không bị mất chi tiết đến sớm.

Answer 7

Thay đổi lớn nhất mà bạn có thể thực hiện để tự giúp mình là lập kế hoạch mã của bạn trước tiên. Trên giấy.

Kế hoạch của bạn không phải là siêu chuyên sâu (mặc dù đôi khi cũng tốt). Chỉ cần phác thảo một ý tưởng thô sơ về những gì bạn muốn chương trình của bạn làm. Ghi lại các điểm chức năng chính. "Tôi muốn nó làm điều này, cái này và cái này".

Khi bạn có điều đó, hãy phác họa một thiết kế thô. Các lớp, phương thức, hàm, đối tượng. Cung cấp cho nó một hình thức nhỏ. Làm một phân bổ thô chức năng cho các phần khác nhau của thiết kế của bạn.

Tùy thuộc vào bản chất của dự án, tôi có thể thiết kế thô như vậy và biến nó thành một thiết kế chi tiết hơn. Nếu đó là một dự án nhỏ, có thể không. Nhưng không có vấn đề phức tạp dự kiến, dành thời gian thiết kế sẽ thưởng cho bạn mã tốt hơn và ít tốn thời gian hơn để mã hóa. Nếu bạn có những sai lầm rõ ràng yêu cầu bạn phải cấu trúc lại các phần lớn trong chương trình của bạn, chúng phải rõ ràng trong thiết kế ban đầu của bạn và bạn có thể điều chỉnh nó. Bạn sẽ không phải lãng phí hàng trăm dòng mã trên một sai lầm rõ ràng.

Answer 8

Cân nhắc tìm hiểu một số khung trong bất kỳ ngôn ngữ nào bạn đang sử dụng (hoặc bằng bất kỳ ngôn ngữ nào cho vấn đề đó).

Tôi nghĩ rằng khung học tập làm cho mã của tôi tốt hơn hàng triệu lần. Bằng cách học các khuôn khổ (và quan trọng hơn là cách chúng hoạt động), tôi đã học được không chỉ các mẫu thiết kế, mà còn là cách thực hiện chúng một cách thực tế.

Cân nhắc xem xét đường ray, cakephp hoặc django (giả sử bạn đang sử dụng ngôn ngữ kịch bản; Tôi không biết bất kỳ khung ngôn ngữ máy tính để bàn nào. Xin lỗi!). Sau đó, xem các mảnh của chúng phù hợp với nhau như thế nào.

Answer 9

Tất cả các đề xuất ở đây đều hợp lệ, tuy nhiên, hãy nhớ rằng có một thời điểm trong thời gian tồn tại của chương trình là "đủ tốt". Thật dễ dàng để rơi vào một cái bẫy không bao giờ kết thúc tái cấu trúc, chỉ vì bạn thấy rằng "có, điều này có thể được thực hiện tốt hơn!". Vâng, đối mặt với sự thật - trừ khi chương trình của bạn chỉ có một vài dòng, luôn luôn có một cách để làm điều đó tốt hơn.

Tôi tin rằng có những lập trình viên hạnh phúc ở đó không chịu đựng điều đó, nhưng ít nhất tôi cần phải nhắc nhở bản thân rằng có một dòng được gọi là "đủ tốt".

Và điều này đặc biệt đúng nếu bạn viết mã cho người khác - không ai sẽ lưu ý rằng bạn đã làm điều gì đó "đẹp hơn", tất cả những gì được tính là "nó hoạt động tốt?".

Ngoài ra, thực hành RẤT TỐT là ít nhất để làm cho nó hoạt động trước khi viết lại. Sau đó, bạn luôn có thể quay trở lại giải pháp làm việc trước đó.

(kể từ 12 năm tôi liên tục viết lại một trò chơi tôi đang viết, và tôi không có nơi nào gần kết thúc ...)

Answer 10

Trình biên dịch là các ứng dụng rất phức tạp, và bạn không thể viết trình biên dịch tối ưu từ đầu đến cuối trong một lần - bất kể bạn suy nghĩ bao nhiêu lần đầu tiên. Thông thường bạn cố gắng để có được một cái gì đó để làm việc một cách chính xác từ đầu đến cuối và sau đó quay trở lại để mô đun hóa nó và thêm các tính năng mới như tối ưu hóa. Quá trình này có nghĩa là rất nhiều refactoring và thay thế toàn bộ các phần hoàn toàn. Đây cũng là một phần của quá trình học tập - vì không ai có thể biết mọi thứ và ghi nhớ nó!

(Tôi cũng đang làm việc trên một trình biên dịch NET như một phần của dự án MOSA -. Www.mosa-projet.org)

Answer 11

giải quyết vấn đề của bạn trên giấy. . . không được vội vàng để gõ.

Answer 12

Có hai tình huống. (1) Tôi đã có thể tự tin lập kế hoạch trước và cô lập các trừu tượng của tôi. (2) Tôi không có.

Đối với (1), một kỹ thuật hiệu quả là đưa vào các phiên bản giả của một số lớp hoặc chức năng nhất định chỉ để thúc đẩy phần còn lại của mã. (hoặc ngược lại, để viết các lớp và chức năng đã nói và hướng chúng bằng một kịch bản thử nghiệm.) Điều này cho phép bạn giải quyết một phần của sự phức tạp trong mỗi lần truyền.

Giống như mọi người nói mọi người nên lập kế hoạch trước, nó thường không hoạt động theo cách đó, dẫn đến tình huống (2). Ở đây, hãy cẩn thận để quản lý những gì bạn đang cố gắng thực hiện trong một lần lặp mã. Ngay sau khi bạn tìm thấy bộ não của bạn không thể sắp xếp tất cả những gì bạn đang làm, quy mô trở lại tham vọng của bạn cho những gì bạn muốn đạt được trước khi biên dịch và thử nghiệm tiếp theo. Cho phép mã của bạn bị thiếu sót nhưng dễ viết trên thẻ đầu tiên, và sau đó phát triển nó thông qua tái cấu trúc. Điều này cải thiện hiệu quả hơn nhiều lần lau sạch đá phiến.

Ví dụ, một cách mà tôi thường gặp phải là làm hỏng mã thông thường và tái cấu trúc lại các chương trình con quá sớm, trước khi tôi thực sự biết hình dạng của mã. Tôi đã bắt đầu cho phép bản thân mình để lặp lại mã trên pass đầu tiên, và sau đó quay trở lại và bao thanh toán nó vào các chương trình con sau này. Nó đã giúp rất nhiều.

Answer 13

Nó được gọi là bạn cấu trúc lại và tốt, bạn chỉ cần giới hạn nó để bạn không phải lãng phí toàn bộ mã thời gian của bạn mà bạn có và đang làm việc thay vì viết mã mới.

Một số lý do tại sao người ta phải cấu trúc lại là:

• hiệu suất Tăng cường.
• Sắp xếp mã.
• Bạn cần phải viết mã theo một cách khác để làm việc gì đó.
• Để làm điều gì đó theo một cách khác vì nó tiết kiệm được nhiều công việc (ví dụ: Sử dụng MXML thay vì ActionScript).
• Bạn đã sử dụng tên sai cho một biến.