Mengisap Kurang Setiap Tahun? [Tutup]


10

Mengisap Kurang Setiap Tahun -Jeff Atwood

Saya telah menemukan artikel yang berwawasan luas ini. Mengutip langsung dari pos

Saya sering berpikir bahwa mengisap lebih sedikit setiap tahun adalah cara programmer yang rendah hati meningkatkan. Anda seharusnya tidak puas dengan kode yang Anda tulis setahun yang lalu. Jika tidak, itu berarti A) Anda belum belajar apa pun dalam setahun, B) kode Anda tidak dapat ditingkatkan, atau C) Anda tidak pernah mengunjungi kembali kode lama. Semua ini adalah ciuman kematian bagi pengembang perangkat lunak.

  1. Seberapa sering ini terjadi atau tidak terjadi pada Anda?
  2. Berapa lama sebelum Anda melihat peningkatan aktual dalam pengkodean Anda? bulan tahun?
  3. Apakah Anda pernah mengunjungi kembali kode lama Anda ?
  4. Seberapa sering kode lama Anda mengganggu Anda? atau seberapa sering Anda harus berurusan dengan utang teknis Anda.

Jelas sangat menyakitkan untuk memperbaiki bug lama dan kode kotor yang mungkin telah kita lakukan untuk dengan cepat memenuhi tenggat waktu dan perbaikan cepat itu, beberapa kasus kita mungkin harus menulis ulang sebagian besar aplikasi / kode. Tidak ada argumen tentang itu.

Beberapa pengembang saya temui berpendapat bahwa mereka sudah pada tahap berevolusi di mana pengkodean mereka tidak perlu perbaikan atau tidak bisa diperbaiki lagi.

  • Apakah ini terjadi?
  • Jika demikian, berapa tahun pengkodean pada bahasa tertentu, apakah orang mengharapkan ini terjadi?

Terkait:

Pernah melihat kembali beberapa kode lama dan menyeringai kesakitan?

Momen Star Wars dalam Kode "Luke! Saya kode Anda!" "Tidak! Tidak mungkin! Tidak mungkin!"


3
Orang-orang IMHO yang berpikir mereka sempurna dan berpikir mereka tidak perlu meningkatkan yang benar. Mereka tidak bisa membaik. Setiap orang yang berakal tahu bahwa mereka tidak akan pernah sempurna, selalu ada ruang untuk peningkatan / pembelajaran hal-hal baru. Saya akan ngeri jika saya tahu bahwa saya tidak dapat memperbaiki diri - Saya tidak ingin berpikir saya memiliki langit-langit.
MAK

Saya suka kembali ke proyek yang saya buat ketika saya masih sangat baru, dan melihat kode yang sangat sulit bagi saya untuk menulis. Banyak kali kode ini sangat sederhana. Itu membuatku tertawa.
The Muffin Man

Jawaban:


6
  > Sucking Less Every Year ?

Tidak ada tapi Mengisap berbeda Setiap Tahun :-)

Setelah ulasan pertama saya bertahun-tahun yang lalu saya menderita karena tidak adanya konvensi penamaan.

Kemudian saya menderita bahwa kode saya (tidak perlu) diimplementasikan untuk menjadi generik mungkin tetapi itu membuat kode sulit dipahami dan dipelihara.

Kemudian saya belajar pengembangan testdriven, InversionOfControl, apa dot generics mana dan banyak lagi.

kesimpulan

Penderitaan kebiasaan buruk lama berkurang, tetapi saya mendapat lebih banyak kompensasi dari penderitaan baru karena saya belajar lebih banyak.


19

Menariknya, semua programmer "rockstar" yang pernah saya ajak bekerja sangat rendah hati, ingin belajar, dan siap mengakui bahwa mereka tidak tahu segalanya. Heck, banyak yang benar-benar mencela diri sendiri, setidaknya di saat-saat yang menyenangkan.

