Godaan berbahaya dalam pemrograman


97

Hanya ingin tahu, jenis godaan apa dalam pemrograman ternyata benar-benar berbahaya dalam proyek Anda?

Seperti ketika Anda benar-benar merasakan dorongan untuk melakukan sesuatu dan Anda yakin itu akan menguntungkan proyek atau Anda hanya menipu diri sendiri untuk mempercayainya, dan setelah seminggu Anda menyadari bahwa Anda belum menyelesaikan masalah nyata tetapi malah membuat yang baru atau , dalam kasus terbaik, senang binatang buas Anda tanpa dampak yang terlihat.

Secara pribadi, saya merasa sangat sulit untuk tidak memperbaiki kode buruk. Saya bekerja dengan banyak kode warisan yang buruk, dan butuh napas dalam-dalam untuk tidak menyentuhnya ketika saya tidak memiliki tes untuk membuktikan refactoring saya tidak merusak apa pun.

Setan lain bagi saya dalam antarmuka pengguna, saya benar-benar dapat menghabiskan berjam-jam mengubah tata letak UI hanya karena saya senang melakukannya. Kadang-kadang saya mengatakan pada diri sendiri bahwa saya sedang mengerjakan kegunaan, tetapi kenyataannya adalah saya suka memindahkan tombol.

Apa setan pemrograman Anda, dan bagaimana Anda menghindarinya?


19
Saya merasa lucu bahwa tidak ada yang bisa menjawab bagian kedua dari pertanyaan Anda - "[dan] bagaimana Anda menghindarinya?".
Craige

3
Adakah yang memperhatikan bahwa ini adalah pertanyaan teratas di SE sepanjang hari.
msarchet

+1 untuk "... habiskan berjam-jam mengubah tata letak UI ..." Saya terlalu sering terperangkap dalam perangkap itu.
7wp

Jawaban:


67

Generalisasi prematur adalah bugaboo besar saya; alih-alih menyelesaikan masalah yang dihadapi terlebih dahulu dan menunggu sampai ada kebutuhan aktual untuk menyelesaikan kasus umum, saya selalu mencari kasus umum di muka dan akhirnya menulis satu ton kode yang lebih kompleks daripada yang seharusnya.

Memperbarui:

Lihat " Dosa # 1 - Generalisasi Prematur " untuk penjelasan mendalam.


6
Aku benci ketika astronot arsitektur melakukannya!
ozz

13
Oh, kegembiraan pabrik metafactory :(

+1 "Sebuah studi tentang perancang hebat menemukan bahwa mereka semua pandai mengantisipasi perubahan" (Kode Lengkap 2). Adalah baik untuk mengetahui perubahan macam apa yang mungkin terjadi. Kemudian Anda dapat memutuskan apakah ada sesuatu yang bisa diperoleh dengan menyelesaikan kasus yang lebih umum sejak dini - apakah akan menghemat waktu nanti. Terkadang itu tidak layak, itu akan mudah untuk memodifikasi kode nanti.
MarkJ

1
Pernahkah Anda mendengar tentang Prinsip YAGNI (Anda Tidak Perlu) ?
Oscar Mederos

1
Ini. Saya menyalahkan fakta bahwa membuat kode yang cantik, umum dan dapat digunakan kembali sangat memuaskan, terutama jika masalahnya sendiri tidak terlalu menantang dan / atau hanya pengulangan dari apa yang telah Anda lakukan sebelumnya. Contohnya, operasi basis data CRUD generik (UI, menanggapi tindakan pengguna, melakukan sesuatu dengan DB, thar).
Cthulhu

197

"Kami akan kembali ke sini dan memperbaikinya nanti. Kami hanya perlu bekerja sekarang!"


16
Ini adalah iblis absolut.
alesplin

6
Saya akan memberi Anda +100 untuk ini jika saya bisa. "Nanti" TIDAK PERNAH TERJADI. Lakukan hal yang benar pertama kali atau tidak sama sekali.
quick_now

12
bukankah ini pelengkap dari jam kerja refactoring kode buruk? Kita dapat membagi dunia menjadi programmer yang "akan memperbaikinya nanti" tetapi tidak, dan programmer yang mencoba untuk memperbaikinya pertama kali kemudian menghabiskan berjam-jam "refactoring kode yang buruk".

6
ulang frasa ini menjadi "Kami akan kembali dan memperbaiki iterasi berikutnya " dan kedengarannya jauh lebih terstruktur
Chris S

4
Anda harus melakukan ini. Jika Anda menghabiskan seluruh waktu Anda untuk membuatnya sempurna, itu tidak akan pernah dikirimkan. Selesaikan proyek, lalu poles.
Zan Lynx

105

Tenggat waktu adalah soooooo jauh, saya punya lebih dari cukup waktu untuk melakukannya, jadi mengapa tidak menghabiskan sedikit waktu berselancar di web?


72
ganti "web" dengan "programmers.stackexchange.com" :)
davidhaskins

