Bagaimana cara memvisualisasikan desain mesin fisika?

Saya membuat mesin fisika dan menjadi sangat sulit untuk melacak semuanya. Seringkali ketika saya kembali ke kode saya setelah istirahat saya hanya tidak ingat mengapa itu tidak berhasil. Sebagian besar masalah bukanlah kesalahan pemrograman sederhana tetapi kekurangan desain pada mesin fisika saya. Itu sebabnya saya harus menyelesaikan mendesainnya sebelum memprogramnya.

Namun, saya perlu cara untuk menulis di atas kertas seluruh desain mesin fisika saya. Kalau tidak, aku akan melupakannya besok dan hilang lagi. Diagram kelas UML tidak cocok sama sekali untuk desain mesin fisika. Saya tidak terlalu peduli dengan kelas tetapi prosesnya. Saya tidak melihat diagram proses bisnis sebagai sangat berguna karena memodelkan satu langkah (bingkai) dari proses saya tidak akan membantu saya memahami perilaku akhir mesin saya pada banyak langkah.

Jadi, diagram seperti apa yang harus saya gunakan untuk membantu saya melacak prosesnya? Diagram profesional seperti apa yang digunakan untuk membuat mesin fisika?

TO DO daftar adalah hal-hal yang luar biasa.

Saya tidak berbicara tentang // #TODO: komentar bla bla. Maksud saya mendapatkan buku catatan Tuhan yang jujur.

Anda tidak pernah tahu kapan Anda akan mengingat sesuatu yang penting untuk dilakukan. Notebook akan diam-diam duduk di sana dan membiarkan Anda berpikir tanpa mengeluh tentang bagaimana tulisan tangan Anda tidak akan dikompilasi. Beberapa ide terbaik saya terjadi di kamar mandi (ya saya punya buku catatan air tetapi Anda tidak harus sejauh itu).

Anda bisa mendapatkan yang berukuran saku yang dijahit (tidak direkatkan) sehingga tidak berantakan di saku Anda. Tidak berhasil mendapatkan yang mewah dengan tanda buku bawaan? Pita, gunting, pita dan tidak ada yang akan tahu.

Ketika sebuah ide muncul, catat saja. Gambarlah kotak-kotak kecil di sebelah setiap ide dan Anda dapat dengan mudah menandainya setelah selesai. Letakkan kotak di bagian atas halaman dan Anda tahu kapan halaman itu selesai.

Akses sekuensial apa yang tidak cukup baik untuk Anda? Ya mereka juga membuat pengikat saku. Ini semua mungkin tampak agak banyak tetapi lebih baik daripada tenggelam dalam catatan posting atau mencoba untuk menangkap segala sesuatu di Jira.

Jangan biarkan hal-hal setengah terlaksana

Jaga agar perbaikan Anda kecil dan dapat dicapai. Jangan memulai apa pun yang tidak dapat diselesaikan dalam satu sesi. Jika terlalu besar untuk itu, pilah menjadi beberapa langkah kecil. Selalu tinggalkan kode yang mengkompilasi dan lulus tes itu. Oh, dan jangan tinggalkan tes kelulusan yang belum pernah Anda lihat gagal. Membuat tes lulus dan gagal adalah cara Anda menguji tes.

Berhentilah berpikir Anda perlu seluruh desain di atas kertas

Yang perlu Anda lakukan adalah menangkap rencana Anda yang sedang berkembang. Anda tidak tahu bagaimana keadaannya ketika Anda selesai jadi berhentilah berpura-pura melakukannya. Tangkap apa yang sudah Anda pahami sebaik mungkin. Gunakan serbet dan krayon jika perlu. Hanya sedikit orang yang memahami 90% dari UML. Gunakan cara apa pun yang Anda bisa untuk menunjukkan apa yang perlu Anda perlihatkan. Saya fokus pada menunjukkan antarmuka saya dan apa yang tahu tentang apa.

Tulis catatan saat Anda berhenti menulis kode

Saat Anda melepaskan jari dari kunci adalah terakhir kali Anda akan memahami apa yang telah Anda lakukan (dan apa yang telah Anda rencanakan) serta yang Anda lakukan sekarang. Tangkap pemahaman itu sebaik mungkin dalam beberapa catatan. Jika yang Anda miliki hanyalah komentar maka Anda masih terikat pada komputer dan cenderung meninggalkan genangan air di kursi. Sekali lagi, memiliki notebook adalah hal yang luar biasa.

