Apakah perangkat lunak digunakan kembali mencegah proses pengulangan


25

Penggunaan Kembali Kode sebagai Masalah

Saya sedang memikirkan pertanyaan ini tentang pengiriman perangkat lunak, dan saya terus kembali ke masalah pengulangan dan / atau reproduksibilitas . Mereka penting, karena jika Anda tidak mengulangi proyek maka menjadi lebih sulit untuk meningkatkan proses yang Anda gunakan untuk membangun proyek. Rekayasa melibatkan peningkatan proses yang terlibat dalam desain dan konstruksi untuk menghasilkan proyek berkualitas lebih tinggi.

Perangkat lunak dapat sangat bergantung pada penggunaan kembali karena bentuk digitalnya. Alih-alih menulis ulang modul, kami hanya menyebutnya lagi atau menyalinnya ke sistem lain. Beberapa contohnya adalah otentikasi / login atau mungkin fungsi logging. Ada banyak contoh terkenal untuk kategori-kategori tersebut, dan kebijaksanaan konvensional adalah menggunakan kembali apa yang ada alih-alih menggulirkan kategori Anda.


Beberapa Perbandingan dengan Disiplin Lain

Konstruksi

Sebaliknya, konstruksi sistem fisik (bangunan, jembatan) tidak dapat digunakan kembali. Memang benar bahwa cetak biru sebuah rumah dapat digunakan berulang kali untuk membangun salinan rumah yang sama, tetapi pembangunannya harus dilakukan setiap waktu. Potong & tempel tidak berfungsi seperti itu di dunia analog. Cetak biru jembatan kurang dapat digunakan kembali oleh rumah karena kondisi lokasi akan bervariasi.

Pembangun ahli adalah ahli yang diakui telah merancang dan / atau membangun puluhan, ratusan, atau ribuan hal di area mereka. Misalnya, Frank Lloyd Wright , seorang arsitek dan desainer terkenal di dunia designed more than 1,000 structures and completed 532 works. Berbeda dengan Anders Hejlsberg yang telah merancang "hanya" lima bahasa (Turbo Pascal; Delphi; J ++; C #; Typcript). Dalam banyak hal, ini perbandingan yang tidak adil karena domainnya berbeda. Tetapi pada tingkat yang luas, produksi yang dapat diukur dari dua orang yang sangat cerdas sangat berbeda.

Seni bela diri

Seniman bela diri akan mengatakan bahwa penguasaan gerakan hanya datang dari ribuan pengulangan. Setelah sebagian besar pengulangan itu dilakukan, banyak seniman bela diri terkejut melihat bagaimana kata atau bentuk yang sebelumnya kompleks itu menjadi sederhana. Instruktur dari siswa tersebut juga akan memperhatikan bagaimana gerakan menjadi lebih lancar dan terarah serta memiliki ekonomi gerak. Demikian juga, seniman bela diri yang berpengalaman dapat mengambil katas yang lebih kompleks lebih cepat daripada siswa yang kurang berpengalaman. Pengalaman dari pengulangan telah memberi mereka kerangka kerja atau proses yang memungkinkan mereka untuk belajar lebih cepat.

Woodworking

Pekerja kayu mengalami transformasi serupa. Tukang kayu penghobi selalu merujuk kembali ke proyek pertama mereka yang membutuhkan banyak laci. Jika mereka menyelesaikan proyek, mereka mendapatkan apresiasi baru untuk efisiensi yang dihasilkan jalur perakitan. Ada manfaat lain seperti pemahaman yang lebih baik tentang cara meletakkan bagian-bagian laci pada lembar stok untuk memaksimalkan penggunaan kayu. Dibandingkan dengan penghobi, pekerja kayu profesional dapat lebih cepat merancang, memulai, dan membuat barang yang telah mereka buat berkali-kali sebelumnya. Mereka juga mendapatkan kemampuan untuk melihat masalah yang melekat dalam desain orang lain setelah melakukan kesalahan dalam pekerjaan mereka.


Jadi, apakah penggunaan kembali perangkat lunak mencegah pengembang perangkat lunak menjadi lebih mahir?

Dalam banyak hal, desain dan konstruksi perangkat lunak selalu baru. Kami tidak mengulangi pekerjaan sebelumnya, karena jika kami dapat menggunakan kembali modul, pustaka, atau sistem, maka kami melakukannya. Kami lebih suka memperluas sistem yang ada sebelum menulis ulang semuanya dari awal. Tetapi pengulangan itulah yang memungkinkan kami menemukan efisiensi dalam desain dan konstruksi. Siapa pun yang telah berlatih olahraga atau aktivitas fisik akan memberi tahu Anda bahwa pengulangan adalah kunci untuk menjadi seorang praktisi yang baik.

Pertanyaan saya: Apakah kemampuan perangkat lunak untuk digunakan kembali mencegah peningkatan proses yang diperlukan dan efisiensi yang datang dari pengulangan proyek?


Jika Anda telah menulis sepotong kode, pada dasarnya Anda telah memecahkan masalah. Jika Anda pandai, bagian ini memecahkan KELAS masalah. Jika Anda benar-benar baik, itu dapat diperluas ke metaclass masalah. Dan kemudian Anda kehilangan minat: tidak perlu menyempurnakan satu sepeda jika ada masalah desain yang belum terselesaikan. Sensasi pemecahan masalah datang dari menyinari hal-hal baru, bukan dari memoles masalah lama menjadi sempurna.
Pemburu Rusa

2
proyek perangkat lunak yang baik "menggeser" banyak pengulangan ke QA. Ketika saya adalah seorang penguji dalam proyek selama 1,5 tahun, kami menjalankan siklus uji pada rilis "pos pemeriksaan" mingguan, sekitar 70 kali total melalui proyek. Itu ... cukup berulang, berbicara dengan lembut (tidak banyak hal berubah dalam seminggu). Pengujian build malam telah, secara alami, bahkan lebih berulang - sekitar 500 kali melalui proyek (beberapa bug showstopper menghibur terlalu jarang untuk membuat perbedaan). Sekarang, katakan padaku sebuah perusahaan konstruksi yang telah membangun 500 jembatan - semuanya dengan tim yang sama
nyamuk

@gnat - itu wawasan yang sangat bagus dan perspektif yang belum saya renungkan. Aspek-aspek lain dari SDLC menjadi jauh lebih efisien karena pengulangan itu.

1
@ GlenH7 memperluasnya menjadi jawaban , sebagian besar untuk menyertakan gambar jembatan :)
agas