1
Apakah ada hal lain di web yang layak dibaca? Saya lupa ada hal lain!
James McLeod

3
alias 'Sialan kamu, Minecraft'
johnc

1
@david, itu hanya titik awal di web - pertanyaannya adalah seberapa jauh Anda mendapatkan ...

Id 'say, ini sudah tidak berlaku lagi karena Agile.
vartec

103

"Ini hanya membuang-bukti kode konsep. Begitu mereka menyukainya, aku akan benar-benar membuatnya baik."


13
Ini disebut Pengembangan Aplikasi Cepat; dan itu tidak pernah berfungsi di lingkungan bisnis. :)
John Kraft

12
Lucu bagi saya itu sebaliknya - saya tidak bisa membuat diri saya menulis kode yang dibuang bahkan ketika itu persis apa yang diperlukan.
Dan

6
Saya bekerja di bidang keuangan dan RAD masih kuat, terutama hal-hal VBA / Excel. Ada bakat untuk itu, RAD tidak harus berarti ceroboh.
Ian

5
Dan kadang-kadang aplikasi yang Anda habiskan dua tahun menyempurnakan akhirnya menjadi kode membuang karena seseorang yang lebih tinggi tangga memutuskan "oh, kita tidak bisa melakukan itu" atau versi lain dari "tidak apa-apa".
PSU

12
Ini. Saya: "Ini hanya bukti konsep saya. Jika Anda suka, kami akan menulis versi produksi." Manajer: "Versi Anda berfungsi, mari kirimkan!" Saya: "Yah, itu tidak mencakup semua kegunaan ... Anda sudah mengirim, bukan?"

74
  1. Refactoring bagian dari kode beberapa hari sebelum rilis.
  2. Internet: Gangguan terbesar dari semua.
  3. Teknologi baru : Tidak bisa melepaskan diri dari teknologi baru.
  4. Optimalkan: Optimalkan, Optimalkan. .. dan lainnya Optimalkan
  5. Kesempurnaan : Tidak pernah puas dengan kode.
  6. TODO: Kurangnya waktu todos yang tidak akan pernah dilakukan.
  7. Estimasi waktu: Banyak PM tidak menganggap ini sebagai "estimasi". Mereka mengambil fakta.
  8. Janji: Memberikan terlalu banyak janji.

1
Pernah bekerja pada proyek yang memiliki 100 orang di ruangan besar, dan hanya 2 PC yang dibagi memiliki internet. Produktivitasnya sangat tinggi. Manajemen memberi semua orang internet dan bertanya-tanya mengapa hasil pekerjaan dibelah dua.
cepat

2
Mengenai Estimasi Waktu ... begitu banyak manajer menganggapnya sebagai titik awal dalam negosiasi (seperti menawar harga). Orang yang menganggapnya sesat tetapi sebenarnya di atas rata-rata ...
dbkk

@quickly_now Memotong jaring mungkin berfungsi untuk tugas-tugas biasa seperti entri data atau perbaikan rutin, di mana Anda tidak perlu mencari apa pun. Untuk banyak hal yang tidak biasa (misalnya mencari dokumen API / kode contoh), Google adalah teman Anda - dibutuhkan 5 kali lebih banyak waktu untuk mengetahuinya sendiri. Juga, jika orang tidak termotivasi dan ingin terganggu, mereka akan menemukan cara.
dbkk

@ dbkk - ya sampai titik tertentu. Itu semua di Ada, tidak ada API untuk dicari, itu pada perangkat keras khusus, dan keamanan nasional diklasifikasikan. Menempatkan mesin yang terkoneksi internet yang tidak terklasifikasi ke dalam lingkungan itu juga merupakan mimpi buruk keamanan.
cepat

