Thiết kế phần mềm ở mức độ phức tạp?

Question

Tôi đang viết một phần mềm có vẻ phức tạp hơn nhiều so với trước đây. Nó thực hiện một số nhiệm vụ phụ, có một tập hợp các nhiệm vụ hoàn toàn khác nhau và tích hợp chính nó vào các ứng dụng, mô-đun và ngôn ngữ lập trình khác. Có hàng trăm điều tôi cần phải làm, và mọi thứ có vẻ quá phức tạp để nghĩ thẳng về phía trước. Một số cách hay để thiết kế phần mềm của bạn ngoài "chỉ viết" là gì? Tôi cần phải tổ chức dự án của tôi bằng cách nào đó, tôi cần phải biết phải viết gì mà không mất một giờ đầu tiên để tìm ra việc cần làm tiếp theo.

Có ai ở trong tình huống tương tự không?

Answer 1

Chia nhỏ dự án của bạn thành các công việc nhỏ (ít hơn một ngày làm việc). Tổ chức chúng theo nhóm. Ưu tiên chúng (có thể bạn cần phải làm tính năng X để làm Y). Bắt đầu mã hóa!

---

Bất kỳ dự án, phức tạp như nó có thể được, chỉ là một chuỗi các nhiệm vụ nhỏ hơn. Một khi bạn nhận ra rằng, nó dễ dàng hơn để tập trung và tìm cách để tiếp cận dự án. Tất nhiên phá vỡ mọi thứ thành những nhiệm vụ nhỏ là công việc và không tầm thường. Nếu bạn không có kinh nghiệm trong việc này, hãy thử nhận trợ giúp từ đồng nghiệp. Nhưng cách tốt nhất để có được kinh nghiệm là thử!

Tùy thuộc vào tình huống và sở thích cá nhân của bạn, bạn có thể xem xét sử dụng phương pháp nhanh nhẹn như Scrum or Kanban. Bạn cũng nên sử dụng một công cụ quản lý dự án để theo dõi những gì bạn phải làm. Nó có thể là bất cứ điều gì từ bài của nó để pivotal tracker, chỉ cần tìm một trong đó là đúng cho bạn.

Answer 2

Thử sử dụng SCRUM & TDD.

Lập kế hoạch lặp lại ngắn (1-2 tuần) với mục tiêu ngắn, rõ ràng, cố tạo một số kịch bản đầu cuối càng sớm càng tốt và chỉ tạo cơ sở hạ tầng bắt buộc.

Sử dụng TDD - Tôi thấy rằng nó giúp khi có các mục tiêu không rõ ràng - bằng cách viết kiểm tra trước khi bạn mã, bạn tập trung vào một đối tượng địa lý cùng một lúc.

Answer 3

Có vẻ như bạn cần tổ chức phần mềm của mình trong một số chức năng thay vì xử lý phần mềm đó dưới dạng một đĩa mã spaghetti duy nhất.

Bạn có thể muốn sử dụng một số hình thức để cấu trúc suy nghĩ của bạn, chẳng hạn như UML cho kiến ​​trúc tĩnh hoặc MSC cho kiến ​​trúc động.

Answer 4

Tôi chỉ ở trong các tình huống tương tự với quy mô nhỏ hơn nhiều. Tuy nhiên, tôi hy vọng những gợi ý này có thể hữu ích.

• có một phiên thiết kế (tốt với các đồng nghiệp) để tìm ra kiến ​​trúc thô cho phần mềm của bạn
• cố gắng phá vỡ những câu chuyện phức tạp thành subtasks nhỏ mà là một thể kiểm soát được bằng cách kiểm tra một đơn vị
• ghi - những sẽ cho phép bạn mạnh dạn refactor code của bạn mà không sợ bị phá vỡ một cái gì đó, nếu bạn cảm thấy rằng thiết kế hiện tại của bạn là không hoàn toàn đúng

Answer 5

tôi muốn tưởng tượng nhất nhà phát triển đã đi qua rằng "oh sh **" khoảnh khắc khi bạn nhận ra phạm vi đầy đủ của những gì bạn ' đã được yêu cầu để làm :)

Có vẻ như bạn đang làm việc như một đội bóng một người đàn ông vì vậy đây là lời khuyên của tôi:

1. Talk cho khách hàng - Không thể nhấn mạnh điều này . Bạn cần có một cuộc trò chuyện cởi mở và trung thực ngay bây giờ. Nếu họ đã yêu cầu mặt trăng trên một cây gậy và bạn đang được trả tiền tuppence, không ai sẽ nhận được kết quả đúng từ nỗ lực này.

2. Phá vỡ hệ thống xuống các tính năng cấp cao (ví dụ như ứng dụng sẽ xuất X để hệ thống Y), làm việc với khách hàng để xác định lát theo chiều dọc hợp lý có thể được thực hiện từng bước và ưu tiên cho họ

3. Trong tính năng Tổ chức và ưu tiên các tiểu nhiệm vụ

4. Vì marcgg đề xuất, hãy thử và chia các công việc thành các phần có thể quản lý được, tôi thường sử dụng 4 ngày tối đa, nhiều hơn thế này và bạn không hiểu chi tiết đủ để ước tính chính xác để tinh chỉnh thêm. Tuy nhiên không phải lúc nào cũng cần thiết để ước tính mọi thứ chi tiết chi tiết. Bạn có thể đồng ý tinh chỉnh mọi thứ sau đó miễn là bạn và khách hàng hiểu được thời điểm có thể xảy ra phiếu thời gian.

5. Nhận công cụ theo dõi công việc phong nha như JIRA hoặc bất kỳ công cụ gì. Bạn muốn giảm tải nhiệm vụ tung hứng từ bộ não của bạn để bạn có khả năng tihk về việc thực hiện các giải pháp.

6. Hãy nhớ rằng giao hàng là một tính năng - không biến mất thành một lỗ mã hóa như điên trong sáu tháng. Tiếp tục phân phối các nguyên mẫu (hoặc nhiều phiên bản làm việc phù hợp tốt hơn với một tập hợp con tăng các tính năng) thường xuyên và làm việc với khách hàng không chỉ cho khách hàng.