Berapa banyak masalah yang harus diselesaikan Frank Lloyd Wright dalam 1000 strukturnya versus Anders Hejsberg dalam mendefinisikan hanya 5 bahasa? Wright harus membuat keputusan berdasarkan dekrit, Anders harus membenarkan keputusan bagi banyak orang, sama pintar dan berpengetahuannya. Saya berani bertaruh Anders harus menyelesaikan banyak masalah. Jadi angka lempar Anda dalam campuran hanya pada apa yang Anda pilih untuk dihitung dan bukan angka yang dapat diperbandingkan nyata NYATA. Jadi saya suka pertanyaan, saya hanya tidak suka alasan / contoh yang menginspirasi pertanyaan. Efisiensi SW telah meningkat pesat selama bertahun-tahun.
Dunk

Jawaban:


10

Kemampuan untuk menggunakan kembali perangkat lunak tidak mencegah peningkatan proses.

Jika Anda berpikir tentang proses yang digunakan untuk membangun perangkat lunak - mengembangkan persyaratan, merancang sistem, menerapkan sistem, menyebarkan sistem, mengelola persyaratan, mengelola konfigurasi, memverifikasi dan memvalidasi produk kerja, melacak perubahan, dan sejumlah lainnya (lihat Area proses CMMI untuk satu kemungkinan gangguan kegiatan utama dalam pengembangan perangkat lunak) - ini diulang pada setiap proyek terlepas dari berapa banyak penggunaan kembali yang Anda miliki. Selain itu, masing-masing memiliki semacam ukuran kuantitatif dan kualitatif yang dapat digunakan untuk menentukan seberapa baik proses atau kegiatan tertentu itu, dan sebagai hasilnya, seberapa baik proses pengembangan secara keseluruhan.

Di salah satu ujung ekstrem, kita dapat mengasumsikan lini produk perangkat lunak yang kuat. Di sisi lain, Anda dapat mengasumsikan pengembangan greenfield. Masih ada kebutuhan untuk melakukan semua proses ini, pada tingkat yang berbeda-beda, meskipun mereka mungkin terjadi pada tingkat yang berbeda atau bahkan mungkin dalam urutan yang berbeda. Misalnya, dalam penggunaan kembali dalam jumlah besar, persentase lebih besar dari waktu yang dialokasikan dapat dihabiskan untuk kegiatan integrasi dan verifikasi / validasi pada tingkat sistem (persyaratan V&V, pengujian integrasi, pengujian sistem, tes penerimaan). Dengan upaya pengembangan baru, persentase waktu yang lebih besar mungkin diperlukan pada desain dan implementasi. Selama Anda melakukan proses setidaknya sekali selama proyek, Anda dapat mengukurnya (secara kuantitatif dan kualitatif). Setelah Anda membuat penyesuaian, dan melihat bagaimana penyesuaian tersebut berdampak pada ukuran area proses atau kemampuan keseluruhan untuk mengirimkan perangkat lunak,

Kunci dari peningkatan proses adalah untuk memiliki semacam penguraian logis dari aktivitas dan proses Anda, menentukan cara mengukurnya (lebih disukai secara konsisten), dan bagaimana memahami pengukuran tersebut untuk membuat perubahan proses menuju akhir. Ini bukan tentang pengulangan proyek, tetapi tentang konsistensi dalam bagaimana Anda mengulangi proses.


tergantung pada apa yang sebenarnya digunakan kembali, bahkan mungkin jatuh dalam Akuisisi CMMI, yaitu bukan pekerjaan pengembangan.
imel96