55

Jatuh mangsa untuk mencoba membangun semuanya di rumah, ketika ada kerangka kerja dan perpustakaan.


6
Kadang-kadang kerangka kerja dan perpustakaan yang ada ditandai Verboten dalam huruf merah besar oleh hukum IT.
Christopher Mahan

22
Dan tentu saja, godaan yang berlawanan: menggunakan kerangka kerja atau perpustakaan yang tidak dikenal dan dengan asumsi bahwa itu akan melakukan apa yang Anda butuhkan dan semuanya akan berjalan dengan lancar.
Carson63000

"tapi itu hanya akan memakan waktu satu minggu untuk menulis dan kerangka kerja kita akan melakukan apa yang kita inginkan, yang gratis secara online mungkin penuh dengan bug"

2
@Christopher: Maka itu akan menjadi alasan yang baik untuk mengimplementasikan ulang (atau menemukan perpustakaan yang berbeda dengan lisensi yang dapat diterima). Tapi terlalu sering alasan untuk mengimplementasikannya hanya NIH ...
Donal Fellows

@Carson: +1 :-)
Macke

48

Setan saya berulang: Optimasi prematur dan rekayasa ulang.

Dan saya masih tidak bisa menghindarinya 100% ...


10
+1 untuk rekayasa ulang. Saya pernah menulis "kerangka konfigurasi" seluruh dengan "config parameter adapter" untuk file .ini, file XML, tabel database dan soket jaringan (karena semua orang ingin meng-host layanan web konfigurasi, kan?)
TMN

8
Rekayasa berlebihan prematur?
Christopher Mahan

@ Chris "prematur overengineering" berlaku juga. Sudah disebutkan dalam jawaban lain juga. Saya tahu ini adalah larangan saya.
Matthew Scharley

Bagaimana dengan mega-engineering prematur yang terlalu dioptimalkan ...
Newtopian

4
Ini adalah milikku. Saya menyalahkan manajemen yang memberi saya tenggat waktu bebas dari pemerintahan / masa depan dan tidak memberikan tenggat waktu untuk komponen tertentu.
Cthulhu

46

Perkiraan yang terlalu optimis

Ketika manajer Anda menatap Anda ke bawah, dan Anda merasakan perasaan yang membara untuk memberikan perkiraan yang lebih rendah daripada yang dikatakan usus Anda ... jangan lakukan itu!

Bagaimanapun, usus Anda mungkin sudah terlalu rendah!


13
Ketika mereka bertanya kepada Anda apakah itu benar - benar akan memakan waktu selama itu, katakan saja ya dan kemudian duduklah dalam diam sampai mereka merasakan canggung ...
PeterAllenWebb

4
Dosen perguruan tinggi saya pernah mengatakan kepada saya untuk, "Cari tahu perkiraan terbaik Anda, lalu gandakan." Sejauh ini itu bekerja untuk saya.
zzzzBov

2
Atau, coba pendekatan SMBC .
detly

4
Salah satu bos lama saya tiga kali lipat perkiraan pengembang, lalu dinegosiasikan ke dua kali lipat dengan klien. Klien mengira mereka mendapat kesepakatan, pengembang mendapatkan waktu yang mereka butuhkan bahkan jika mereka tidak mengetahuinya. Menang-menang!
DaveE

2
Penjadwalan berbasis bukti dapat membantu dengan masalah ini: joelonsoftware.com/items/2007/10/26.html
Rei Miyasaka

33

Untuk menggunakan teknologi / alat / bahasa dalam proyek Anda murni karena Anda baru saja mempelajarinya.

Untuk mencoba membuktikan seberapa baik pengembang Anda.

Untuk mempertimbangkan kode yang Anda tulis menjadi milik Anda.


Seandainya saya hanya bisa mengunggulkannya setiap kali saya melakukannya. Untungnya, setengah dari solusi ternyata cukup bagus. Setengah tidak.
Dan

Atau yang belum Anda pelajari sama sekali. Hanya saja, jangan lupa untuk mengikat taji Anda karena itu akan menjadi perjalanan yang panjang.
Evan Plaice

32

Saya hanya akan istirahat dan melihat stackoverflow.com;)


