Jika seseorang menawarkan kepada Anda pernyataan tidak terverifikasi mengenai praktik pengembangan perangkat lunak, apakah Anda merespons dengan "rujukan?" [Tutup]


14

Baru-baru ini saya menghadiri kuliah yang diberikan oleh Greg Wilson (Kepala Ilmuwan Perangkat Lunak Pertukangan). Dari abstrak:

Gagasan bahwa klaim tentang praktik pengembangan perangkat lunak harus didasarkan pada bukti masih asing bagi pengembang perangkat lunak, tetapi ini akhirnya mulai berubah: setiap akademisi yang mengklaim bahwa alat atau praktik tertentu membuat pengembangan perangkat lunak lebih cepat, lebih murah, atau lebih dapat diandalkan sekarang diharapkan untuk mendukung klaim itu dengan semacam studi empiris.

Secara keseluruhan, kuliahnya sangat informatif dan membuat saya berpikir cukup mendalam tentang pendekatan saya terhadap pengembangan. Secara khusus, saya sekarang menemukan diri saya mencari kutipan untuk mendukung banyak pernyataan. Sebelumnya, saya telah tergelincir ke dalam kebiasaan hanya mengulangi kebenaran yang ditawarkan, mungkin dengan catatan mental untuk memeriksanya nanti.

Terus terang, saya mudah tertipu .

Berikut ini contoh yang diambil dari kuliah:

"Jika lebih dari 25% kode perlu refactoring, lebih cepat untuk menulis ulang".

Kedengarannya masuk akal, tetapi apakah itu benar? Di mana studi mendukung ini? Benarkah untuk semua bahasa? Dan seterusnya.

OK, sangat mungkin untuk mengambil ini ke ekstrem dan tidak percaya apa pun oleh siapa pun kecuali Anda telah mengambilnya sendiri dari prinsip pertama. Dengan begitu terletak kegilaan (atau mungkin matematika ;-)). Tetapi, jika seseorang mendatangi Anda dengan pernyataan di sepanjang baris "Hei, dengan melakukan ini di [pilih bahasa saat ini] kami akan dapat meningkatkan produktivitas dengan [pilih kelipatan 10]%" apakah Anda cenderung hanya menerimanya, atau Anda akan meminta bukti yang terbukti?

Jika yang terakhir (dan saya harap begitu) maka

  1. kemana Anda akan pergi untuk menemukan bukti ini?
  2. seberapa ketat Anda akan?

Singkatnya, jika seseorang menawarkan kepada Anda pernyataan yang tidak diverifikasi, akankah Anda merespons dengan "rujukan?"


2
Dalam berapa banyak bidang, di luar sains, apakah orang menuntut bukti empiris? Dalam pengamatan saya, tidak sebanyak yang saya inginkan.
David Thornley

1
Bagaimana dengan beberapa komentar pada voting dekat? "Terlalu terlokalisasi" dan "Bukan pertanyaan nyata" tidak terlalu jelas dalam konteks ini.
Inaimathi

1
Ya, saya juga ingin tahu alasan di balik suara yang dekat.
Robert Harvey

@ Robert Terima kasih atas hasil editnya. Apalagi sedikit meradang pada refleksi.
Gary Rowe

1
Pertanyaan bagus Saya melihat Prof. Wilson berbicara di CUSEC tahun lalu dan juga sangat dipengaruhi oleh apa yang dia katakan. Bagian terbaiknya adalah ketika seorang siswa menantangnya untuk mengutip klaimnya bahwa klaim harus dikutip, dan ia melakukannya tanpa kehilangan sedikitpun.
Matius Baca

Jawaban:


3

Masalah dengan pernyataan semacam ini adalah bahwa bahkan jika Anda memiliki bukti empiris yang mendukung klaim, akan sangat sulit untuk menentukan apakah penelitian yang mengarah pada bukti yang diterapkan pada situasi Anda saat ini.

Hampir segala sesuatu dalam profesi memiliki peringatan, atau beberapa sehingga setiap perbaikan di satu tempat memiliki kemungkinan menjadi merugikan di tempat lain.

