เมื่อฉันเริ่มเขียนโปรแกรมเป็นครั้งแรกฉันพึ่งพาผังงานอย่างหนัก (และแผนภูมิระยะห่างของเครื่องพิมพ์) ในขณะที่ฉันอยู่ในชั้นเรียนภาษาโคบอลฉันไม่สามารถเริ่มเขียนโค้ดใด ๆ ได้จนกว่าผังงานของฉันจะถูกลงชื่อโดยผู้สอน ก่อนหน้านี้ฉันต้องทำแผนผังลำดับงานสำหรับทุกสิ่ง

วันนี้ยี่สิบห้าปีต่อมาฉันพบว่าตัวเองเป็นเพียงผังงานสองประเภท อัลกอริทึมที่เฉพาะเจาะจงมากซึ่งเป็นตรรกะที่มีความซับซ้อนหรือแนวคิดทั่วไปมากเพื่อให้แน่ใจว่าฉันได้รับทุกขั้นตอนใหญ่ที่กำหนดและในลำดับที่เหมาะสม

มีกรณีการใช้งานอื่น ๆ สำหรับผังงานที่ฉันมองข้ามไปหรือไม่?

อย่างแน่นอน

เมื่อใดก็ตามที่ฉันใช้บางสิ่งที่ฉันไม่ได้ทำมาก่อน (และอัลกอริทึมใช้เวลามากกว่าสองสามขั้นตอน) ฉันจะทำแผนภูมิออกมา ฉันพบว่ามันบังคับให้ฉันต้องวิเคราะห์โซลูชันทั้งหมดในระดับอะตอมมากขึ้นและละเอียดยิ่งขึ้นกว่าที่มันไม่ได้จัดทำแผนภูมิ ฉันพบว่ามีประโยชน์ที่สำคัญสามประการสำหรับการฝึกนี้:

• น้อยกว่า "oh craps" เพราะฉันคิดว่าอัลกอริทึมทั้งหมดผ่าน
• ล้างออกเคาะที่อาจเกิดขึ้นกับปัญหาที่อาจเกิดขึ้นตลอดทั้งระบบที่เหลือ
• ทำให้ฉันสามารถเดินคนอื่น ๆ ผ่านอัลกอริทึมได้อย่างง่ายดาย

สองโอกาสที่แตกต่างกันที่ฉันใช้สิ่งเหล่านี้คือ:

• อัลกอริทึมระดับต่ำ (ish) ฉันหมายถึงคำตอบที่เฉพาะเจาะจงสำหรับปัญหาที่เฉพาะเจาะจง ฉันจะผ่านสิ่งเหล่านี้โดยเพื่อนร่วมงานก่อนที่จะนำไปใช้
• กระแสผู้ใช้ ไม่เพียง แต่ฉันสามารถใช้สิ่งนี้เพื่อส่งผ่านเพียร์ แต่ฉันจะใช้เพื่ออธิบายการไหล (ในลักษณะที่ไม่ใช่ด้านเทคนิค) ไปยังผู้เชี่ยวชาญการใช้งาน

ต้องบอกว่าฉันไม่ผลิตผังงานทุกวัน (และแม้ว่าพวกเขาจะทำเสร็จแล้วมันเป็นเซสชั่นไวท์บอร์ดโดยทั่วไปเว้นแต่ฉันจะเขียนเอกสารการออกแบบทางเทคนิค)

ไม่เคย

ผังงาน - โดยเฉพาะเมื่อฝึกมากกว่า 25 ปีที่แล้ว - ถูกแทนที่ด้วยเทคนิคการสร้างไดอะแกรมที่แสดงออกมากขึ้น (cf Action Diagrams, Sequence Charts, State Charts, et al)

