Bukti empiris untuk pilihan paradigma pemrograman untuk mengatasi masalah


11

Wiki C2 memiliki diskusi tentang Bukti Empiris untuk Pemrograman Berorientasi Objek yang pada dasarnya menyimpulkan bahwa tidak ada yang melebihi daya tarik otoritas. Ini terakhir diedit pada tahun 2008. Diskusi di sini tampaknya memberikan ini: pertanyaan tentang apakah OO sudah ketinggalan zaman , ketika pemrograman fungsional adalah pilihan yang buruk dan keuntungan dan kerugian AOP semuanya dijawab dengan pendapat kontributor tanpa bergantung pada bukti.

Tentu saja, pendapat dari praktisi mapan dan terkenal adalah hal yang diterima dan berharga untuk dimiliki, tetapi mereka lebih masuk akal jika konsisten dengan data eksperimental. Apakah bukti ini ada? Saya tahu bahwa rekayasa perangkat lunak berbasis bukti adalah suatu hal, tetapi dapatkah saya mempraktikkannya dalam konteks ini? Secara khusus, jika saya memiliki masalah tertentu Pyang ingin saya selesaikan dengan menulis perangkat lunak, apakah ada badan pengetahuan, studi dan penelitian yang akan membuat saya melihat bagaimana hasil penyelesaian masalah seperti Ptelah bergantung pada pilihan paradigma pemrograman?

Saya tahu paradigma mana yang muncul sebagai "jawaban yang tepat" dapat bergantung pada metrik apa yang diperhatikan oleh penelitian tertentu, pada kondisi apa yang dipertahankan atau bervariasi, dan tidak diragukan lagi pada faktor-faktor lain juga. Itu tidak memengaruhi keinginan saya untuk menemukan informasi ini dan secara kritis menaksirnya.

Menjadi jelas bahwa beberapa orang berpikir saya sedang mencari solusi "putar engkol" - beberapa mesin sosis di mana saya memasukkan informasi tentang masalah saya dan keluar dari kata "fungsional" atau "terstruktur". Ini bukan maksud saya. Apa yang saya cari adalah penelitian tentang bagaimana - dengan banyak peringatan dan asumsi bahwa saya tidak akan membahasnya di sini tetapi literatur yang baik mengenai hal itu akan - sifat-sifat tertentu dari perangkat lunak bervariasi tergantung pada masalah dan pilihan paradigma.

Dengan kata lain: beberapa orang mengatakan "OO memberikan fleksibilitas yang lebih baik" atau "program fungsional memiliki lebih sedikit bug" - (bagian dari) apa yang saya minta adalah buktinya. Sisanya meminta bukti yang menentang ini, atau asumsi di mana pernyataan ini benar, atau bukti yang menunjukkan bahwa pertimbangan ini tidak penting. Ada banyak pendapat tentang mengapa satu paradigma lebih baik dari yang lain; Adakah yang objektif di balik semua ini?


1
Pencarian web untuk rekayasa perangkat lunak berbasis bukti menunjukkan banyak tautan
agas

@gnat EBSE adalah tentang merangkum literatur secara sistematis dan menarik kesimpulan umum tentang bagaimana kita dapat meningkatkan praktik. Pertanyaan saya adalah apakah literatur itu ada; apakah ada cukup untuk ulasan sistematis atau metaanalyses menjadi produktif.

Jawaban:


12

Untuk pengambilan sebelumnya, lihat Revisi 1 dari jawaban ini . Namun, komentar dan pengeditan untuk pertanyaan lebih lanjut memperjelas apa yang dicari dan memungkinkan saya untuk menjadi lebih jelas.

Ya, rekayasa perangkat lunak berbasis bukti (EBSE) adalah suatu hal. Tampaknya ada beberapa upaya menuju basis data EBSE, seperti yang ini di Durham University dan SEED, yang dimulai oleh seorang profesor di Cal Poly . Semua upaya ini, serta yang dibahas dalam sejumlah makalah yang dapat ditemukan melalui server IEEE Xplore atau ACM Digital Library(berlangganan atau membeli diperlukan untuk banyak makalah di keduanya), didasarkan pada obat berbasis bukti. Mereka memberikan tinjauan literatur dari data empiris (observasi dan eksperimen) yang dipublikasikan. Bahkan, termasuk "tinjauan pustaka" dalam string pencarian pada setiap pencarian publikasi menghasilkan informasi pada sebagian besar topik - lebih dari 14.000 klik pada ACM dan lebih dari 1000 pada database IEEE (ketika terbatas hanya pada topik komputasi).

