Jika tim saya memiliki keterampilan rendah, haruskah saya menurunkan keterampilan kode saya? [Tutup]

Misalnya, ada cuplikan umum di JS untuk mendapatkan nilai default:

function f(x) {
    x = x || 'default_value';
}

Cuplikan semacam ini tidak mudah dipahami oleh semua anggota tim saya, level JS mereka rendah.

Haruskah saya tidak menggunakan trik ini? Itu membuat kode kurang dibaca oleh rekan-rekan, tetapi lebih mudah dibaca daripada yang berikut ini menurut JS dev:

function f(x) {
    if (!x) {
        x = 'default_value';
    }
}

Tentu, jika saya menggunakan trik ini dan seorang rekan melihatnya, maka mereka dapat mempelajari sesuatu. Tetapi seringkali mereka melihat ini sebagai "berusaha untuk menjadi pintar".

Jadi, haruskah saya menurunkan level kode saya jika rekan setim saya memiliki level lebih rendah dari saya?

Baiklah, inilah pendapat saya tentang topik besar dan rumit ini.

Pro untuk menjaga gaya pengkodean Anda:

• Hal-hal seperti x = x || 10idiomatik dalam pengembangan JavaScript dan menawarkan bentuk konsistensi antara kode Anda dan kode sumber daya eksternal yang Anda gunakan.
• Tingkat kode yang lebih tinggi seringkali lebih ekspresif, Anda tahu apa yang Anda dapatkan dan lebih mudah dibaca di kalangan profesional yang sangat terlatih.
• Anda akan lebih menikmati pekerjaan Anda. Saya pribadi menghargai membuat kode cantik. Saya pikir itu memberi saya banyak kepuasan dalam pekerjaan saya.
• Umumnya itu menciptakan gaya yang lebih mudah dibaca. Tetap dengan idiom bahasa bisa sangat berharga - mereka sering idiom karena suatu alasan.

Cons untuk menjaga gaya pengkodean Anda:

• Akan lebih sulit bagi programmer level bawah untuk mengikutinya. Ini seringkali adalah orang-orang yang menjaga kode Anda dan orang-orang yang harus benar-benar membaca hal-hal yang Anda tulis.
• Pemelihara kode, seringkali kode JavaScript berasal dari bahasa lain. Pemrogram Anda mungkin kompeten di Java atau C # tetapi tidak mengerti bagaimana dan kapan JavaScript berbeda persis. Poin-poin ini seringkali idiomatis - ekspresi fungsi yang dipanggil langsung (IIFE) adalah contoh dari konstruksi semacam itu.

Pendapat pribadi saya

Anda seharusnya tidak menurunkan keterampilan kode Anda. Anda harus bercita-cita untuk menulis kode yang ekspresif, jelas, dan ringkas. Jika Anda memiliki keraguan tentang tingkat tim Anda - mendidik mereka . Orang lebih dari bersedia untuk belajar daripada yang mungkin Anda pikirkan, dan bersedia untuk mengadaptasi konstruksi baru ketika yakin mereka lebih baik.

Jika mereka berpikir Anda 'pintar', cobalah untuk memperdebatkan maksud Anda. Bersedialah untuk mengakui bahwa Anda kadang-kadang salah, dan apa pun yang terjadi, cobalah untuk menjaga gaya tetap konsisten di seluruh lingkungan kerja Anda. Melakukan hal itu akan membantu menghindari permusuhan.

Yang paling penting adalah tetap konsisten.

Kode tim harus ditulis seolah-olah satu orang mengkodekannya. Anda benar-benar harus menyetujui pedoman pengkodean. Anda harus mematuhi panduan itu. Jika pedoman pengkodean menentukan bahwa membaca parameter opsional harus dilakukan dengan cara 'kurang pintar', maka itu caranya.

Komentar Baik

