it-swarm-id.com

Godaan berbahaya dalam pemrograman

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 Anda sendiri untuk mempercayainya, dan setelah seminggu Anda menyadari bahwa Anda belum menyelesaikan apa pun masalah nyata tetapi malah menciptakan 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 dibutuhkan napas dalam-dalam untuk tidak menyentuhnya ketika saya tidak memiliki tes untuk membuktikan bahwa 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?

97
Dan

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

Memperbarui:

Lihat " Sin # 1 - Generalisasi Prematur " untuk deskripsi mendalam.

67
John Bode

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

197
user18041

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

105
user281377

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

103
davidhaskins
  1. Refactoring bagian dari kode beberapa hari sebelum rilis.
  2. Internet: Gangguan terbesar dari semua.
  3. Teknologi bar: Tidak dapat melepaskan tangan saya 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.
74
Amir Rezaei

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

Setan saya berulang: Optimasi prematur dan rekayasa ulang.

Dan saya masih tidak bisa menghindarinya 100% ...

48
Tomas Narros

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 adalah mungkin sudah terlalu rendah!

46
Nicole

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.

33
biziclop

Saya hanya akan istirahat dan melihat stackoverflow.com;)

32
Richard Miskin

Godaan terburuk:

Oh, well .. Saya kira satu trik/hack/fix yang kotor tidak akan sakit.

Coba tebak, itu menyakitkan. :)

goto

31
Goran Jovic
25
Dan

Fitur Merayap

Buat rencana, patuhi, dan gunakan. Dan lal 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 menempatkannya fitur retro jelek di tempat pertama! Tidak bisakah Anda mengatakan bahwa sisa desain membuatnya sia-sia?

23
Satanicpuppy
  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 oleh 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 pemrograman 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 "sangat merepotkan". Saya hanya bisa screenshot halaman pesaing untuk maket dan menggambar sitemap "nanti" secara gratis yang tidak pernah. Dan kemudian langsung masuk ke pemrograman halaman pertama yang saya bayangkan dalam pikiran saya.

Pengakuan: Saya secara pribadi telah 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.

[~ # ~] sunting [~ # ~] Tidak menyadari pertanyaan mengharuskan kita 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 1 hal.

Baca tentang Twitter, Groupon , dll tentang cara mereka menghapus semua hal menjadi hanya 1 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 untuk sebagian besar pengembang perangkat lunak.)" Di tautan ini

2) Kompetisi memiliki fitur ini. Jadi ini fitur yang harus ada

Lihat solusi 1

3) Kompetisi TIDAK memiliki fitur ini. Jadi ini adalah fitur pembeda

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 IS 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. Ingat 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 mengkode karena Anda ingin "lakukan dengan benar"

Berolah raga. Anda akan merasakan Rush 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 tindak lanjut secara agresif. Tindak lanjuti semua janji untuk diri sendiri dan orang lain.

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

Pergi menghabiskan USD75 pada edisi desktop balsamiq mockups. Saya tahu ini karena saya membelinya 3 minggu yang lalu. Itu telah 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

20
Kim Stacks

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

17
Adam Crossland

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

16
Hila

"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."

16
Wayne Conrad

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.

15
Nikita Barsukov

"Ini jauh ' lebih mudah ' untuk menerapkan kembali fungsi dari awal daripada memahami kode yang ada."

13
k3b

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 adalah besarnya masalah).

10
AlexC

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 sangat besar bahkan jika 9 kali dari 10 solusi pihak ketiga harus dihindari, saya harus cukup objektif untuk mewujudkan satu Itu akan bekerja.

10
Nicole

The Pasti ada perpustakaan yang melakukannya di suatu tempat sindrom.

terkait erat dengan

The Fetish Plugin

9
Newtopian

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 real.

9
dwidel

Perfeksionisme membunuh; mungkin alasan terbesar proyek tidak berhasil.

8
Naftuli Kay

Menulis ulang alih-alih refactoring.

7
Dave O.

Yah, kadang-kadang pemrograman mendorong saya ke botol.