ของไอบีเอ็มศึกษาของตัวเองแสดงให้เห็นว่าการใช้ผังไม่มีผลต่อคุณภาพของการออกแบบระบบหรือการดำเนินการ (แม้ว่าพวกเขาจะมีประโยชน์เล็กน้อยสำหรับการสื่อสารกับผู้ใช้และนักพัฒนาอื่น ๆ ) [อ้างอิงได้อย่างแม่นยำไม่พร้อม แต่ถูกอ้างถึงในเจมส์มาร์ตินแผนภาพเทคนิค สำหรับนักวิเคราะห์และโปรแกรมเมอร์ ]

ฉันไม่ได้วาดแผนภูมิลำดับคลาสสิกตั้งแต่คลาสการเขียนโปรแกรมครั้งแรกของฉันในปี 1976 และไม่เคยเห็นใครสร้างมาตั้งแต่ต้นยุค 80 แผนภูมิการไหลมีประโยชน์ในการสื่อสารตรรกะของโปรแกรมเมื่อรหัสเป็นภาษาแอสเซมบลี ในช่วงปลายปี 1960 โปรแกรมเมอร์ภาษาแอสเซมบลีกำลังใช้โค้ดหลอก เมื่อการเขียนโปรแกรมในภาษา OO สมัยใหม่ทั้งแผนภูมิการไหลหรือรหัสหลอกมีค่าใด ๆ คุณอาจเขียนโค้ดระดับสูงในภาษาการใช้งานได้เช่นกัน

ฉันวาดไดอะแกรม UML เป็นส่วนใหญ่บนกระดาษเป็นครั้งคราวเพื่อแสดงแนวคิดการออกแบบ แต่ไดอะแกรมเหล่านั้นมีชีวิตอยู่จนกระทั่งสิ้นสุดการอภิปรายเท่านั้น ฉันยังวาดไดอะแกรมการเปลี่ยนสถานะเป็นครั้งคราวจากนั้นแปลงเป็นตารางสถานะในภาษาที่ใช้งาน

ฉันใช้ผังงานตลอดเวลาด้วยเหตุผลหลายประการ:

1. พวกเขาดีกว่าแผนภาพใช้กรณี UML ในความคิดของฉัน พวกเขาสามารถสะท้อนจำนวนกรณีการใช้งานที่แตกต่างกันและวิธีโต้ตอบและพวกเขาทำงานได้ดีขึ้นโดยรวมนำประสบการณ์ผู้ใช้และการตัดสินใจเข้าด้วยกัน

2. พวกเขาเข้าใจง่ายและเข้าใจง่ายยิ่งขึ้น จิตใจของคุณตามลูกศรเหมือนเขาวงกตตั้งแต่ต้นจนจบ คุณสามารถใช้ผังงานเพื่อสิ้นสุดและอ้างอิงผังงานอื่นสำหรับเรื่องราวของผู้ใช้ที่แตกต่างกัน โดยทั่วไปฉันสามารถพิมพ์ลงในหนังสือที่มีหมายเลขหน้าและพลิกหน้าอย่างรวดเร็วเพื่อนำทางไปยังแผนภูมิลำดับต่อไป

3. พวกเขาเป็นสากล มีคนไม่กี่คนที่อยู่นอกวิศวกรรมซอฟต์แวร์ที่รู้และเข้าใจไดอะแกรม UML ซึ่งไดอะแกรม Flowchart เป็นที่รู้จักมากขึ้นโดยผู้ใช้และนักวิเคราะห์ธุรกิจ ฉันพยายามสื่อสารกรณีการใช้งานที่ซับซ้อนให้กับลูกค้าและพวกเขาพยายามเข้าใจบางครั้งฉันวาดแผนผังลำดับงานให้พวกเขาและพวกเขาเข้าใจว่าทำไมในที่สุดจึงเข้าใจความแตกต่างทั้งหมดที่ทำให้ซับซ้อนมากขึ้นกว่าที่พวกเขาคิด