Haruskah Anda menurunkan keterampilan kode Anda? Tidak harus, tetapi Anda harus meningkatkan keterampilan komentar Anda . Pastikan untuk memasukkan komentar yang baik dalam kode Anda, terutama di sekitar bagian yang menurut Anda mungkin lebih rumit. Jangan menggunakan begitu banyak komentar sehingga kode menjadi sulit untuk diikuti, tetapi pastikan untuk membuat tujuan setiap bagian jelas.

Kenyataannya adalah bahwa sedikit lebih banyak bertele-tele dengan komentar dapat berguna dengan anggota tim yang kurang terampil, tetapi mereka yang memiliki keterampilan terendah dengan mengabaikannya, terutama jika ada terlalu banyak, jadi jangan berlebihan.

Masalah Gaya?

Contoh yang Anda berikan agak mendasar, tetapi juga agak bergaya. Sebuah komentar di sekitar setiap variabel default akan sangat membosankan untuk dijaga dan dibaca. Alih-alih, pintasan gaya atau pola kode yang berulang atau mungkin harus ditetapkan sebagai standar. Jika Anda berpikir sesuatu seperti bentuk standar pengaturan harus dipahami oleh semua dan digunakan setiap waktu, tuliskan ide-ide ini dan bawa mereka ke pimpinan tim Anda. Mungkin saja yang diperlukan untuk mengajari teman satu tim Anda adalah pertemuan sederhana di mana Anda membahas standar yang Anda usulkan.

Seperti jawaban lain yang sudah dinyatakan, pertahankan dengan konsisten .

Teach a Man To Fish ...

Mengajar rekan satu tim Anda mungkin adalah cara terbaik untuk membantu semua orang yang terlibat. Jelaskan bahwa jika ada yang memiliki pertanyaan mengenai sepotong kode dengan nama Anda di log komit atau cap waktu, mereka harus merasa bebas untuk menanyakannya kepada Anda. Jika tim Anda memiliki ulasan kode, ini adalah peluang bagus untuk menjelaskan kode yang mungkin membingungkan (ahem) yang dikomentari dengan baik kepada teman satu tim Anda. Jika tim Anda tidak memiliki ulasan kode, mengapa tidak? Dapatkan itu!

Anda harus berhati-hati. Anda mungkin tidak selalu ada untuk mengajar orang dan Anda bahkan mungkin lupa apa yang awalnya Anda coba lakukan di bagian kode tertentu.

Trik "Pintar"

Mempertahankan kemampuan rekan tim Anda sangat penting, tetapi menulis kode yang dapat dipelihara sering kali berarti tidak menggunakan cara pintas misterius untuk masalah yang mungkin memiliki solusi yang lebih umum. Ini penting bahkan ketika rekan kerja Anda cerdas. Anda tidak ingin membuat kode terlalu lama untuk dipahami atau memiliki efek samping yang halus tetapi penting yang bisa terlewatkan. Secara umum, yang terbaik adalah menghindari trik "pintar" ketika ada alternatif yang sesuai. Anda tidak pernah tahu siapa yang mungkin harus menjaga kode di telepon - sering kali versi lama dari diri kita sendiri tidak akan mengingat detail atau alasan untuk trik ini.

Jika ternyata Anda harus menerapkan trik pintar, setidaknya ikuti sedikit nasihat selanjutnya ...

CIUMAN

Jika ragu, buat sederhana . Apakah kode itu sederhana atau tidak tidak selalu sesuai dengan keterampilan programmer seperti yang mungkin Anda pikirkan. Sebenarnya beberapa solusi paling cemerlang untuk suatu masalah adalah yang paling sederhana, dan beberapa solusi yang lebih rumit berakhir di TheDailyWTF . Menjaga kode Anda tetap sederhana dan ringkas dapat membuat beberapa keputusan yang lebih cerdas tetapi kemungkinan kontra-intuitif lebih mudah dipahami.

