Apakah Anda menulis kode yang buruk ketika di bawah tekanan? [Tutup]


14

Ketika Anda berada di bawah tekanan, tenggat waktu semakin dekat, dan seorang manajer menarik leher Anda, apakah Anda mulai menulis kode yang buruk? Apakah TDD dan praktik terbaik tergelincir di pinggir jalan untuk menyelesaikan sesuatu? Apa yang Anda lakukan dalam situasi seperti itu? Apa pengalamanmu?


Biarkan saya menantang Anda dengan satu cara besar: beberapa inovasi terbesar dan terbaik yang saya hasilkan merupakan produk kebutuhan mendesak dan mendesak. Terkadang panasnya pertempuran membawa fokus yang tajam sehingga berhari-hari pontifikasi dan keahlian tidak menginspirasi.
user1172763

Jawaban:


31

Singkatnya, ya. Siapa pun yang memberi tahu Anda sebaliknya mungkin, paling tidak, salah.

Namun, kuncinya adalah membangun pengalaman Anda untuk menulis kode yang tidak terlalu buruk. Tahan godaan untuk memasukkan sesuatu untuk membuatnya "hanya berfungsi" jika memungkinkan, karena itu tidak akan berhasil. Anda masih harus mengikuti semacam proses (baik itu milik Anda sendiri, atau perusahaan Anda, atau beberapa campurannya).

Pengalaman mengatakan kepada saya bahwa jauh lebih baik untuk ( terkesiap ) melewati jadwal beberapa hari untuk mencegah perbaikan selama satu minggu, terutama ketika "di bawah tekanan" berarti rilis yang dipercepat untuk produksi. Jika Anda terburu-buru untuk melepaskan kode, penguji mungkin akan terburu-buru untuk menggosoknya juga.


saya akan memberikan plus 10 untuk posting ini, katanya dengan sangat baik
maz3tt

16

Jika tim dalam krisis maka ada sesuatu yang dilakukan salah.

Tenggat waktu yang hilang adalah tanda perencanaan dan estimasi yang buruk. Mengakui bahwa tenggat waktu akan terlewatkan dan menyelesaikan masalah. Terkadang Anda tidak memiliki kendali atas perencanaan atau estimasi. Identifikasi siapa yang melakukannya dan pastikan bahwa mereka tahu ini dilakukan karena kesalahan.

Dalam situasi itu, tenggat waktu tidak dapat dihilangkan. Anda mengeluarkan minuman yang sangat berkafein dan memburunya. Identifikasi apa pun yang dapat Anda korbankan dan hentikan itu. Ambil apa yang tersisa dan implementasikan secepat mungkin. Ini akan menyebabkan masalah seperti ketidakstabilan, kesalahan aneh, praktik pengkodean yang tidak efisien, perbaikan band-aid, dan segala macam kengerian lainnya. Ini belum tentu kode yang buruk , tetapi itu tidak ideal .

Solusi 50% -baik yang orang benar-benar punya memecahkan lebih banyak masalah dan bertahan lebih lama dari solusi 99% yang tidak dimiliki siapa pun karena itu ada di lab Anda tempat Anda terus-menerus memoles benda sialan itu. Pengiriman adalah fitur .

Dari Joel pada Perangkat Lunak The Duct Tape Programmer .

Kode yang tidak ideal dapat ditangani jika ditangani . Kode yang belum ditangani akan menumpuk dan pada gilirannya membuat perubahan tambahan lebih sulit, jika bukan tidak mungkin. Itu bisa sampai ke titik di mana aplikasi tersebut saling menempel sehingga penambahan hanya bisa dilakukan oleh programmer yang paling hati-hati dengan biaya waktu yang selangit. Sementara pengiriman adalah fitur, jadi itu rawatan.


1
Satu-satunya hal yang akan saya ubah adalah kata "Anda" di poin utama Anda. Saya berpendapat bahwa untuk setiap anggota di tim Anda ada faktor multiplikasi hal yang bisa salah, dan untuk setiap ketergantungan luar, ada beberapa faktor eksponensial hal yang bisa salah. Atau sebaliknya. ;)
Wonko the Sane

2
@ysolik: Lihat penulisan ulang. Mungkin bukan kesalahan Anda bahwa perencanaan atau estimasi telah FUBAR.
Josh K

2
@ysolik: Anda menulis kode yang kurang ideal untuk memenuhi tenggat waktu dan berdoa Anda akan mendapat kesempatan untuk memperbaikinya nanti. Dengan perencanaan yang tepat ini tidak pernah terjadi.
Josh K

