Khi tôi mới bắt đầu lập trình, tôi đã phụ thuộc rất nhiều vào sơ đồ (và biểu đồ khoảng cách máy in). Khi tôi học lớp COBOL, tôi không thể bắt đầu viết bất kỳ mã nào cho đến khi sơ đồ của tôi được ký bởi người hướng dẫn. Hồi đó, tôi phải làm sơ đồ cho mọi thứ.

Hôm nay, hai mươi lăm năm sau, tôi thấy mình chỉ lưu chuyển hai loại thứ. Các thuật toán rất cụ thể trong đó logic là các khái niệm phức tạp hoặc rất chung chung để đảm bảo rằng tôi có được tất cả các bước lớn được xác định và theo đúng thứ tự.

Có trường hợp sử dụng nào khác cho sơ đồ mà tôi đơn giản bỏ qua không?

Chắc chắn rồi.

Bất cứ khi nào tôi thực hiện điều gì đó mà tôi chưa từng làm trước đây (và thuật toán mất hơn một vài bước), tôi sẽ vạch ra nó. Tôi thấy rằng nó thực sự buộc tôi phải phân tích toàn bộ giải pháp ở cấp độ nguyên tử và kỹ lưỡng hơn so với việc nó không được vạch ra. Tôi thấy rằng có ba lợi ích chính cho thực hành này:

• Ít "oh craps" hơn vì tôi đã nghĩ toàn bộ thuật toán thông qua
• Xóa bỏ bất kỳ tiếng gõ tiềm năng nào đối với các vấn đề có thể xảy ra trong phần còn lại của hệ thống
• Cho phép tôi dễ dàng đi bộ người khác thông qua thuật toán

Hai dịp khác nhau mà tôi thực sự sử dụng đó là:

• Các thuật toán mức thấp (ish). Tôi có nghĩa là một giải pháp rất cụ thể cho một vấn đề rất cụ thể. Nói chung tôi sẽ vượt qua những điều này bởi các đồng nghiệp trước khi thực hiện.
• Lưu lượng người dùng. Tôi không chỉ có thể sử dụng điều này để vượt qua một người ngang hàng, mà tôi cũng sẽ sử dụng nó để giải thích (theo cách rất phi kỹ thuật) cho một chuyên gia về khả năng sử dụng.

Như đã nói, tôi không tạo ra sơ đồ hàng ngày (và ngay cả khi họ đã hoàn thành, đó thường là phiên bảng trắng trừ khi tôi đang viết tài liệu thiết kế kỹ thuật).

Không bao giờ

Sơ đồ khối - đặc biệt là đã được thực hiện hơn 25 năm trước - đã được thay thế bằng các kỹ thuật biểu đồ biểu cảm hơn nhiều (cf Sơ đồ hành động, Biểu đồ trình tự, Biểu đồ trạng thái, et al).

Các nghiên cứu của IBM cho thấy rằng việc sử dụng sơ đồ không ảnh hưởng đến chất lượng thiết kế hoặc triển khai của hệ thống (mặc dù chúng rất hữu ích để giao tiếp với người dùng và các nhà phát triển khác) [tham khảo chính xác không có sẵn, nhưng được trích dẫn trong Kỹ thuật lập sơ đồ của James Martin cho các nhà phân tích và lập trình viên ].

Tôi đã không vẽ một biểu đồ dòng cổ điển kể từ lớp lập trình đầu tiên của tôi vào năm 1976, và chưa thấy ai khác tạo ra một biểu đồ kể từ đầu những năm 80. Biểu đồ luồng rất hữu ích để giao tiếp logic chương trình khi mã bằng ngôn ngữ hợp ngữ. Vào cuối những năm 1960, các lập trình viên ngôn ngữ lắp ráp đã sử dụng mã giả. Khi lập trình bằng các ngôn ngữ OO hiện đại, cả biểu đồ luồng và mã giả đều không có giá trị. Bạn cũng có thể viết mã cấp cao bằng ngôn ngữ thực hiện.

Thỉnh thoảng tôi vẽ sơ đồ UML, chủ yếu trên giấy, để thể hiện ý tưởng thiết kế, nhưng những sơ đồ đó chỉ tồn tại cho đến khi kết thúc cuộc thảo luận. Thỉnh thoảng tôi cũng vẽ sơ đồ chuyển trạng thái, sau đó chuyển đổi chúng thành bảng trạng thái bằng ngôn ngữ thực hiện.

Tôi sử dụng sơ đồ mọi lúc vì một số lý do:

