Apakah pengembang perangkat lunak yang mengabaikan kualitas / standar lebih baik untuk perusahaan? [Tutup]


10

Apakah pengembang perangkat lunak yang memilih untuk tidak menempatkan optimisasi kode, standar, dan praktik terbaik sebagai prioritas utama, membuat kode lebih bermanfaat daripada pengembang yang ingin khawatir tentang optimasi, penerapan standar pengkodean, dan praktik di atas menyelesaikan tugas tepat waktu?

Bagaimana metodologi berbeda ini dibandingkan ketika datang ke ulasan kinerja individu?

Bagaimana gaya ini dibandingkan dalam ulasan rekan?

Apa cara terbaik untuk memengaruhi tim Anda untuk menerapkan lebih banyak praktik terbaik selama SDLC?


2
@Haylem - Saya pikir hasil edit asli yang saya buat lebih baik. Jika judulnya sama dengan kalimat pertama, lalu apa gunanya judul itu?
BlackJack

1
@ BlackJack Saya membawa kembali judul Anda dan lebih mempertajam pertanyaan. Saya pikir kami bertiga terperangkap menginjak pos yang sama dalam riwayat sunting. Seharusnya bagus sekarang.
Thomas Owens

4
SE bukan tempat untuk ocehan tentang bos Anda. Kita semua memiliki bos dan sebagian besar dari kita memiliki seseorang dalam rantai komando yang mereka pikir tidak cocok di sana (Bukan saya, saya pikir mereka hebat / payah). Mengomel tentang mereka di sini tidak ada gunanya.
SoylentGray

1
@Chad: Sementara saya setuju dengan semua yang Anda katakan, saya tidak sepenuhnya yakin OP bermaksud menggerutu tentang bosnya (langsung).
haylem

2
@Chad: Saya sudah membaca itu, dan sementara aku bisa mengerti reaksi Anda, Jitendra tidak mengatakan bahwa semua yang dia lakukan adalah memperbaiki kode rakyat. Tetapi saya setuju dengan argumentasi Anda - dan beberapa jawaban lain - bahwa memberikan fungsionalitas lebih penting mungkin lebih penting daripada produk yang belum selesai dengan kualitas sempurna. Tidak seorang pun harus memelihara produk yang tidak akan pernah melihat cahaya karena sudah mati lebih awal atau gagal karena masih dilahirkan.
haylem

Jawaban:


32

Tidak, mereka hanya akan mendapat respek dari pemilik proyek saat itu.

Mereka akan dihancurkan selama bertahun-tahun dengan:

  • pemelihara masa depan,
  • penguji masa depan,
  • pemilik proyek masa depan,
  • manajer masa depan,
  • dan hampir semua orang terlibat dengan basis kode di masa depan.

Mereka bahkan mungkin mendapatkan perawatan yang sama dari:

  • penguji saat ini,
  • penulis dokumentasi teknis saat ini.

@Ivan: Terima kasih. Pemikiran jangka panjang selalu menang.
haylem

@haylem - Saya setuju dengan Anda karena orang-orang mengganti pekerjaan dengan cepat. jadi kode yang lebih baik akan berguna bagi para peserta baru untuk memahami kode dengan cepat
Jitendra Vyas

Semua benar, tetapi karena kinerja mereka, mereka akan lama diangkat jauh dari prajurit infanteri yang menjalani rasa sakit yang tersisa. Sedih tapi benar!
anon

6

Dikotomi palsu: kualitas bersifat ortogonal.

                Kualitas Tinggi Kualitas Rendah

Sketsa Mengagumkan Menguntungkan

Iffy FIRE FIRST PERTAMA

5
Apakah Iffy lebih baik atau lebih buruk daripada Sketchy?
HLGEM

1
@HLGEM: Menguntungkan selalu lebih baik daripada tidak menguntungkan.
Donal Fellows

yang mengabaikan biaya masa depan yang diciptakan oleh kualitas samar
Rudolf Olah

1
Menetapkan profitabilitas semata-mata di belakang pengembang adalah penyederhanaan yang berlebihan. Bagaimana dengan manajemen produk, infrastruktur penyebaran? Bukankah mereka juga memiliki peran dalam profitabilitas?
DavidS

5

Tidak. Praktik terbaik adalah yang terbaik karena, menurut definisi , mereka membantu menyelesaikan proyek dengan lebih benar, dalam waktu yang lebih singkat, dengan modifikasi yang lebih cepat, sehingga mengabaikannya dijamin akan mengurangi laba. Tentu saja, manajer Anda mungkin meresepkan praktik yang menurut mereka terbaik, tetapi sebenarnya tidak, atau mereka mungkin salah menilai apa yang akan dibayar pelanggan dan apa yang tidak - maka semua taruhan dibatalkan.