Tampaknya ada keengganan besar untuk membuat fungsi di JS. Keengganan ini menyebabkan orang mencoba untuk menjadi pintar dan menggunakan trik konyol hanya untuk menjaga barang-barang dalam satu baris seperti panggilan fungsi. Tentu saja nama fungsi dalam panggilan juga berfungsi sebagai dokumentasi tambahan. Kita tidak dapat melampirkan komentar pada ekspresi yang rumit karena dengan begitu akan mengalahkan maksud melakukannya sehingga kita menyebutnya "idiom" dan tiba-tiba itu bisa dimengerti.

Javascript sangat mudah diakses, kebanyakan orang tidak makan spesifikasi untuk sarapan seperti kami. Jadi mereka tidak akan pernah mengerti apa asumsi tersembunyi dan kasus tepi idiom.

x = x || 'default_value';

Rata-rata joe tidak akan mengerti ini atau telah menghafal bahwa itu adalah ungkapan untuk nilai default. Keduanya berbahaya, bahkan yang terakhir bahkan lebih berbahaya. Dia tidak akan mengerti asumsi dan kasus tepi di sini. Dia tidak akan peduli untuk membaca spesifikasi dan memahaminya.

Ketika saya melihat kode yang saya lihat "apakah itu nullatau undefined, kemudian set ke nilai default ini. Meskipun akan juga secara implisit mengobati +0, -0, NaN, false, dan"" nilai-nilai tidak cocok. Saya harus ingat bahwa 3 bulan dari sekarang ketika kebutuhan yang untuk berubah. Saya mungkin akan melupakannya. "

Asumsi implisit sangat mungkin menyebabkan bug di masa depan dan ketika basis kode Anda penuh dengan trik seperti ini maka tidak ada kemungkinan Anda menyimpan semuanya di kepala Anda setiap kali Anda memikirkan apa yang akan mempengaruhi modifikasi. Dan ini untuk "pro JS", rata-rata joe akan menulis bug bahkan jika persyaratan untuk menerima nilai palsu untuk memulai.

Cuplikan baru Anda memiliki sintaks yang lebih akrab tetapi masih memiliki masalah di atas.

Anda bisa pergi dengan:

function f(x) {
    x = valueOrDefault(x, "default_value");
}

Sekarang Anda dapat memiliki logika yang sangat kompleks untuk menangani kasus tepi dan kode klien masih terlihat cantik dan mudah dibaca.

Sekarang, bagaimana Anda membedakan antara fitur bahasa canggih seperti melewatkan fungsi sebagai argumen atau trik pintar || "default"?

Trik cerdas selalu beroperasi di bawah beberapa asumsi tersembunyi yang dapat diabaikan ketika kode awalnya dibuat. Saya tidak akan pernah harus mengubah IIFE ke sesuatu yang lain karena persyaratan berubah, itu akan selalu ada. Mungkin pada tahun 2020 ketika saya bisa menggunakan modul yang sebenarnya tapi ya.

| 0atau versi pemujaan kargo yang ~~numdigunakan untuk lantai mengasumsikan batas integer positif dan bertanda 32-bit.

|| "default" menganggap semua nilai falsy sama dengan tidak melewatkan argumen sama sekali.

Dan seterusnya.

Anda seharusnya tidak menurunkan keterampilan pemrograman Anda, tetapi Anda mungkin perlu menyesuaikan cara Anda menulis kode. Tujuannya, hampir di atas semua, adalah untuk membuat kode Anda jelas kepada orang-orang yang harus membaca dan memeliharanya.

Sayangnya itu bisa menjadi panggilan penilaian, apakah gaya tertentu "pintar" atau hanya penggunaan tingkat lanjut. Kode dalam pertanyaan adalah contoh yang bagus untuk hal ini - solusi Anda belum tentu lebih baik dari yang lain. Beberapa akan berpendapat itu, beberapa akan tidak setuju. Karena kedua solusi memiliki kinerja runtime yang sama efektifnya (baca: pengguna tidak akan pernah tahu perbedaannya), pilih gaya yang paling nyaman digunakan tim.

Dalam beberapa kasus, Anda perlu mengajari mereka cara kode yang lebih baik, tetapi di lain waktu Anda perlu berkompromi untuk kepentingan kejelasan.

