Thiết kế phần mềm bằng mã giả?

Bạn có biết một cách tốt để thiết kế phần mềm (tức là viết ra) với một phương pháp dựa trên mã giả?

Tôi chưa quen với thiết kế phần mềm và đọc một số thông tin về UML. Hệ thống phân cấp lớp khiêm tốn của tôi là tốt cho đến nay, tuy nhiên, sau khi nó trở nên phức tạp, tôi nhận thấy rằng với hình ảnh "nhìn thấy toàn bộ", tôi có thể sử dụng một cấu trúc khác để có khả năng mở rộng trong tương lai. Vì Python rất tốt để tạo mẫu nên tôi gần như ổn khi mới bắt đầu viết, nhưng không hoàn toàn.

Vì vậy, tôi đã thử các sơ đồ lớp UML, nhưng chúng dường như không giúp tôi nhiều. Những vấn đề tôi giải quyết ở đó tôi có thể làm một cách tầm thường trong đầu. Nhưng tôi nhận thấy các yêu cầu thiết kế bổ sung khi tôi bắt đầu giả mã hóa các phương thức thực tế.

Vì vậy, nếu bạn muốn thiết kế bằng mã giả, bạn sẽ làm thế nào? Tôi tin rằng đối với tôi một phương pháp có giá trị từ 1 đến 1 với mã hoạt động tốt nhất. Nhưng hầu hết các phần mềm UML thậm chí không hiển thị mã của phương thức (trái ngược với hình ảnh trong ví dụ GoF).

Ai đó tuyên bố UML chỉ dành cho tài liệu và trình bày và không tuyệt vời cho thiết kế? Tôi cũng có được cảm giác đó. Tôi nghĩ rằng UML thuần túy và một số bản phác thảo bảng trắng đơn giản là cách để thiết kế phần mềm cho đến khi tôi tìm thấy Envision APDT.

Vì vậy, phát triển nhanh là thứ gì đó tôi nên tìm kiếm hoặc họ ngẫu nhiên gọi đó là nhanh nhẹn - tôi nghĩ nhanh là chỉ về lịch trình? Hoặc tôi đang thiết kế không chính xác (với UML) - có ai thiết kế bằng mã giả không? Làm thế nào tôi có thể tìm thấy một công cụ tốt cho điều đó?

 I thought agile is about schedule only?

Nó không chỉ là kế hoạch. Phát triển phần mềm Agile liên quan nhiều hơn đến việc phát triển tiến hóa và phân phối lặp theo thời gian với kế hoạch thích ứng nhằm khuyến khích đáp ứng linh hoạt với các thay đổi do chủ sở hữu sản phẩm yêu cầu.

 Or am I designing incorrectly (with UML) - does anyone design by pseudocode? 

Theo kinh nghiệm của tôi, biểu đồ dễ hiểu hơn nhiều từ góc độ khách hàng. Chúng hấp dẫn trực quan và nhiều lần rất nhiều màu sắc và dễ làm theo. Tuy nhiên, rất khó để duy trì biểu đồ do bản chất của việc ngắt kết nối với mã ứng dụng thực tế. Mỗi lần thay đổi được thực hiện trong ứng dụng, nhà phát triển phải dành thời gian để cập nhật tất cả các tài liệu bao gồm các biểu đồ. Tuy nhiên, vấn đề đó có thể được loại bỏ dễ dàng khi có BA trong nhóm hoặc công ty, người hiểu rõ quy trình kinh doanh của khách hàng và có thể quản lý các sơ đồ UML.

Các công cụ như UML có thể làm cho quá trình này dễ dàng hơn nhưng chỉ hoạt động tốt với lập trình hướng đối tượng. Mã giả dễ dàng hơn nhiều cho các nhóm kỹ thuật. Quá trình tạo mã này làm tăng đáng kể tốc độ của giai đoạn phát triển ngôn ngữ lập trình thực tế.

Có một số lựa chọn thay thế khác mà bạn có thể nhìn là tốt:

• Sơ đồ luồng dữ liệu
• Sơ đồ nhà nước
• Biểu đồ quy trình

Tài liệu tham khảo tốt để xem: Hướng dẫn thiết kế phần mềm . Ngoài ra, cá nhân tôi sẽ tư vấn để đọc một blog tốt về Pseudocode hoặc Code? được đăng bởi Coding H khiếp sợ - blog yêu thích của tôi để đọc :)

Tất cả trong tất cả, có một số sự đánh đổi mà bạn cần xem xét.

Khi lập trình bằng ngôn ngữ lắp ráp, viết mã giả có rất nhiều ý nghĩa. Thuật toán có thể được xác minh trước khi mở rộng nỗ lực dịch thủ công sang ngôn ngữ lắp ráp và sau đó gỡ lỗi bản dịch. Nó vẫn có ý nghĩa đối với các ngôn ngữ được biên dịch thế hệ đầu tiên như FORTRAN IV, trong đó cấu trúc điều khiển duy nhất là GOTO, tất cả các biến (trừ đối số chính thức) là toàn cục và tên biến được giới hạn trong sáu ký tự.

