Tôi đã thử lên kế hoạch trước, nhưng dường như tôi không thể thấy trước mọi thứ cho đến khi tôi bắt đầu thực hiện một số mã.
Thật hấp dẫn khi nghĩ rằng lập kế hoạch hoàn hảo sẽ cung cấp cho bạn thiết kế / kiến trúc phần mềm hoàn hảo, tuy nhiên, hóa ra đó là sai về mặt phân loại. Có hai vấn đề lớn với điều này. Thứ nhất, "trên giấy" và "mã" hiếm khi khớp nhau, và lý do là bởi vì thật dễ dàng để nói nó nên được thực hiện như thế nào trái ngược với thực tế làm nó . Thứ hai, những thay đổi không lường trước trong các yêu cầu trở nên rõ ràng vào cuối quá trình phát triển mà không thể có lý do từ khi bắt đầu.
Bạn đã nghe nói về phong trào Agile? Đó là một cách suy nghĩ nơi chúng ta coi trọng "phản ứng với thay đổi" trái ngược với "theo một kế hoạch" (trong số những thứ khác). Đây là bản tuyên ngôn (đây là một bản đọc nhanh). Bạn cũng có thể đọc về Big Design Up Front (BDUF) và những cạm bẫy là gì.
Thật không may, phiên bản công ty của "Agile" là một nhóm không có thật (thạc sĩ scrum được chứng nhận, quy trình nặng nề dưới tên "Agile", buộc scrum, buộc bảo hiểm mã 100%, v.v.), và thường dẫn đến thay đổi quy trình asinine vì người quản lý nghĩ rằng Agile là một quá trình và một viên đạn bạc (trong đó không phải là một viên đạn). Đọc bản tuyên ngôn nhanh nhẹn, lắng nghe những người bắt đầu phong trào này như chú Bob và Martin Fowler, và đừng bị cuốn hút vào phiên bản vô nghĩa của "Agile công ty".
Đặc biệt, bạn thường có thể thoát khỏi việc chỉ thực hiện TDD (Phát triển dựa trên thử nghiệm) trên mã khoa học và rất có thể dự án phần mềm của bạn sẽ trở nên khá tốt. Điều này là do mã khoa học thành công hầu hết có giao diện cực kỳ hữu dụng, với hiệu suất là mối quan tâm thứ yếu (và đôi khi cạnh tranh), và vì vậy bạn có thể thoát khỏi một thiết kế "tham lam" hơn. TDD loại buộc phần mềm của bạn phải cực kỳ có thể sử dụng được , bởi vì bạn viết như thế nào bạn muốn mọi thứ được gọi (lý tưởng) trước khi bạn thực sự thực hiện chúng. Nó cũng buộc các hàm nhỏ với các giao diện nhỏ có thể nhanh chóng được gọi theo kiểu "đầu vào" / "đầu ra" đơn giản và nó đặt bạn vào vị trí tốt để tái cấu trúc trong trường hợp yêu cầu thay đổi.
Tôi nghĩ rằng tất cả chúng ta có thể đồng ý rằng đó numpylà phần mềm máy tính khoa học thành công. Giao diện của chúng nhỏ, siêu tiện dụng và mọi thứ chơi độc đáo với nhau. Lưu ý rằng numpyhướng dẫn tham khảo rõ ràng đề xuất TDD: https://docs.scipy.org/doc/numpy-1.15.1/reference/testing.html . Trước đây tôi đã sử dụng TDD cho phần mềm chụp ảnh SAR (Radar A Nhiệt độ Tổng hợp): và tôi cũng có thể khẳng định rằng nó hoạt động rất tốt cho miền cụ thể đó.
Hãy cẩn thận: Phần thiết kế của TDD hoạt động kém hơn trong các hệ thống trong đó việc tái cấu trúc cơ bản (như quyết định rằng bạn cần phần mềm của mình đồng thời cao) sẽ khó, như trong một hệ thống phân tán. Chẳng hạn, nếu bạn phải thiết kế một cái gì đó như Facebook nơi bạn có hàng triệu người dùng đồng thời, thực hiện TDD (để thúc đẩy thiết kế của bạn) sẽ là một sai lầm (vẫn sử dụng được sau khi bạn có thiết kế sơ bộ và chỉ cần "thử nghiệm phát triển đầu tiên "). Điều quan trọng là phải suy nghĩ về các tài nguyên và cấu trúc của ứng dụng của bạn trước khi nhảy vào mã. TDD sẽ không bao giờ dẫn bạn đến một hệ thống phân tán, có sẵn cao.
Làm thế nào tôi có thể tránh luôn cảm thấy như thế nào nếu tôi xây dựng lại hoàn toàn chương trình của mình từ đầu Tôi sẽ làm điều đó tốt hơn nhiều?
Với những điều trên, có thể thấy rõ rằng một thiết kế hoàn hảo thực sự là không thể đạt được, vì vậy, theo đuổi một thiết kế hoàn hảo là một trò chơi ngu ngốc. Bạn thực sự chỉ có thể đến gần. Ngay cả khi bạn nghĩ rằng bạn có thể thiết kế lại từ đầu, có thể vẫn còn những yêu cầu tiềm ẩn chưa được thể hiện. Hơn nữa, việc viết lại mất ít nhất chừng nào nó cần để phát triển mã gốc. Nó gần như chắc chắn sẽ không ngắn hơn, vì có khả năng thiết kế mới sẽ giải quyết được các vấn đề của chính nó, cộng với việc bạn phải triển khai lại tất cả các tính năng của hệ thống cũ.
Một điều khác cần xem xét là thiết kế của bạn chỉ thực sự quan trọng khi yêu cầu thay đổi .Không quan trọng là thiết kế tệ đến mức nào nếu không có gì thay đổi (giả sử nó có đầy đủ chức năng cho các trường hợp sử dụng hiện tại). Tôi đã làm việc trên một đường cơ sở có câu lệnh chuyển đổi dòng 22.000 (chức năng thậm chí còn dài hơn). Đó có phải là thiết kế khủng khiếp? Heck yea, nó là khủng khiếp. Chúng tôi đã sửa nó chưa? Không. Nó hoạt động tốt như nó vốn có, và một phần của hệ thống không bao giờ thực sự gây ra sự cố hoặc lỗi. Nó chỉ được chạm vào một lần trong hai năm tôi tham gia dự án, và ai đó, bạn đoán nó, đã chèn một trường hợp khác vào công tắc. Nhưng nó không đáng để dành thời gian để sửa một cái gì đó không thường xuyên, nó chỉ là không. Hãy để thiết kế không hoàn hảo như hiện tại và nếu nó không bị hỏng (hoặc liên tục bị hỏng) thì đừng sửa nó. Vì vậy, có lẽ bạn có thể làm tốt hơn ... Nhưng nó có đáng để viết lại không? Bạn sẽ đạt được gì?
HTH.