Ini mungkin sudah dikatakan dalam jawaban lain, tetapi saya ingin menjawab pertanyaan ini atas perintah saya sendiri.

Pedoman Umum

Ketika Anda bekerja di tim, Anda bukan target audiens sepotong kode. Audiens Anda adalah pengembang tim Anda. Jangan menulis kode yang tidak dapat mereka pahami tanpa alasan yang kuat.

1. Kecuali ada kelemahan khusus untuk itu, semua kode harus ditulis mengikuti pola atau pedoman tertentu yang akan memungkinkan perawatan yang mudah oleh pengembang yang akan mempertahankannya. (Peringatan: Mengikuti pola buruk hanya karena mereka saat ini dalam basis kode adalah praktik yang mengerikan.)
2. Jika Anda dapat menemukan alasan yang bagus untuk menggunakan idiom khusus bahasa yang tidak mudah dibaca oleh audiens target, tambahkan komentar. Jika Anda perlu menambahkan komentar ke setiap baris lain, Anda mungkin ingin menulis ulang kode Anda agar lebih mudah dibaca oleh audiens Anda. Saya tidak merasa berharga untuk menjadi idiomatis demi menjadi idiomatik.

Contoh spesifik

Kami memiliki sejumlah besar skrip perl di basis kode kami. Kami biasanya hanya menggunakan perl untuk operasi yang sangat sederhana dan sebagian besar kode ditulis oleh pengembang java, jadi itu ditata seperti java. Kami memiliki serangkaian skrip perl dan kerangka kerja yang ditulis oleh 'perl guru' yang sejak itu meninggalkan perusahaan kami. Kode ini mengandung banyak idiom perl yang lebih jelas dan tidak ada pengembang kami, termasuk saya, yang dapat membaca kode perl ini tanpa usaha yang panjang. Kami sering mengutuknya untuk itu. :)

Jika Anda menulis kode yang baik tetapi menurut Anda kolega Anda saat ini atau di masa depan mungkin mengalami kesulitan untuk mengikutinya, Anda harus menambahkan komentar singkat untuk menjelaskannya.

Dengan begitu, Anda bisa mengajari mereka sesuatu tanpa menghina kecerdasan pribadi mereka atau mempermalukan siapa pun dalam diskusi kelompok.

Saya tidak akan menyebut contoh Anda trik, tetapi hanya idiomatis. Jika Anda harus menggunakannya, itu tergantung IMHO tidak terlalu pada level tim Anda saat ini, tetapi jika (setidaknya beberapa) teman satu tim Anda bersedia untuk belajar beberapa idiom baru. Tentu saja, Anda harus mendiskusikan topik ini dengan mereka dan tidak memaksakan gaya ini pada mereka. Dan Anda seharusnya tidak meminta mereka untuk belajar setiap hari 5 hal baru atau "trik". Tetapi jujur, jika Anda hanya memiliki rekan tim yang tidak mau belajar sesuatu yang baru, bahkan itu sangat sederhana dan kecil dari ungkapan ini, Anda harus mempertimbangkan untuk beralih ke tim yang berbeda.

Membaca pertanyaan ini dan jawaban serta diskusi berikutnya sepertinya ada dua poin. Yang pertama: apakah boleh menggunakan fitur bahasa tingkat lanjut? Yang kedua: bagaimana saya bisa melakukan ini tanpa terlihat seolah-olah saya 'pamer'?

Dalam kasus pertama, masuk akal untuk menggunakan peningkatan dan fitur-fitur canggih. Sebagai contoh: di C # Anda tidak harus menggunakan ekspresi Linq atau Lambda tetapi kebanyakan orang melakukannya karena membuat kode lebih rapi dan lebih mudah dipahami, setelah Anda benar-benar tahu apa yang dilakukannya. Pada awalnya itu hanya terlihat aneh.