2
Saya selalu suka ketika stackoverflow adalah jawaban untuk salah satu pertanyaan ini
Bill Leeper



23

Fitur Merayap

Buat rencana, patuhi, dan gunakan. Dan kemudian kembali dan tambahkan hal-hal yang diminta orang.

Saya telah melihat ini berulang kali. Anda duduk, mengerjakan desain, dan mulai coding. Para pengguna mendengar omong kosong bingung tentang fitur favorit mereka yang "hilang" dan mereka mulai melobi untuk itu. Bos Anda menuntut Anda menambahkannya pada jam ke-11, melanggar penerapan, memperkenalkan bug di mana-mana, dan 3 bulan kemudian, setelah semua orang tenang, Anda diminta untuk menghapusnya, karena tidak ada yang tahu mengapa Anda memasukkannya fitur retro jelek di tempat pertama! Tidak bisakah Anda mengatakan bahwa sisa desain membuatnya sia-sia?


Meninggalkan spec tidak beku dan terbuka sebagai konsesi karena PM pertama (yang sekarang dipecat) tidak tahu apa-apa tentang pengembangan perangkat lunak dan merancang jadwal rilis yang sama sekali tidak realistis. Ide terburuk yang pernah ada.
Evan Plaice

20
  1. Tambahkan lebih banyak fitur

  2. Kompetisi memiliki fitur ini. Jadi ini adalah harus memiliki fitur maka lebih banyak pemrograman daripada menganalisis strategi, posisi, dll.

  3. Kompetisi TIDAK memiliki fitur ini. Jadi ini adalah fitur yang membedakan maka lebih banyak pemrograman daripada menganalisis strategi, penentuan posisi, dll.

  4. Memecahkan masalah bisnis dengan lebih banyak pemrograman. mis., keahlian yang lebih baik dalam mengelola server linux yang dihosting situs web Anda tidak dapat diperoleh melalui pemrograman lebih banyak fitur. Terkadang Anda hanya perlu belajar cara memperbaiki masalah daripada mengkode ulang semuanya menjadi C # .Net

  5. Memecahkan masalah pemasaran dengan lebih banyak pemrograman. misalnya, menyalahgunakan konsep sapi ungu Seth Godin bahwa Anda secara tidak langsung memecahkan masalah pemasaran dengan memprogram lebih banyak fitur ke dalam produk Anda untuk menjadikannya "sapi ungu". Terkadang, itu hanya monster mutan.

  6. Menyelesaikan masalah produktivitas dengan lebih banyak pemrograman yang berargumentasi pada diri Anda sendiri bahwa waktu yang dihabiskan untuk menulis skrip ini akan disimpan kembali dalam beberapa jam di masa depan, alih-alih sebenarnya memprogram hal-hal yang sangat penting

  7. Berencana membuat kode tetapi belum mengkode karena Anda ingin "melakukannya dengan benar"

  8. Menyandikan versi yang kotor dan berjanji bahwa Anda akan "membuatnya lebih baik nanti" tetapi tidak pernah kembali ke "membuatnya lebih baik"

  9. Tidak melakukan mockup atau sitemap karena itu "sangat merepotkan". Saya hanya bisa screenshot halaman pesaing untuk maket dan menggambar sitemap "nanti" yang tidak pernah. Dan kemudian langsung masuk ke pemrograman halaman pertama yang saya bayangkan dalam pikiran saya.

Pengakuan: Saya pribadi membuat kesalahan 1, 3, 7, 8. Saya juga membuat 2, 4, 5, 6 tetapi sering menipu diri saya sendiri bahwa saya tidak melakukannya.

Saya sedang memperbaiki 9.

EDIT Tidak menyadari pertanyaan mengharuskan kami untuk memasukkan solusi.

1) Tambahkan lebih banyak fitur. Jangan lakukan itu. Bekerja dengan bisnis Anda, pemasaran, pendiri, penasihat, dll dan strip aplikasi Anda menjadi hanya satu hal.

Bacalah tentang twitter, Groupon , dll tentang bagaimana mereka menghapus semua hal menjadi hanya satu hal yang mengarah pada kesuksesan mereka.