Melihat jenis umum dari topik yang dibahas dalam database EBSE dan tinjauan literatur ini, saya melihat utas yang sama - mereka cenderung tidak bergantung pada teknologi. Penekanan tampaknya sebagian besar berpusat pada proses dan metodologi daripada alat khusus yang digunakan untuk melakukan rekayasa perangkat lunak.

Jadi, konsep ini ada dalam rekayasa perangkat lunak. Academia mengetahui konsep berbasis bukti dan berhasil menerapkannya pada rekayasa perangkat lunak.

Secara khusus, pertanyaan yang membahas penerapan teknik EBSE untuk pemilihan paradigma tampaknya sulit, karena banyaknya variabel yang terlibat, memaksa asumsi dibuat serta mengurangi kemampuan untuk mengulangi percobaan atau pengamatan. Dikatakan benar dalam pertanyaan - "paradigma mana yang muncul sebagai" jawaban yang tepat "dapat bergantung pada metrik apa yang diperhatikan oleh studi tertentu, pada kondisi apa studi ini konstan atau bervariasi, dan tidak diragukan lagi pada faktor-faktor lain juga" . Meskipun itu tidak berarti bahwa mempelajari paradigma mana yang "terbaik" dalam situasi tertentu, itu membuat segala jenis tinjauan pustaka terhadap dokumen-dokumen ini sangat sulit untuk diselesaikan dan masih mengekstrak informasi di dalamnya.

Jelas tidak ada solusi "putar engkol" untuk memilih paradigma.

Diberikan paradigma pemrograman, Anda dapat menemukan studi di berbagai database akademik dan industri tentang bagaimana paradigma itu memengaruhi berbagai aspek pengembangan perangkat lunak - kualitas, cacat, efisiensi, dan sebagainya - dalam berbagai kondisi spesifik, mulai dari pengetahuan dan pengalaman tim ke domain masalah. Setiap makalah yang ketat harus secara jelas mengidentifikasi kondisi di mana data dikumpulkan dan asumsi. Masalahnya menjadi mencoba untuk mengisolasi faktor-faktor yang membuatnya baik di setiap kondisi tersebut.

Secara akademis, ada beberapa pernyataan yang mudah diteliti. Misalnya, pernyataan bahwa paradigma fungsional sangat cocok untuk aplikasi yang memerlukan konkurensi berasal dari teorema Gereja-Rosser . Karena itu, kemungkinan sistem perangkat lunak yang ditulis dalam bahasa fungsional akan memiliki lebih sedikit cacat terkait dengan concurrency daripada sistem yang sama yang ditulis dalam bahasa prosedural atau berorientasi objek.

Namun, dari sudut pandang praktis, tim perangkat lunak tidak selalu dapat menggunakan alat atau teknik "terbaik" untuk pekerjaan itu hanya karena penelitian menunjukkannya. Meskipun kami berusaha keras untuk menghasilkan sistem perangkat lunak dengan kualitas terbaik, kami beroperasi dalam batasan. Seringkali, saya melihat batasan ini diminimalkan (atau bahkan dihilangkan dari persamaan) ketika membahas efektivitas metodologi apa pun.

Sebagai seorang praktisi, ketika saya terlibat dalam memilih teknologi untuk digunakan, saya mencoba mengidentifikasi alat terbaik. Tetapi kemudian saya membatasi diri pada apa yang diketahui dan dipahami dengan baik oleh tim yang saya miliki. Kembali ke contoh saya sebelumnya, jika saya memiliki tim yang berpengalaman dalam membangun aplikasi bersamaan di C ++ dan tidak ada pengalaman di Haskell, tidak masuk akal untuk mengusulkan membangun sistem di Haskell karena saya kemungkinan tidak akan mampu membuat kendala jadwal dan anggaran, dan kualitas saya kemungkinan akan menurun karena kurangnya pengalaman dalam rantai alat.

Untuk rekap, rekayasa perangkat lunak berbasis bukti umumnya adalah hal yang baik yang ada dan tinjauan literatur memang ada dan tersedia. Namun, ada aspek rekayasa perangkat lunak di mana menerapkan pendekatan berbasis bukti menawarkan nilai yang kecil. Pemilihan paradigma pemrograman untuk upaya pengembangan skala besar adalah salah satunya.