Orang terbiasa dengan pola dan dalam banyak kasus orang menggunakan cara yang ditetapkan untuk melakukan sesuatu hanya untuk menyelesaikan pekerjaan. Saya sama bersalahnya dengan pria berikutnya. Kita semua memiliki tenggat waktu. Dalam beberapa hal Anda bersalah karena memperkenalkan ide-ide baru dan cara berpikir baru! Ini datang ke poin kedua dan ini mungkin di mana Anda mungkin menghadapi perlawanan paling banyak.

Untuk orang yang menggunakan situs web mereka tidak peduli gaya mana yang digunakan semua yang mereka pedulikan adalah apakah itu berhasil? Apakah ini cepat? Jadi, jika tidak ada keuntungan kinerja dengan cara Anda maka tidak ada cara yang benar atau salah dalam contoh yang Anda berikan. Apakah cara Anda membuat kode lebih mudah dibaca atau tidak? Ini mungkin dilakukan setelah kolega Anda terbiasa.

Jadi, bagaimana Anda memperkenalkan perubahan ini? Coba dan lakukan diskusi dengan kolega Anda: apakah Anda tahu bahwa fungsi ini dapat ditulis dengan cara ini? Ulasan kode dan pemrograman pasangan bisa menjadi saat yang tepat untuk memungkinkan 'penyerbukan silang' gagasan. Sulit bagi saya untuk meresepkan apa yang harus dilakukan karena saya tidak tahu lingkungan tempat Anda bekerja. Saya menemukan bahwa beberapa programmer bisa sangat defensif dan tahan terhadap perubahan. Sekali lagi saya bersalah atas ini. Cara terbaik untuk bekerja dengan programmer semacam ini adalah meluangkan waktu untuk mempelajari apa yang membuat mereka tergerak, mempelajari latar belakang mereka dan kemudian membandingkan dan membedakan gaya dan pengalaman Anda dengan mereka. Butuh waktu tetapi menghabiskan waktu dengan baik. Jika mungkin cobalah dan dorong mereka.

Hanya saja, jangan bekerja untuk Royal McBee Computer Corp, karena siapa bilang Anda bukan programmer yang tidak berpengalaman.

tentu, bagus untuk menulis kode yang singkat dan singkat dan mungkin berguna dalam lingkungan javascript (well, sampai seseorang membuat kompiler js untuk diunduh ke browser, tapi itu cerita lain).

yang penting adalah kemampuan kode Anda untuk hidup melewati beberapa menit yang Anda perlukan untuk menulisnya. Tentu, ini cepat dan mudah dan Anda dapat memotongnya dan melanjutkan, tetapi jika Anda harus kembali ke sana bertahun-tahun kemudian, saat itulah Anda mungkin berpikir "muppet yang menulis ini", dan menyadari itu adalah Anda! (Saya sudah melakukan itu, tentu saja kebanyakan orang juga .. Saya menyalahkan tenggat waktu yang terlalu agresif, jujur).

Ini adalah satu-satunya hal penting yang perlu diingat, jadi sementara saya akan mengatakan ya - pergi dengan operator tertentu jika itu bekerja dan jelas, dan devs 'tidak berpengalaman' Anda (meskipun, yang merendahkan mereka, saya tahu banyak dari dev yang tidak berpengalaman yang mengetahui semua operator dan trik karena mereka telah menghafal berbagai tutorial dan referensi halaman web, mereka menulis kode terburuk meskipun mereka tahu setiap trik kecil ... mungkin ada lebih dari ini daripada kebetulan)

Ngomong-ngomong, jika Anda bisa membaca kisah Mel , Anda akan menyadari bahwa triknya bukan yang terbaik untuk dimasukkan ke dalam kode apa pun, meskipun Mel adalah seorang programmer sejati dari urutan pertama. Ini memberikan bayaran untuk setiap argumen di mana seseorang mengatakan mereka dapat menulis kode yang baik dan semua orang perlu belajar lebih banyak untuk mengikuti.

Nah, untuk pemula yang terlihat seperti JS dasar bagi saya.