1
Namun CMMI belum berhasil dengan cara yang berarti. Tak satu pun dari "aplikasi pembunuh" abad ke-21 dibangun oleh orang-orang yang peduli dengan matriks kematangan CMMI. Beberapa orang brilian memiliki ide dan menerapkannya, dan kemudian mempekerjakan lebih banyak orang brilian untuk meningkatkan skala solusi. Sebaliknya, proyek-proyek yang mungkin setidaknya memberikan lip service ke standar seperti CMMI telah gagal total, misalnya upaya Departemen Pertahanan AS untuk membangun aplikasi penggajian baru.
kevin cline

1
@kevincline Tidak masalah bahwa CMMI telah atau belum berhasil. Duduk di industri kedirgantaraan / pertahanan, saya melihat CMMI di organisasi saya dan perusahaan tempat kami bekerja, bahwa kami adalah subkontraktor, dan kami subkontrak. Namun, maksud saya adalah bahwa untuk melakukan perbaikan proses, Anda perlu mengidentifikasi proses Anda. CMMI adalah alat tunggal untuk melakukan hal itu. Ada orang lain di luar sana, dan Anda dapat menentukan sendiri. Setelah Anda memiliki proses, Anda dapat mendefinisikannya, mengukurnya, dan memperbaikinya.
Thomas Owens

1
@Kevin: "Aplikasi Pembunuh" pada dasarnya "di luar arus utama". Jadi tidak mengherankan bahwa sebagian besar karya baru dan inovatif diciptakan oleh eksperimen dan peretasan daripada melalui beberapa proses disiplin. Meskipun, "aplikasi pembunuh" sesuai dengan definisi seseorang. Apakah aplikasi yang menjadi mode benar-benar "aplikasi pembunuh" atau program DoD yang memungkinkan Jet Fighters untuk terbang dengan aman dan mencegah mereka menembak sekutu mereka lebih dari "aplikasi pembunuh". Mode sering tidak memerlukan keterampilan / inovasi sama sekali (misalnya batu kesayangan, hula-hoop) ......
Dunk

... termasuk banyak program aplikasi "mode" yang sangat populer. Padahal, proyek tipe DoD besar hampir selalu membutuhkan keterampilan dan proses yang luar biasa. Juga, pandangan Anda tentang kegagalan CMMI mungkin mengatakan lebih banyak tentang pengalaman Anda (atau ketiadaannya) dalam industri yang menggunakan CMMI daripada CMMI itu sendiri. CMMI tidak sempurna, dan mungkin bahkan tidak baik, tetapi setidaknya itu membuat perusahaan setidaknya mencoba untuk menulis dan mengikuti proses dan bahkan mencoba untuk memperbaikinya. Jika hanya itu yang CMMI capai maka itu adalah kesuksesan.
Dunk

5

Saya pikir ide bahwa disiplin ilmu teknik lainnya tidak menggunakan kembali adalah salah. Bahkan ketika merancang bangunan / mesin Anda masih memiliki komponen yang digunakan oleh banyak proyek lain. Misalnya, apakah Anda merancang sekrup Anda sendiri? Mesin? Pintu atau jendela? Tentu saja tidak. Itu sering dirancang oleh orang yang berbeda yang kemudian menggunakannya dalam produk yang berbeda. Dan mereka sering standar, yang mempromosikan lebih banyak digunakan kembali.

Saya pikir masalahnya suka dalam kompleksitas. Anda tidak dapat membandingkan kompleksitas bahkan bangunan paling kompleks dengan perangkat lunak kompleks. Ini adalah ide yang diterima umum bahwa kompleksitas perangkat lunak adalah apa yang membuatnya sulit untuk didekati dari sisi teknik. Saat Anda memiliki proses di tempat yang memungkinkan Anda untuk membuat perangkat lunak dengan kualitas yang dapat diterima, Anda menemukan bahwa kompleksitas perangkat lunak yang Anda butuhkan untuk membuat lompatan dalam urutan besarnya. Jadi prosesnya tidak bisa digunakan. Jadi jika kita harus mengulang beberapa bagian dari perangkat lunak beberapa kali sampai kita puas dengan hasilnya, kita tidak akan pernah menyelesaikan perangkat lunak itu.

Itu sebabnya kode bersih dipromosikan. Kemampuan untuk mengubah kode masa lalu berdasarkan pengalaman baru dapat dikatakan sebagai bentuk penggunaan kembali desain. Jadi, alih-alih membuat perangkat lunak yang berbeda beberapa kali, kami melakukan refraksi dan memperbaiki satu perangkat lunak dengan menggunakan kembali pengalaman dan desain baru pada masalah lama. Semua sambil mencoba membuat perangkat lunak melakukan hal yang sama.