Jika Anda ingin mengetahui tentang bagaimana orientasi objek mengatasi usabilitas atau cacat dalam pemrograman fungsional - Anda akan dengan mudah menemukan publikasi tentang itu. Namun, saya tidak menemukan (saya juga tidak akan menaruh kepercayaan pada) publikasi yang mampu secara efektif menangani pemilihan paradigma di berbagai proyek rekayasa perangkat lunak dunia nyata.


Bagian tentang kelengkapan Turing mengabaikan pertukaran, yang ingin saya lihat terbuka dan dibandingkan. Biarkan saya memberi contoh spesifik. Banyak orang mengatakan kepada saya bahwa pemrograman fungsional sangat bagus untuk menghindari bug konkurensi. Sekarang kami menemukan bahwa Skema, seperti Pascal, Turing-complete. Jadi mungkin untuk menulis kode konkurensi-aman secara prosedural. Sepakat. Tapi apakah ini hebat ? Apakah ada keuntungan memilih satu metode? Bisakah keuntungan seperti itu diukur?

1
@ GrahamLee Mengonfirmasi atau menolak hipotesis Anda memerlukan bukti objektif, yang tidak ada. Ada alasan subjektif untuk membuat paradigma baru dan model baru yang mewakili kemampuan komputasi yang sama persis - dan ini tidak terbatas pada bahasa pemrograman, tetapi juga untuk representasi matematika yang mendasari bahasa tersebut . Alasan obyektif itu termasuk menargetkan demografis tertentu (matematikawan komputasi versus analis bisnis - cara berpikir mereka berbeda membutuhkan paradigma yang berbeda).
Thomas Owens

2
@ Thomas: implikasi Anda bahwa praktik pemrograman aneh secara unik untuk ilmu pengetahuan adalah aneh. Ada banyak penelitian yang sedang berlangsung. Contoh yang sering dikutip adalah kelompok penelitian Lutz Prechelt . Saya tidak tahu area yang cukup baik untuk mengetahui apakah ada orang yang menjawab pertanyaan spesifik Graham, tetapi tidak ada alasan untuk percaya bahwa mereka tidak mudah dipengaruhi oleh metode yang digunakan oleh Prechelt dan lainnya.
Cris

1
@ Chris Saya tidak percaya mereka buram terhadap sains. Namun, saya percaya bahwa ada beberapa hal yang pada saat Anda, seperti kata Graham dalam pertanyaan, menambahkan "banyak peringatan dan asumsi" untuk penelitian, itu tidak lagi berguna bagi para praktisi. Pada titik itu, dari perspektif praktis, di dalam parit, itu hanya lebih efektif untuk mendasarkan keputusan Anda pada sejarah dan pengalaman. Memiliki data yang baik, sulit, valid adalah hal yang sangat baik. Tetapi ada saatnya ketika terlalu sulit untuk mendapatkan atau itu hanya valid dalam situasi yang sangat spesifik yang tidak berguna bagi industri.
Thomas Owens

1
@ Thomas Saya ragu itu. Praktik umum medis sekurang-kurangnya situasional dan peka terhadap konteks seperti halnya rekayasa perangkat lunak, dan, er, semakin banyak bukti yang menunjukkan bahwa GP berbasis bukti menghasilkan peningkatan yang terukur. Sebagian besar masalah kuantitas dan kualitas penelitian.
Cris

7

Saya telah membaca The Art of Unix Programming oleh Eric S. Raymond. Ini memiliki beberapa wawasan sejarah yang sangat menarik tentang hal-hal yang sekarang kita anggap remeh. Dia mengutip beberapa penelitian yang baik dari perangkat lunak IEEE yang menggunakan bukti empiris seperti kepadatan cacat. Itu mungkin sumber yang bagus jika Anda mencari studi bergaya akademik.

Bahkan teknik seperti modularisasi menggunakan fungsi tidak selalu merupakan praktik umum. Salah satu kutipan favorit saya dari buku sejauh ini:

Dennis Ritchie mendorong modularitas dengan mengatakan kepada semua orang bahwa panggilan fungsi benar-benar murah di C. Semua orang mulai menulis fungsi kecil dan modularisasi. Bertahun-tahun kemudian kami menemukan bahwa panggilan fungsi masih mahal pada PDP-11, dan kode VAX sering menghabiskan 50% dari waktunya dalam instruksi CALLS. Dennis telah berbohong kepada kita! Tapi sudah terlambat; kami semua doyan ...