1. Theo tôi, chúng tốt hơn sơ đồ ca sử dụng UML. Chúng có thể phản ánh một số trường hợp sử dụng khác nhau và cách chúng tương tác, và chúng thực hiện công việc tốt hơn nói chung mang lại trải nghiệm và quyết định của người dùng với nhau.

2. Chúng dễ hiểu và trực quan hơn. Tâm trí của bạn tự nhiên đi theo những mũi tên như một mê cung từ đầu đến cuối. Bạn có thể sử dụng sơ đồ để kết thúc và tham khảo một sơ đồ khác cho một câu chuyện người dùng khác. Tôi thường có thể in chúng trong một cuốn sách được đánh số trang và nhanh chóng lật các trang để điều hướng đến biểu đồ luồng tiếp theo.

3. Họ là phổ quát. Rất ít người ngoài công nghệ phần mềm biết và hiểu sơ đồ UML, trong đó sơ đồ Flowchart dễ nhận biết hơn nhiều bởi người dùng và nhà phân tích kinh doanh. Tôi cố gắng truyền đạt các trường hợp sử dụng phức tạp cho khách hàng và đôi khi họ đấu tranh để hiểu, tôi vẽ cho họ một sơ đồ và họ hiểu tại sao cuối cùng lại hiểu tất cả các sắc thái khiến nó phức tạp hơn họ nghĩ.

Sơ đồ khối là hữu ích khi mọi thứ cần phải được thực hiện theo một thứ tự cụ thể. Nơi họ thực sự tỏa sáng trong tâm trí tôi đang chỉ ra nơi quyết định được đưa ra và đảm bảo rằng mỗi quyết định có thể có một con đường. Điều này ngăn chặn việc tạo các chương trình yêu cầu phê duyệt mamager nhưng không có cách nào để xử lý nếu người quản lý (người phê duyệt 98% thời gian) nói không. Họ nhắc nhở chúng ta rằng con đường phổ biến nhất không phải là con đường duy nhất. Tôi thấy chúng hữu ích khi nói chuyện với người dùng về các yêu cầu bởi vì thường thì họ sẽ chỉ cho bạn biết con đường phổ biến nhất.

Biểu đồ dòng chảy có thể hữu ích cho kỹ thuật đảo ngược mã có cấu trúc rất xấu. Đặc biệt nếu nó có gotos. Rất may, tôi đã không thấy nhiều mã goto-đột ngột gần đây.

Như những người khác lưu ý để giao tiếp với người dùng cuối. Tôi sắp xếp việc khởi động một máy phát TV được ghi lại bằng biểu đồ dòng chảy. Những người phần cứng và phần mềm có một đặc điểm kỹ thuật chung để làm việc.

Sơ đồ hoạt động UML và Sơ đồ khối rất hữu ích để hiển thị độ phức tạp từ thấp đến trung bình của một quy trình hoặc thuật toán.

Họ rất tốt khi giao tiếp với người dùng doanh nghiệp về các quy tắc kinh doanh.

Một biến thể tồn tại trên hình thức BPMN 2.0 rất hữu ích trong Mô hình hóa quy trình nghiệp vụ.

Một số công cụ BPMN có thể tạo các ứng dụng web đang chạy từ biểu đồ.

Vì vậy, có, lưu đồ vẫn có một vị trí nhưng chúng cần được sử dụng một cách khôn ngoan.

Tôi không phải là một lập trình viên. Tôi là một công nghệ kỹ thuật phần cứng.

Nó có ý nghĩa với tôi ít nhất là bắt đầu với các bình luận giải thích các khối logic sẽ được sử dụng. Sau đó, làm sáng tỏ bộ xương chương trình với mã thực tế. Nó tương tự như bắt đầu một kịch bản phim với một bảng câu chuyện và sau đó điền vào các chi tiết hành động và hộp thoại sau đó.

Không nên có bất kỳ nỗ lực đáng giá nào được lên kế hoạch cẩn thận? Trong lĩnh vực phần cứng, chúng tôi bắt đầu với một tài liệu yêu cầu của khách hàng, sau đó viết ra một tài liệu đặc tả phần cứng, sau đó đưa ra sơ đồ, sau đó vẽ bố cục bảng, sau đó đưa ra tài liệu lắp ráp. Chúng tôi không chỉ bắt đầu lấy các bộ phận và hàn chúng lại với nhau khi chúng tôi đưa ra ý tưởng để tạo ra sản phẩm cuối cùng.

Tôi không thấy cách mã hiệu quả có thể được viết trong chương trình 15KB hoặc 15 MB mà không có nhiều công việc chuẩn bị trước khi bắt đầu mã hóa thực tế.