Dengan cara ini Anda dapat mendaratkan otak Anda dengan anggun, menyelamatkan kandung kemih Anda, dan lepas landas lagi nanti tanpa menggunakan kafein dan menggertakkan gigi.

"Semuanya harus dibangun dari atas ke bawah, kecuali untuk pertama kalinya", kata mereka.

Saya akan mulai dari level terendah (misalnya matematika vektor dasar), dan memastikan saya memahaminya dengan baik dan memiliki cakupan tes yang baik. Lalu saya akan membangun satu lapisan lagi di atasnya, memungkinkan untuk operasi yang lebih abstrak (misalnya grup / entitas, deteksi tabrakan, mekanika tabrakan). Sekali lagi, saya akan menutupinya dengan tes; itu akan membantu saya berpikir tentang kasus penggunaan nyata dari abstraksi ini di mesin.

Kecuali jika Anda memiliki pemahaman yang sangat baik tentang keseluruhan mesin (misalnya ketika Anda menerapkan kembali mesin yang sudah terkenal), biasanya baik untuk memiliki lapisan-lapisan ini; itu memungkinkan Anda untuk berpikir pada lapisan tertentu dalam hal lapisan sebelumnya, dan biasanya tidak jauh lebih dalam. Anda dapat bereksperimen dan membuat layer dengan abstraksi baru yang bermanfaat; apa yang terbukti praktis pada kenyataannya sering menyimpang dari ide-ide awal.

Semoga setiap layer cukup kecil sehingga Anda tidak perlu diagram yang rumit untuknya, atau mudah untuk membuat yang berguna.

Saya tidak pernah menemukan diagram kode kompleks yang bermanfaat. InteraksiDiagram dan siklus hidup bermanfaat. Cukup sering diagram seperti itu dibatasi 1-2 layer, dan karenanya sederhana.

Apa yang biasanya saya temukan paling berharga adalah deskripsi antarmuka dan jaminan yang disediakan oleh setiap tingkat. Misalnya format matematika vektor, dan apa yang terjadi pada kesalahan numerik; format deskripsi objek yang lebih besar (selalu cembung? selalu searah jarum jam ?, bagaimana berpotongan? dll), parameter mekanis interaksi (bagaimana waktu berkembang? bagaimana massa ditangani? momentum selalu dilestarikan? bagaimana gaya dihitung?) lalu interaksi yang tepat (bagaimana menangani gesekan? deformasi? fragmentasi? mengubah energi mekanik menjadi kehilangan panas?).

Setiap lapisan harus cukup kecil untuk memiliki jumlah yang dapat diamati yang diperkenalkan dan jaminan yang diberikannya. Deskripsi ini bahkan dapat disusun tanpa kode implementasi ditulis (belum). Ini menurunkan kesempatan untuk menentukan bahwa Anda telah melakukan sesuatu yang sangat salah dengan kedalaman tiga lapis; jika Anda melakukannya, itu akan terlihat paling dalam dua lapisan.

Buat diagram arsitektur! The diagram pipa OpenGL FrustratedWithFormsDesigner diposting di komentar adalah contoh yang bagus untuk program aliran , tapi itu hanya satu jenis diagram yang dapat berguna.

Saat mendesain diagram, Anda ingin memahami kode sederhana dan intuitif; ini dapat mencakup kedua konsep tingkat tinggi (seperti garis atas node dalam diagram pipa OpenGL, mengatakan sesuatu) atau rincian teknis yang sangat terperinci (seperti grafik panggilan fungsi penuh).

Idealnya, dokumentasi Anda juga harus membuat kode mudah dipahami orang lain; ini dapat membuat hal-hal seperti ulasan kode atau kolaborasi open-source menjadi mudah. Lihatlah ke proyek-proyek besar untuk melihat bagaimana mereka mencapai hal ini - ketika bekerja dengan ratusan atau ribuan baris kode, memahami bagaimana program bekerja tanpa harus membacanya secara besar-besaran penting untuk melacak basis kode atau memperkenalkannya kepada orang lain . Repositori Vim, dengan 1,3 juta LOC, memiliki dokumentasi tingkat tinggi (IMO) yang cukup bagus untuk ini di /src/README.txt . Ini memperkenalkan:

• Kode apa yang ada di setiap file
• Variabel global yang penting dan nilainya
• Apa yang terjadi di loop utama, dan apa fungsinya
• Apa yang terjadi di masing-masing mode, dan fungsi utama yang menanganinya
• Apa fitur debug asli itu

Jika saya ingin berkontribusi tambalan, saya biasanya tahu file mana yang perlu saya modifikasi untuk mencapai tujuan saya tanpa banyak menggali.

Salah satu fitur terbaik tentang Vim /src/README.txtadalah betapa mudahnya untuk menemukan dan seberapa komprehensifnya; itu tidak granular dalam arti apa pun, tetapi jika Anda mengklik srcfolder pada Github secara otomatis memuat, dan memberikan arahan untuk menemukan kode atau dokumentasi lain. Bandingkan dengan repo Powershell, yang saya cari contohnya tetapi tidak dapat menemukan file yang setara dengan Vim's /src/README.txt. (Pertanda buruk untuk proyek dengan 988 ribu LOC!)

Beberapa hal yang Anda mungkin ingin diagram atau dokumen termasuk:

• Alur program konseptual (Apa yang dicapai program , dan dalam urutan apa?)
• Grafik panggilan aliran fungsi / fungsi yang diterapkan (Bagaimana program mencapai tujuannya? Fungsi apa yang disebut atau kelas yang dibuat?)
• Kode apa dalam file apa? Apa skema organisasi dan aturan apa yang Anda miliki untuk menentukan ke mana fungsi baru berjalan? Jika Anda memiliki skema organisasi yang kuat, mengetahui file mana yang harus dicari untuk fungsi atau kelas yang diberikan akan mudah, bahkan tanpa fitur “find project-wide” seperti IDE atau IDE.
• Terkait, file mana yang termasuk file lain (terkait dengan grafik panggilan fungsi)?
• Kelas mana yang diwarisi dari kelas lainnya? Apa tujuan dari masing-masing kelas?

Bagaimana Anda bisa membuat diagram itu? Di level Anda, dan untuk draft pertama, pensil dan kertas mungkin merupakan metode terbaik / tercepat. Ketika diagram dan dokumentasi menjadi lebih disempurnakan, Anda dapat melihat:

• Dot / Graphviz, satu set program untuk menghasilkan grafik dari .dotfile.
• LaTeX / TikZ, alat yang sangat kompleks dan bertele-tele untuk menghasilkan grafik atau gambar dalam bentuk apa pun - mungkin terlalu kuat untuk kebutuhan Anda, terutama karena semua pemosisian simpul adalah manual, tetapi harus diingat, terutama jika Anda berencana untuk menulis kertas atau apapun semacam itu nanti.
• Untuk C, egyptkait gson ke dalam gccdan output .dotgrafik panggilan. Dapat diotomatisasi atau disematkan dalam makeperintah, yang bagus!
• Terkait, GNU cflowdapat menghasilkan grafik panggilan hanya teks untuk C. Alat yang setara mungkin ada untuk bahasa lain, meskipun Anda mungkin ingin menyimpang dari alat otomatis secara umum - tidak membuat grafik secara manual dapat menghambat pemahaman Anda tentang kode atau memberikan secara tidak tepat tingkat detail yang rumit (mengetahui fungsi mana yang dipanggil printf()biasanya tidak membantu).

Coba gunakan diagram berdasarkan Petri Nets. Dimungkinkan untuk menerjemahkan diagram ke dalam program komputer secara sistematis, dan dimungkinkan untuk mengintegrasikan diagram tingkat tinggi dengan diagram tingkat rendah.

Referensi

Elemen dan Anotasi Bersih: Bahasa Pemrograman Visual Tujuan Umum (2016). Tersedia di https://www.academia.edu/31341292/Net_Elements_and_Annotations_A_General-Purpose_Visual_Programming_Language .

Elemen dan Anotasi Bersih untuk Pemrograman Komputer: Komputasi dan Interaksi dalam PDF (2014). Tersedia di https://www.academia.edu/26906314/Net_Elements_and_Annotations_for_Computer_Programming_Computations_and_Interactions_in_PDF .