- Steve Johnson

Sebenarnya ada dua masalah dengan menjadi terlalu empiris. Yang pertama adalah bahwa kualitas kode adalah hal yang sangat subyektif. Kode bisa mengerikan dan masih benar. Rakyat persepsi dari paradigma pemrograman adalah metrik yang sangat valid, karena kode ini ditulis untuk orang-orang untuk membaca sebanyak untuk komputer, jika tidak lebih.

Masalah kedua adalah bahwa 50% pengembang memiliki bakat pemrograman di bawah rata-rata. Tidak masalah jika pengembang teratas Anda lebih produktif menggunakan pemrograman fungsional jika "rakyat jelata" berjuang untuk menulis perangkat lunak yang berfungsi menggunakannya, apalagi perangkat lunak yang indah dan dirancang dengan baik. Demikian juga dengan bahasa pemrograman TMTOWTDI , pengembang teratas Anda masih akan menulis kode modular yang bersih, tetapi coders yang kurang berbakat menulis derau baris karena kurangnya struktur yang dipaksakan.

Itu sebabnya saya pikir OOP telah naik ke puncak popularitas meskipun kekurangannya. Ini tidak begitu membatasi bahwa ia pincang yang paling berbakat, tetapi strukturnya menyediakan cara ringkas untuk berkomunikasi dan memaksakan prinsip-prinsip desain yang baik pada yang paling berbakat.

Dalam pekerjaan kami, kami memiliki kecenderungan untuk mengevaluasi solusi berdasarkan terlalu banyak pada kemampuan teknisnya saja. Usaha yang sukses harus memperhitungkan sisi manusia dari persamaan juga.


"kualitas kode adalah hal yang sangat subyektif" setuju - Anda harus berhati-hati dengan apa yang Anda ukur, dan persepsi adalah faktor penting. Tapi persepsi, seperti banyak hal lain, adalah mudah dibentuk juga: lihat meningkat dan jatuh dan bangkit dari pemrograman fungsional untuk melihat bahwa apa yang orang pikirkan tentang bagaimana mereka bekerja tidak secara langsung berhubungan dengan bagaimana mereka bekerja. Saya juga baru saja membaca kembali TAOUP. Bagian dari motivasi saya untuk pertanyaan ini adalah melihat solusi literatur awal untuk masalah yang saat ini dalam rekayasa perangkat lunak.

+1, "Masalah kedua adalah 50% pengembang memiliki bakat pemrograman di bawah rata-rata." Kalimat ini melegakan saya. Ini lebih baik daripada banyak pil yang saya coba :)
NoChance

3

Ada kontes pemrograman yang menggunakan sistem penilaian komputer dan memungkinkan Anda untuk menulis dalam berbagai bahasa dan memposting semua jenis hasil dan hal-hal. Saya yakin mereka memiliki data yang bagus untuk Anda. Berikut daftar 8: http://www.makeuseof.com/tag/8-onlineprogramming-contests-challenge-win/

Saya membayangkan Anda dapat membuat perbandingan solusi yang berarti untuk masalah yang sangat sederhana dan jelas, seperti jumlah kuadrat, atau seri Fibonacci, atau menggambar garis lurus menggunakan algoritma garis Bresenham. Sebagian besar tugas pemrograman dunia nyata tidak memiliki pos tujuan yang jelas dan setiap bahasa memiliki titik-titik manisnya. Banyak manfaat dari suatu bahasa adalah subjektif. Anda mungkin menemukan data yang lebih bermakna dengan mensurvei programmer dan kebahagiaan klien daripada menghitung garis kode atau jumlah cacat.

Saya ingat ketika saya menghabiskan setengah hari menulis salah satu program Awk pertama saya, saya pikir itu akan memakan waktu seminggu penuh untuk melakukan hal yang "sama" di Jawa. Tapi itu karena solusi Java saya akan berfokus pada menjadi kuat di mana karena solusi Awk cepat dan kotor dan memerlukan beberapa penyesuaian manual pada input dan output dan benar-benar dibuang ketika saya selesai. Awk dan Java sama-sama hebat, hanya saja tidak untuk hal yang sama.