Bukan karena disiplin ilmu lain tidak menggunakan kembali desain, perbedaannya adalah jumlah penggunaan kembali. Semua objek yang Anda sebutkan harus dibangun secara fisik untuk setiap instansiasi. Saya tidak bisa hanya menyalin & menempelkan pintu, misalnya. Pengulangan yang berasal dari konstruksi mengarah pada pengidentifikasian efisiensi dan perbaikan yang tidak jelas pada permulaan. Bangun satu set lemari dapur dan Anda akan menemukan hal-hal baru antara tanggal 1 dan yang terakhir. Anda ada benarnya dengan kompleksitas keseluruhan, karena sifat virtual dari perangkat lunak memungkinkan kami untuk menumpuk kompleksitas tanpa disadari.

1
@ GlenH7 Masalahnya, pengembangan perangkat lunak tidak membangun. Itu merancang. Dengan membangun barang, Anda melakukan hal yang sama berulang kali. Tetapi dengan desain, Anda selalu memiliki tujuan dan masalah yang berbeda. Anda tidak harus membandingkannya dengan konstruksi bangunan, tetapi dengan penciptaan cetak biru itu.
Euforia

2
Saya tidak yakin saya sepenuhnya setuju dengan poin Anda tentang pengembangan perangkat lunak. Pengembangan SW adalah desain dan konstruksi. Konstruksi harus memberikan putaran umpan balik ke desain. Baik di bidang analog maupun digital, arsitek yang baik "membuat tangan mereka kotor" dan membangun untuk menyelesaikan loop umpan balik. Bahkan jika kita fokus pada desain saja, saya pikir pengulangan desain mengidentifikasi efisiensi yang mengarah pada desain yang lebih baik. SW tidak terulang seperti halnya bidang lainnya. Setiap jembatan memerlukan modifikasi dari pendekatan umum yang menyesuaikannya dengan situs yang akan dituju.