ผังงานมีประโยชน์เมื่อจำเป็นต้องทำสิ่งต่าง ๆ ตามลำดับเฉพาะ จุดที่พวกเขาเปล่งประกายในใจของฉันแสดงให้เห็นว่ามีการตัดสินใจเกิดขึ้นที่ใดและทำให้แน่ใจว่าการตัดสินใจที่เป็นไปได้แต่ละอย่างมีเส้นทาง วิธีนี้จะป้องกันการสร้างโปรแกรมที่จำเป็นต้องมีการอนุมัติ mamager แต่ไม่มีวิธีจัดการหากผู้จัดการ (ผู้อนุมัติ 98% ของเวลา) บอกว่าไม่มี พวกเขาเตือนเราว่าเส้นทางที่พบบ่อยที่สุดไม่ใช่เส้นทางเดียว ฉันพบว่ามีประโยชน์ในการพูดคุยกับผู้ใช้เกี่ยวกับข้อกำหนดเนื่องจากบ่อยครั้งที่พวกเขาจะบอกเส้นทางที่พบบ่อยที่สุดให้คุณเท่านั้น

แผนภูมิการไหลจะมีประโยชน์สำหรับวิศวกรรมย้อนกลับรหัสที่มีโครงสร้างไม่ดีมาก โดยเฉพาะอย่างยิ่งถ้ามี gotos โชคดีที่ฉันไม่เห็นโค้ด goto-riddden มากในช่วงนี้

ตามที่คนอื่น ๆ ระบุไว้สำหรับการสื่อสารกับผู้ใช้ปลายทาง ฉันเรียงลำดับการเริ่มต้นของเครื่องส่งสัญญาณทีวีที่บันทึกไว้โดยโฟลว์ชาร์ต คนฮาร์ดแวร์และซอฟต์แวร์มีคุณสมบัติทั่วไปในการทำงาน

UML Activity Diagram และ Flowchart มีประโยชน์ในการแสดงความซับซ้อนของกระบวนการหรืออัลกอริทึมต่ำถึงปานกลาง

พวกเขาดีมากเมื่อสื่อสารกับผู้ใช้ทางธุรกิจเกี่ยวกับกฎเกณฑ์ทางธุรกิจ

การเปลี่ยนแปลงมีอยู่ในรูปแบบของ BPMN 2.0 ซึ่งมีประโยชน์มากในการสร้างแบบจำลองกระบวนการทางธุรกิจ

เครื่องมือ BPMN บางตัวสามารถสร้างแอปพลิเคชันเว็บที่กำลังเรียกใช้จากแผนภูมิ

ใช่แล้วผังงานยังคงมีสถานที่ แต่ต้องใช้อย่างชาญฉลาด

ฉันไม่ใช่โปรแกรมเมอร์ ฉันเป็นเทคโนโลยีวิศวกรรมฮาร์ดแวร์

อย่างน้อยก็ต้องเริ่มจากความเห็นที่อธิบายถึงบล็อกเชิงตรรกะที่จะใช้ หลังจากนั้นขยายโครงกระดูกของโปรแกรมด้วยรหัสจริง มันคล้ายกับการเริ่มบทภาพยนตร์ด้วยกระดานเรื่องราวแล้วกรอกรายละเอียดแอ็คชั่นและบทสนทนาหลังจากนั้น

ไม่ควรมีการวางแผนอย่างรอบคอบหรือไม่ ในขอบเขตฮาร์ดแวร์เราเริ่มต้นด้วยเอกสารความต้องการของลูกค้าจากนั้นเขียนเอกสารข้อกำหนดฮาร์ดแวร์จากนั้นร่างโครงร่างจากนั้นวาดโครงร่างกระดานแล้วสร้างเอกสารประกอบ เราไม่เพียงแค่เริ่มจับชิ้นส่วนและบัดกรีพวกมันเข้าด้วยกันเมื่อเราคิดไอเดียเพื่อสร้างผลิตภัณฑ์ขั้นสุดท้าย

ฉันไม่เห็นว่าโค้ดที่มีประสิทธิภาพสามารถเขียนในโปรแกรม 15KB หรือ 15MB ได้โดยไม่ต้องเตรียมงานมากมายก่อนเริ่มการเข้ารหัสจริง