Làm thế nào để viết mã tốt với công cụ mới? [đóng cửa]

Tôi luôn cố gắng viết mã dễ đọc được cấu trúc tốt.

Tôi phải đối mặt với một vấn đề đặc biệt khi tôi đang loay hoay với một cái gì đó mới. Tôi tiếp tục thay đổi mã, cấu trúc và rất nhiều thứ khác. Cuối cùng, tôi nhìn vào mã và cảm thấy khó chịu về việc nó trở nên phức tạp như thế nào khi tôi đang cố gắng làm một việc đơn giản như vậy.

Khi tôi đã hoàn thành một cái gì đó, tôi cấu trúc lại nó một cách mạnh mẽ để nó sạch hơn. Điều này xảy ra sau khi hoàn thành hầu hết thời gian và nó gây phiền nhiễu vì mã càng lớn thì càng khó chịu khi viết lại nó.

Tôi tò mò muốn biết làm thế nào mọi người đối phó với sự đau đớn như vậy, đặc biệt là về các dự án lớn được chia sẻ giữa nhiều người?

Miễn là bạn đang tái cấu trúc, bạn đang làm đúng.

Xem xét điều này: tại bất kỳ thời điểm nào bạn có thể vạch ra một giải pháp cho vấn đề. Tuy nhiên, khi thời gian trôi qua, bạn đang tìm hiểu ngày càng nhiều về vấn đề dẫn đến việc bạn có thể đưa ra các giải pháp tốt hơn. Lặp lại đầu tiên có thể là ngược, và lần cuối cùng là hy vọng thanh lịch. Nếu bạn tiếp tục tái cấu trúc khi kiến ​​thức của bạn phát triển thì bạn sẽ luôn có kết quả tốt hơn. Không có lối tắt nào để chuyển sang giải pháp thanh lịch nhất ngay lập tức mà không cần thực hiện các bước 'học tập' trừ khi bạn gặp phải vấn đề tương tự, có thể khái quát hóa từ các vấn đề trong quá khứ hoặc gặp may mắn.

Tôi tò mò muốn biết làm thế nào mọi người đối phó với sự đau đớn như vậy, đặc biệt là về các dự án lớn được chia sẻ giữa nhiều người?

• Công nhận nó tồn tại.
• Lịch trình thời gian cho nguyên mẫu.
• Cố gắng học những điều mới trong các dự án sở thích hơn là mã sản xuất.

Vâng, tôi làm TDD với các bài kiểm tra Đơn vị. Toàn bộ câu thần chú TDD xoay quanh chu kỳ sau:

Vì tôi đang sử dụng TDD, tôi buộc phải viết bài kiểm tra đơn vị. Nếu một bài kiểm tra khó viết thì đó là dấu hiệu cho thấy thiết kế của tôi quá phức tạp và nó cần được đơn giản hóa.

Chu trình không kết thúc trừ khi bạn tái cấu trúc để loại bỏ sự dư thừa, do đó, phần lớn thời gian tái cấu trúc được thực hiện trong các phần nhỏ và không tốn thời gian. Ngoài ra, sau mỗi lần tái cấu trúc, tôi chạy tất cả các trường hợp thử nghiệm để đảm bảo rằng tôi đã không làm hỏng bất cứ thứ gì.

nguồn hình ảnh: http://www.javacodegeek.com/2012/05/test-driven-development-win-win.html

Mọi người học cách viết một chương trình bằng cách viết nó. Tái cấu trúc là một phần của quy trình, bởi vì bạn đủ điều kiện để viết nó lần thứ hai thông qua. Bí quyết không phải là cố gắng tránh tái cấu trúc, mà là thực hiện sớm hơn và thường xuyên hơn. Tái cấu trúc ngay khi bạn nhận thấy một vấn đề, thay vì chờ đợi cho đến khi "kết thúc".

Khi bạn đã viết và gỡ lỗi mã rồi đặt mã đó sang một bên và viết lại mã theo một cách khác. Thay đổi cấu trúc dữ liệu. Hoặc các cấu trúc điều khiển. Hãy thử thiết kế lập dị. Nói lại. Thường thì cấu trúc mã sạch nhất không rõ ràng ngay lập tức và bằng cách thử các cách đánh giá khác nhau, bạn có thể vấp phải một giải pháp tốt hơn.

Tôi phát hiện ra từ thực tiễn của mình rằng tôi viết mã rõ ràng và đơn giản hơn khi tôi hiểu hoàn toàn miền vấn đề. Thật không may, khách hàng thường không thể làm rõ chính xác những gì họ muốn và đây là một tình huống làm việc bình thường. Nếu bạn hiểu nhầm tên miền, nó sẽ được phản ánh trong mã của bạn. Và nếu bạn là người dẫn đầu dự án, một trong những nhiệm vụ chính của bạn là giúp khách hàng có được cái nhìn mới về giải pháp kinh doanh của anh ấy mà anh ấy muốn bạn thực hiện. Vì vậy, hãy cố gắng dành nhiều thời gian hơn cho phân tích tên miền và nó giúp bạn viết mã đơn giản và rõ ràng hơn.