SW dev tidak begitu rumit dibandingkan dengan desain yang akan dibuat oleh arsitek. Hanya saja kami pikir itu sulit karena kami tidak memperlakukan perangkat lunak sebagai disiplin teknik yang tepat, dan karena kami terus menciptakan kembali hal-hal. Kalau saja Anda tahu apa yang masuk ke desain barang-barang lain Anda akan melihat bahwa sebagian besar perangkat lunak harus sepele, tetapi kami membuatnya sulit untuk diri kita sendiri :(
gbjbaanb

Untuk dibandingkan dengan jembatan - Anda benar, jembatan adalah masalah yang diselesaikan. Anda ingin jembatan baru, bersihkan desain lama dan buat beberapa penyesuaian dan Anda punya jembatan baru (saya melebih-lebihkan kesederhanaan di sini, tentu saja). Jadi mengapa layanan web tidak dibangun dengan perangkat lunak yang serupa? Itu sebabnya perangkat lunak bukan rekayasa IMHO, kami memperlakukannya lebih seperti kerajinan (atau seni) di mana setiap proyek adalah pekerjaan kustom.
gbjbaanb

2

Software ini berbeda dari kebanyakan disiplin lain, sehingga ekonomi di mana kita terbaik menghabiskan waktu kita sering kali berbeda.

Dalam konstruksi, Anda menghabiskan sejumlah waktu dan uang pada cetak biru (dan perangkat lunak jauh lebih seperti memproduksi cetak biru daripada seperti membangun gedung), kemudian, secara kasar, lebih banyak pada benar-benar membangunnya satu atau lebih kali. Jadi sangat layak untuk melakukan banyak pekerjaan untuk mendapatkan cetak biru yang benar. Lebih khusus untuk pertanyaan Anda - perlu diulang upaya melakukannya dari awal untuk membuat produk akhir sedikit lebih baik.

Dalam perangkat lunak, ketika Anda memiliki cetak biru itu, jauh lebih murah untuk membangun produk daripada membuat cetak biru itu. Setidaknya sebagian besar waktu - jika perangkat lunak akan tertanam dalam alat pacu jantung Anda jauh lebih dekat dengan situasi pembangun jembatan dalam beberapa cara. Tetapi secara umum, menggunakan kembali perangkat lunak dapat menghemat 90% dari biaya item anggaran terbesar Anda, vs menghemat 90% dari item anggaran yang jauh lebih kecil untuk membangun jembatan. Jadi, gunakan kembali kemenangan lebih sering.

Sejauh produktivitas - ketika Anda membangun, katakanlah, jembatan, Anda menghadapi kendala dunia nyata yang sangat signifikan. Bayangkan jika arsitek dibayar sejumlah besar uang untuk merancang jembatan untuk game online multipemain besar, di mana biaya konstruksi mendekati 0 dan batasannya kurang signifikan daripada dunia nyata. Mereka akan merancang jembatan yang sangat rumit menurut standar jembatan dunia nyata. Fase cetak biru mungkin membutuhkan waktu sedikit lebih lama.

Selain itu, ada sejumlah jembatan yang harus dibangun, dan, karena desain merupakan bagian kecil dari biaya, Anda dapat membayar untuk yang terbaik, dan beberapa yang terbaik dapat melakukan sebagian besar desain. Ada ratusan ribu pengembang perangkat lunak, dan pada dasarnya mereka semua memiliki tumpukan besar hal-hal yang akan mereka lakukan jika mereka punya waktu. Anda tidak akan menemukan satu orang yang melakukan sebagian besar dari semua itu - sungguh mengejutkan bahwa ada orang yang agak dekat, sungguh.

Maksud Anda yang sebenarnya adalah bahwa kita mungkin kehilangan sesuatu dengan menggunakan kembali alih-alih mencoba mengulangi dan memperbaiki keadaan. Saya pikir Anda ada benarnya. Masalahnya adalah bahwa meskipun kemungkinan besar akan lebih efisien secara global untuk menulis ulang beberapa hal mendasar dan mencoba untuk memperbaikinya, siapa pun yang mengambil risiko itu akan mendapatkan semua risiko dan mungkin tidak akan mendapatkan imbalan yang sebanyak itu. (Ada juga masalah praktis besar ketergantungan neraka, yang mungkin mengambil beberapa kemenangan dari penulisan ulang hal-hal, tetapi tidak sampai pada titik bahwa itu tidak akan berguna, setidaknya melihat gambaran global. Hak cipta dan paten juga dapat memaksa upaya rekayasa ulang yang diusulkan menggigit sedikit pekerjaan menulis ulang untuk mengulangi potongan-potongan kecil kode yang ada).

Dalam hal belajar dari pengulangan - di semua disiplin ilmu ini terjadi kurang dalam desain dari dalam konstruksi, karena ada yang kurang pengulangan, sehingga lebih sedikit kesempatan untuk belajar, dan mungkin kurang menguntungkan. Juga, proses desain mungkin tidak berulang. Ini seperti memiliki proses untuk menulis novel. Proses yang baik hampir pasti dapat membantu, dan perangkat lunak pada umumnya jauh lebih kolaboratif daripada sebuah novel, tetapi mengulangi proses ketika tujuannya adalah untuk menciptakan sesuatu yang baru itu bermasalah. Bahkan novelis belajar dari masa lalu, sangat banyak, tetapi proses berulang adalah faktor sekunder untuk usaha kreatif. Dan jika ada bagian dari pengembangan perangkat lunak yang benar-benar dapat diulang, mengapa komputer tidak melakukannya?


2

Apakah kemampuan perangkat lunak untuk digunakan kembali mencegah peningkatan proses yang diperlukan dan efisiensi yang datang dari pengulangan proyek?

Saya telah bekerja sebagai insinyur sistem dan perangkat lunak dalam proyek besar yang sama selama 17 tahun terakhir, secara kebetulan (memikirkan referensi Airbus A380 di tautan pertama Anda) di industri pesawat terbang, meskipun tanggung jawab saya ada di sektor pesawat militer. Cerita seperti itu pada dasarnya adalah fiksi murni, dan sebenarnya sangat lucu untuk ditonton ketika Anda memiliki wawasan orang dalam.

Tetapi untuk pertanyaan singkat dan ringkas Anda: Dari pengalaman saya, saya akan mengatakan ya dan tidak.

Pertama-tama saya katakan bahwa saya semua mendaur ulang perangkat lunak dalam segala bentuk (well, mungkin tidak semua ...). Keuntungan menggunakan kembali apa saja, mulai dari potongan-potongan kode dan algoritma, hingga seluruh modul kode dan pustaka fungsi, secara keseluruhan jauh lebih baik daripada selalu mulai dari awal lagi (untuk mendorongnya sedikit).

Kelemahannya adalah, seperti yang Anda tunjukkan (atau paling tidak menyimpulkan), bahwa ketika Anda menambahkan fungsionalitas dengan hanya menyatukan satu set komponen tertentu (dan, ya, saya menyederhanakan ini sampai ekstrem), Anda tidak benar-benar berkembang sebagai programmer, insinyur atau apa pun.

Hanya melihat para insinyur perangkat lunak di sekitar saya di tempat kerja, saya tahu dari pengalaman panjang bahwa sebagian besar dari mereka tidak tahu, dan lebih buruk lagi - tidak tertarik untuk belajar, apa pun tentang produk yang kami buat selain dari minimum yang mereka butuhkan untuk menghasilkan dokumen atau potongan kode yang ditugaskan untuk mereka lakukan.

Saya sedikit terhuyung-huyung topik di sini, tetapi poin saya adalah bahwa ketika programmer tidak perlu mempelajari kode apa yang mereka bangun akan benar-benar digunakan, dan tidak perlu mempelajari cara kerja dalam sistem karena mereka hanya bisa menggunakan kembali komponen yang sudah ditulis dan diuji, maka sebagian besar dari mereka tidak akan repot melakukannya.

Memang, ini juga karena keadaan lain, seperti bahwa produk yang kami bangun sangat kompleks, dan tidak mungkin bagi satu orang untuk mempelajari semua itu (dan saya hanya berbicara tentang salah satu komputer di pesawat - salah satu yang paling kompleks, tapi tetap saja).

Jika insinyur perangkat lunak kami tidak memiliki opsi untuk menggunakan kembali sebanyak mungkin kode, saya yakin mereka akan menjadi lebih baik dalam profesi mereka secara umum, dan aset yang jauh lebih besar untuk proyek secara khusus.

Oh, dan Anda mungkin telah memperhatikan bahwa saya berbicara tentang mereka banyak di sini. Saya tentu saja juga termasuk di antara para insinyur perangkat lunak ini. Pengecualiannya adalah bahwa saya tampaknya jauh lebih ingin tahu dan ingin belajar hal-hal baru daripada yang lain :-) Ketika dihadapkan dengan tugas baru, saya selalu mengambil sendiri untuk belajar sebanyak mungkin tentang hal itu yang saya bisa, baik dalam bentuk fakta dan dengan mempelajari kode sumber (ya, saya benar-benar menikmatinya juga).

