Jika seorang pembuat kode yang lancar mengabaikan praktik-praktik yang baik, bukankah kelancarannya bekerja melawannya? [Tutup]


16

Saya sedang mengerjakan aplikasi yang cukup besar dan bermasalah - dan karena cara penulisannya (saya akan berikan Anda detail, tetapi itu melanggar aturan di sebagian besar area yang dapat Anda pikirkan), hampir tidak mungkin untuk mengembangkannya tanpa refactoring besar.

Bagian penting dari aplikasi ini ditulis oleh pekerja magang, n00bs dll .; tetapi ada juga seorang programmer di peringkat Master Developer, dan dengan segala kerendahan hati, kode yang ditinggalkannya juga meragukan, dengan cara yang berbeda mungkin tapi tetap saja.

Memang, kodenya cenderung menyelesaikan pekerjaan - sebagian besar waktu - tetapi biasanya samar, menciptakan kembali roda (mis. Metode kustom besar menyelesaikan cadangan SQL db yang agak biasa) dll. Pada dasarnya, kebingungan yang tidak perlu ditambah banyak rekayasa ulang

Dan itu membuat saya berpikir bahwa menjadi pembuat kode yang sangat terampil (saya sengaja tidak menggunakan kata "pengembang", dengan asumsi itu menunjukkan serangkaian keterampilan yang lebih luas), jika tidak disertai dengan kualitas lain, sebenarnya dapat menjadi semacam racun.

Dengan asumsi itu benar, beberapa alasan yang dapat saya pikirkan adalah:

  • jika Anda mengkode dengan mudah, rasanya (atau sebenarnya, dalam jangka pendek) lebih cepat untuk mengeluarkan solusi Anda sendiri di tempat, tanpa beralih ke perpustakaan, fungsi yang sudah ada, dll.
  • jika seseorang cukup berpengalaman untuk dengan mudah memelihara citra mental dari program yang kompleks, seseorang cenderung untuk membaginya menjadi modul, lapisan dll.

Jadi poin saya adalah bahwa jika seorang pembuat kode yang lancar menjadi pengembang yang buruk, kelancaran mereka tidak hanya tidak mengimbangi yang terakhir, tetapi sebenarnya malah malah lebih membahayakan.

Apa yang kamu pikirkan tentang itu? Apakah benar (sampai sejauh mana jika demikian)?


24
"Beri aku enam jam untuk menebang pohon dan aku akan menghabiskan empat pertama mengasah kapak." --Abraham Lincoln "Pertajam kapak Anda di waktu Anda sendiri." - Most Bosses
JeffO

15
Beberapa kebingungan di sini bagi saya disebabkan oleh judul, seperti ketika saya membaca 'lancar'I.ThinkOf(this).KindOfThing()
Benjol

Sudahkah Anda bertanya kepada pengembang senior ini alasan mengapa ia melakukan hal ini? Seperti yang sudah Anda tunjukkan, aplikasi ini bermasalah. Jadi mungkin pengembang senior terbatas dalam apa yang dapat dilakukannya dengan aplikasi kereta itu sendiri. Jika kodenya hanya berfungsi "sebagian besar waktu" maka itu mengandung bug dan harus diganti dan / atau diperbaiki.
Ramhound

@Ramhound - tidak, ketika dia meninggalkan perusahaan sebelum saya bergabung. Dia adalah orang terakhir yang mengerjakannya sebelum saya mengambilnya. Saya tahu dari rekan kerja bahwa ia terburu-buru, karena memperbaiki aplikasi adalah prioritas karena banyak keluhan pelanggan. Tetapi dia tidak melakukan pekerjaan yang sangat baik dalam hal manajemen waktu, karena dia jelas-jelas menyerbu melalui pintu yang terbuka setiap saat. BTW ia menciptakan perpustakaannya sendiri untuk melokalkan aplikasi WPF dan Winforms.
Konrad Morawski

1
sangat terkait: ini dan ini . Beberapa (banyak) orang terjebak pada tahap ini ...
BlueRaja - Danny Pflughoeft

Jawaban:


22

