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

156

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?

teamwork communication skills Florian Margaine
sumber
42
Saya percaya ini bermuara pada pertanyaan "Haruskah Anda menulis kode idiomatik dan memaksa orang ke tingkat itu? Atau menulis kode non-idiomatik yang menjabarkan semuanya secara eksplisit?"
53
Jangan menurunkan level keahlian kode Anda! Saya belajar banyak dari membaca kode programmer yang lebih maju. Ciptakan budaya di mana, jika teman Anda tidak memahami sesuatu, mereka didorong untuk bertanya (dan belajar). Pastikan Anda konsisten.
Kosta Kontos
6
Apakah Anda memiliki ulasan kode? Itu akan menjadi tempat yang sangat baik bagi mereka untuk bertanya tentang kode seperti itu.
thegrinner
3
Bagian dari keterampilan coding adalah kejelasan, dengan mempertimbangkan "audiens" Anda. Idiom khusus ini sepertinya layak untuk diajarkan, tetapi tentu akan ada kasus di mana akan lebih masuk akal untuk menggunakan gaya pengkodean yang lebih transparan.
LarsH
3
Apakah ini hanya berarti siapa yang berpikir bahwa contoh kedua memiliki kualitas yang lebih baik daripada contoh pertama karena apa yang dilakukan sangat jelas? Sepertinya contoh kedua lebih mudah dibaca daripada versi tangan pendek yang merupakan exmaple pertama. Apakah tidak ada alat yang secara otomatis akan mengambil kode buatan manusia dan mengoptimalkannya untuk Javascript? Berdasarkan pengalaman Javascript saya kode sebenarnya yang dijalankan tidak harus cukup hanya berjalan seefektif mungkin.
Ramhound

Jawaban:

135

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.

Benjamin Gruenbaum
sumber
1
Saya tahu belajar adalah hal yang konstan, tetapi apakah ini benar-benar tugas pengembang ini untuk melatih sesama karyawannya? Benar-benar harus menjadi tugas manajemen untuk menemukan pelatihan yang paling tepat bagi mereka.
corsiKa
8
@corsiKa Para pengembang itu tidak mungkin mempelajari semua keistimewaan bahasa melalui "pelatihan berbayar" (yaitu jenis manajemen pelatihan yang akan mengirim staf ke). Saya menganggapnya sebagai tempat kerja yang sakit ketika rekan kerja tidak saling belajar. Ini tidak seperti OP harus memberi mereka pelatihan di kelas. Orang-orang hanya dapat bertanya ketika mereka mandek, dan seperti yang disebutkan dalam komentar di atas, ulasan kode bisa bagus untuk berbagi pengetahuan semacam itu.
MetalMikester
2
Rekan-rekan karyawannya harus belajar sendiri, dari contoh yang diberikan oleh OP (dan lainnya). Kalau tidak, mereka tidak akan pernah maju melampaui pengetahuan mereka saat ini. OP tidak harus menghabiskan waktu berjam-jam setiap hari untuk melatih mereka secara pribadi, tetapi ulasan kode dan sesekali sesi brown-bag dapat membantu semua orang (yah, semua orang yang ingin belajar, itu).
alroc
1
@corsiKa setuju bahwa tinjauan terhadap kode dev senior bukanlah pelatihan yang memadai, meskipun itu bisa menjadi cara yang baik untuk mengidentifikasi hal-hal yang harus dicari dev junior nanti.
Dan Lyons
2
@yms Cukup adil, itu sudut pandang yang valid. Saya tidak pernah berpendapat bahwa keterbacaan adalah raja. Saya memiliki keberatan kuat untuk menggunakan beberapa bahasa seolah-olah mereka adalah bahasa yang sama. Keberatan 'diterima' dalam ratusan jam debugging. Sementara saya sepenuhnya setuju bahwa keterbacaan adalah raja, saya percaya Anda tidak dapat memperlakukan kode dalam beberapa bahasa dengan cara yang sama. Selain itu, saya pikir sebagian besar dari 'reputasi buruk' yang dimiliki JavaScript adalah karena hal itu. Orang-orang berharap itu berperilaku seperti bahasa lain tetapi tidak. Saya setuju bahwa keterbacaan sangat penting bagi misi. Kode yang lebih baik selalu lebih mudah dibaca :)
Benjamin Gruenbaum
47

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.