Ah - sial, dilacak lagi ... Alasan saya adalah saya belum tidur selama 32 jam, jadi kemampuan fokus saya sedikit ... apa yang saya katakan?

Jika ada yang masih membaca, kesimpulan saya adalah:

Ya , terlalu banyak menggunakan kembali perangkat lunak membuat insinyur perangkat lunak kurang berpengetahuan, yang membuat mereka sangat kurang efisien ketika mereka benar-benar perlu tahu cara kerja barang. Analisis masalah adalah contoh yang baik, atau bahkan hanya bisa mengetahui apakah solusi desain yang disarankan layak. Dan tentu saja, peningkatan proses juga lebih sulit untuk dicapai ketika Anda tidak benar-benar tahu apa yang Anda lakukan :-)

dan Tidak , menggunakan kembali perangkat lunak dengan hati-hati , berpotensi memberi Anda banyak waktu luang untuk mempertimbangkan dan merencanakan perbaikan proses.


Bukankah fakta bahwa sebagian besar pengembang sw dapat bertahan tanpa mengetahui cara kerja dalam sistem indikator yang kuat untuk digunakan kembali secara luas? Saya juga merasa lucu bagaimana cerita proyek pemerintah mengeluarkan suara yang cukup mengerikan tetapi jika Anda memiliki pengetahuan tentang pekerjaan pemerintah maka Anda akan mengerti betapa tidak mengerti penulisnya. Palu $ 1.500 dll ... Semua menjadi dapat dimengerti ketika Anda menyadari bahwa proses pemerintah membutuhkan 10 orang untuk meninjau dan mendapatkan penawaran kompetitif sebelum membeli ATAU itu sama sekali tidak memindahkan dana antar ember akuntansi.
Dunk

Saya tidak merasa nyaman mengetahui bahwa seorang insinyur perangkat lunak yang bekerja pada sistem komputer "yang paling kompleks" dalam pesawat terbang belum tidur dalam 32 jam. =)
RubberDuck

2

Sebagaimana ditunjukkan dalam jawaban yang diterima dalam pertanyaan Pemrogram lain, analogi dengan konstruksi harus dijaga dengan hati-hati:

bacaan yang disarankan untuk ini adalah The Software Construction Analogy is Broken

perangkat lunak sering disamakan dengan konstruksi. Sayangnya analogi ini cacat dan pelajaran dari industri konstruksi diduga ...

Apa yang saya amati adalah, proyek perangkat lunak yang baik "menggeser" banyak pengulangan ke jaminan kualitas.

Ketika saya adalah seorang penguji dalam proyek selama 1,5 tahun, kami menjalankan siklus uji pada rilis "pos pemeriksaan" mingguan, sekitar 70 kali total melalui proyek. Itu ... cukup berulang, berbicara dengan lembut (tidak banyak hal berubah dalam seminggu). Pengujian build malam telah, secara alami, bahkan lebih berulang - sekitar 500 kali melalui proyek (beberapa bug showstopper menghibur terlalu jarang untuk membuat perbedaan).

Sekarang, mengikuti analogi "tersangka" itu, katakan padaku sebuah perusahaan konstruksi yang telah membangun 500 jembatan - semuanya dengan tim yang sama.

  • Mengikuti lebih jauh, katakan padaku sebuah perusahaan yang telah menggunakan sebagian besar batu bata dan besi yang sama di setiap jembatan baru mereka (di sini, saya merujuk pada fakta bahwa rilis yang kami uji sebagian besar memiliki bit kode yang sama hari demi hari, minggu demi minggu minggu - "tidak banyak hal-hal berubah").
    http://upload.wikimedia.org/wikipedia/commons/thumb/0/0c/GoldenGateBridge-001.jpg/220px-GoldenGateBridge-001.jpg http://upload.wikimedia.org/wikipedia/commons/thumb/5/52/Ponte25Abril1.jpg/220px-Ponte25Abril1.jpg

Pembangun ahli adalah ahli yang diakui telah merancang dan / atau membangun puluhan, ratusan, atau ribuan hal di area mereka.

Baik, menindaklanjuti penjelasan Anda tentang pengulangan yang dikutip di atas, saya bisa mengatakan apa? Saat itu, kelompok kecil penguji kami yang tidak terlalu khusus telah memverifikasi, lihat di atas ("sekitar 500") ratusan hal di wilayah kami.

