Ketika saya pertama kali memulai pemrograman, saya sangat bergantung pada diagram alur (dan grafik jarak printer). Ketika saya berada di kelas COBOL, saya tidak bisa mulai menulis kode apa pun sampai flowchart saya ditandatangani oleh instruktur. Saat itu, saya harus membuat diagram alur untuk semuanya.

Hari ini, dua puluh lima tahun kemudian, saya mendapati diri saya hanya merencanakan dua jenis hal. Algoritma yang sangat spesifik di mana logika rumit atau konsep yang sangat umum untuk memastikan bahwa saya mendapatkan semua langkah besar yang didefinisikan dan dalam urutan yang tepat.

Apakah ada kasing lain untuk bagan alur yang saya abaikan?

Benar.

Setiap kali saya mengimplementasikan sesuatu yang belum pernah saya lakukan sebelumnya (dan algoritma ini mengambil lebih dari beberapa langkah), saya akan memetakannya. Saya menemukan bahwa itu benar-benar memaksa saya untuk menganalisis seluruh solusi pada tingkat yang lebih atom dan lebih teliti daripada jika tidak dipetakan. Saya menemukan bahwa ada tiga manfaat utama praktik ini:

• Lebih sedikit "oh craps" karena saya sudah memikirkan keseluruhan algoritma
• Menghilangkan potensi ketukan pada masalah yang mungkin terjadi di seluruh sistem
• Memungkinkan saya memandu orang lain dengan mudah melalui algoritme

Dua kesempatan berbeda di mana saya benar-benar menggunakan ini adalah:

• Algoritma level rendah (ish). Maksud saya solusi yang sangat spesifik untuk masalah yang sangat spesifik. Saya biasanya akan melewati ini dengan teman sebaya sebelum implementasi.
• Alur pengguna. Saya tidak hanya dapat menggunakan ini untuk melewati rekan, tetapi saya juga akan menggunakannya untuk menjelaskan (dengan cara yang sangat non-teknis) mengalir ke pakar kegunaan.

Setelah mengatakan semua itu, saya tidak menghasilkan diagram alur setiap hari (dan bahkan ketika sudah selesai, ini umumnya sesi papan tulis kecuali saya sedang menulis dokumen desain teknis).

Tidak pernah

Flowchart - terutama seperti yang dipraktikkan 25+ tahun yang lalu - telah digantikan oleh teknik diagram yang jauh lebih ekspresif (lihat Diagram Tindakan, Diagram Urutan, State Charts, dkk).

Studi IBM sendiri menunjukkan bahwa penggunaan diagram alur tidak berpengaruh pada kualitas desain atau implementasi sistem (meskipun mereka sedikit berguna untuk berkomunikasi dengan pengguna dan pengembang lain) [referensi yang tepat tidak tersedia, tetapi dikutip dalam Diagramming Technik James Martin untuk Analis dan Programer ].

Saya belum menggambar diagram alir klasik sejak kelas pemrograman pertama saya pada tahun 1976, dan belum melihat orang lain membuatnya sejak awal 80-an. Diagram alir berguna untuk mengkomunikasikan logika program ketika kode tersebut dalam bahasa assembly. Pada akhir 1960-an, programmer bahasa assembly menggunakan kode semu. Saat pemrograman dalam bahasa OO modern, diagram alir atau pseudo-code tidak memiliki nilai. Anda mungkin juga menulis kode tingkat tinggi dalam bahasa implementasi.

Saya kadang-kadang menggambar diagram UML, kebanyakan di atas kertas, untuk mengekspresikan ide-ide desain, tetapi diagram itu hanya hidup sampai akhir diskusi. Saya juga menggambar diagram transisi negara dari waktu ke waktu, lalu mengonversinya menjadi tabel negara dalam bahasa implementasi.

Saya menggunakan diagram alur sepanjang waktu karena sejumlah alasan:

1. Mereka lebih baik daripada UML use case diagram menurut saya. Mereka dapat mencerminkan sejumlah kasus penggunaan yang berbeda dan bagaimana mereka berinteraksi, dan mereka melakukan pekerjaan yang lebih baik secara keseluruhan menyatukan pengalaman pengguna dan keputusan bersama.