Standar pengkodean lebih rumit; dimungkinkan untuk meresepkan terlalu banyak detail untuk coders Anda, yang mengarah pada penurunan efisiensi. Tetapi dengan pengalaman, menjadi sangat mudah untuk memberi tahu pedoman yang bermanfaat dari pengelolaan mikro anal-retensi, sehingga hal yang sama berlaku: praktik terbaik aktual selalu bermanfaat, praktik pseudo-terbaik biasanya tidak.

Optimasi kode biasanya tidak layak dilakukan kecuali Anda telah mengukur apa hambatan Anda, memastikan bahwa melakukan optimasi diperlukan dan mengukur bahwa trik pintar Anda benar-benar memenuhi persyaratan kinerja sebelumnya. Kalau tidak (yang sebagian besar) tidak layak dilakukan, dan karenanya tidak optimal.


6
Praktik terbaik tidak membantu menyelesaikan semua proyek dengan benar dalam waktu yang lebih singkat. Mereka hanyalah hal-hal yang telah diamati bekerja dengan baik pada sebagian besar proyek sebagian besar waktu.
Thomas Owens

2
Ketaatan buta terhadap "praktik terbaik" atau cara terbaik orang lain untuk melakukan sesuatu adalah dengan proses pengembangan, apa itu pengkodean pemujaan kargo terhadap proses pengkodean. Anda harus mampu memahami apa arti suatu praktik, apakah itu sebenarnya hal terbaik dalam situasi Anda dan jika tidak, apa yang harus menggantikannya.
Blrfl

5

Apakah saya setuju dengan pengembang yang tidak peduli dengan optimasi dan praktik kode? Tidak.

Apakah mereka melakukan pekerjaan yang harus mereka lakukan? Iya.

Bisnis adalah tentang menghasilkan uang, dan satu-satunya cara menghasilkan uang adalah dengan melepaskan produk. Ini biasanya berarti bahwa proyek memiliki jadwal yang ketat, yang berarti apa yang mungkin merupakan cara terbaik untuk melakukan sesuatu mungkin bukan cara tercepat untuk melakukan sesuatu.

Walaupun saya tidak setuju dengan gaya pengembangan ini, mungkin terlihat terhormat oleh perusahaan jika produk dirilis.


Saya sangat peduli tentang optimalisasi kode dalam pekerjaan terakhir saya tetapi rekan-rekan pengembang saya tidak peduli tetapi mereka mengerjakan lebih banyak proyek daripada saya dan ketika saya berbicara dengan manajer proyek, dia mengatakan Klien menginginkan proyek tepat waktu dan dia tidak pernah melihat bagaimana kode ditulis.
Jitendra Vyas

1
@Jitendra - Jika Anda menghabiskan waktu seharian untuk mengoptimalkan hal-hal yang telah ditulis dan tidak mendapatkan fungsionalitas baru, saya juga tidak akan senang. Kecuali jika optimasi memberi Anda sesuatu selain jumlah baris dan karakter yang lebih sedikit dalam kode sumber, maka Anda tidak mencapai apa-apa.
SoylentGray

3
@Jitendra - Saya tidak mengatakan bahwa itu tidak. Dan menulis kode Anda dengan cara yang mudah dibaca sangat bagus. Berkeliaran 'memperbaiki' tampilan kode orang lain ketika Anda memiliki tugas sendiri bukan.
SoylentGray

1
@Chad -Ini bukan tentang menulis ulang kode saya sendiri atau memperbaiki kode orang lain ini tentang menulis kode pada saat pertama dengan indensi yang tepat untuk keterbacaan yang baik, komentar yang tepat untuk pengembang masa depan dan menggunakan praktik terbaik yang membuat kode dapat digunakan kembali dan itu semua membutuhkan waktu kemudian menulis kode berantakan yang hanya bisa dipahami oleh pengembang asli. Kode yang baik selalu membutuhkan waktu.
Jitendra Vyas

4
@Ivan: Saya punya pengalaman langsung dengan mentalitas ini. Seperti ini. Perusahaan memulai proyek greenfield. Pengembang Hotshot X melempar barang secepat mungkin, menggunakan jumlah ctrl + cdan ctrl + v. Produk ini diluncurkan dalam waktu yang sangat singkat. Perusahaan senang dengan Pengembang X. Laporan bug dan permintaan fitur masuk. Pengembang X tidak dapat mengikuti dan dipecat / pindah ke pekerjaan berikutnya. 3 tahun pengembangan berikutnya adalah pintu putar tim insinyur baru yang tidak dapat membuat kemajuan, dan Perusahaan X kehilangan semua keunggulan pasar yang pernah dimilikinya.
Greg Burghardt