Orang-orang di parit mengetahui perbedaan melalui pengalaman dan umumnya tidak memiliki dana / waktu / sumber daya untuk mencoba membuktikannya melalui studi ilmiah.

Orang-orang yang mencoba membuktikannya melalui studi ilmiah jelas memiliki sumber daya untuk mendedikasikan untuk studi seperti itu dan karena itu sangat mungkin untuk menjual sesuatu kepada Anda, jadi saya akan mengatakan bahwa Anda harus lebih ketat menerapkan pengalaman pribadi Anda pada apa pun yang mengklaim didukung oleh penelitian empiris.

Jika seseorang mengatakan kepada Anda "Jika lebih dari 2% dari kode membutuhkan refactoring, lebih cepat untuk menulis ulang" Anda akan tahu bahwa itu salah sama seperti jika seseorang mengatakan kepada Anda "Hanya jika lebih dari 98% dari kode membutuhkan refactoring, itu adalah lebih cepat menulis ulang itu ". Di mana angka aktual tergantung pada apa yang Anda lakukan dan seberapa jauh dari ideal kode saat ini.

Gagasan bahwa setelah titik tertentu lebih mudah untuk melakukan reaktor nuklir jelas benar dalam banyak kasus, tetapi persentase sebenarnya lebih merupakan contoh yang perlu Anda pertimbangkan melalui lensa pengalaman (tim) Anda sendiri dan situasi saat ini.


+1 untuk analisis menyeluruh dari contoh pernyataan. Apakah Anda benar-benar berpikir bahwa semua penelitian ilmiah memiliki sudut pandang komersial yang harus dieksploitasi? (Maafkan kenaifan saya tapi saya benar-benar ingin tahu tentang hal ini)
Gary Rowe

@Gary: Semua hal menjadi sempurna tidak, tetapi sangat sulit jika bukan tidak mungkin untuk menentukan bias penelitian dari luar. Keraguan jadi ketika tidak ada metrik yang disepakati yang mencakup seluruh situasi
Bill

8
Jika seseorang menawarkan kepada Anda pernyataan tidak terverifikasi mengenai praktik pengembangan perangkat lunak, apakah Anda merespons dengan "rujukan?"

Tidak, saya mempostingnya di sini dan melihat apakah ada perbaikan. Bukti sosial lebih baik daripada tidak ada bukti!


2
Anda mungkin mendapatkan suatu tempat dengan model ini, tapi saya ngeri membayangkan kertas mengutip programer. SE sebagai sumber.
Inaimathi

@Inaimathi: setidaknya ini dapat diandalkan seperti wikipedia, jika tidak lebih dari itu!
Steven A. Lowe

+1 untuk mencari bukti - saran selalu bagus. Berapa banyak upvotes sebelum Anda percaya? ;-)
Gary Rowe

1
@Gary: pada SO, sepuluh. di situs ini, dua puluh. pada meta, seratus - kecuali itu melibatkan unicorn dan wafel, dalam hal ini pasti benar
Steven A. Lowe

Cinta referensi unicorn - harus mendapatkan saya salah satu dari mereka
Gary Rowe

4

Banyak pengembang mendasarkan keputusan mereka dari waktu ke waktu berdasarkan pengalaman di parit yang bekerja dengan kode dan pelanggan yang dilayani oleh kode itu.

Ketika sebuah kelas atau metode telah menjadi sangat terfragmentasi oleh perbaikan bug dan permintaan perubahan pelanggan yang telah menjadi tidak dapat dipelihara, pengembang terkadang akan membuat keputusan untuk menulis ulang daripada refactor, berdasarkan teori bahwa ia akan menghemat waktu dan upaya dalam jangka panjang , karena kode yang dihasilkan akan berkualitas lebih tinggi.

Kecerdasan pengalaman semacam ini adalah apa yang disebut departemen SDM "modal manusia." Ini adalah salah satu hal yang membuat pengembang berpengalaman berharga, dan salah satu alasan perusahaan yang baik melakukan sesuatu untuk mencoba dan menjaga umur panjang karyawan mereka.