2. Mereka lebih mudah dimengerti dan lebih intuitif. Pikiran Anda secara alami mengikuti panah seperti labirin dari awal hingga akhir. Anda bisa menggunakan diagram alur untuk mengakhiri dan referensi diagram alur lain untuk cerita pengguna yang berbeda. Saya biasanya dapat mencetaknya dalam buku bernomor halaman dan dengan cepat membalik halaman untuk menavigasi ke bagan alur berikutnya.

3. Mereka universal. Hanya sedikit orang di luar rekayasa perangkat lunak yang tahu dan memahami diagram UML, di mana diagram Flowchart jauh lebih mudah dikenali oleh pengguna dan analis bisnis. Saya mencoba untuk mengkomunikasikan case use yang kompleks kepada pelanggan dan mereka kadang-kadang kesulitan untuk memahami, saya menggambar mereka bagan alur dan mereka mengerti mengapa akhirnya memahami semua nuansa yang membuatnya jauh lebih kompleks dari yang mereka kira.

Diagram alir berguna ketika hal-hal perlu dilakukan dalam urutan tertentu. Di mana mereka benar-benar bersinar dalam pikiran saya menunjukkan di mana keputusan dibuat dan memastikan bahwa setiap keputusan yang mungkin ada jalan. Ini mencegah pembuatan program di mana persetujuan mamager diperlukan tetapi tidak memiliki cara untuk menghadapinya jika manajer (yang menyetujui 98% dari waktu) mengatakan tidak. Mereka mengingatkan kita bahwa jalan yang paling umum bukanlah satu-satunya jalan. Saya menemukan mereka berguna dalam berbicara dengan pengguna tentang persyaratan karena seringkali mereka hanya akan memberi tahu Anda jalan yang paling umum.

Diagram Alir dapat berguna untuk rekayasa terbalik kode yang sangat terstruktur. Terutama jika memiliki foto. Untungnya saya belum melihat banyak kode goto-riddden baru-baru ini.

Seperti yang lain dicatat untuk berkomunikasi dengan pengguna akhir. Saya mengurutkan startup dari pemancar TV yang didokumentasikan oleh bagan alur. Perangkat keras dan perangkat lunak orang memiliki spesifikasi umum untuk bekerja.

Diagram Aktivitas UML dan Diagram Alir berguna untuk menunjukkan kompleksitas proses atau algoritme yang rendah hingga sedang.

Mereka sangat baik ketika berkomunikasi dengan pengguna bisnis tentang aturan bisnis.

Variasi ada pada bentuk BPMN 2.0 yang sangat berguna dalam Pemodelan Proses Bisnis.

Beberapa alat BPMN dapat menghasilkan aplikasi web yang sedang berjalan dari grafik.

Jadi ya, diagram alur masih memiliki tempat tetapi harus digunakan dengan bijak.

Saya bukan seorang programmer. Saya seorang teknisi perangkat keras.

Masuk akal bagi saya untuk setidaknya mulai dengan komentar yang menjelaskan blok logis yang akan digunakan. Setelah itu, menyempurnakan kerangka program dengan kode aktual. Ini mirip dengan memulai skrip film dengan papan cerita dan kemudian mengisi detail tindakan dan dialog sesudahnya.

Tidakkah usaha yang bermanfaat harus direncanakan dengan hati-hati? Di ranah perangkat keras, kita mulai dengan dokumen kebutuhan pelanggan, lalu menulis dokumen spesifikasi perangkat keras, kemudian menyempurnakan skematiknya, kemudian menggambar tata letak papan, kemudian membuat dokumentasi perakitan. Kami tidak hanya mulai mengambil bagian-bagian dan menyatukannya bersama-sama saat kami memiliki ide untuk membuat produk akhir.

Saya tidak melihat bagaimana kode efisien dapat ditulis dalam program 15KB atau 15MB tanpa banyak persiapan sebelum memulai pengkodean yang sebenarnya.