Haruskah metode pengembangan menghancurkan individualisme pengembang?


9

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?


20
Itu sangat buruk bahwa kelas Anda mengajarkan metode Waterfall, yang merupakan contoh kanonik dari proses buruk untuk pengembangan perangkat lunak.
whatsisname

6
Saya akan mengatakan bahwa kelas ini telah banyak mengajarkan Anda.
JeffO

7
Sebenarnya, air terjun asli memiliki iterasi yang saling memberi umpan balik. Ini adalah pengajaran yang salah dari Waterfall selama bertahun-tahun yang telah menghancurkan kegunaannya. Bahkan dengan sesuatu seperti Scrum, langkah-langkah yang dilalui sebuah Cerita dalam Sprint mengemulasi langkah dari air terjun itu sendiri. Diagram UML hanya berguna untuk desain tingkat tinggi. Segera setelah kode ditulis, dokumen apa pun yang ditulis sebelum kode itu sudah kedaluwarsa. Inilah realisasi rekayasa. Pada akhirnya, kodenya harus berupa dokumentasi.
Andrew T Finnell

10
Cukup banyak setiap pengembang telah melihat kasus individualisme pengembang yang seharusnya tergencet. (Meskipun mungkin tidak dengan metodologi air terjun).
psr

2
@whatsisname, saya sangat tidak setuju. Setiap pengembang harus mempelajari pengembangan Air Terjun sehingga mereka MEMAHAMI dan PENGALAMAN sebagai contoh kanonik dari pengembangan perangkat lunak yang buruk. Selain itu, banyak toko masih Air Terjun untuk benar atau salah dan penting bahwa lulusan siap untuk itu.
maple_shaft

Jawaban:


10

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.


+1 untuk menunjukkan bagaimana desain yang berbeda diperlukan untuk tujuan yang berbeda. Poin bagus tentang desain kelas juga; bertanya pada instruktur adalah ide yang bagus
Ethel Evans

1
Ingat aturan untuk lulus kuliah: Cari tahu apa yang diinginkan profesor, dan sampaikan itu.
Christopher Mahan

9

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.


4

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.


1
@pillmuncher Begitu sedikit orang yang membacanya, ini agak menyedihkan.
Thomas Owens

3
Hal yang paling menyedihkan tentang kertas itu adalah bahwa kebanyakan orang benar-benar menemukan air terjun melaluinya, sementara itu kertas yang benar-benar mendiskreditkan praktik.
Joeri Sebrechts

3

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.


1
@FreshDaddy. "Mereka (sebagian besar) tidak akan pernah melihat fungsi pribadi." Salah. Setelah Anda memenangkan lotre, programmer lain akan mengambil alih kode Anda dan melihat fungsi-fungsi pribadi. Juga. Beberapa bahasa (misalnya Python) menghindari privasi semacam ini.
S.Lott

2
@ S.Lott - Mendaftarkan setiap fungsi pribadi bukanlah persyaratan umum sama sekali. Itu terjadi, jangan salah, tapi skala penuh "daftar setiap fungsi pribadi sebelum menulis kode" tentu sangat jarang. Ada "tedius yang diperlukan" dan kemudian ada "tedius yang tidak berharga". Mempertimbangkan programer dalam bisnis menghilangkan "kebosanan yang tidak berharga", klien dunia nyata hampir tidak pernah akan meminta sesuatu yang mahal dan tidak berguna seperti ini, kecuali itu adalah kode jenis "hidup atau mati".
Morgan Herlocker

1
@ironcode: '"daftar setiap fungsi pribadi sebelum menulis kode" tentu sangat jarang.' Tidak dalam pengalaman saya. Begitulah cara orang belajar mendesain. Pemrogram junior sering memegang standar ini sampai mereka dapat membuktikan bahwa pekerjaan mereka tidak memerlukan tingkat pengawasan ini. Umumnya kurang dari setahun. Sebuah organisasi yang mengambil n00b dari sekolah dan melemparkan mereka pada pemrograman tanpa pengawasan sebagian besar hanya menciptakan masalah besar. Tingkat pengawasan ini sangat penting untuk memastikan bahwa kode memiliki peluang untuk bekerja.
S.Lott

1
@ S Lott - moto saya adalah jika pengembangan perangkat lunak membosankan, Anda salah melakukannya. Kami adalah programmer. Kami mengotomatisasi kebosanan. Kami tidak mengulangi diri kita dalam kode, dan tidak ada alasan untuk mengulangi diri kita sendiri dalam dokumentasi.
kevin cline

1
@ kevin: jawaban ini adalah sarkasme murni. Karena itu, itu sepenuhnya tidak pantas, dan saya telah menandai itu.
Michael Borgwardt

1

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.


1

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


1

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.


Dan hati-hati tentang "Bisakah itu membunuh orang jika crash" ada jenis lain yang disebut "Bisakah seseorang masuk penjara jika ini mencetak data yang salah" dan itu akan sering kembali ke orang itu meraba-raba keyboard, jadi ada baiknya untuk sangat detail persyaratan, hingga detail terkecil.
Christopher Mahan

@ Christopher: disesuaikan jawaban saya sesuai, terima kasih untuk komentar :)
Matthieu

0

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.


0

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.


2
Berani saya katakan Anda tidak pernah bekerja untuk perusahaan yang menghasilkan uang dari kontrak pemerintah. (sunting) Anda bilang perangkat lunak Komersial .. Pernyataan saya tidak ada artinya sekarang.
Andrew T Finnell

@Andrew Finnel: Kebenarannya sangat menyakitkan, pada banyak tingkatan.
Peter Rowell

2
@Andrew - Saya telah bekerja ke DOD2167. Itu mengerikan dan tidak produktif seperti yang dipraktikkan. Kemudian saya bekerja untuk perusahaan lain yang melakukan pengembangan tangkas untuk pemerintah dengan pengiriman sering. Klien itu sangat senang. Mereka memiliki aplikasi yang berguna dalam enam bulan dan mendapatkan fitur baru setiap tiga bulan.
kevin cline

@Andrew Saya memiliki lebih dari 2 tahun pengalaman dalam pekerjaan Departemen Pertahanan AS, sebagai pegawai pemerintah dan sebagai kontraktor. Metode tangkas sedang diadopsi. Satu tim yang saya kerjakan aktif menggunakan Scrum, menghasilkan "cukup" dokumentasi "tepat waktu". Ya, dokumentasi (bahkan dokumentasi "cukup") secara signifikan lebih luas daripada banyak tempat lain, tetapi itu biasanya didorong oleh jumlah pihak yang terlibat (kontrak dapat berpindah tangan, pihak lain dapat mengembangkan sistem lain, dan sebagainya) dan / atau keselamatan atau kekritisan hidup dan pentingnya sistem yang sedang dikembangkan.
Thomas Owens

2
@Andrew bukan hanya pemerintah. Saya telah melihat spesifikasi 40 halaman untuk "produk"; biasanya Anda dapat memilih semuanya dari tabel ini dan tolong beri saya pipa yang dibatasi. Tidak ada yang bisa diganggu untuk membacanya ...
Ben
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.