4

Tidak, dan saya akan menemukan rute tercepat menjauh dari perusahaan mengatakan bahwa menghargai mereka keburukan.


2
+1 karena singkat, to the point, dan benar. Perusahaan yang tidak memedulikan standar kualitas adalah bodoh, bodoh, atau scam.
Wayne Molina

3

Ya dan tidak, yang agak plin plan tapi itu praktik terbaik dan bukan praktik yang sempurna. Idealnya Anda harus mengikuti mereka terus-menerus, tetapi akan selalu ada situasi di mana bisnis ingin menempatkan kebutuhan itu sebelum kebutuhan produk Anda.

Anda akan dibenci oleh pengelola tetapi dicintai oleh atasan Anda.


3

Praktik Terbaik agak seperti akal sehat, semua orang setuju bahwa setiap orang harus mengetahuinya sampai dua orang mulai mendiskusikannya secara rinci. Tidak ada dua orang yang sepenuhnya setuju dengan definisi tersebut dan tidak ada sumber kebenaran logis yang berlaku untuk semua situasi.

Apakah Anda menulis sistem panduan untuk satelit ruang angkasa (mungkin Anda tidak)? Maka Neraka Tidak ada kode berkualitas / berkinerja buruk yang tidak pernah dapat diterima dalam jenis pekerjaan ini.

Apakah Anda menulis situs web sekali pakai untuk dorongan pemasaran satu kali (Anda mungkin tidak melakukan ini juga atau Anda tidak akan mengajukan pertanyaan, tetapi lebih mungkin daripada satelit)? Lalu Neraka Ya, dapatkan potongan itu dari pintu melalui segala cara yang diperlukan untuk memenuhi tenggat waktu, direktur pemasaran berikutnya mungkin akan melakukan sesuatu yang lain dengan perusahaan yang berbeda pula. APA YANG ANDA LAKUKAN TIDAK SENI ATAU ILMU PENGETAHUAN - DAPATKAN BAYARAN.

Segala sesuatu yang lain di antara: dinegosiasikan, terutama selama dev ada di kait untuk dukungan awal.

Sampai kedatangan kedua makhluk suci apa pun yang Anda sukai terjadi dan dia / mereka / itu mendefinisikan praktik pembangunan dengan cara yang ajaib akan ada ruang yang signifikan untuk perdebatan tentang proyek apa pun yang tidak secara langsung bertanggung jawab atas keputusan hidup dan mati yang tidak jadi tidak penting untuk dibuang.

Segala sesuatu di luar praktik terbaik berlabel kritis kehidupan biasanya lebih seperti kebijakan perusahaan, spesifikasi klien, atau pendapat pribadi. Banyak dari mereka adalah pendapat pribadi yang disetujui banyak orang saat ini, tetapi itu tidak menjadikannya panduan abadi untuk semua situasi.


2

Berapa banyak uang yang mereka hasilkan untuk perusahaan masih bisa diperdebatkan. Jika ada tingkat meninjau kembali kode yang dimaksud, biaya pemeliharaan akan naik dan seseorang tidak akan bahagia. Biaya perawatan jangka panjang yang tinggi lebih mahal daripada melakukannya dengan benar di muka.

Seberapa besar rasa hormat yang mereka dapatkan mungkin spesifik untuk kasus tertentu. Namun, pada titik tertentu, seseorang akan memperhatikan.


2

Tidak memedulikan hal-hal ini dapat membuat perusahaan lebih banyak uang dalam jangka pendek, tetapi dapat membuat perusahaan mengeluarkan lebih banyak uang dalam jangka panjang karena lebih banyak perbaikan bug dan coding perawatan.

Terkadang pekerjaan cepat dan kotor mungkin diperlukan jika ada desakan dengan perusahaan pesaing untuk mendapatkan produk serupa ke pasar pada saat yang sama, tetapi biaya di masa depan dari tindakan tersebut harus dipertimbangkan dengan hati-hati.


2

Itu semua tergantung pada pelanggan.

Pelanggan yang suka cepat dan kotor (dan biasanya lebih murah) tidak peduli bahwa itu akan menimbulkan masalah di masa depan.

Pikirkan konstruksi kabinet.

Beberapa orang akan membayar, dan menghargai, kabinet yang dibangun dengan kualitas baik. Mereka tidak keberatan dengan biaya ekstra untuk laci kayu keras dan perangkat keras terbaik. Mereka tidak keberatan akan membutuhkan satu minggu ekstra atau bahkan sebulan untuk membangun dan menginstalnya.