Jika Anda pikir itu hanya berfungsi jika Anda ingin membangun perusahaan besar, pikirkan lagi. Ctrl + F untuk baris ini "Semakin banyak fitur yang saya tambahkan ke perangkat lunak, semakin buruk yang dijualnya. (Ini, tentu saja, sangat tidak intuitif bagi kebanyakan pengembang perangkat lunak.)" Di tautan ini

2) Kompetisi memiliki fitur ini. Jadi ini adalah fitur yang harus dimiliki

Lihat solusi 1

3) Kompetisi TIDAK memiliki fitur ini. Jadi ini adalah fitur yang membedakan

Lihat solusi 1

4) Memecahkan masalah bisnis dengan lebih banyak pemrograman.

Jika Anda perlu mempekerjakan seseorang untuk mengajar Anda, memberikan konsultasi, atau melakukannya untuk Anda dan kemudian mendokumentasikan bagaimana dia melakukannya, sehingga Anda dapat melakukannya sendiri di lain waktu. LAKUKAN SAJA!! Jangan menulis ulang kode, jangan lewat GO, jangan kumpulkan $ 200.

5) Memecahkan masalah pemasaran dengan lebih banyak pemrograman.

Jika orang tidak mengerti apa yang Anda jual, itu masalah pemasaran. Kembali ke solusi 1 dan inden.

6) Memecahkan masalah produktivitas dengan lebih banyak pemrograman

Tunggu.

Tunggu hingga Anda merasa bahwa produktivitas Anda mengalami masalah produktivitas tertentu untuk jangka waktu lebih dari 2 minggu dan itu wajar akan terjadi selama 2 minggu lagi.

Sekarang, evaluasi jumlah waktu yang dihabiskan untuk memprogram skrip untuk menyelesaikan masalah ini. Ingatlah untuk mengambil estimasi terburuk Anda dan kalikan dengan 2.

Lipat gandakan estimasi Anda dengan kurs per jam Anda.

Sekarang tinjau solusi alternatif: outsourcing, beli solusi langsung, jangan lakukan apa-apa, dll

Pilih solusi yang paling hemat biaya.

Tetap pada itu.

7) Berencana untuk kode tetapi belum coding karena Anda ingin "melakukannya dengan benar"

Berolah raga. Anda akan merasakan desakan endorfin yang akan memotivasi pantat Anda dan membuat Anda berencana untuk bertindak. Saya tahu ini karena saya baru saja melakukan benchpresses 5x5 dan squat 5x5.

8) Menyandikan versi yang kotor dan berjanji bahwa Anda akan "membuatnya lebih baik nanti" tetapi tidak pernah kembali ke "membuatnya lebih baik"

Atur sistem file pengingat di GTD. dan menindaklanjutinya dengan agresif. Tindak lanjuti semua janji untuk diri sendiri dan orang lain.

9) Tidak melakukan mockup atau sitemap karena "sangat merepotkan".

Pergi menghabiskan USD75 pada edisi desktop balsamiq mockups. Saya tahu ini karena saya membelinya 3 minggu yang lalu. Itu membuat saya mengulang maket saya karena saya merasa seperti seorang seniman, arsitek dan visioner semua dalam 1 meskipun gambar saya di dunia nyata menyebalkan. Font yang digunakan dalam balsamiq secara tidak sadar mengingatkan Anda bahwa ini hanyalah mockup, bukan batu yang membantu Anda dalam RAD.

Akhiri EDIT


Memberi +1 jawaban ini, tetapi saya merasa agak sulit untuk membaca. Saya tidak begitu mengerti konteks dari 9 poin pertama. Maukah Anda mengklarifikasi? Tetap saja, pekerjaan bagus.

@MattFenwick Halo, terima kasih atas +1 Anda. Poin 1-5 biasanya diterapkan dalam skenario menciptakan produk untuk dijual, meskipun Anda juga dapat menerapkannya pada skenario di mana kecenderungan Anda untuk menemukan jawaban terbaik mengarahkan Anda untuk meneliti secara ekstensif pada bidang sebelumnya. Misalnya, dalam penelitian.
Kim Stacks

Poin 6-9 lebih berkaitan dengan kecenderungan neurotik seorang programmer. Saya membaca di suatu tempat (tidak dapat menemukannya) bahwa seorang desainer akan selalu mendekati masalah dengan solusi desain; seorang pemasar dengan solusi pemasaran; dan seorang programmer dengan solusi kode. Ya, yang ditakuti "Ketika Anda memiliki palu emas, yang Anda lihat adalah sindrom kuku". Ini terbukti pada poin 6) Memecahkan masalah produktivitas dengan lebih banyak pemrograman
Kim Stacks