jika Anda mengkode dengan mudah, rasanya (atau sebenarnya, dalam jangka pendek) lebih cepat untuk mengeluarkan solusi Anda sendiri di tempat, tanpa beralih ke perpustakaan, fungsi yang sudah ada, dll.

Iya. Saya sudah menjadi pria itu. Dan saya telah belajar bahwa itu adalah hal yang mengerikan.

Ini semua sangat baik untuk Anda, Anda tidak perlu belajar sesuatu yang baru.

Tetapi bagaimana dengan anggota tim Anda yang lain? Mereka menjadi sangat bergantung pada Anda. Mereka tidak dapat google untuk "Clive's Quicky ORM" untuk mendapatkan bantuan pada mapper-relasional objek yang telah Anda tulis.

Dan kemudian tibalah saatnya mereka perlu mempekerjakan seseorang yang baru dan mereka tidak dapat mencari orang-orang yang berpengalaman dalam ORM Clive's Quicky.

Dan akhirnya datang hari ketika Anda pergi dan seseorang melihat ada bug di ORM Anda. Dan itu akan ada di sana, karena Anda tidak memiliki seluruh komunitas orang yang menguji dan memperbaiki produk Anda.

Ya, belajar Hibernate mungkin membutuhkan waktu lebih lama daripada menulis sesuatu yang ringan. Tetapi manfaat melakukannya terlalu besar untuk diabaikan, IMHO.


1
Saya sudah menjadi pria itu juga - dan saya tidak setuju dengan kalimat kedua. Mampu menyelesaikan sebagian besar masalah tidak berarti bahwa solusi Anda kuat, dapat dipertahankan, fleksibel, dapat diukur ... atau bahkan implementasi awal dikembangkan dengan cepat. Banyak ide terbaik yang Anda pelajari di luar manual referensi bahasa / perpustakaan adalah hal-hal yang "mengapa saya tidak memikirkan itu?" sederhana, dan juga fleksibel, scalable, dll Salah satu hal terburuk - menyadari bahwa saya sedang terkena ide sebelumnya, namun diberhentikan sebagai absurditas akademik sia-sia tanpa penggunaan praktis, jadi ketika saya membutuhkannya ...
Steve314

6
Di beberapa organisasi, mendapatkan persetujuan untuk menggunakan perpustakaan pihak ketiga dapat memakan waktu enam bulan atau lebih. Dalam beberapa kasus, Anda dapat menunggu enam bulan dan ditolak pada akhirnya. Saya telah membangun ORM satu kali sebelumnya hanya karena saya tidak ingin membuang waktu berurusan dengan birokrasi ketika saya sudah berada di timeline yang pendek.
Toby

2
@Toby: Titik adil. Tetapi perusahaan-perusahaan itu pada umumnya tidak bisa menabung.
pdr

Belum lagi Angkatan Udara AS sama dengan perusahaan-perusahaan yang disebutkan @Toby. Kami mencoba mendorong Ruby on Rails melalui, tetapi mereka tidak menyukainya.
Travis Pessetto

@Toby ada beberapa kasus di mana reinventing the wheel adalah hal yang benar untuk dilakukan, kuncinya adalah untuk memastikan Anda mengerti mengapa Anda
jk.

14

• jika Anda mengode dengan mudah, rasanya (atau sebenarnya, dalam jangka pendek) lebih cepat untuk mengeluarkan solusi Anda sendiri di tempat, tanpa beralih ke perpustakaan, fungsi yang sudah ada, dll.

Terampil dalam bahasa tetapi bukan alat. Itu bahkan bukan menjadi pembuat kode yang kuat. Ini hanya memoles satu keterampilan (pengetahuan bahasa) dan memungkinkan yang lain untuk berkarat (pengetahuan perpustakaan). Cara sebaliknya sama buruknya, tetapi lebih mudah dikenali.

• jika seseorang cukup berpengalaman untuk dengan mudah memelihara citra mental dari program yang kompleks, seseorang cenderung untuk membaginya menjadi modul, lapisan dll.