Adapun pengembang proyek, mereka telah benar-benar membangun ("bangunan malam") - lihat, kata itu sama, dan artinya tepat dalam konteks ini - ratusan hal di daerah mereka.

Jika seseorang ingin melanjutkan analogi "curiga" lebih jauh ke "ribuan hal", jumlah ini, sekali lagi, tidak ada yang spektakuler dalam pengembangan perangkat lunak ketika seseorang melihat hal-hal yang benar.

  • Sebagai contoh, satu lagi proyek saya di masa lalu (sekali lagi, tidak ada yang spektakuler, yang agak biasa), kali ini dalam peran dev, telah berlangsung selama lebih dari 5 tahun (8 rilis utama, beberapa lusinan proyek kecil). Ada pos pemeriksaan mingguan yang serupa ( 5x52~=250dari mereka), rilis malam yang serupa ( 5x365~=1800dari mereka) dan juga, tim dev / QA yang sama mengerjakannya. Hari demi hari, minggu ke minggu, bulan ke bulan, sebagian besar barang berulang (tidak banyak berubah antara dua bangunan malam) - seperti yang dijanjikan, dalam kisaran ribuan kali (1800).

Proyek yang berumur lebih lama seperti Windows atau Java, atau AutoCAD dapat menjangkau 10, 20, 30 tahun, yang dengan mudah diperhitungkan sebagai pengulangan sebanyak "ribuan" pembangunan malam dan pengujian malam hari yang didapat.


Konsep pengulangan pengulangan ke QA menjadi lebih menonjol dengan integrasi berkelanjutan ...

praktik ... menggabungkan semua salinan kerja pengembang dengan arus utama bersama beberapa kali sehari ... CI dapat dilihat sebagai intensifikasi praktik integrasi berkala ..

Selain pengujian unit otomatis, organisasi yang menggunakan CI biasanya menggunakan server bangun untuk menerapkan proses kontinu menerapkan kontrol kualitas secara umum - usaha kecil, sering diterapkan. Selain menjalankan tes unit dan integrasi, proses tersebut menjalankan tes statis dan dinamis tambahan, mengukur dan profil kinerja, mengekstrak dan memformat dokumentasi dari kode sumber dan memfasilitasi proses QA manual. Aplikasi kontrol kualitas yang berkelanjutan ini bertujuan untuk meningkatkan kualitas perangkat lunak , dan untuk mengurangi waktu yang dibutuhkan untuk mengirimkannya, dengan mengganti praktik tradisional menerapkan kontrol kualitas setelahmenyelesaikan semua pengembangan. Ini sangat mirip dengan ide orisinil yang lebih sering diintegrasikan untuk membuat integrasi lebih mudah, hanya diterapkan pada proses QA ...

Pengulangan? itu ada di sana, sebanyak yang bisa dipikirkan orang.

Dengan QA yang sering / terus-menerus, hal-hal yang salah dengan cepat kembali ke pengembang yang terpaksa mengulangi upaya melakukannya dengan benar sampai tes gagal berhasil lulus. Dalam arti tertentu, siklus berulang sampai melewati menyerupai kode cata ,

latihan dalam pemrograman yang membantu seorang programmer mengasah keterampilan mereka melalui latihan dan pengulangan ...


1
Poin luar biasa, dan saya pikir pelarian yang kemudian digulirkan kembali ke ruang uji otomatis menangkap beberapa pengalaman yang saya singgung. Mengenai klaim "tim yang sama", saya kembali ke pengalaman Wright. Dengan lebih dari 500 bangunan yang dibangun, ia adalah elemen umum untuk semua itu. Tapi intinya dibuat, dan saya setuju dengan beberapa premis.

@ GlenH7 ya dampak dari pengulangan telah benar-benar mendalam dan jauh melampaui test suite. Pengetahuan terkumpul di mana-mana di mana pengulangan terjadi - Anda tahu, semuanya cenderung menetap secara optimal setelah 20 ... 30 ... 50 kali melakukannya. Pos pemeriksaan / persiapan malam, pengiriman bug (dan seluruh "kehidupan bug" sama sekali), komunikasi dev / QA / mgmt / sysadmin, mendokumentasikan hal-hal dll. Saya hanya fokus pada pengulangan, karena menyelam ke masalah akumulasi pengetahuan yang secara alami diikuti akan memiliki efek firehose pada penyajian poin saya
nyamuk

-1

Beberapa yang Anda katakan benar: mis. Perpustakaan menyelesaikan fungsi yang tidak diselesaikan oleh bahasa tingkat tinggi yang memecahkan masalah yang tidak diselesaikan dengan perakitan yang memecahkan masalah yang tidak diselesaikan oleh kode mesin. Ketika Anda memanggil System.out.println () di java Anda kehilangan pandangan tentang bagaimana output CPU ke perangkat.

Jadi ya, Anda kehilangan sesuatu. Yang Anda peroleh adalah kemampuan untuk fokus pada masalah yang tidak terpecahkan. Sekarang mungkin Anda harus membenamkan diri dalam beberapa aspek teknologi lainnya (misalnya bagaimana jaringan berfungsi) untuk menyelesaikan masalah. Tetapi Anda tidak perlu menjadi ahli dalam membaca bahasa mesin ketika semua yang ingin Anda lakukan adalah membangun halaman web.