Saya kira apa yang saya katakan adalah bahwa untuk aplikasi dunia nyata, membandingkan bahasa atau alat dengan cara yang berarti sangat sulit - masalah apel dan jeruk yang lama. Semoga berhasil! Saya ingin melihat apa yang Anda ketahui.


2

Saya telah mempelajari berbagai cara untuk mengembangkan perangkat lunak selama 30+ tahun. Ada kelangkaan bukti yang dipublikasikan tentang pemilihan paradigma.

Saya mengumpulkan bibliografi ASCII yang bisa dicari. Ini termasuk banyak makalah dan artikel IEEE dan ACM. Saya memberi tag pada item dengan jenis bukti yang disediakan. Berikut adalah tag yang paling umum:

...
133 =EXPERIMENT
177 =HISTORY
233 =IDEA
267 =SURVEY
338 =ESSAY
395 =THEORY
454 =ADVERT
491 =EXPERIENCE
500 =DEMO

Sekarang cari PARADIGM dan hitung tagnya

  1 =ESSAY
  1 =EXPERIENCE
  1 =HISTORY
  1 =IDEA
  1 =POLEMIC
  1 =SURVEY
  1 =TALK

Jika Anda ingin menggali lebih dalam, http://cse.csusb.edu/dick/lab.html dan saya harap ini membantu ...


1

Tampaknya dalam banyak kasus tidak ada kumpulan penelitian yang cukup besar atau berkualitas cukup tinggi untuk memungkinkan kesimpulan umum diambil tentang apakah satu praktik dalam rekayasa perangkat lunak lebih baik daripada yang lain. Saya secara khusus mencari penelitian untuk bekerja dalam paradigma yang berbeda, tetapi kurangnya ketersediaan tidak terbatas pada arena itu sehingga saya akan membingkai jawaban saya dalam arti yang lebih luas.

Sebuah makalah dari tahun 2004, Rekayasa Perangkat Lunak Berbasis Bukti oleh Kitchenham et al , mencakup dengan cukup ringkas manfaat yang bisa diperoleh dari pendekatan berbasis bukti dan masalah dengan penerapannya dalam rekayasa perangkat lunak. Saya tidak akan membahas sisi manfaat di sini (jelas dari pertanyaan bahwa saya ingin dapat bekerja dengan cara ini), tetapi masalahnya relevan sebagai jawaban atas pertanyaan yang saya ajukan.

  • pertama, jika Anda bukan anggota ACM maka Anda mungkin tidak dapat membaca tautan di atas sama sekali, yang mencakup masalah pertama: tidak semua penelitian yang masih ada benar-benar tersedia untuk praktisi.
  • banyak praktik rekayasa perangkat lunak berlangsung secara rahasia sebagai bagian dari proses rahasia-komersial sehingga tidak ada visibilitas terhadap apa yang berhasil atau tidak bekerja untuk orang-orang itu.
  • rekayasa perangkat lunak adalah praktik yang terampil, sehingga sulit (bukan tidak mungkin, hanya sulit) untuk mengatur studi yang sesuai-buta.
  • berbagai bagian siklus hidup perangkat lunak memengaruhi hasil masing-masing hingga tingkat yang sulit dikendalikan dalam eksperimen apa pun.
  • seperti yang diperlihatkan oleh diskusi di sini, banyak praktisi tidak melihat "literatur" (atau sisi akademik dari rekayasa perangkat lunak pada umumnya) yang relevan dengan pekerjaan mereka.

Jadi jawaban yang saya cari adalah "tidak", bukti yang saya cari mungkin tidak ada. Saya harus memilih paradigma saya berdasarkan kriteria populer yang ada tentang apa yang saya tahu, pendapat yang keren dan ahli.


2
dari abstrak makalah yang dikutip, penekanan pada tambang: "Faktor keterampilan berarti percobaan rekayasa perangkat lunak rentan terhadap bias subjek dan eksperimen . Faktor siklus hidup berarti sulit untuk menentukan bagaimana teknologi akan berperilaku setelah dikerahkan . Kesimpulan: Rekayasa perangkat lunak akan mendapat manfaat dari mengadopsi apa yang bisa dilakukan dari pendekatan bukti asalkan itu berurusan dengan masalah spesifik yang muncul dari sifat rekayasa perangkat lunak . " Yang akan saya tambahkan: semoga sukses dengan itu! ;)
Steven A. Lowe

