Di kelas kita belajar tentang berbagai metode pengembangan perangkat lunak. Yang kami fokuskan, dan digunakan untuk mengembangkan proyek kami, adalah metode air terjun.
Anda mungkin belajar model Waterfall klasik, yang dikaitkan dengan memperkenalkannya kepada dunia pengembangan perangkat lunak sejak awal tidak sesuai untuk mengembangkan sistem perangkat lunak skala besar. Anda mungkin akan tertarik membaca makalah Winston Royce berjudul Mengelola Pengembangan Sistem Perangkat Lunak Besar untuk mempelajari lebih lanjut tentang masalah dengan apa yang banyak orang anggap sebagai model Waterfall.
Namun, model Waterfall baik untuk mengajarkan siklus pengembangan perangkat lunak saat Anda melewati dan dapat menghabiskan waktu belajar tentang dan melakukan rekayasa persyaratan, desain arsitektur, desain rinci, implementasi, pengujian, dan pemeliharaan dalam fase yang sangat jelas, berbeda.
Di diagram kelas kami, kami harus membuat daftar SEMUA properti dan metode termasuk yang pribadi. Saya telah membaca beberapa buku, yaitu Clean Code, yang mengatakan untuk menjaga fungsi sesingkat dan fokus mungkin. Tampaknya membosankan untuk membuat daftar setiap fungsi kecil di diagram kita jika mereka tidak membantu pengembang lain (mereka pribadi, tidak ada orang lain yang akan menggunakannya). Plus, saya mungkin tidak memikirkan setiap fungsi kecil saat mendesain program, mereka mungkin muncul saat refactoring.
Ini semua adalah poin yang sangat valid.
Daftar semua properti dan metode selama fase desain, bahkan ketika menggunakan Air Terjun, mungkin berlebihan. Anda harus mencantumkan semua yang bersifat publik, bersama dengan properti-properti penting. Pada kenyataannya, semua yang lain adalah detail implementasi yang dapat Anda peroleh dengan merekayasa balik implementasi Anda menjadi diagram.
Saran Clean Code (saya belum pernah membacanya - saya hanya akan dengan apa yang Anda posting) tampaknya adil, dan berlaku bahkan ketika menggunakan metodologi Waterfall. Anda dapat merancang kelas dan metode Anda sehubungan dengan Prinsip Tanggung Jawab Tunggal , pemisahan masalah , dan prinsip-prinsip SOLID lainnya . Waterfall tidak memberi tahu Anda cara mendesain, hanya saat Anda perlu melakukannya. Yang mengatakan, lebih sulit di muka saat Anda belajar dan memikirkan cara yang lebih baik untuk melakukannya selama implementasi.
Saya pikir ini menunjukkan fakta bahwa perlu ada iterasi antara desain dan implementasi yang sangat jelas - masalah yang tidak dijelaskan oleh Waterfall tradisional.