Rasanya tidak adil atau bahkan praktis untuk meminta pengembang berpengalaman untuk membuat studi dan data empiris sebagai bukti bahwa teknik mereka valid. Pengalaman tidak bekerja seperti itu. Sebaliknya, pengalaman adalah sesuatu yang "terasa masuk akal". Di dunia refactoring, kita sering menyebutnya "bau."

Pada akhirnya, pernyataan seperti "Jika lebih dari 25% dari kode perlu refactoring, lebih cepat untuk menulis ulang" tidak dapat terbukti bekerja dalam semua keadaan, sehingga pernyataan [rujukan?] Benar-benar cara untuk memberi tahu programmer dogmatik yang berusaha untuk memaksakan pandangannya pada orang lain bahwa itu tidak selalu "Jalan-Nya atau Jalan Raya."


Ahh, sumber daya manusia dan sumber daya manusia yang baik, ungkapan kembar yang luar biasa yang mempromosikan dehumanisasi pekerja yang berkelanjutan di mana-mana ...
Aaronaught

@Aaronaught: Eksekusi suatu konsep kadang-kadang tidak memenuhi kosakata yang digunakan untuk menggambarkannya. Itulah sebabnya orang yang skeptis terkadang meminta bukti.
Robert Harvey

Bukankah hal yang baik untuk mengeksekusi konsep-konsep tertentu gagal?
Aaronaught

+1 untuk penggunaan yang bagus dari pertahanan "rujukan?" Terhadap seorang programmer dogmatik - sangat berguna
Gary Rowe

4

Saya pikir dengan apa pun yang Anda tidak pernah tahu sampai Anda mencobanya. Bahkan dengan bukti yang mendukung pernyataan, selalu memungkinkan untuk membengkokkan fakta demi kepentingan Anda. Yang sedang berkata Anda tidak harus mencoba setiap hal baru yang menyentuh jalinan. Buat penilaian terbaik Anda. Ingat, jika sesuatu terdengar terlalu bagus untuk menjadi kenyataan, mungkin itu benar. Selalu tanyakan pada diri sendiri mengapa Anda perlu mengadopsi sesuatu? Apa yang harus Anda dapatkan? Apakah masuk akal dari calon bisnis? Jangan pernah membutakan kecuali sesuatu pada iman.


+1 untuk bertanya "mengapa Anda perlu mengadopsi sesuatu". Terkadang mundur dari posisi terdepan adalah hal yang baik.
Gary Rowe

Saya menemukan bahwa terlalu sering pengembang terjebak dalam hal terbaik berikutnya tanpa menganalisanya dan memahami bagaimana hal itu dapat menguntungkan dan menghalangi mereka. Saya telah melihat situasi di mana organisasi mengadopsi sesuatu seperti Asp.Net MVC melalui Asp.Net Webforms tetapi tidak mengadopsi TDD.
Carlosfocker

3

Contoh dari kuliah adalah heuristik, aturan praktis dan tidak lebih. Itu harus jelas secara implisit.

Heuristik seperti yang lain: mereka tunduk pada konteks tertentu dan bergantung pada sejumlah asumsi yang tidak disebutkan, dan kegunaannya bisa sangat non-deterministik. Sebanyak mungkin penilaian sewenang-wenang untuk menemukan mereka berguna seperti halnya merumuskan mereka.

Apakah itu berarti mereka tidak berharga? Saya tidak akan mengatakannya sama sekali.

Heuristik adalah salah satu pendekatan yang dapat kita ambil untuk mengatasi masalah NP-complete, dan dalam banyak hal, rekayasa perangkat lunak itu sendiri merupakan masalah NP-complete.


Poin bagus. =)
Pablo

1

Tergantung. :) Ketika pernyataan seseorang bertentangan dengan pengalaman yang diulang, direfleksikan, dan diverifikasi secara pribadi, maka ya, saya ingin melihat semacam referensi penelitian. Di sisi lain, jika seseorang menggemakan ide yang telah Anda lihat dan hidup berkali-kali, tidak ada banyak reaksi yang diprovokasi (tidak berarti bahwa ide itu sempurna).