Banyak yang tidak. Banyak yang akan memilih barang papan partikel yang diproduksi secara massal murah yang Anda dapatkan dari toko kotak besar. Mereka ingin mereka diinstal dalam 2 hari. Kesenjangan kecil di sana-sini sangat bisa diterima. Mereka tidak peduli bahwa mereka akan hancur dalam 10 tahun.

Jadi jika manajer Anda memuji pengembang yang menyelesaikannya dengan cepat dan kotor maka pelanggan Anda tidak ingin kualitas tinggi atau manajer berbohong kepada pelanggan.

Hanya waktu yang akan memberitahu. Lakukan apa yang diinginkan manajer atau cari pekerjaan lain.


1
tentu saja perangkat lunak dapat datang dengan dukungan sehingga melakukan keduanya bisa menjadi pilihan. yaitu kita akan menjadi yang pertama memasarkan dengan v1 meskipun masalah diketahui namun uang yang kita peroleh dari bentuk ini akan memungkinkan kita untuk memperbaiki masalah di masa depan dll.
jk.

1

Tidak, tidak pernah. Optimalisasi kode IMO, praktik terbaik, keahlian aktual adalah hal PALING penting untuk dimiliki dalam basis kode; tanpanya semuanya berubah menjadi lumpur dan disatukan dengan lakban. Ini desain yang tidak berkelanjutan. Ini seperti mengabaikan tumor karena kecil dan Anda sehat sekarang; Anda pasti sehat sekarang, tetapi beberapa tahun kemudian menjadi terminal karena Anda mengabaikannya begitu lama.

Saya tidak hanya tidak setuju dengan pengembang yang tidak peduli dengan hal-hal ini, tetapi saya tidak menghargai mereka untuk boot. Cara yang pasti untuk membuat saya mempertimbangkan meninggalkan suatu organisasi, tidak peduli seberapa singkat waktu saya di sana, adalah dikelilingi oleh tim di mana saya adalah satu-satunya orang (jika bukan satu-satunya orang di seluruh perusahaan) yang peduli tentang konsep rekayasa perangkat lunak yang tepat.


1

Bacaan yang bagus: http://www.joelonsoftware.com/items/2009/09/23.html

Tapi IMHO, praktik terbaik satu pria adalah mimpi buruk pria lain. Dan setiap basis kode non-sepele akan menjadi mimpi buruk bagi orang luar.

Apa pun yang Anda pikirkan, jangan menyebalkan tentang itu.

EDIT: Saya tidak membela salah satu posisi, tergantung pada tugas yang saya mungkin condong ke kedua sisi.


Tergantung pada "praktik terbaik" IMO. Hal-hal seperti memiliki tes (tidak harus TDD tetapi tes otomatis pada umumnya), mengikuti SOLIDprinsip - prinsip, menggunakan pola desain, menggunakan abstraksi / antarmuka adalah dasar yang harus dilakukan oleh setiap pengembang yang kompeten.
Wayne Molina

Sebanyak yang saya suka tes ... mereka bukan baseline.
CaffGeek

1

Lebih baik untuk perusahaan? Tergantung.

Untuk startup dengan dana terbatas, selesaikan dan laksanakan di sana - tidak masalah apakah itu berantakan, yang dapat diperbaiki nanti ketika ada lebih banyak sumber daya.

Untuk produk matang di mana ada banyak pengguna yang mengandalkan kualitas perangkat lunak, semuanya harus dilakukan "dengan benar".

Lebih baik untuk pengembang individu? Sebenarnya itu tidak relevan. Lakukan hal yang sama seperti apa yang dilakukan kolega Anda, dan biarkan manajemen menangani dampaknya - itu bukan pekerjaan Anda. Jika Anda memperbaiki omong kosong orang lain sepanjang waktu Anda AKAN terlihat lambat, dan Anda akan menjadi orang yang masih ada sementara yang lain dipromosikan di atas Anda. Dapatkan dengan program ini, atau keluar selagi Anda bisa jika itu buruk.


"Tidak masalah apakah itu berantakan, itu bisa diperbaiki nanti ketika ada lebih banyak sumber daya." Secara teori, tentu saja. Dalam praktiknya ini tidak pernah terjadi karena begitu Anda mendorong keluar sesuatu Anda terjebak mempertahankannya dan menambahkan hal-hal baru, sehingga Anda tidak pernah memiliki sumber daya untuk kembali dan memperbaikinya.
Wayne Molina