Ngày nay chúng ta lập trình rất ít bằng ngôn ngữ lắp ráp và tôi thấy ít giá trị khi viết mã giả thay vì chỉ viết mã. Trong một ngôn ngữ đàng hoàng, mã thực tế sẽ tuân theo mã giả gần như từng chữ và mã giả chỉ là một sự lãng phí thời gian.

Tuy nhiên, tôi không bắt đầu viết mã ở phía dưới. Tôi theo TDD và bắt đầu với một bài kiểm tra. Sau đó, tôi bắt đầu viết mã ở trên cùng, và dần dần làm việc xuống phía dưới khi cần thiết để vượt qua các bài kiểm tra.

Thay thế cho mã giả là không viết 1000 dòng của các lớp cấp thấp. Thay vào đó hãy bắt đầu từ đầu, gọi API lý tưởng nhưng không tồn tại cho miền của bạn. Sau đó, xây dựng API.

Tôi thấy các sơ đồ lớp hầu như không đáng để bỏ công sức, ngay cả khi bạn bỏ qua việc liệt kê tất cả các phương thức và chỉ đơn giản hiển thị hệ thống phân cấp kế thừa. Biểu đồ trình tự là tốt, nhưng cảm thấy lúng túng khi tôi vẽ chúng (có lẽ chỉ có tôi).

Tôi thấy các sơ đồ luồng dữ liệu và biểu đồ cấu trúc sẽ hữu ích hơn (mặc dù các biểu đồ cấu trúc thường được liên kết với BDUF và do đó không được ưa chuộng tại thời điểm này). DFD đặc biệt hữu ích cho phân rã chức năng. Mỗi "bong bóng" trong DFD có thể được chia thành DFD của chính nó cho đến khi bạn đạt được bất kỳ mức độ chi tiết nào bạn muốn.

Tôi nghĩ rằng các công cụ đồ họa tốt hơn mã giả, nhưng UML đơn giản là quá phức tạp đến mức nó kết hợp cái xấu trong các phương thức đó :-)

Nói rõ hơn một chút: Tôi nghĩ lập trình chủ yếu là một cách để phân tích một vấn đề nhất định, tách nó thành các thành phần nhỏ hơn và sự tương tác của chúng. Đây là "một hành trình, không phải đích đến", bạn liên tục nâng cao kiến ​​thức về vấn đề này, vì vậy biểu đồ của các thành phần đang thay đổi: các lớp xuất hiện và mờ dần đi, các chức năng và các mục dữ liệu di chuyển lên xuống, v.v.

Công cụ tự nhiên để thực hiện theo quy trình này là một bản phác thảo, càng đơn giản càng tốt, nhưng đủ phức tạp để giúp hiểu nhanh (cùng màu sắc, hình dạng, mũi tên cho cùng một ý nghĩa logic). Tôi đã không tìm thấy viên đạn bạc, và có lẽ tôi sẽ tự viết một ngày nào đó, nhưng bây giờ tôi sử dụng ánh sáng ; kết hợp với tính năng phóng to của prezi, nó gần như sẽ hoàn hảo.

Tại sao không giả mã? Mã giả là một bước tiến để thực hiện, một "dạng tuần tự của biểu đồ thành phần", khi bạn chưa định hình ý tưởng của mình. Không tốt, giới hạn đầu của bạn. Theo kinh nghiệm của tôi, tôi thấy rằng càng về sau, tôi bắt đầu viết mã, càng ít mã tôi phải vứt đi ...

Nhưng có lẽ điều này là do tôi đã viết tất cả những mã bị loại ra, vì vậy tôi không phải viết chúng ngay bây giờ, kinh nghiệm tôi có được từ chúng là khi tôi thiết kế hệ thống? Vâng, tôi phải sửa đổi tuyên bố.

Nếu bạn bị mất với biểu đồ của mình và thấy nhiều giải pháp tương đương có thể, hãy truy cập mã giả hoặc thậm chí viết mã đó với các đối tượng giả - trong Java, điều đó gần như không có gì khác biệt. Xem mã, cảm nhận cấu trúc và khả năng sử dụng của các thành phần đó, nó sẽ giúp bạn sửa biểu đồ của bạn và đưa ra quyết định. Nhưng điều này chỉ hoạt động nếu bạn sẵn sàng vứt bỏ mã đó nếu bạn cảm thấy nó tệ. Tôi nghĩ rằng đây là lợi thế của mã giả: càng ít cám dỗ để giữ nó khi nó hoạt động, nhưng nó sai về cấu trúc (và như mọi khi, bạn không có đủ thời gian). :-)