7
mipadi

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 dengan orang lain yang mungkin memiliki perspektif berbeda tentang suatu masalah atau melihat solusi dari sudut yang berbeda.

6
JB King

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 kemacetan produktivitas dan hanya setelah ditemukan, obati mereka dengan beberapa otomatisasi yang baik.

5
Dan

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.

4
Mahesh Velaga

Otak saya lelah dari proyek ini. Saya hanya akan mengambil istirahat sejenak pada proyek sampingan pendek ini untuk meremajakannya.

3
emragins

"There must be a better solution to this."

Dan Anda akhirnya berpikir dan berpikir, dan membiarkan pikiran Anda melayang ke tanah yang jauh sampai Anda menyadari bahwa Anda sudah terlalu lama. Itu harus baik-baik saja, tetapi tidak ketika Anda memiliki tenggat waktu.

3
gladysbixly

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 sama sekali 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 pendek 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 Dorong untuk lebih banyak waktu sehingga Anda dapat membuat perubahan dengan cara yang benar.

3
travis

Menulis kode baru setelah tanggal pembekuan kode.

Tanggal pembekuan kode harus ditetapkan di atas batu. Setiap kode baru yang ditulis setelah itu harus dipindahkan ke rilis yang akan datang, karena mungkin memerlukan semua jenis pengujian regresi.

3
Mag20

Untuk menjawab pertanyaan tentang cara menghindarinya: Biasakan diri Anda dengan Anti-Pola sehingga Anda dapat memanggilnya saat Anda mengenalinya.

3
Lee Kowalkowski

Kepandaian. Tentu saja tidak selalu. Beberapa kepintaran dan keringkasan akan membuat kode Anda terlihat sangat bagus dan dapat dipelihara. Tetapi hanya karena Anda bisa melakukannya

x=foo?true:bar?biz,FooBar(true)?!foo:baz,FooBar(false):baz;

alih-alih beberapa baris pernyataan if, tidak berarti Anda harus melakukannya.

Btw, ya saya tahu ada sedikit redundansi dalam contoh saya ... Jika Anda bahkan menangkapnya sendiri :)

3
Earlz

Semua yang lain ditambah fitur creep: "Akan sangat keren jika melakukan ini, dan saya tahu pelanggan akan menyukainya dan akan memasukkannya ke dalam spesifikasi jika mereka memikirkannya". Saya mencoba untuk menghindari ini dengan menanyakan di mana dalam spesifikasi nyata persyaratan ada untuk fitur keren ini.

Kemudian lagi, saya tidak sering mendapatkan spesifikasi tertulis.

2
PSU

"Ini hanya pilot, jadi tidak perlu membuatnya mudah untuk mempertahankan atau memperluas".

Dalam pengalaman saya, lebih umum untuk melihat pilot memasuki produksi dan produk yang seharusnya menjadi pilot untuk dihapus daripada untuk pilot untuk dihapus dan produk aktual dikembangkan ke status siap produksi.

2
jwenting

Menghabiskan terlalu lama mengutak-atik editor. Mencoba menemukan skema font dan warna terbaik untuk pemrograman.

2
dheerosaur

"Saya telah diberi fitur yang berinteraksi dengan [perangkat lunak/misalnya: sharepoint]. Saya mungkin harus tahu semua yang perlu diketahui tentang perangkat lunak itu."

Kemudian Anda menghabiskan berminggu-minggu meneliti produk itu, ketika fitur itu bisa ditulis dan diuji dalam satu atau dua hari. Rasa lapar akan pengetahuan memiliki perut yang gelap. rawr

2
Steven Evers

"Aku akan berkomentar/mendokumentasikan ini nanti"

itu tidak pernah terjadi, penulis melanjutkan, dan kemudian Anda mengetahui bahwa mereka tidak mengomentari kode mereka ketika pekerjaan telah ditugaskan kepada Anda.

2
sunwukung