Sebagai contoh, buku "Code Complete" mengutip sejumlah studi dalam setiap bab untuk menunjukkan poin-poinnya, terkadang tentang hal-hal yang tampaknya kecil (seperti lekukan dan jarak, atau panjang nama variabel). Saya ingat beberapa pengembang (yang lebih muda) yang saya perkenalkan buku untuk berpikir bahwa tingkat detail dan bukti itu konyol. Tetapi beberapa bulan kemudian dengan lebih banyak pengalaman pengkodean produksi dan setelah beberapa ulasan kode, beberapa pengembang yang sama memiliki kejujuran untuk mengakui bahwa ya, bahkan jumlah ruang dalam lekukan tidak masalah. Komentar yang baik penting. Enkapsulasi penting. dll. dll

Di sisi lain, ketika vendor mengklaim beberapa IDE baru 50% lebih produktif, reaksi pertama saya adalah $ $ ^ &!


1
Itu tergantung, tetapi bahkan contoh kode lengkap tergantung pada situasi Anda. Sebagai Contoh: Jika Anda memiliki formatter parsing dan alat diff Anda mengabaikan spasi putih, maka argumen lekukan menjadi cukup sepele
Bill

1
+1 untuk contoh Kode Lengkap (juga berlaku untuk Pengembangan Cepat oleh penulis yang sama Steve McConnell).
Gary Rowe

@ Bill Sangat menarik bahwa karena teknologi meningkatkan masalah yang diperlukan bukti sebelumnya menghilang. Saya ingin tahu apakah ini merupakan efek yang mengurangi kebutuhan kita untuk meminta bukti?
Gary Rowe

1
@ Halifax Saya tidak berpikir ini (dalam arti umum) adalah kasus peningkatan sebanyak variasi. Contoh kode yang lengkap pasti merujuk ke suatu perangkat tertentu pada titik waktu tertentu sehingga keduanya, tetapi tipe "kapan harus refactor" lebih banyak berkaitan dengan situasi daripada dengan teknologi. Pikirkan perangkat lunak penting keselamatan dalam kendaraan vs solusi pemrosesan data. Persyaratan pengujian akan jauh lebih tinggi pada sistem keselamatan, jadi titik refactor akan selalu jauh lebih tinggi sebelum ada keuntungan bersih.
Bill

1

Bukankah itu sesuatu yang tergantung pada banyak variabel tidak berwujud (variabel yang tidak memiliki cara untuk diukur secara ilmiah)?

Menurut pendapat saya, mereka berbicara tentang metode empiris untuk mengukur emosi. Sesuatu yang bahkan Spock tidak bisa capai. =)


1
+1 untuk tampilan yang menarik. Mengesampingkan (dengan sengaja) contoh wol, jika seseorang berkata kepada Anda bahwa Rails adalah kerangka kerja yang lebih baik daripada SpringMVC bagaimana Anda akan menentukan validitasnya?
Gary Rowe

Seperti yang dinyatakan Benjamin Graham dalam buku klasiknya tentang investasi ("Analisis Keamanan"), bahwa alat (investasi) harus diukur dalam dua aspek yang berbeda, tetapi kesepian: Kualitatif (tidak berwujud, perasaan), dan Kuantitatif (bilangan real, matematika , perhitungan, logika).
Pablo

Kuantitatif adalah apa yang Anda ukur melalui metode ilmiah. Kualitatif adalah apa yang Anda ukur melalui insting Anda sendiri. Tidak mungkin untuk menilai emosi versus emosi tanpa memiliki emosi tentang analisis.
Pablo

Singkatnya, ketika kita berbicara tentang pendapat dan perbedaan di dalamnya, kita tidak bisa menyepakati metode yang masuk akal, ilmiah, dan nyata untuk mengukur abstrak.
Pablo

Jawaban saya adalah kita hanya bisa mengukur aspek teknis, bukan pemikiran / opini abstrak. Juga, saya tidak bermaksud terdengar seperti keledai. Pos-pos itu tidak dimaksudkan sebagai semacam tanggapan bodoh.
Pablo
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.