Steven: bagian dari motivasi di balik EBSE adalah pergi dari "Saya bisa menebak masalah-masalah berikut, karena itu saya akan menolak segala peluang solusi Anda bekerja" untuk menganalisis hasil berdasarkan kemampuan mereka sendiri. Ada jauh lebih banyak daripada kertas abstrak.

2
Saya menghargai antusiasme Anda. Ilmu kedokteran dan pengembangan perangkat lunak adalah disiplin ilmu yang sangat berbeda. Meskipun analoginya menarik, ini hampir tidak inovatif. Makalah lengkap tersedia di sini labada.inf.utfsm.cl/~gvaldes/ESE/docs/… Bagian 5 mencerminkan ketidakcocokan impedansi yang disebutkan dalam abstrak. Pemetaan teknik medis yang lebih langsung adalah dengan men-debug sistem yang ada, bukan membangun yang baru. ;) Jika Anda ingin membangun produk yang lebih baik, bangun tim yang lebih baik. Orang-orang jauh lebih penting daripada alat (lih Peopleware)
Steven A. Lowe

1
tambahan: situs EBSE memiliki beberapa informasi yang berguna, dur.ac.uk/ebse/evidence.php akan sangat berguna bagi mereka yang baru ke bidang SE - tetapi mengambil survei dengan balok garam, karena (1) bukti yang tersedia hanya sedikit dan (2) hasil rata-rata mungkin tidak relevan dengan kinerja tim Anda dari individu-individu tertentu dengan keterampilan dan bakat yang sangat terspesialisasi.
Steven A. Lowe

0

Saya tidak percaya jenis studi ini ada. Orang akan percaya bahwa bukan paradigma pemrograman yang lebih penting daripada algoritma aktual yang digunakan. Misalnya diberikan setiap sistem non-sepele yang bergantung pada algoritma ruang kecil ayat satu yang bergantung pada algoritma waktu kecil akan menghasilkan metrik yang berbeda. Yang memiliki waktu lebih baik kemungkinan besar akan dianggap lebih valid, kecuali ruang adalah masalah maka kebalikannya benar. Saya menemukan itu mirip dengan membuka jalan. Sementara algoritme atau resep untuk membuat bahan-bahan itu konstan di semua proses, ada kemungkinan satu perusahaan berpikir untuk membuka dua lajur sekaligus (satu di setiap sisi jalan) lebih baik daripada membuka dua lajur di sisi jalan yang sama sekaligus . Pada akhirnya, tidak masalah karena proses pembuatan atasan hitam masih sama, satu-satunya perbedaan adalah pendekatannya. Kembali ke pemrograman, jika Anda memiliki tim pengembang C, tulis kode secara prosedural, jika Anda memiliki tim pengembang Java, tulislah dalam OO. Jangan terpaku pada paradigma sebanyak implementasi algoritma. Karena pada akhirnya Anda dapat menulis Java seperti C dan Anda dapat mencoba menulis C seperti Java.

MEMPERBARUI

Untuk membalas komentar graham, tinggalkan aku:
Saya berasumsi dengan arsitektur yang Anda maksud paradigma pemrograman. Jika Anda akan menggunakan Clojure mungkin Anda harus menyewa tim programmer Clojure. Namun, berdasarkan pencarian cepat Clojure adalah bahasa berbasis Java itu kebetulan fungsional. Mengingat informasi itu saya akan mengambil programmer Java (karena secara teknis mereka hanya bisa menulis Java dan itu akan memberi Anda hasil yang sama) atau mencari programmer fungsional seperti pengembang Haskell. Sekarang dalam hal memilih apa yang terbaik itu sepenuhnya tergantung pada tim Anda. Saya tidak akan pernah memiliki tim ahli basis data relasional yang mengatur solusi cloud untuk saya dan saya juga tidak akan memiliki tim programmer fungsional membangun solusi berorientasi objek untuk saya. Anda harus menggunakan kekuatan tim Anda tidak memiliki visi yang dimuliakan yang Anda miliki di kepala Anda untuk apa yang tim "harus"


Bagaimana saya memilih apakah akan menyewa tim programmer Java, atau tim programmer C? Haruskah saya melatihnya lagi di Clojure? Setelah saya memilih algoritma saya, arsitektur apa yang merupakan cara "terbaik" untuk merangkumnya dalam solusi perangkat lunak, untuk nilai-nilai "terbaik" yang diberikan?