Untuk mulai menyerang proyek baru, tanpa memahaminya, dan saya biasanya menghindari ini dengan meneliti sedikit tentang domain proyek sebelum saya benar-benar mulai bekerja dengannya, hanya untuk memiliki titik awal yang baik, dan untuk membuktikan proyek itu lebih kompleks daripada Saya awalnya melalui itu.

Saya juga punya masalah yang saya suka bergerak dengan tombol, mereka sangat keren !! Tapi mungkin itu karena saya sedang melakukan sistem multimedia dan desain antarmuka pengguna ... Jadi bagi saya solusi untuk masalah ini, adalah dengan memasukkannya ke dalam kurikulum saya dan mempelajari sesuatu tentangnya, sehingga saya memiliki alasan yang valid jika ada yang melihat saya banyak bermain dengan UI. (Dan itu termasuk menempatkan latar belakang hijau, teks oranye, dan ikon dengan banyak warna kuning.)

1
Coyote21

Daftar yang sangat lengkap: anti-pola .

1
vartec
/**
* Calculates the return value for humptyDumpty
*
* return int modifiedHumptyDumpty
*/
function awesomeWayToCalculateSomething(int humptyDumpty) {
.. 
}

TODO: Saya perlu mendokumentasikan ini dengan benar.

Will _never_ terjadi

1

Menggunakan fitur bahasa, idiom, atau pola desain bukan karena itu adalah solusi terbaik untuk masalah tersebut, tetapi murni untuk menggunakannya.

1
Dima

Saya pikir ada di kepala saya bahwa enum jauh lebih berguna daripada yang sebenarnya di Jawa. Saya cenderung mencoba dan melakukan terlalu banyak dengan mereka, dan kemudian macet karena mereka tidak benar-benar mendukung polimorfisme.

1
MattLBeck

lebih dari komitmen diri untuk menghindari pengembangan in-house, 90% dari roda tidak lebih baik daripada menciptakan satu.

1

Menggunakan kerangka kerja sementara tidak sepenuhnya memahaminya. Tapi sekali lagi. suatu kerangka kerja hanya sepenuhnya dipahami oleh pembuatnya (sebagian besar kasus). Saya tidak punya solusi nyata untuk item itu tetapi mencoba untuk memahami sebanyak mungkin dari suatu kerangka kerja.

1
user18483

Memperbaiki bug yang mengganggu Anda karena "sangat sederhana", tetapi tidak pernah memberi tahu QC dan/atau pelanggan.

Perbaikan ini selalu menghentikan produksi.

1
Scott McIntyre

Seseorang mengatakan generalisasi prematur, tetapi spesialisasi prematur bisa sama buruknya. Dengan generalisasi prematur, Anda bisa mendapatkan perangkat lunak yang berfungsi untuk 50% kasus, tetapi spesialisasi prematur dapat bekerja untuk 5%, atau tidak sama sekali. Pada akhirnya, manajemen lebih suka memiliki 50% dari 5%.

1
MPelletier

Melakukan pekerjaan ekstra yang tak terhitung jumlahnya untuk perusahaan di waktu luang saya hanya untuk mengetahui "itu bukan arah yang mereka cari."

1
user13280

Apa iblis pemrograman Anda,

Semua yang telah disebutkan, terutama keinginan untuk refactor seperti orang gila.

dan bagaimana Anda menghindarinya?

Sebelum memulai pengeditan nontrivial, lepaskan tangan saya dari keyboard selama 5 detik dan dengan cepat timbang kemungkinan hasil dari perubahan dan biarkan. Kemudian lagi sebelum melakukan, pertimbangkan konsekuensi yang sama selama sekitar satu menit.

1
Cheezmeister

Untuk menemukan sofa yang nyaman untuk bekerja atau berbaring di tempat tidur.

1
kiewic

Menjadi "Sempurna"

Meskipun menghindari melakukan yang benar pertama kali adalah masalah, itu tidak seburuk fokus abadi pada kesempurnaan. Selesaikan saja, tidak ada yang namanya sempurna, dan jika ada, itu murni temporal, atau sudah dilakukan dan tidak sepadan dengan waktu untuk melakukannya lagi.

0
blunders