Saya tidak berpikir saya pernah bertemu dengan seorang pengembang yang berpikir bahwa pengkodean mereka "tidak dapat diperbaiki", tetapi ada sesuatu yang memberitahu saya bahwa orang-orang ini akan berada sejauh yang Anda bisa dapatkan dari rockstar - dengan kata sederhana.


2
Saya setuju 100%. Mereka adalah pembunuh bayaran! Oh dan nama pengguna yang luar biasa, xkcd? :)
jamiebarrow

@ jamiebarrow: Tentu saja. :)
Bobby Tables

kasus kegagalan lain adalah orang yang mengatakan "semua perangkat lunak buruk, semua peretasannya, ide Anda untuk perbaikan tidak masalah". Agak menyedihkan untuk bekerja dengan tipe-tipe itu.
Doug T.

13

Poin-poin berikut ini bukan saran tetapi catatan pribadi:

  • menggunakan lebih sedikit variabel global
  • jangan gunakan singkatan untuk variabel atau nama fungsi
  • tulis [beberapa] kode pengujian
  • jangan menilai kode sebagai lambat (atau cepat) tanpa pembandingan
  • belajar cara memuat menguji aplikasi
  • jangan memperbaikinya, jika tidak rusak
  • gunakan alat manajemen kode sumber (git / hg)
  • refactoring itu keren, jangan meremehkan biaya pengujian yang dibawanya
  • keamanannya sulit, jadi waspadalah terhadap hal ini sedini mungkin
  • menambal beberapa bug proyek sumber terbuka
  • blog sesuatu yang baru
  • Kegunaan mungkin bukan permintaan fitur tetapi itu penting

Saya tidak belajar semuanya dalam setahun, semuanya membutuhkan waktu ...


Saya suka bagaimana Anda menyebutkan "tulis [beberapa] kode pengujian". Saya percaya tidak ada orang yang mencapai kesempurnaan di mana mereka tidak akan pernah membuat kesalahan sebagai programmer - kita semua manusia, dan kita membuat kesalahan dari waktu ke waktu. Tes unit dan tes integrasi dapat mengurangi kesalahan kami. Dan saya perhatikan Anda mengatakan 'beberapa' tes, yang penting, karena kadang-kadang saya terbawa ujian menulis yang tidak benar-benar berguna.
jamiebarrow

Bahkan, saya pikir di bawahnya "jangan memperbaikinya, jika tidak rusak" Saya akan menambahkan "Jika itu rusak, dan itu rumit, mereproduksi dan memperbaiki bug dengan kode uji"
jamiebarrow

2
Bisakah saya menambahkan beberapa? Jika itu API, jangan perlihatkan detail internal lebih banyak dari yang seharusnya, jika Anda menyembunyikannya, Anda bisa mengubahnya nanti. Selalu gunakan konstanta sebagai ganti angka ajaib karena lebih mudah untuk didokumentasikan dan diubah. Kekekalan sangat berguna, terutama di mana konkurensi terlibat. Bekerja pada basis kode orang lain, ini merupakan proses yang sangat berharga untuk menilai gaya pengkodean Anda sendiri ketika Anda harus membenarkannya kepada orang lain. Dapatkan spec beku (jika mungkin) karena lebih sulit untuk mencapai target yang bergerak.
Evan Plaice

Jika bekerja di lokasi atau di sekitar klien, kemas kartu tanpa otoritas dan kartu berdaya tinggi Anda. Jika mereka meminta Anda untuk mengubah sesuatu di luar spesifikasi, tarik (saya punya) kartu tanpa otoritas diikuti oleh (rujukan ke) kartu berkekuatan lebih tinggi (lebih disukai PM luar kantor yang dapat menerima permintaan). Kasus terbaik, itu akan membebaskan Anda untuk fokus pada pengembangan; kasus terburuk, ini akan mengurangi jumlah permintaan fitur drive-by. (kontroversial) Kembali lebih awal dan sering kembali, jika pengembalian dimaksudkan untuk terjadi pada akhir blok kode tidak akan ada kata kunci untuk itu. Semoga, saya terus menyusu lebih sedikit setiap tahun.
Evan Plaice