2
Never say never ... :)
Wonko the Sane

3
@ Wonko: Benar, dengan perencanaan yang tepat ini jarang terjadi.
Josh K

7

Saya penggemar berat pengerjaan perangkat lunak - menulis kode bersih sebaik mungkin, dll, tetapi kadang-kadang saya harus terburu-buru pada saat-saat di mana waktu singkat dan tenggat waktu semakin dekat. Saya benar-benar berusaha untuk tidak melakukan ini semampu saya, tetapi kadang-kadang Anda tidak dapat menghindarinya.

Beberapa orang akan berkata "Yah, itu hidup, kamu harus mengirim", tetapi saya benar-benar tidak setuju dengan sikap ini.

Saat menulis kode tergesa-gesa, Anda mungkin mendapatkan perangkat lunak keluar tepat waktu, tetapi apa yang terjadi ketika, selama beberapa hari berikutnya, Anda akhirnya mendapatkan panggilan dukungan yang berkaitan dengan bug dalam perangkat lunak (bug ini hidup dalam bagian yang sama kode Anda bergegas untuk menyelesaikan). Atau Anda mendapatkan klien yang marah memanggil Anda bertanya mengapa modul pelaporan mereka tidak lagi berfungsi, meskipun Anda berjanji itu akan baik-baik saja pada hari rilis?

Semuanya mengatakan "Anda harus mengirim" , tetapi ada perbedaan antara terlihat efisien dan terlihat seperti pekerja yang ceroboh.


5

Iya. Tapi itu selalu kembali menghantuiku nanti.



1

Saya tidak percaya saya secara pribadi menulis kode yang jauh lebih buruk, tetapi saya memberikan produk yang lebih buruk.

Ketika menghadapi tenggat waktu yang sewenang-wenang dan tidak mungkin, kami berhemat pada proses pengembangan. Kami melakukan lebih banyak ulasan kode yang dangkal (atau melompati semuanya). Kami menguji lebih sedikit, mem-bypass pengujian unit terperinci untuk tes integrasi tipe spot-check, kemudian mencoba menghitung uji integrasi sebagai kualifikasi formal. Kami cenderung mengabaikan anomali selama pengujian jika mereka tidak secara langsung terkait dengan kriteria lulus-gagal. Kami melewatkan pembaruan dokumentasi, jangan mengecek catatan rilis, lupa menggosok daftar kiriman untuk file yang tidak lagi diperlukan.

Kode sumber yang Anda tulis selama krisis mungkin berkualitas tinggi, tetapi hampir pasti akan dikirim sebagai bagian dari produk yang jelek.


0

Tergantung.

Apakah tekanan karena tidak ada cara semuanya bisa dilakukan dan karena fitur baru utama sedang ditambahkan beberapa jam sebelum rilis?

Kode buruk muncul!

Tetapi jika itu karena jadwalnya benar-benar sangat ketat tetapi rencana keseluruhan padat dan saya hanya harus bekerja lebih keras dari biasanya dan tetap fokus terus-menerus sambil mengutak-atik beberapa fitur mendengar dan di sana ... Kemudian saya menghasilkan kode yang jauh lebih baik daripada jika jadwal memungkinkan banyak waktu. Bahkan jika itu berarti saya tidak mendapatkan semua tes unit tertulis tetapi mencakup bagian utama dari kode.


Oooh - komentar yang bagus, kecuali kalimat terakhir yang membuatku sedikit takut.
Wonko the Sane

Baik. Itu tidak berarti mereka tidak akan pernah ditulis. Itu menakutkan tetapi saya pikir itu membantu saya tetap fokus. Dan ada unit test, tidak hanya cakupan 100%. Lebih seperti 66%.
ElGringoGrande

Satu-satunya masalah adalah bahwa 34% yang tidak tercakup adalah kode baru yang Anda masukkan dengan tergesa-gesa, dan bukan kode yang sudah ada yang tidak mungkin (semua) memecah perubahan Anda. Bukan untuk mengatakan bahwa kita belum semua melakukannya, hanya itu proposisi yang menakutkan.
Wonko the Sane

0

Saya kenal seseorang yang tidak pernah menulis kode buruk di bawah tekanan. Dia juga memiliki beberapa kacang ajaib yang mungkin menarik bagi Anda.

Semua orang kadang-kadang menulis kode yang buruk dan tenggat waktu yang menjulang adalah alasan biasa, triknya adalah menghindari masuk ke situasi itu di tempat pertama (dan itu juga tidak mudah).

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.