@ MattFenwick maaf jika Anda bingung dengan nama saya. Saya mengubah nama panggilan saya setelah menulis jawaban ini. Saya melihat bahwa latar belakang Anda lebih banyak dalam penelitian. Jawaban saya sebagian besar berasal dari pengalaman saya mengembangkan solusi untuk menjual. Tetapi saya yakin, ada beberapa kesamaan antara pekerjaan saya dan pekerjaan Anda karena kami berdua melakukan pemrograman.
Kim Stacks

17

Beberapa gelas bir akan membantu saya bekerja lebih baik dan lebih lama.


11
Tunggu ... maksudmu bukan? ( xkcd.com/323 )
Craige

4
@Craige: setelah 21 tahun pengalaman dalam minum dan 20 tahun pengalaman sebagai insinyur perangkat lunak profesional, saya masih mengerjakan bagian kalibrasi.
Adam Crossland

4
@ Mad, kamu butuh setahun minum untuk menjadi seorang insinyur?

17
Pengodean sambil minum bir membantu Anda membuat jejaring sosial yang sangat populer yang akan bernilai miliaran dalam beberapa tahun. Memang benar, saya melihat ini di film.
janosrusiczki

1
@Kitsched: Yap! Terutama jika Anda memiliki desain yang sudah ada orang lain untuk merobek.
Mason Wheeler

16

"Ya, aku bisa memperbaiki spaghetti 2000 baris yang berantakan ini dalam satu hari ..."


13
Atau: "orang baru [yang sama sekali tidak tahu tentang perangkat lunak atau struktur kodenya] tidak melakukan apa-apa, ia dapat memperbaikinya". Poin bonus ketika pria itu belum pernah menggunakan bahasa di mana kode ditulis.
wildpeaks

16

"Aku bisa bertahan tanpa tes untuk itu. Terlalu sulit untuk menguji."

dan itu saudara jahat,

"Aku harus melakukan tes untuk itu, tidak peduli seberapa keras tes itu untuk menulis atau mengerti."


2
Jika ujian sulit untuk ditulis, Anda mungkin tidak memprogramnya dengan benar :)
Merlyn Morgan-Graham

2
@Erylyn Morgan-Graham, cukup benar. Tetapi ada beberapa area, seperti konkurensi, yang jelas sulit untuk diuji.
Wayne Conrad

1
@Merlyn: Jika Anda menemukan diri Anda sedang menulis sebuah simulator instruksi sehingga Anda dapat memaksakan pergantian konteks di tempat yang tepat, maka Anda mungkin sudah melangkah terlalu jauh dalam pengujian concurrency Anda. :)
Zan Lynx

1
@ Zan: Saya setuju - pada titik yang diperlukan, saya akan mendorong kembali pada devs dan mencoba untuk membuat mereka memperbaiki kode mereka dan biarkan saya memasukkan tiruan. Saya bekerja melawan bahasa tingkat tinggi di mana kita melihat Big-O, mengoptimalkan kemacetan, perlu memikirkan concurrency sebagian besar untuk integritas data daripada kecepatan mentah, dan mengirim (dan seringkali tidak ada satu pun dari itu karena itu hanya cukup cepat dari kotak).
Merlyn Morgan-Graham

15

Penundaan dan estimasi tugas optimis adalah dosa terbesar saya.

Peregangan, push-up atau pull-up (atau latihan fisik lainnya) untuk yang pertama dan suasana pesimis sebelum memberikan estimasi untuk yang kedua.


Klarifikasi ... Dengan, "estimasi tugas optimis" yang Anda maksud 'sindrom mudah sial' kan? :)
Evan Plaice

@Evan Plaice - tepatnya. Seperti "oh, ini sangat sepele" dan kemudian googling setiap huruf kode Anda setelah Anda mulai coding aktual.
Nikita Barsukov

13

"Jauh lebih mudah untuk menerapkan kembali fungsi dari awal daripada memahami kode yang ada."