4

Seringkali orang berpikir bahwa kode yang baik tiba-tiba terjadi tetapi bagi kebanyakan dari kita hanya manusia saja kode yang baik tumbuh dalam basis kode kita. Maksud saya, sangat sulit untuk menulis perangkat lunak yang sempurna sejak awal karena persyaratan terus berubah dan kami bukan programmer yang sempurna, jadi keputusan bodoh dibuat terus-menerus dari manajer dan programmer. Lalu saya melihat setiap persyaratan mengubah peluang yang baik untuk mengubah beberapa kode lama menjadi kode yang lebih baik (dan dibayar untuk itu!) Dan membayar sedikit hutang teknis. Seperti yang mereka katakan: "biarkan repositori kode sedikit lebih baik setiap kali Anda melakukan kode". Kemudian sistem Anda akan berkembang menjadi sistem yang lebih dekat ke ideal.

Saya benar-benar tidak tahu ada programmer yang bangga dengan software-nya tapi itu bagus. Daripada berarti bahwa programmer telah belajar dalam proses itu.

Juga jika Anda membaca buku "Kode Bersih" maka Anda akan meningkatkan kode "faktor mengisap" Anda sendiri beberapa kali. : D


1
Saya tidak setuju dengan Anda pada satu titik, saya percaya beberapa kode yang bisa Anda banggakan. Ironisnya, Anda bisa membuat satu proyek berjalan dengan sangat baik, dan berbanggalah, dengan sedikit gangguan. Maka proyek selanjutnya, WTF Anda per jam tinggi ... untuk kode Anda sendiri! : D
jamiebarrow

1
Mungkin tergantung pada langkah Anda sekarang. Sekarang saya menemukan kode yang saya tulis satu tahun yang lalu dan bahkan saya merasa sulit untuk memahami beberapa nama atau tujuan dari beberapa metode. Saya juga menemukan kode yang ditemukan oleh tes dan hal-hal seperti itu. Ketika saya terus meningkatkan, hal-hal seperti itu cenderung menjadi pengecualian daripada norma dan saya mulai merasa malu pada masalah yang sebelumnya tampaknya tidak penting ...
Rafa de Castro

+1 untuk kode Bersih meskipun perbandingannya selalu dengan diri Anda.
Aditya P

4

Saya sebenarnya memiliki kedua sisi mata uang untuk ini.

Di satu sisi, Anda melihat kode lama dan Anda melihat itu penuh dengan bug dan cara rumit untuk melakukan hal-hal yang hanya dicapai dengan memanfaatkan teknik dan fitur bahasa yang Anda tidak tahu tentang itu.

Di sisi lain, Anda melihat solusi yang sangat elegan untuk suatu masalah dan Anda tidak bisa melepaskan senyum puas pada seberapa pintar Anda saat itu.

Dan kemudian Anda gulir ke bawah beberapa garis dan meringis ngeri pada kenyataan Anda menggunakan GOTO di C.


3

Hmm ... Saya sering cukup terkejut dengan betapa baiknya banyak kode lama saya.

Jika saya melakukannya hari ini, saya sering menulisnya secara berbeda, tetapi jika saya harus hidup dengan keterbatasan waktu, saya tidak yakin saya akan melakukannya. Ketika Anda dapat mengandalkan mesin biasa yang memiliki setidaknya beberapa gigs RAM, Anda dapat (dan seringkali harus) menulis kode Anda sedikit berbeda dari ketika hard drive besar adalah 100 megabyte.