@ GrahamLee, lihat pembaruan saya
Woot4Moo

Saya merasa kita sedang membahas masalah yang sama tetapi pada tingkat abstraksi yang berbeda. "Menggunakan kekuatan tim yang Anda miliki" berarti tidak akan pernah membangun komputer, karena Bletchley Park tidak memiliki orang dengan kekuatan dalam membangun komputer. Terkadang Anda harus mengatakan "kita bisa menciptakan solusi yang lebih baik jika kita menggunakan hal ini "; Yang saya kejar adalah informasi tentang kasus-kasus itu.

0

Paradigma yang berbeda mengarah pada solusi yang berbeda. Yang paling cocok adalah yang paling tergantung pada:

  • solusinya
  • tim pengembangan
  • lingkungan operasional

Saya tahu tidak ada studi yang pasti, dan bahkan jika ada, saya tidak akan mempercayainya.

Itu adalah pekerjaan arsitek.

Mengganti kebijaksanaan arsitek dengan kesimpulan yang mungkin tidak relevan dari sebuah penelitian adalah resep untuk bencana.

Catatan: komentar menyebutkan "algoritma" dan kemudian memilih bahasa. Algoritma adalah mekanisme struktural sentral untuk bahasa prosedural. Bahasa berorientasi objek fokus pada kelas dan pola kolaborasi / komunikasi. Jika Anda yakin (sebagai arsitek) bahwa solusi algoritma-sentris adalah 'terbaik', maka gunakan bahasa prosedural atau fungsional.

Tambahan: tidak memercayai studi bukanlah 'takhayul', itu masuk akal. Eksperimen ilmiah harus objektif dan berulang. Proyek perangkat lunak sangat subyektif, tetapi lebih buruk lagi, itu adalah eksperimen yang tidak dapat diulang . Anda tidak bisa mengimplementasikan proyek X dengan tim Y, mengukur hasilnya, dan kemudian memutar kembali waktu, menghapus ingatan, dan melakukan kembali proyek yang sama dengan tim yang sama. Informasi yang ditemukan atau tersirat oleh studi mungkin berguna bagi arsitek, tetapi tidak pernah dapat menjadi definitif.


1
Jadi, apakah di luar bidang arsitek untuk mencari pekerjaan sebelumnya untuk membangun pendapatnya? Mungkin tidak - karenanya pertanyaan apakah dan di mana hasil tersebut dapat ditemukan.

2
Jika ada penelitian definitif dengan metode eksperimental yang masuk akal, hasil penelitian mungkin menarik; seperti berdiri jawaban ini tampaknya menyatakan bahwa studi apa pun tidak berharga terlepas dari metode yang sedikit terlalu non-ilmiah untuk seleraku
jk.

3
@ Seven: kata untuk tidak mempercayai hasil studi yang benar-benar definitif adalah 'takhayul'. Mungkin yang Anda maksud adalah Anda tidak percaya akan pernah ada studi definitif dalam SE (yang pernyataannya sendiri jelas membutuhkan sejumlah besar bukti yang didukung dengan baik).
Cris

1
Kualitas metode perangkat lunak adalah seberapa cocok dengan kebutuhan manusia setempat. Secara umum, itu tidak dibatasi oleh hukum fisika (Scotty). Butuh waktu lama sebelum 'disiplin' perangkat lunak berhasil menyaring hukum-hukum fundamentalnya yang tidak berubah. Misalnya, lihat "Metrik Kualitas Perangkat Lunak: Tiga Metrik Berbahaya dan Dua Metrik Bermanfaat" di ppi-int.com/newsletter/SyEN-046.php#feature dan ppi-int.com/newsletter/SyEN-047.php#feature
Philip Oakley

1
@ Chris: Sebagai catatan, tidak, saya tidak percaya bahwa akan pernah ada studi yang benar-benar definitif di bidang ini; lihat lampiran. Gagasan bahwa studi 'pasti' dapat digunakan alih-alih penilaian ahli untuk membuat keputusan arsitektur kritis adalah 'banding ke otoritas', yang merupakan bentuk kekeliruan logis :) Dalam pengalaman saya - dan saya tidak membuat selimut tuduhan, hanya pengamatan - pencarian untuk hal-hal seperti itu paling sering merupakan upaya untuk menghindari tanggung jawab atas keputusan, atau upaya untuk mendukung keputusan yang telah dibuat.
Steven A. Lowe
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.