Tetapi secara umum - Anda seharusnya tidak menggunakan peretasan yang cerdik, untuk memparafrasekan "debugging dua kali lebih keras daripada pemrograman. Jika Anda menulis kode sepintar yang Anda bisa, maka Anda secara definisi tidak dapat men-debug itu".

Itu tidak berarti bahwa Anda harus menghindari kode hanya karena orang lain tidak akan memahaminya - Anda harus menulis kode dengan cara yang jelas dan konsisten yang Anda bisa. Tetapi kriteria Anda yang jelas harus "akankah saya memahami ini pada bacaan pertama dalam setahun", bukan "adakah yang bisa memahaminya".

Tulis dengan cara yang jelas, bahwa Anda tidak mengalami kesulitan memahami dan membiarkan orang lain meningkatkan keterampilan mereka - jangan menghalangi diri Anda sendiri untuk menyelamatkan orang lain dari masalah hipotesis.

Saya akan berdiskusi dengan rekan tim saya seperti apa standar pengkodean yang ingin kita miliki karena ini kebanyakan tentang bagaimana seharusnya sesuatu yang dapat dilakukan dalam banyak cara dilakukan untuk basis kode kita. Jika ada konsensus yang akan menjadi upaya awal saya untuk mendapat jawaban.

Jika tidak ada, maka saya kemungkinan akan mempertimbangkan standar apa yang diusulkan masuk akal dan mulai menerapkannya setelah saya menyelesaikannya dengan manajemen dan beberapa tim. Idenya di sini adalah untuk memastikan bahwa manajemen setuju dengan ide ini dan bahwa saya tidak hanya melakukan hal saya sendiri dan kemudian memaksa orang lain untuk mengambilnya.

Saya akan melihat ini lebih seperti pertanyaan tentang standar dan praktik seperti apa yang dimiliki tim Anda daripada hanya tingkat keterampilan karena ada banyak cara untuk mengevaluasi kode. Seberapa baik orang lain dapat mempertahankannya adalah salah satu kriteria itu.

Masalahnya adalah Anda menginginkan keterbacaan yang baik dari sumbernya, tetapi keterbacaan ada di mata yang melihatnya.

Saya menyarankan agar kita membutuhkan alat yang lebih baik untuk menyelesaikan masalah ini. Tidak ada yang rumit, ingatlah, kami memiliki teknologi untuk melakukannya selama lebih dari 50 tahun. Sertakan pengurai dalam editor, dan minta editor menyimpan sumber dalam bentuk sexps (ya, sama seperti lisp). Kemudian sumber dibaca, editor mem-parsingnya menjadi sintaksis dan tipografis (Anda tahu, spasi, tab, koma), bentuk yang disukai pengguna.

Dengan cara ini, Anda dapat mengetik dan membaca x = x || 10dan programmer lain akan membacanya sebagai

if (0 == x) { x = 10;}

emacs memiliki semua bagian untuk melakukannya dengan mudah.

Daripada membodohi kode, mengapa tidak meningkatkan kualitas tim? Pelatihan, pembinaan, pendidikan, dan praktik perekrutan yang ditingkatkan dapat melakukan banyak hal untuk memastikan peningkatan berkelanjutan.
Statisme, kode membusuk, menolak untuk meningkatkan dan berinovasi karena seseorang tidak ingin bekerja pada perbaikan diri hanya menyebabkan masalah, dan lebih cepat daripada nanti.

Tentu saja dalam kasus spesifik yang Anda tunjukkan, Anda hanya berusaha menjadi pandai dan sengaja menulis kode yang dikaburkan, yang tidak pernah merupakan ide yang baik. Kode pertama-tama dan terutama harus dapat dibaca, mudah dimengerti, tidak ditulis untuk menunjukkan seberapa pintar Anda dalam menciptakan sesuatu dalam pernyataan sesedikit mungkin (kasus khusus dikecualikan, seperti di mana lebih banyak pernyataan akan mengarah pada kinerja yang sangat buruk, di mana kasus komentar berlebihan disebut untuk).