Saya tidak setuju. Ini tentu saja terjadi pada banyak proyek web kecil-menengah yang pernah saya ikuti, dan ada juga banyak contoh perusahaan terkenal yang akan kembali dan merestorasi basis kode mereka dengan cara-cara besar - misalnya Twitter beralih dari Ruby ke Scala, Facebook dan pencarian mereka untuk mengoptimalkan bahasa PHP, dll. Bahkan, saya cukup yakin sebagian besar aplikasi dewasa yang sukses (web dan desktop) yang kita gunakan setiap hari tidak memiliki banyak kode yang sama dengan nenek moyang v1 mereka.
timh

Mungkin, tetapi dalam enam tahun pengembangan perusahaan, saya telah menemukan satu perusahaan yang dapat memperbaiki kode dari waktu ke waktu; tempat lain tidak pernah memiliki sumber daya untuk mencurahkan "memperbaiki apa yang tidak rusak" bahkan ketika kode tidak dapat dikelola.
Wayne Molina

0

Tergantung pada pengembang dan proyek / situasi.

Waktu yang luar biasa membutuhkan tindakan luar biasa.

Jadi jika saya memerlukan sesuatu yang dikirim sekarang, dan seseorang adalah rekayasa aplikasi tingkat perusahaan Java over-engineering yang memanfaatkan tidak kurang dari 14 kerangka kerja kata kunci terbaru sementara skrip python sederhana akan melakukan pekerjaan itu sama buruknya dengan pengembang yang mengambil jalan pintas dan berpikir kode kereta akan dilakukan di waktu normal.

Bagian dari menjadi pengembang adalah fleksibel. Anda tidak boleh menjadi budak alat Anda dan mengikuti praktik secara membabi buta - akan selalu ada kasus di mana mereka akan mengecewakan Anda. Mengetahui kapan harus melanggar dan menekuk aturan adalah salah satu hal yang datang dengan banyak pengalaman dan berharga.

Dalam kasus Anda - jika dia memberikan nilai lebih dari Anda karena kecepatan sangat penting, bahkan setelah memperhitungkan peningkatan biaya pemeliharaan di jalan, maka ia layak mendapatkan kompensasi yang lebih baik. Di sisi lain - jika Anda terjebak dengan membersihkan kekacauan - Anda memiliki masalah komunikasi dengan manajemen.

Ini adalah kasus per kasus. Kecuali gaya pengkodean - tidak ada alasan di sana.


0

Saya minta maaf tetapi saya harus tidak setuju dengan sebagian besar jawaban untuk pertanyaan ini, kecuali untuk yang teratas.

Nilai utama dari perangkat lunak adalah fleksibel.

Saya tidak berpikir Anda harus menulis ulang kode orang lain tanpa alasan. Jika Anda harus mengubah modul dengan alasan apa pun untuk mengimplementasikan fitur Anda, Anda sekarang, menjadi lebih baik atau lebih buruk, pemilik modul itu. Ubah, tulis ulang sebagian, tulis ulang semuanya.

Jangan pernah menghasilkan kualitas rendah dalam hal fleksibilitas. Tidak ada yang namanya membuang apa pun dalam perangkat lunak. Jika klien mengatakan ini sementara dan bahwa mereka tidak akan membutuhkannya setelah tanggal tertentu, dan mereka tidak peduli dengan kualitas, baik mengatakan "buruk" atau secara tertulis bahwa kode tidak akan diubah oleh Anda atau programmer lain sekali itu digunakan untuk produksi, atau Anda memiliki hak untuk menuntut mereka.

Asumsi termiskin yang saya lihat dalam beberapa jawaban ini adalah bahwa beberapa kode bersih entah bagaimana mengurangi kecepatan pengembangan. Untuk proyek apa pun dari bahan apa pun (lebih dari 6 jam kerja) kode bersih mempercepat pengembangan dalam jangka panjang (apa pun yang lebih besar dari seminggu). Saya telah melihatnya berulang kali.

Kode kualitas yang buruk hanya tidak menghormati profesi dan rekan kerja Anda. Maaf tapi benar.

Jadi tidak dengan kualitas buruk, dalam hal fleksibilitas, lamanya!


1
Tidak pernah berkata tidak. Seluruh aplikasi dibuang ke tempat sampah. Konversi data dari satu sistem ke sistem lain digunakan sekali dan membusuk.
JeffO

Menjaga kode tetap bersih seringkali mengurangi kecepatan pengembangan sedikit dalam jangka pendek . Bagian penting adalah bahwa kode yang tidak bersih menyebabkan pengurangan yang jauh lebih besar dalam jangka panjang. Saya melihat beberapa jawaban lain yang menyebutkan itu.
Ixrec
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.