Corion
sumber
10
Masalahnya adalah bahwa fitur bahasa dipandang sebagai "trik pintar", bahkan ketika saya pikir mereka jelas tidak. Pernah melihat penutupan? Pernah melihat IIFE? Pernah melihat referensi fungsi dilewatkan sebagai panggilan balik? Itu adalah fitur bahasa yang diketahui oleh setiap pengembang JS berpengalaman . Namun mereka "trik pintar" untuk pengembang JS yang kurang berpengalaman.
Florian Margaine
1
@FlorianMargaine terdengar kepada saya seperti Anda harus bekerja pada mengubah terminologi, yaitu: ini bukan "trik pintar", ini adalah fitur yang lebih maju dari bahasa ... 1 menyiratkan kode Anda tidak mudah dipahami / hal yang buruk, 2 menyiratkan kesempatan untuk belajar dan meningkatkan keterampilan pengkodean 'saya' (bagaimana membuat orang lain mengubah terminologi mereka? Komentar, dorong pertanyaan, bagikan artikel kode yang menjelaskan bagaimana fitur ini berguna, dll ...)
Andrew Bickerton
3
Jika itu meringankan sakit kepala Anda, bagian dari frustrasi mungkin Javascript sebagai bahasa ... tidak masuk akal. Masuk akal bagi AS, orang-orang yang memposting di sini, karena kami sudah lama melakukannya. Tetapi tidak peduli bagaimana kita membuat bahasa berfungsi dengan baik, bagi mata netral itu tidak masuk akal. Pada catatan lain; Anda mungkin, sayangnya, menunjukkan nilai mempekerjakan pengembang berpengalaman , atau lebih disukai, pengembang 'bahasa apa pun' dengan kemauan tinggi untuk mempelajari paradigma baru.
Katana314
1
@FlorianMargaine Saya bekerja terutama di JavaScript, saya tahu rasa sakit yang Anda rasakan. Saya sudah mendekati ini dengan mencoba mendidik rekan satu tim. Video Crockford JavaScript membantu ( 1 , 2 ). Saya tidak berpikir hal-hal yang Anda daftarkan termasuk dalam trik "pintar" - rekan tim Anda harus mempelajarinya - tetapi beberapa hal yang Anda lakukan dengan fitur-fitur bahasa itu bisa menjadi jenis "pintar" yang buruk. Bagaimana meyakinkan perusahaan Anda untuk mempekerjakan Dev yang berpengalaman mungkin adalah pertanyaan lain sepenuhnya ...
Corion
2
Komentar tidak selalu baik. Saya membaca "Kode Bersih" beberapa waktu lalu dan beberapa poin yang ia berikan tentang komentar sangat baik. Jika Anda merasa perlu menulis komentar untuk menjelaskan kode Anda, ada kemungkinan kode itu ditulis dengan buruk. Jika kodenya lebih ekspresif, komentar berlebihan. Setiap kali Anda akan menulis komentar, berhentilah sejenak untuk mempertimbangkan apakah refactoring mungkin pilihan yang lebih baik. Jika kode ekspresif, menjelaskan tujuannya menjadi tidak perlu. Juga, komentar bisa menyesatkan atau salah jika kode diubah tetapi komentar tidak diperbarui agar sesuai.
Pappa
34

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.