3
  1. Seberapa sering ini terjadi atau tidak terjadi pada Anda?

  2. Berapa lama sebelum Anda melihat peningkatan aktual dalam pengkodean Anda? bulan tahun?

  3. Apakah Anda pernah mengunjungi kembali kode lama Anda?

  4. Seberapa sering kode lama Anda mengganggu Anda? atau seberapa sering Anda harus berurusan dengan utang teknis Anda.

  1. Setiap kali saya belajar sesuatu yang baru, semoga itu setiap hari.

  2. Jika saya bisa menerapkan apa yang telah saya pelajari, maka langsung dari saat saya menerapkannya.

  3. Ya, hanya untuk (1) Fitur baru, (2) Perbaikan bug, (3) Nostalgia, (4) Lihat bagaimana saya memecahkan sesuatu, dapat bermanfaat.

  4. Terkait dengan 1., ketika saya belajar bagaimana melakukan sesuatu yang lebih baik, saya sadar bahwa beberapa proyek lama "bisa" dilakukan dengan lebih baik. Saya membiarkan mereka. Pastikan proyek berikutnya dilakukan dengan cara yang lebih baik. Saya tidak khawatir kecuali itu bug yang sebenarnya.


3

Dalam pertanyaan lain , subjeknya adalah tentang cara mengevaluasi kualitas kode Anda sendiri. Salah satu saran saya adalah untuk meninjaunya dalam beberapa tahun, ketika pengalaman Anda jauh lebih tinggi daripada ketika kode itu ditulis. Satu kutipan jawaban saya untuk pertanyaan lain ini berkaitan langsung dengan pertanyaan Anda:

"dalam kasus saya, masa pakainya adalah satu tahun: itu berarti bahwa saya dapat memodifikasi kode yang saya tulis enam bulan lalu, tetapi jika kode itu ditulis dua tahun lalu, ia memiliki peluang kuat untuk dilempar, kemudian ditulis ulang sepenuhnya, karena itu terlalu menyebalkan. "

Jadi ya, dalam praktiknya, setiap kode yang saya tulis menjadi tak tertahankan dari sudut pandang saya dalam setahun. Dan saya tidak berbicara tentang kode yang dibuang, tetapi juga tentang kode yang saya tulis dengan kualitas, pemeliharaan dan keterbacaan dalam pikiran. Untuk saat ini, tidak ada pengecualian.

Untuk menjawab pertanyaan kedua Anda tentang umur, itu sangat bervariasi. Sepotong kode memiliki masa hidup nol detik : kode itu menyebalkan setelah Anda menulisnya, tetapi itu tidak masalah. Beberapa bagian kode yang saya tulis dapat ditanggung setelah dua tahun , tetapi membutuhkan beberapa perubahan kosmetik: sedikit refactoring, menegakkan aturan StyleCop, dll. Secara rata-rata, dalam kasus saya yang tepat, masa hidup bervariasi antara delapan bulan dan satu tahun untuk C #, dan antara dua enam bulan untuk PHP.

Apakah saya meninjau kembali kode lama saya? Ya, tentu saja, seperti setiap pengembang, kecuali jika Anda tidak peduli dengan KERING dan menemukan kembali roda Anda sendiri berulang kali. Ada juga peluang untuk meninjau dan meningkatkan kode sangat sering jika Anda memiliki basis kode umum yang Anda gunakan dalam banyak proyek . Poin lain adalah bahwa jika Anda bekerja pada proyek-proyek besar, beberapa mungkin membutuhkan waktu bertahun-tahun , jadi Anda harus meninjau kembali kode lama.

Beberapa pengembang saya temui berpendapat bahwa mereka sudah pada tahap berevolusi di mana pengkodean mereka tidak perlu perbaikan atau tidak bisa diperbaiki lagi.

Ketika seseorang mengatakan bahwa dia begitu sempurna sehingga dia tidak perlu belajar apa-apa, itu berarti dia bahkan tidak mampu memahami betapa bodohnya dia.

Bahkan jika Anda memiliki pengalaman dua puluh tahun dalam komputer / pemrograman, segala sesuatunya berubah terlalu cepat, sehingga selalu ada hal baru untuk dipelajari dan teknik baru untuk meningkatkan kode. Sebagai contoh, kode C # ditulis ketika tidak ada .NET Framework 3.0 sangat mungkin dapat dibuat lebih mudah dibaca dan lebih baik dengan hal-hal baru yang kita miliki saat ini (termasuk Linq, kontrak Kode, dll.), Dan ini, bahkan jika kode lama ditulis oleh pengembang paling pintar.