Itu hanya kemalasan yang menyamar sebagai keterampilan. Tidak perlu banyak upaya untuk mempertahankan apa yang Anda kerjakan secara aktif di kepala Anda. Dibutuhkan keterampilan untuk menemukan jahitan yang tepat dan membagi kode di sepanjang mereka. Coder yang mengatakan lebih cepat atau lebih baik untuk meninggalkan semuanya di satu tempat sering tidak dapat melihat item mana yang harus dibagi.


1
Ya memang. Dan saya kira saya akan lebih menentang rakyat seperti ini jika saya tidak mendapatkan penghasilan yang baik selama bertahun-tahun datang untuk membersihkan setelah mereka ... ;-)
Mike Woodhouse

4

Pastikan ini bukan karena dia bekerja di lingkungan "Jika keyboard Anda tidak mengklik, Anda tidak berfungsi". Kami semua melihat kembali kode dan bertanya-tanya apa yang kami pikirkan. Juga, apakah toko ini dalam praktik refactoring kode mereka? Itu mungkin sebuah kemewahan yang tidak diberikannya.

Namun, kita perlu melepaskan diri dari ide pertama kami (ide yang bisa Anda duduki dan tempati) dan melakukan sedikit lebih banyak perencanaan, penelitian, pemikiran. Godaan untuk menyingkirkan setiap masalah kecil memang menggoda dan seluruh proyek dipenuhi dengan praktik ini. Tidak ada yang mau membayar orang untuk memperbaiki hal-hal yang "tidak rusak", jadi mengapa refactor.

Sunting: Mari kita pastikan kita tidak menghukum mereka yang mengetahui jawabannya. Ada yang fasih dan menulis kode bagus dengan kecepatan. Kuncinya adalah tidak mendekati setiap masalah dengan cara ini.


Pikiranku persis. Jika fokus utama perusahaan adalah memberikan secepat mungkin, maka orang sering bekerja lembur dan melakukan hal-hal yang tidak akan mereka lakukan jika mereka diizinkan untuk bekerja tanpa tekanan. Anda merasa lebih "produktif" dan berguna jika Anda mengetik banyak kode yang Anda pikirkan saat mengetik. Bersandar untuk berpikir, atau bahkan mengobrol dengan rekan kerja tentang masalah masalah ... hal-hal semacam itu dengan mudah membuat Anda merasa seperti menunda proyek. Anda bisa mengkode pada waktu itu, bukan? ;-).
deadsven

Saya beruntung. Saya diizinkan bekerja dari rumah setelah pindah. Semua orang ingin tahu apakah itu dilakukan dan saya tidak bekerja. Saya tidak akan dihukum karena mengetahui jawabannya.
JeffO

3

100%

Cara sinis dalam memandang hal ini adalah bahwa jenis coders ini benar-benar menjaga mayoritas pengembang dalam pekerjaan, memperbaiki bug yang sangat mendasar sehingga Anda dapat memasukkan ribuan jam pengembang ke dalamnya tanpa harus setengah jalan ke stabil, fleksibel, aman , modular atau sistem [properti perangkat lunak favorit Anda]. Sistem ini memiliki begitu banyak keanehan sehingga pemikiran untuk bermigrasi ke sesuatu yang lain, bahkan dengan 95% fitur yang sudah ada dan komunitas yang hidup di belakangnya, dianggap suatu tempat antara konyol dan alasan untuk dipecat.

Singkatnya, coders yang lancar dapat melakukan lebih banyak kerusakan daripada gerombolan pesaing, tetapi harga biasanya dibayar selama bertahun-tahun. Dan mereka biasanya hanya melakukan pekerjaan mereka (seperti yang didefinisikan oleh orang lain).

Bagaimana cara mengetahui apakah Anda seorang pengembang atau pembuat kode? Saya kira itu tidak mungkin, tetapi setiap kali Anda menemukan cara untuk membuat kode Anda lebih sederhana tanpa mengurangi kualitas, Anda telah mengambil langkah lain menuju pencerahan.


1

Masalah yang Anda jelaskan pada dasarnya adalah NIH ("tidak ditemukan di sini") - apakah ada gejala lain?

