Haruskah metode pengembangan menghancurkan individualisme pengembang?

Saya di semester akhir kuliah dan sedang mengambil kursus rekayasa perangkat lunak. Di kelas kita belajar tentang berbagai metode pengembangan perangkat lunak. Yang kami fokuskan, dan digunakan untuk mengembangkan proyek kami, adalah metode air terjun.

Saya merasa bahwa instruktur mungkin telah menerapkannya dengan salah. 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.

Apakah instruktur memberi tahu kami salah dengan meminta kami membuat daftar setiap fungsi? Dan, apakah metode desain ini menghancurkan individualisme pengembang untuk menulis kode bagaimana mereka bisa memahaminya?

Apakah Anda bertanya kepada instruktur mengapa Anda harus membuat daftar semua metode?

Ada kemungkinan bahwa, seperti banyak dari apa yang diminta di lingkungan kelas, tujuannya bukan untuk membuat diagram kelas Anda lebih bermanfaat bagi pengembang tetapi untuk membantu Anda dan teman sekelas Anda berpikir tentang bagaimana Anda akan merancang kelas Anda. Ketika siswa belajar bagaimana menguraikan masalah yang lebih besar menjadi masalah yang lebih kecil, mungkin membantu mereka untuk memikirkan metode pribadi apa yang mungkin mereka butuhkan. Dan mungkin bermanfaat bagi instruktur untuk mendapatkan ide yang lebih baik tentang metode apa yang dipikirkan siswa untuk diterapkan agar dapat melakukan intervensi lebih awal dalam proses jika desain seseorang tidak dipikirkan dengan baik. Dokumentasi di lingkungan kelas sering kali lebih banyak terlibat daripada dokumentasi di lingkungan dunia nyata karena instruktur '

Tentu saja, instruktur juga percaya bahwa level dokumentasi ini sangat membantu dalam proyek nyata. Jika itu masalahnya, instruktur mungkin kedaluwarsa atau berasal dari latar belakang ceruk tertentu di mana tingkat perencanaan dan dokumentasi ini sesuai. Jika Anda sedang membangun sistem navigasi untuk pesawat ruang angkasa atau mendesain perangkat medis, misalnya, umumnya jauh lebih tepat untuk berinvestasi besar-besaran dalam mendesain di muka daripada kode refactoring selama pengembangan. Jika Anda mengembangkan situs jejaring sosial, di sisi lain, pendekatan yang lebih gesit lebih tepat.

Tidak, instruktur benar memberi tahu Anda untuk membuat daftar semua properti dan metode di muka jika Anda menggunakan metode air terjun. Wikipedia mencatat kritik terhadap air terjun:

Banyak yang berpendapat bahwa model air terjun adalah ide yang buruk dalam praktiknya — meyakini bahwa mustahil bagi proyek non-sepele untuk menyelesaikan fase siklus hidup produk perangkat lunak dengan sempurna sebelum pindah ke fase berikutnya dan belajar dari mereka. Misalnya, klien mungkin tidak tahu persis persyaratan apa yang mereka butuhkan sebelum meninjau prototipe yang berfungsi dan mengomentarinya. Mereka dapat mengubah persyaratan mereka secara konstan. Desainer dan programmer mungkin memiliki sedikit kendali atas ini. Jika klien mengubah persyaratan mereka setelah desain selesai, desain harus dimodifikasi untuk mengakomodasi persyaratan baru. Ini secara efektif berarti membatalkan banyak jam kerja, yang berarti peningkatan biaya, terutama jika sejumlah besar sumber daya proyek telah diinvestasikan dalam Big Design Up Front.

Metode desain ini tidak menekan implement individualisme desain karena masih ada bagian untuk menafsirkan dan cara untuk menempatkan sentuhan unik seseorang pada struktur, misalnya gambar yang diberi kerangka dan menambahkan otot dan jaringan lain untuk membuat hewan bertanya-tanya berapa banyak kebebasan apakah Anda harus merancang binatang itu?

Anda telah menemukan kekurangan air terjun ya tapi semuanya memiliki kekuatan dan kelemahannya.

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.

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).

Jika Anda pikir ini membosankan, tunggu sampai Anda mendapatkan pemrograman pekerjaan nyata. Pertimbangkan, sejenak, bahwa perangkat lunak mungkin bukan karier yang layak untuk Anda.

Plus, saya mungkin tidak memikirkan setiap fungsi kecil saat mendesain program, mereka mungkin muncul saat refactoring.

Begitu?

apakah instruktur memberi tahu kami salah dengan meminta kami untuk membuat daftar setiap fungsi?

Tidak. Ini persyaratan umum.

Dan, apakah metode desain ini meremukkan pelaksana individualisme desain (pengembang) untuk menulis kode bagaimana mereka bisa memahaminya?

Iya. Menghancurkan jiwa individu adalah bagian penting dari pengembangan perangkat lunak. Semua individualitas akan dikalahkan oleh semua programmer setiap saat dengan cara yang memungkinkan. Dikatakan bahwa di suatu tempat dalam "Peraturan Pemrograman Tuhan" diturunkan dari gunung kepada seorang nabi.

Tidak. Anda hanya menolak keras di kebosanan. Lupakan dan kembali bekerja.