Esailija
sumber
4
Anda berkonsentrasi pada satu contoh. Bagaimana dengan menggunakan hal-hal seperti IIFE, penutupan, referensi fungsi? Itulah poin utama dari pertanyaan saya.
Florian Margaine
1
@FlorianMargaine Anda tidak berpikir saya membahasnya di bagian kedua dengan cukup baik?
Esailija
3
Yah, itu tidak mengatakan apa-apa tentang bagaimana menangani situasi di mana saya hanya menggunakan "fitur bahasa canggih", yang rekan tim salah paham sebagai "trik pintar".
Florian Margaine
Saya suka jawaban ini +1, saya pikir itu melewatkan sebagian besar dari pertanyaan, tetapi berbicara tentang bagian lain dan skenario tentang hal itu secara mendalam dan menjelaskan masalah di pengembang tim lain mengambil konsep seperti itu sendiri tanpa bimbingan dari membaca Anda kode.
Benjamin Gruenbaum
@FlorianMargaine maksud Anda bagaimana sebenarnya menangani situasi dalam praktik di tempat kerja Anda di mana Anda menggunakan IIFE dan seseorang berpikir itu adalah trik yang cerdas? Seperti yang saya jelaskan, karena tidak ada asumsi tersembunyi, penghafalan seperti "variabel tidak akan bersifat global" akan berfungsi dengan baik untuk rata-rata.
Esailija
23

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.

Bryan Oakley
sumber
+1. Baik contoh spesifik OP memberi secara empiris lebih baik dari yang lain, mereka hanya berbeda.
Ross Patterson
jawaban yang sangat bagus @ bryan-oakley. Cheers
Andy K
7

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. :)

pengguna606723
sumber
5

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.

DavidR
sumber
3

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.

Doc Brown
sumber
3

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.

Daniel Hollinrake
sumber
Jika Anda pikir akan lebih mudah bagi Anda untuk mencontohkan apa yang Anda maksud dalam lingkungan C # saya ragu OP tidak akan keberatan - saya yakin tidak akan. Pertanyaan ini bukan tentang JavaScript :) Bayangkan menyerahkan parameter opsional, atau lambdas dalam kode Anda karena pengembang tim lain tidak memahaminya - maukah Anda melakukannya? Saya pikir Anda mengajukan beberapa ide menarik di sini, tetapi jika Anda berhenti mengkhawatirkan bahasa tertentu, Anda dapat menulisnya dengan cara yang lebih menarik :)
Benjamin Gruenbaum
1
Saya bekerja terutama dengan C # jadi itu adalah contoh yang paling mudah diingat. Anda membuat poin yang sangat baik, sehubungan dengan apakah saya akan menyerah fitur bahasa yang berguna hanya karena orang lain tidak menyadarinya. Jawabannya haruslah tidak, tetapi tentu saja bagian yang sulit adalah membuat orang lain melihat manfaat dari cara baru ini, yang tampaknya menjadi masalah utama Florian.
Daniel Hollinrake
3

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.

gbjbaanb
sumber
1
Saya tidak tahu seorang programmer tunggal yang belum kembali ke kode mereka (dari sebulan yang lalu!) Dan pergi "siapa sih yang menulis ini". Kami selalu berevolusi dalam gaya (setidaknya kami mencoba). Dalam kasus khusus ini OP menulis kode standar, bukan kode WTFish. OP tidak membahas penulisan kode "pintar" atau kode "lebih pendek menjadi keren", ini JS idiomatik.
Benjamin Gruenbaum
2

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.

jmoreno
sumber
1

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.

JB King
sumber
1

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.

Pascal Bourguignon
sumber
1
Dalam hal ini kita tahu siapa yang melihatnya. Mereka adalah rekan kerja kita. Saya pikir kalimat itu biasanya digunakan ketika Anda tidak mengenal audiens Anda.
dcaswell
-1

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

jwenting
sumber
5
Dalam hal ini, saya tidak pintar. Saya menulis kode idiomatik untuk pengembang berpengalaman. Apakah Anda melihat mengapa saya berjuang sekarang? :)
Florian Margaine
3
Paragraf pertama Anda tepat, tetapi -1 karena paragraf kedua Anda jauh dari sasaran. Tidak tepat untuk mengatakan bahwa contoh ini adalah upaya yang disengaja untuk menjadi pintar. Ini sebenarnya sangat jelas, dan yang lebih penting, ini adalah gaya idiomatik yang disetujui oleh banyak pengembang javascript yang baik. Ini bukan satu-satunya ungkapan dalam javascript untuk parameter fungsi default, tetapi itu adalah yang umum.
Ben Lee