2
Ya, c2.com/cgi/wiki?RewriteCodeFromScratch mengklaim bahwa ini adalah salah satu dari "Hal yang Seharusnya Tidak Pernah Anda Lakukan".
David Cary

Bekerja dengan open source membantu kecenderungan ini. Saya pribadi memandangi tambalan sebelum juling, kemudian melanjutkan dan menulis implementasi saya sendiri hanya untuk menyadari bahwa itu hampir identik dengan tambalan (bahkan setelah meningkatkan / refactoring kode saya). Lucu juga cara kerjanya.
Evan Plaice

10

Salah satu godaan berbahaya yang sangat besar yang diderita oleh proyek yang sedang saya jalani adalah 'Inner Platform Effect'. Ini adalah pendekatan yang Arsitek, yang sekarang telah lama pergi, telah menetapkan dalam kebijaksanaan tak terbatas mereka yang telah menciptakan proyek yang menghasilkan sekitar 20 juta dolar per tahun tetapi biaya 60 juta untuk memperbarui dan memelihara (angka kasar jelas tetapi ini besarnya masalah).


10

NIH - Tidak Diciptakan Di Sini

Saya sangat kesulitan memberikan solusi pihak ketiga kesempatan yang adil. Setiap orang harus secara alami skeptis terhadap solusi pihak ketiga yang tidak dibuat khusus untuk mereka, tetapi saya kesulitan 100% objektif tentang hal itu.

Penghematan waktu bisa begitu besar bahwa bahkan jika 9 kali dari 10 solusi pihak ketiga harus dihindari, saya harus cukup obyektif untuk mewujudkan salah satu yang akan bekerja.


1
Saya mengerti maksud Anda dan harus terus hidup dengannya. Saya tepat di pendapat yang berlawanan kadang-kadang ke titik di mana itu akan layak jawaban tepat di sebelah Anda. Namun saya sulit percaya bahwa saya bisa melakukan yang lebih baik dalam satu minggu daripada sekelompok ahli tentang masalah yang telah terjadi selama bertahun-tahun. Tentu saja Anda harus memastikan bahwa orang-orang di belakang mengatakan pihak ketiga memang ahli. Investigasi yang baik pada lingkungan sekitar komponen sangat membantu memilih dengan benar antara mengadopsi atau coding.
Newtopian

1
@Newtopian cara "benar" jelas ada di suatu tempat di tengah. Masalah saya dengan perpustakaan pihak ketiga bukanlah apakah saya bisa melakukan yang lebih baik daripada tim ahli dengan waktu berbulan-bulan atau berminggu-minggu, tetapi saya jarang , mungkin tidak pernah menemukan perpustakaan yang persis seperti yang kita butuhkan. Selalu ada beradaptasi untuk dilakukan, dan kemudian saya sering menemukan diri dan orang lain menghabiskan banyak waktu gulat dengan itu seperti menulis sebuah solusi yang adalah apa yang kita butuhkan.
Nicole

Saya sendiri yang berasal dari ujung yang berlawanan dari spektrum itu hanya ingin tahu bagaimana Anda berhasil mencoba dan mencapai ini "hanya tengah" jika sama sekali. Juga ingin tahu tentang apa yang membuat Anda tidak ingin menggunakan pihak ketiga dalam mencoba memahami apa yang membuat saya berlebihan menggunakannya karena saya yakin keduanya sama-sama berbahaya bagi produktivitas.
Newtopian

@Newtopian, apakah penjelasan saya di atas masuk akal mengapa? Upaya saya untuk mencapai tengah adalah sederhana untuk menjadi lebih objektif ketika mengevaluasi dan mencari solusi pihak ketiga.
Nicole

9

Merancang, mengkode dan atau menguji unit terhadap "data sampel" yang disediakan alih-alih menganalisis salinan database aktual pelanggan. Tenggat waktu singkat dan mereka terus mengatakan itu datang tetapi tidak pernah terjadi. Ketika dikerahkan, ledakan itu spektakuler. Sungguh, siapa yang akan mengharapkan pelanggan untuk memiliki 3 pelanggan induk.

Saya tidak akan pernah lagi memulai proyek sampai saya memiliki salinan data nyata .


Jika belum ada produk, apakah akan ada data untuk disalin?
Svish

Jika tidak ada data, selalu ada kertas. Catatan perusahaan juga akan membantu di sini.
burnt_hand