Pemrograman adalah seni bekerja dalam batasan. CPU menyediakan set instruksi terbatas; IO dibatasi oleh desain perangkat keras; API OS dibuat untuk mendorong perilaku tertentu dan membatasi yang lain; bahasa tingkat tinggi sering dirancang untuk mempromosikan satu set idiom di atas yang lain ...

Dan metodologi juga dibuat untuk membatasi.

Tantangan Anda, dalam semua aspek proses pengembangan, adalah mewujudkan visi Anda dalam batasan-batasan itu. Apakah Anda akan menampar kepala Anda ke setiap dinding yang dilempar oleh perangkat keras, bahasa, API, dan metodologi? Atau apakah Anda akan menemukan cara untuk menyelaraskan apa yang ingin Anda capai dengan apa yang diperbolehkan dan didorong?

Apakah Anda benar-benar berpikir instruktur Anda ingin membaca halaman-halaman minutia tanpa akhir? Kemudian uji teori itu: hancurkan sebuah program, dan dokumentasikan setiap atom. Ketika mejanya merosot di bawah beban, saya agak curiga Anda akan menemukan bahwa hasrat sejatinya agak berbeda dari yang Anda harapkan.

Atau mempersiapkan dokumentasi seperti yang Anda lihat cocok. Jelaskan, buatlah dimengerti, buatlah bacaan seperti novel Dashiell Hammett. Dan kemudian duduk dan berbicara dengannya, tunjukkan kepadanya apa yang telah Anda lakukan, yakinkan dia akan kebaikannya.

Saya pikir instrukturnya brilian untuk membuat Anda melakukan proyek ini, dan dengan demikian mengajarkan Anda pro dan kontra (kebanyakan) kontra pengembangan Waterfall.

Aturan sederhana untuk mengukur kompleksitas analisis proyek adalah "Dapatkah pengembang atau perusahaan tempat ia bekerja dapat dianggap bertanggung jawab atas sesuatu yang cukup dramatis (umumnya termasuk kematian atau kehilangan banyak uang) yang terjadi dengan perangkat lunak yang dibuat?".

Saya memiliki pengalaman yang sama dengan Anda untuk beberapa kursus saya. Orang-orang yang memiliki latar belakang industri miltary akan mengajari kami analisis. Dan itu akan menjadi analisis yang lengkap dan lengkap, merencanakan semua jalannya proyek, bahkan dalam perincian terkecil. Anda tidak dapat membeli banyak iterasi dengan proyek semacam ini (juga ledakan bom bisa baik-baik saja, ledakan anggaran tidak), jadi tidak ada tempat untuk kreativitas di sini, Anda harus mengikuti rencana.

Di sisi lain, jika Anda telah membaca sedikit, Anda tentu membaca tentang metodologi lincah. Pada umumnya ada lebih sedikit dokumentasi, dan lebih banyak ruang bagi pengembang untuk menggunakan kreativitasnya sambil mengembangkan solusi untuk masalah yang ia hadapi.

Sebagai kesimpulan, semakin banyak pengalaman yang Anda dapatkan, semakin baik, dan apa yang ditunjukkan oleh instruktur Anda benar-benar berlaku di beberapa bagian industri. Perlu diketahui bahwa pasti ada banyak cara untuk mengelola dan mendesain proyek sebagaimana ada kode mereka. Dan Anda akan menemukan pembela dan kritik untuk mereka semua. Uji mereka saat Anda belajar, dan pilih yang Anda sukai.

Beberapa kelas rekayasa perangkat lunak, seperti yang saya miliki, diajarkan dengan gaya aneh di mana 'kegagalan adalah kesuksesan', kesuksesan adalah kesempatan yang sia-sia untuk belajar dari kegagalan, dan lebih banyak semakin sedikit dan semakin sedikit semakin banyak. Jika ini salah satunya, maka tetaplah dengan tugas dan menikmati keanehan.

Saya pikir instruktur Anda tidak terhubung. Perangkat lunak komersial jarang dirancang atau didokumentasikan sejauh itu. Itu terlalu mahal, dan dokumentasi yang dihasilkan tidak dapat dipertahankan tanpa biaya lebih banyak. IMO praktik semacam itu adalah warisan dari hari-hari ketika pengkodean sering dilakukan dalam bahasa assembly. Waktu Anda akan lebih baik dihabiskan untuk mencoba praktik yang lebih gesit: pengembangan berbasis tes, pemrograman pasangan, refactoring berkelanjutan.

Apakah instruktur "salah memberitahumu"?

Aku pikir begitu.

Menugaskan pekerjaan yang membosankan kepada pekerja properti intelektual itu sia-sia. Di sekolah, pekerjaan yang membosankan memiliki nilai pedagogis yang sedikit atau tidak ada, kecuali mungkin untuk membujuk siswa untuk melakukan pekerjaan yang membosankan. Latihan semacam itu memiliki konsekuensi negatif, baik bagi siswa, dan bagi industri. Para siswa dirugikan karena waktu mereka terbuang sia-sia. Industri ini dirugikan, karena beberapa siswa dapat menyimpulkan bahwa kebosanan seperti itu perlu, dan bermanfaat. Tidak juga. Dalam tiga puluh tahun dalam perangkat lunak, satu-satunya pekerjaan yang dapat saya pikirkan yang membosankan dan bermanfaat adalah mengubah kaset cadangan. Ada robot yang bisa melakukan itu, tetapi harganya sangat mahal.