Lebih seperti jika Anda bertanya ini, Anda berisiko terlihat seperti seseorang yang tidak tahu cara menulis kode yang baik.
Aditya P

@AdityaGameProgrammer: Ada perbedaan antara buggy, kode jelek, dan kode bagus yang, setelah satu tahun atau kurang, dapat ditulis dengan cara yang lebih elegan. (1.) Tidak ada yang dapat menulis kode sempurna yang akan tetap sempurna selamanya, jadi kita harus mengakui bahwa kode kita dapat ditingkatkan seiring waktu. (2.) Kami memperoleh pengalaman dan pengetahuan dari waktu ke waktu, yang juga merupakan sumber untuk perbaikan kode lama.
Arseni Mourzenko

1

Itu terjadi cukup teratur ketika saya melihat kode dan bertanya-tanya, "Apa yang saya pikirkan ketika saya menulis ini?"

Biasanya ada peningkatan sepanjang waktu karena kadang-kadang ide baru untuk mengatur kode, menata kode atau sesuatu yang lain akan datang kepada saya dan sementara itu mungkin bukan perbaikan besar, setiap hal kecil dapat membantu yang layak dilakukan.

Tergantung pada lingkungan kerja, saya mungkin melihat kode dari beberapa tahun yang lalu ketika saya terus bekerja di basis kode yang sama dan cukup akrab dengan apa yang ada di sana dan merupakan sesuatu untuk dikelola.

Kode lama hampir selalu mengganggu saya karena biasanya saya mengubah sistem yang ada atau mengganti sistem. Dalam kedua kasus, saya harus tahu kebiasaan sistem yang ada untuk memastikan mereka ada di yang baru.

Walaupun saya yakin ada orang-orang seperti Jon Skeet yang hanya bisa memikirkan kode yang sempurna, kebanyakan orang mengatakan bahwa kode mereka tidak dapat diperbaiki mengatakan bahwa dari sudut ego yang mungkin tidak menarik. Pada saat yang sama, dalam hal menemukan peningkatan besar setiap kali itu tidak selalu menjadi masalah.


1

1. Seberapa sering ini terjadi atau tidak terjadi pada Anda?

Seberapa sering saya tidak puas dengan kode lama saya? Hampir selalu. Ada pengecualian langka di mana saya memiliki kode yang sangat saya banggakan ... tapi sekali lagi, mereka jarang. Saya telah diberitahu bahwa kode yang saya tulis beberapa tahun yang lalu adalah baik ... Saya merasa ngeri dan berpikir "Anda orang miskin yang malang karena telah melihat yang lebih buruk daripada sampah yang saya tulis."

2. Berapa lama sebelum Anda melihat peningkatan aktual dalam pengkodean Anda? bulan tahun?

Biasanya dalam beberapa tahap ... Saya benar-benar masuk ke gaya atau metodologi (ambil antarmuka yang lancar misalnya ... karena itu adalah gaya terakhir yang saya gunakan untuk basah) dan membantai semua yang saya tulis selama satu atau empat bulan . Kemudian mulai terlihat lebih baik.

3.Apakah Anda pernah mengunjungi kembali kode lama Anda?

Tidak sesering yang saya inginkan. Sebagian besar kode lama saya, dimiliki oleh majikan sebelumnya. Kode pribadi terlalu sering dicuci putih.

4. Seberapa sering kode lama Anda mengganggu Anda? atau seberapa sering Anda harus berurusan dengan utang teknis Anda.

Menjadi majikan sebelumnya memiliki sebagian besar kode lama saya, dan saya putih mencuci sebagian besar kode pribadi saya ... tidak terlalu sering sama sekali.


cuci putih = faktor ulang? apakah Anda merujuk pada kode proyek atau basis kode pribadi Anda.
Aditya P

1
@AdityaGameProgrammer: White wash = membuang semuanya dan menulis ulang dari awal. Saya sedang berbicara tentang kode pribadi saya.
Steven Evers
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.