9

The Ada harus menjadi sebuah perpustakaan yang melakukan itu di suatu tempat sindrom.

terkait erat dengan

The Fetish Plugin


2
Sepertinya saya selalu dapat menemukan perpustakaan yang "melakukannya" Masalah saya sering membuat mereka bekerja sesuai yang diiklankan. :(
Ben L

Mudah untuk menemukan perpustakaan - Sulit untuk menemukan perpustakaan yang memiliki tes unit yang baik built in
burnt_hand

8

Perfeksionisme membunuh; mungkin alasan terbesar proyek tidak berhasil.


Saya kira mungkin saja ini benar, tetapi saya belum pernah mengerjakan proyek yang gagal, atau bahkan terlambat, karena alasan ini.
PeterAllenWebb

Tergantung bagaimana Anda mendefinisikan kesempurnaan dan level apa yang Anda tuju.
Svish


7

Menulis ulang alih-alih refactoring.


Setuju. Jika Anda bersedia berkomitmen untuk jumlah upaya yang diperlukan untuk menulis ulang, hampir SELALU lebih baik untuk refactor. Masih akan memakan waktu lebih lama dari yang Anda duga, tetapi Anda melakukan refactoring secara bertahap, bukan? Anda bisa berhenti sebelum "sempurna".
PeterAllenWebb

1
sebagai akibat wajar .... menulis lagi di tempat lain alih-alih anjak piutang. Basis kode kami memiliki begitu banyak implementasi yang berbeda untuk hal yang sama sehingga tidak mungkin mendapatkan konsistensi apa pun.
Newtopian

6

Berpikir harus ada cara yang lebih baik untuk melakukan ini. Saya tidak akan puas dengan sesuatu yang mungkin "cukup baik." Saya mengambil tidak kurang dari kesempurnaan! Biasanya ini dihindari dengan berbicara kepada orang lain yang mungkin memiliki perspektif berbeda tentang suatu masalah atau melihat solusi dari sudut yang berbeda.


5

Mengotomasi semuanya sampai pada titik lebih banyak waktu dihabiskan untuk memelihara alat-alat daripada pada pekerjaan yang sebenarnya.

Solusi: seperti halnya dengan optimasi kode, pertama-tama temukan hambatan produktivitas dan hanya setelah ditemukan, obati mereka dengan beberapa otomatisasi yang baik .


Saya setuju dengan prinsip ini, tetapi saya belum pernah melihat otomatisasi yang berlebihan dalam praktiknya. Meski begitu, itu bisa saja menjadi pengalaman saya .
PeterAllenWebb

4

Apa iblis pemrograman Anda?

Terlepas dari apa yang beberapa orang lain sebutkan.

Prioritas : Mengabaikan pekerjaan prioritas tinggi sehubungan dengan proyek dan mengerjakan hal-hal lain dalam proyek terlebih dahulu karena, mereka lebih menarik!

Bagaimana Anda menghindarinya?

Dengan sedikit lebih disiplin diri. Serius, disiplin diri dan motivasi diri untuk melakukan hal yang benar membantu menghindari sebagian besar "setan" ini.


3

Kami belum mendapatkan persetujuan dari klien tetapi tenggat waktunya sudah mendekati, jadi inilah beberapa persiapan awal sehingga Anda dapat memulai ...

Kemudian, setelah Anda selesai membangun proyek agar sesuai dengan perusahaan ...

Oh, inilah revisi klien, mereka hanya ingin mengubah beberapa hal kecil *

(* fungsi utama sangat berbeda)

Kemudian Anda tetap melakukan refactoring kode asli Anda, berdasarkan pada model asli yang cacat alih-alih baru mulai dari awal karena Anda berada di bawah tekanan tenggat waktu singkat dan menganggap bahwa itu adalah revisi terakhir.

Saya mendapatkan bit dengan yang ini sepanjang waktu. Sulit untuk dihindari sebagai pengembang web. Saran terbaik saya adalah mendorong lebih banyak waktu sehingga Anda dapat membuat perubahan dengan cara yang benar.


2
Ambil kebijakan di mana Anda tidak memulai pengembangan sampai Anda memiliki tanda tangan klien.
Ben L

1
@ Ben: Kalau saja itu di bawah kendali kami!
sevenseacat
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.