Tôi hiện đang làm việc trên một dự án sắp đạt hơn 5.000 dòng mã, nhưng tôi chưa bao giờ thực sự nghĩ ra thiết kế. Tôi nên sử dụng phương pháp nào để cấu trúc và tổ chức mã của mình? Giấy và bút? Sơ đồ UML? Thứ gì khác?
Câu trả lời:
Bạn có thể nhận được nhiều quan điểm khác nhau như sẽ có câu trả lời. Nhưng đây là quan điểm của tôi.
Đối với người mới bắt đầu, 5000+ dòng mã là dự án rất rất nhỏ. Bây giờ, làm thế nào để bạn đi về thiết kế dự án phát triển. Đầu tiên, bạn thiết kế hệ thống của bạn chứ không phải mã. Mã thực sự là thứ yếu của kiến trúc. Bắt đầu với việc hỗ trợ các yêu cầu tối thiểu hiện tại. Đặt một số bản vẽ đơn giản của các thành phần liên quan. Cá nhân tôi thích UML, nhưng bất cứ điều gì trực quan sẽ tốt. Lý tưởng nhất, bạn muốn tuân thủ các thực tiễn thiết kế tốt ở đây (giao diện, phân tách các mối quan tâm, v.v.).
Một khi bạn hỗ trợ các yêu cầu tối thiểu trong thiết kế của bạn, hãy mã hóa nó. Một lần nữa, cố gắng tuân thủ các thực hành mã hóa tốt.
Sau đó, lặp đi lặp lại thêm nhiều chức năng khi có yêu cầu mới. Lý tưởng nhất là bạn muốn cập nhật thiết kế của bạn là tốt.
Điều quan trọng, dựa trên kinh nghiệm của tôi, không phải là thiết kế hệ thống của bạn theo dự đoán các yêu cầu không tồn tại. Nếu không, dự án của bạn sẽ phát triển rất nhanh và sẽ trở nên rất phức tạp trong một thời gian ngắn. Một lần nữa - tuân thủ các thực hành tốt và bắt đầu với các yêu cầu cụ thể hiện tại.
Sơ đồ dòng, Sơ đồ lớp, Sơ đồ ca sử dụng là những sơ đồ bắt buộc phải có cho các dự án lớn. Tìm kiếm và chọn thư viện bên ngoài nào bạn cần và tìm kiếm bất kỳ mã nguồn mở tương tự nào bạn có thể sử dụng (để tìm hiểu & giảm thời gian phát triển).
Tôi đề nghị bạn nên mua một bảng trắng và một số nam châm đầy màu sắc & Post-It. Nó sẽ giúp bạn xác định nhiệm vụ của bạn.
Tuy nhiên, hơn 5000 dòng mã không "lớn". Một phần mềm CMS / Forum có hơn 5000 dòng mã.
Tôi sẽ tạo sơ đồ gói và lớp. Trong sơ đồ gói, tôi sẽ quan tâm đến việc nhóm các lớp và giao diện một cách hợp lý. Tôi cũng muốn tạo các gói bên trong, v.v ...
Nhưng trước tiên bạn cần nghĩ chương trình nên làm gì. Bạn có thể tạo sơ đồ usecase hoặc thực hiện thủ công. Tôi làm điều đó bằng tay với sơ đồ lớp vì tôi thích lấy mã ngay lập tức và việc trao đổi sang sơ đồ lớp sau sẽ dễ dàng hơn. Sử dụng sơ đồ lớp cho tôi java của tôi. Nếu tôi không thích nó thì tôi tự thay đổi nó. Mã mới được tự động cập nhật vào sơ đồ của tôi. Tôi có một đại diện cập nhật mức cao của mã của tôi. Thực sự hữu ích vì ngay cả khi tôi viết mã, tôi luôn có thể mất vài phút để xem cách dự án của tôi diễn ra theo cách đồ họa. Tôi chỉ cần kéo và thả các thực thể trong gói bên phải theo cách thủ công để sắp xếp nó. Tôi nghĩ rằng mã của tôi tốt hơn khi sử dụng gói trừu tượng và sơ đồ lớp ở mức cao hơn.
(nguồn: ejb3.org )
một số đồng nghiệp của tôi nói rằng cách làm việc của tôi là tào lao .... nhưng tôi thích nó :-)
Chắc chắn rồi. Tôi có một bảng tẩy khô "máy tính bảng" nhỏ để sử dụng cho loại vật dụng này, nhưng sử dụng bất cứ thứ gì bạn thấy thoải mái. Điều quan trọng là bạn có thể suy nghĩ dễ dàng và nhìn thấy bức tranh lớn về cách mọi thứ khớp với nhau.
Một số người thích các kế hoạch chính thức hơn, như sơ đồ UML, nhưng tôi cảm thấy rằng quá dễ dàng để bắt kịp vi mô hóa mỗi phương thức sẽ như thế nào. Tuy nhiên, một lần nữa, sử dụng bất cứ điều gì bạn thấy thoải mái.
EDIT: Bạn cũng có thể quan tâm đến lập trình biết chữ . Ý tưởng là bạn có thể lên kế hoạch cho tất cả và dần dần cụ thể hơn. Ví dụ: bạn có thể nói rằng chương trình của bạn bao gồm:
Sau đó, bạn có thể tinh chỉnh ý tưởng chuyển đổi văn bản thành hình ảnh. Vì vậy, nó có thể trông giống như:
Sau đó, bạn có thể tinh chỉnh ý tưởng chọn màu ngẫu nhiên và chẳng mấy chốc bạn chỉ viết mã thông thường.
Đối với tôi, hoạt động phát triển phần mềm là một loạt các thiết kế chi tiết dần dần để giải quyết một vấn đề cụ thể. Khi bạn có một ý tưởng cấp cao về những gì bạn đang xây dựng, thiết kế của bạn có thể là một thứ gì đó rất cao cấp, như "sẽ có một ứng dụng web nói chuyện với cơ sở dữ liệu SQL và nhiều dịch vụ web" hoặc đại loại như thế. Sau đó, khi bạn đi sâu vào các chi tiết của từng mảnh, bạn sẽ có được chi tiết tốt hơn trong thiết kế. Tùy thuộc vào độ phức tạp của giải pháp, sẽ có nhiều lần lặp lại nỗ lực thiết kế. Lặp lại cuối cùng liên quan đến việc tạo mã thực tế thực hiện các mức cao hơn của thiết kế.
Đối với tôi, sự khác biệt giữa kiến trúc và thiết kế là tối thiểu và chúng chỉ là những bước lặp khác nhau của quá trình tôi mô tả ở trên. Dòng giữa hai là mờ, và khác nhau cho những người khác nhau.
Có một nghệ thuật để quyết định mức độ chi tiết thiết kế sẽ đi vào, cho các phần của ứng dụng và tại điểm nào trong vòng đời dự án. Đối với rủi ro cao, các dự án phức tạp cao, bạn có thể muốn có một thiết kế rất chi tiết trước khi bạn viết một dòng mã. Đối với các dự án nhỏ hơn, bạn có thể thoát khỏi việc thiết kế phía trước rất ít và chỉ cần gõ một số mã và sau đó xem những gì không hoạt động và thiết kế lại các khu vực đó. Không chỉ có một câu trả lời viết ở đây. Thông thường nó ở đâu đó ở giữa hai thái cực đó.
Tôi có một bài viết trên blog nói về một số nguyên tắc tôi sử dụng khi tiếp cận kiến trúc. Nó có thể hữu ích cho bạn khi suy nghĩ dọc theo những dòng này. Một số bài viết dành riêng cho .NET nhưng hầu hết không phải vậy.
Tôi đã từng tự hỏi mình câu hỏi tương tự. Bây giờ tôi chỉ thực hành phát triển dựa trên thử nghiệm và không lo lắng về điều đó. Tôi hoàn toàn không "lên kế hoạch" cho mã, ngoại trừ tuân theo các tiêu chuẩn cho kiến trúc đã chọn. Khi tôi bắt đầu một dự án, tôi có một số ý tưởng về những gì sẽ cần thiết, nhưng khi quá trình phát triển diễn ra, tôi cố gắng giữ một tâm trí cởi mở. Bằng cách theo dõi quá trình phát triển dựa trên thử nghiệm và liên tục tái cấu trúc mã, tôi không phải "lập kế hoạch" cho mã. Tôi chỉ đáp ứng một trường hợp thử nghiệm khác, và thiết kế nổi lên từ việc tái cấu trúc. Đây luôn là một thiết kế tốt hơn bất kỳ kế hoạch nào tôi có thể thực hiện trước khi viết mã.