Kadang-kadang NIH, terutama jika itu terisolasi untuk satu atau dua orang, dapat ditangani dalam diskusi kelompok ("Joe di sini memiliki pengalaman dalam melakukan backup SQL menggunakan perpustakaan standar - bagaimana menurut Anda, Joe?"). Ini bisa jadi kurang konfrontatif daripada Anda langsung mendatangi orang itu dan berkata, "Hei! Gunakan perpustakaan standar, dummy!" :)


1

Setelah berada dalam situasi Anda dan menyebabkan situasi yang sama, saya memahami frustrasi Anda, tetapi saya pikir jawaban atas pertanyaan Anda adalah "tidak". Kefasihan tidak menjamin bahwa seorang programmer akan menghasilkan kode yang dapat dipelihara. Seringkali organisasi memaksa pemrogram untuk memberikan perangkat lunak yang dirancang dan diimplementasikan dengan buruk karena keterbatasan anggaran dan waktu yang konyol. Ada kemungkinan bahwa programmer yang fasih memotong sudut hanya programmer peduli untuk memberikan sesuatu yang pelanggan peduli. Jelas ini tidak baik dalam praktiknya, tetapi sayangnya kenyataan bahwa sebagian besar programmer harus berurusan dengan suatu saat dalam karir mereka. Ada juga kemungkinan bahwa programmer yang fasih hanya menjadi malas atau puas diri. Saya dapat berbicara bahasa Inggris yang sempurna, tetapi lebih mudah dan lebih menyenangkan untuk menggunakan bahasa gaul.

Adapun menggunakan kode orang lain atau menggulirkan argumen Anda sendiri, saya pikir itu benar-benar bermuara pada apa yang membuat pekerjaan terbaik. Terkadang "terbaik" tidak memperhitungkan hal-hal seperti gaya dan pemeliharaan jika "terbaik" berarti memberikan proyek enam minggu dalam dua minggu. Inilah sebabnya kami refactor dan sempurnakan. Selain itu, pengembang harus mengetahui apa yang tersedia dalam hal kode pihak ketiga dan mereka harus tahu cara menggunakannya dan percaya bahwa itu akan berfungsi dan didukung / dipelihara dengan baik. Mengingat bahwa ada ribuan kerangka kerja opsional, pustaka, dan API untuk paradigma pembangunan populer apa pun yang menggunakan hal-hal seperti itu pada akhirnya dapat menghabiskan lebih banyak waktu, energi, dan stres daripada hanya membuat kerangka Anda sendiri. Juga, saya menemukan kasus-kasus di mana kode pihak ketiga tidak melakukan persis apa yang saya perlukan - yaitu saat itu '


0

Saya berada di kapal itu (kode warisan yang ditulis dengan lancar) dan cukup fasih untuk sementara waktu.

Rintangan terbesar untuk solusi "cepat dan kotor" adalah selalu ketika Anda perlu menambahkan lebih banyak lagi nanti. Ketika Anda membutuhkan lebih banyak fitur. Hanya ada begitu banyak yang dapat Anda lakukan tanpa struktur. Setelah itu, itu rusak, dan itu mahal untuk mengatur ulang (belum memuaskan, tetapi tidak benar-benar dihargai).

Pada dasarnya, Anda harus menjaga diri terhadap HACK APAPUN yang berpotensi menjadi "solusi yang bisa diterapkan", siap untuk dijual oleh tenaga penjualan yang bersemangat. Itu yang lama, "Itu belum siap! - Tapi itu berhasil, bukan?" teka-teki.


bagaimana ini menjawab pertanyaan yang diajukan?
nyamuk

@gnat Pertanyaannya adalah "Apa pendapat Anda tentang itu?", jawaban saya adalah apa yang saya pikirkan. Saya masih berpendapat sama: kelancaran (dengan demikian bisa melakukan solusi cepat, hacks, dll) dapat menyebabkan kode berbahaya dalam jangka panjang. Anda tidak bisa hanya fasih berbahasa, Anda harus tahu cara mengatur kode.
MPelletier
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.