Dengan cara yang sama, pembangun jembatan memecahkan masalah yang sedikit berbeda setiap kali (ini sungai yang berbeda). Mereka tidak khawatir tentang cara membuat balok baja dengan kekuatan tarik tertentu, atau cara memasang baut dengan toleransi tertentu. Mereka menyerahkannya kepada spesialis yang telah memecahkan masalah itu.

Perhatikan baik-baik, dan Anda akan melihat seluruh masyarakat dan infrastruktur kami dibangun di atas penggunaan kembali 99% dan hanya kemajuan nyata 1%. Kebanyakan hal-hal baru adalah hal-hal hanya tua dengan sedikit tambahan sesuatu ditambahkan atau dihapus. Itu adalah akumulasi pengetahuan manusia. Anda dapat menulis kode dalam bahasa tingkat tinggi dengan perpustakaan yang layak karena seseorang menemukan semua hal rumit yang diperlukan untuk mencapai titik ini. Ini memungkinkan Anda untuk memecahkan masalah baru dan menarik.

Untuk mengikat ini semua bersama-sama dan menanggapi komentar: Anda tidak harus menyelesaikan masalah yang sudah dipecahkan untuk mengembangkan kecakapan. Selanjutnya, banyak dari apa yang Anda lakukan akan menemukan kembali roda. Jadi singkatnya, jawabannya adalah tidak - Anda tidak perlu mengimplementasikan kembali fungsi perpustakaan untuk menjadi mahir. Ada banyak kesempatan, beberapa di antaranya hafal, sebagian kreatif untuk mengasah keahlian Anda.


1
Saya pikir Anda menyentuh beberapa poin yang berpotensi valid, tetapi saya tidak melihat mereka mengikat bersama untuk menjawab pertanyaan. Dan saya tidak setuju dengan rasio 99: 1 Anda untuk digunakan kembali. Saya pikir itu terlalu melebih-lebihkan berapa banyak penggunaan kembali terjadi. Bahkan dalam pengembang perangkat lunak, tingkat penggunaan kembali tidak terlalu tinggi.

-2

Ini semua tentang sumber daya. Tahun yang lalu, jika Anda mengembangkan proyek perangkat lunak untuk komputer mainframe besar mereka mungkin sekitar selama 15 tahun atau lebih dengan sebagian besar lingkungan pengembangan statis. Program FORTRAN ditulis untuk menghitung penggajian atau program COBOL disempurnakan selama beberapa dekade karena terus digunakan. Ada sumber daya untuk melihat bagaimana ini dapat ditingkatkan. Kami tidak lagi memiliki lingkungan yang lambat seperti itu untuk menyempurnakan dan memoles keterampilan untuk proyek tertentu. Tetapi kami memang mengambil keterampilan dan menyesuaikannya dengan sumber daya proyek berikutnya yang memungkinkan. Tapi pada akhirnya jika menjadi pilihan uang yang dihabiskan untuk proyek baru untuk melakukan pekerjaan, atau untuk melakukan pekerjaan baru dengan sejumlah besar emas-plating. Gold-plating sarana proyek untuk meningkatkan ke tingkat n dan menambahkan ton lonceng dan peluit bahkan jika pengguna didn'

Yang terbaik yang bisa kita lakukan, adalah melihat desain keseluruhan proyek baru dan melihat bagaimana hal itu dapat ditingkatkan berdasarkan pengalaman tim sebelumnya. Tetapi dibutuhkan seorang arsitek perangkat lunak pengalaman nyata untuk memiliki visi tentang apa yang sebenarnya dianggap meningkatkan desain untuk meningkatkan keterampilan vs hanya memasukkan kata kunci terbaru dalam pengembangan seperti Agile, OOP, dll.


3
Saya memahami beberapa poin yang Anda coba buat, tetapi mereka didasarkan pada anggapan dan tidak terbiasa. Saya dulu mengembangkan untuk mainframe, dan saya dapat meyakinkan Anda bahwa laju pengembangan sama cepatnya dengan pada sistem terbuka. Prosesnya berbeda, tetapi langkahnya sama. Jawaban Anda akan lebih kuat dengan berfokus pada komponen keterampilan yang dapat ditransfer, dan menguraikan efisiensi potensial yang diperoleh dengan cara itu.

Anda perlu melihat sejarah, tidak ada teknologi baru yang keluar setiap tahun atau lebih pada sistem mainframe untuk CDC 6600 Kronos OS, misalnya. Itu pada dasarnya statis selama 15 tahun. Sekarang segalanya bergerak jauh lebih cepat dan tidak ada waktu untuk memperoleh pengetahuan yang mendalam selama lebih dari 15 tahun. Tidak ada programmer Flash dengan pengalaman 15 tahun hanya melakukan Flash, misalnya. Setelah membaca kembali posting saya, saya berdiri di samping posting asli saya.
Edward
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.