“Praktik terbaik” populer apa yang tidak selalu terbaik, dan mengapa? [Tutup]

"Praktik terbaik" ada di mana-mana di industri kami. Sebuah pencarian Google pada "coding praktek terbaik" muncul hampir 1,5 juta hasil. Gagasan itu tampaknya membawa kenyamanan bagi banyak orang; cukup ikuti instruksi, dan semuanya akan baik-baik saja.

Ketika saya membaca tentang praktik terbaik - misalnya, saya baru saja membaca beberapa di Kode Bersih baru-baru ini - saya merasa gugup. Apakah ini berarti saya harus selalu menggunakan latihan ini? Apakah ada syarat yang terlampir? Apakah ada situasi di mana itu mungkin bukan praktik yang baik? Bagaimana saya bisa tahu pasti sampai saya belajar lebih banyak tentang masalahnya?

Beberapa praktik yang disebutkan dalam Kode Bersih tidak cocok dengan saya, tetapi sejujurnya saya tidak yakin apakah itu karena berpotensi buruk, atau jika itu hanya bias pribadi saya yang berbicara. Saya tahu bahwa banyak orang terkemuka di industri teknologi tampaknya berpikir bahwa tidak ada praktik terbaik , jadi setidaknya keraguan saya yang mengganggu membuat saya berada di perusahaan yang baik.

Jumlah praktik terbaik yang saya baca terlalu banyak untuk dicantumkan di sini atau ajukan pertanyaan individual, jadi saya ingin mengatakan ini sebagai pertanyaan umum:

Praktik pengkodean mana yang secara populer dilabeli sebagai "praktik terbaik" dapat menjadi sub-optimal atau bahkan berbahaya dalam keadaan tertentu? Keadaan apa itu dan mengapa mereka menjadikan praktik itu miskin?

Saya lebih suka mendengar tentang contoh dan pengalaman spesifik.

Saya pikir Anda telah memukul kepala dengan pernyataan ini

Aku benci mengambil sesuatu dari nilai nominal dan tidak memikirkannya secara kritis

Saya mengabaikan hampir semua Praktik Terbaik ketika tidak disertai dengan penjelasan mengapa itu ada

Raymond Chen mengedepankannya dalam artikel ini ketika dia mengatakan

Nasihat yang baik datang dengan alasan sehingga Anda bisa tahu kapan itu menjadi nasihat yang buruk. Jika Anda tidak memahami mengapa sesuatu harus dilakukan, maka Anda telah jatuh ke dalam perangkap pemrograman kultus kargo, dan Anda akan terus melakukannya bahkan ketika itu tidak lagi diperlukan atau bahkan menjadi merusak.

Mungkin juga melemparkan ini ke atas ring:

Premature optimization is the root of all evil.

Tidak, tidak.

Kutipan lengkap:

"Kita harus melupakan efisiensi kecil, katakanlah sekitar 97% dari waktu: optimasi prematur adalah akar dari semua kejahatan. Namun kita tidak boleh melewatkan peluang kita dalam 3% kritis itu."

Itu berarti bahwa Anda mengambil keuntungan dari peningkatan kinerja strategis spesifik selama proses desain Anda. Ini berarti bahwa Anda menggunakan struktur data dan algoritma yang konsisten dengan tujuan kinerja. Ini berarti bahwa Anda menyadari pertimbangan desain yang memengaruhi kinerja. Tetapi itu juga berarti bahwa Anda tidak mengoptimalkan secara sembrono ketika melakukan hal itu akan memberi Anda keuntungan kecil dengan biaya pemeliharaan.

Aplikasi harus dirancang dengan baik, sehingga tidak jatuh pada akhirnya ketika Anda menerapkan sedikit beban padanya, dan kemudian Anda akhirnya menulis ulang. Bahaya dengan kutipan singkat adalah bahwa, terlalu sering, pengembang menggunakannya sebagai alasan untuk tidak memikirkan kinerja sama sekali sampai akhir, ketika mungkin sudah terlambat untuk melakukan sesuatu tentang hal itu. Lebih baik untuk membangun kinerja yang baik sejak awal, asalkan Anda tidak fokus pada hal-hal kecil.

Katakanlah Anda sedang membangun aplikasi waktu-nyata pada sistem tertanam. Anda memilih Python sebagai bahasa pemrograman, karena "Optimalisasi prematur adalah akar dari semua kejahatan." Sekarang saya tidak menentang Python, tetapi ini adalah bahasa yang ditafsirkan. Jika daya pemrosesan terbatas, dan sejumlah pekerjaan harus diselesaikan dalam waktu-nyata atau mendekati waktu-nyata, dan Anda memilih bahasa yang membutuhkan daya pemrosesan lebih untuk pekerjaan daripada yang Anda miliki, Anda secara kacau mengacau, karena Anda sekarang harus memulai kembali dengan bahasa yang mampu.

Satu pengembalian per fungsi / metode.

Jangan menemukan kembali roda adalah dogma yang banyak digunakan. Idenya adalah bahwa jika ada solusi yang cocok, gunakanlah alih-alih membuat sendiri; sebagai tambahan dari upaya penghematan, solusi yang ada kemungkinan lebih baik diimplementasikan (bebas bug, efisien, teruji) daripada apa yang Anda dapatkan pada awalnya. Sejauh ini bagus.

Masalahnya adalah bahwa solusi yang cocok 100% jarang ada. Solusi yang cocok 80% mungkin ada, dan menggunakannya mungkin baik-baik saja. Tapi bagaimana dengan 60% yang cocok? 40%? Di mana Anda menggambar garis? Jika Anda tidak menarik garis, Anda bisa memasukkan pustaka yang membengkak ke proyek Anda karena Anda menggunakan 10% fitur-fiturnya - hanya karena Anda ingin menghindari "menciptakan kembali roda".

Jika Anda menemukan kembali roda, Anda akan mendapatkan apa yang Anda inginkan. Anda juga akan belajar cara membuat roda. Belajar dengan melakukan seharusnya tidak diremehkan. Dan pada akhirnya, roda custom mungkin lebih baik daripada roda generik off-the-shelf.

"Unit Uji Segalanya."

Saya sering mendengar bahwa semua kode harus memiliki unit test, suatu hal yang tidak saya setujui. Ketika Anda memiliki tes untuk suatu metode, setiap perubahan pada output atau struktur dari metode itu harus dilakukan dua kali (sekali dalam kode, sekali dalam tes).

Dengan demikian, tes unit harus, menurut pendapat saya, proporsional dengan stabilitas struktural kode. Jika saya menulis sistem berlapis dari bawah ke atas, lapisan akses data saya akan melakukan tes wazoo; lapisan logika bisnis saya akan diuji dengan cukup baik, lapisan presentasi saya akan memiliki beberapa tes, dan pandangan saya akan memiliki sedikit atau tanpa pengujian.

Selalu programkan ke antarmuka.

Terkadang hanya akan ada satu implementasi. Jika kita menunda proses ekstraksi antarmuka sampai saat kita melihat kebutuhan untuk itu, kita akan sering menemukan itu tidak perlu.

Jangan gunakan sumber terbuka apa pun (atau non-Microsoft untuk Anda. Pengembang NET)

Jika Microsoft tidak mengembangkannya - kami tidak menggunakannya di sini. Ingin menggunakan ORM - EF, ingin menggunakan IOC - Unity, ingin log - blok aplikasi logging perusahaan. Ada begitu banyak perpustakaan yang lebih baik - namun saya selalu terjebak memesan dari menu dolar dunia pengembangan. Saya bersumpah setiap kali saya mendengar Praktik Terbaik Microsoft, saya rasa "Pedoman Gizi McDonald's". Tentu, Anda mungkin akan hidup jika mengikuti mereka, tetapi Anda juga akan kekurangan gizi dan kelebihan berat badan.

• Perhatikan ini mungkin bukan praktik terbaik Anda , tetapi ini adalah praktik umum yang diikuti hampir di semua tempat saya bekerja.

Orientasi objek

Ada asumsi, hanya karena kode "berorientasi objek", secara ajaib bagus. Jadi orang terus memeras fungsi ke dalam kelas dan metode, hanya untuk menjadi berorientasi objek.

Semua kode harus dikomentari.

Tidak, seharusnya tidak. Beberapa waktu Anda memiliki kode yang jelas, misalnya setter tidak boleh dikomentari, sampai mereka melakukan sesuatu yang istimewa. Juga, mengapa saya harus mengomentari ini:

/** hey you, if didn't get, it's logger. */
private static Logger logger = LoggerFactory.getLogger(MyClass.class);

Metodologi, khususnya scrum. Saya tidak bisa menjaga wajah lurus ketika saya mendengar orang dewasa menggunakan frasa "Scrum Master". Saya bosan mendengar protes pengembang sehingga beberapa aspek dari Metodologi X tidak bekerja untuk perusahaan mereka, hanya untuk diberitahu oleh Guru Si-dan-Jadi bahwa alasan itu tidak berfungsi adalah karena mereka tidak, pada kenyataannya, praktisi sejati Metodologi X. "Scrum lebih keras, Anda harus, Padawan pelajar saya!"

Ada nugget kebijaksanaan dalam metodologi lincah --- banyak dari mereka --- tetapi mereka sering terbungkus dalam begitu banyak kotoran sehingga saya tidak bisa melawan refleks muntah saya. Ambil bit ini dari halaman scrum Wikipedia :

Sejumlah peran didefinisikan dalam Scrum. Semua peran terbagi dalam dua kelompok yang berbeda — babi dan ayam — berdasarkan sifat keterlibatan mereka dalam proses pembangunan.

Benarkah? Babi dan ayam, katamu? Menarik! Tidak sabar untuk melempar yang ini ke bos saya ...

Pemetaan Relasional Objek ... http://en.wikipedia.org/wiki/Object-relational_mapping

Saya tidak ingin diabstraksi dari data saya, saya juga tidak ingin kehilangan kontrol dan optimisasi yang tepat. Pengalaman saya dengan sistem ini sangat buruk ... Pertanyaan yang dihasilkan oleh lapisan abstraksi ini bahkan lebih buruk daripada apa yang saya lihat dari off-shoring.

Menulis nama fungsi seolah-olah itu adalah kalimat bahasa Inggris:

Draw_Foo()
Write_Foo()
Create_Foo()

dll. Ini mungkin terlihat hebat, tetapi itu menyebalkan ketika Anda mempelajari API. Seberapa mudah untuk mencari indeks untuk "Segala sesuatu yang dimulai dengan Foo"?

Foo_Draw()
Foo_Write()
Foo_Create()

dll.

MVC - saya sering menemukan bahwa menyoalkan banyak masalah desain web ke dalam pendekatan MVC lebih tentang membuat kerangka kerja (rails dll) bahagia daripada tentang kesederhanaan atau struktur. MVC adalah favorit "astronot arsitektur" yang tampaknya menghargai perancah berlebihan atas kesederhanaan. ymmv.

OO berbasis kelas - dalam pendapat saya mendorong struktur kompleks negara yang bisa berubah. satu-satunya kasus yang menarik yang saya temukan untuk OO berbasis kelas selama bertahun-tahun adalah contoh "bentuk-> persegi panjang-> norak yang membentuk bab 1 dari buku OO apa pun

YAGNI

( Kamu tidak akan membutuhkannya )

Pendekatan ini memakan waktu berjam-jam ketika saya harus mengimplementasikan fitur pada basis kode yang ada, di mana perencanaan yang cermat akan menyertakan fitur-fitur ini sebelumnya.

Gagasan saya sering ditolak karena YAGNI, dan sebagian besar kali seseorang harus membayar untuk keputusan itu nanti.

(Tentu saja orang dapat berargumen bahwa basis kode yang dirancang dengan baik juga akan memungkinkan fitur ditambahkan nanti, tetapi kenyataannya berbeda)

Untuk SQL

1. Jangan gunakan pemicu
2. Selalu sembunyikan tabel di belakang tampilan

Dalam urutan:

1. Mereka adalah fitur yang memiliki tempat itu. Anda memiliki beberapa jalur pembaruan ke sebuah tabel, atau memerlukan audit 100%?

2. Kenapa? Saya akan melakukannya jika saya refactoring untuk mempertahankan kontrak, tetapi tidak ketika saya membaca bahwa orang mengubah pandangan agar sesuai dengan perubahan tabel apa pun

Sunting:

Nomor 3: Menghindari * dengan EXIS. Coba 1/0. Berhasil. Daftar kolom tidak dievaluasi sesuai standar SQL. Halaman 191

Pola Desain kebanyakan. Mereka terlalu banyak digunakan dan kurang dimanfaatkan.

Prinsip Tanggung Jawab Tunggal

^{("setiap kelas seharusnya hanya memiliki satu tanggung jawab tunggal; dengan kata lain, setiap kelas harus memiliki satu, dan hanya satu, alasan untuk berubah")}

Saya tidak setuju. Saya pikir suatu metode seharusnya hanya memiliki satu alasan untuk berubah, dan semua metode dalam suatu kelas harus memiliki hubungan logis satu sama lain , tetapi kelas itu sendiri mungkin benar - benar melakukan beberapa hal (terkait).

Dalam pengalaman saya, prinsip ini terlalu sering diterapkan terlalu bersemangat, dan Anda berakhir dengan banyak kelas kecil satu metode. Kedua toko tangkas tempat saya bekerja telah melakukan ini.

Bayangkan jika pencipta .Net API memiliki mentalitas seperti ini: daripada List.Sort (), List.Reverse (), List.Find () dll., Kita akan memiliki kelas ListSorter, ListReverser, dan ListSearcher!

Daripada berdebat lagi melawan SRP (yang secara teori tidak mengerikan) , saya akan membagikan beberapa pengalaman anekdot saya yang bertele-tele:

Di satu tempat saya bekerja, saya menulis sebuah pemecah aliran maks yang sangat sederhana yang terdiri dari lima kelas: satu simpul, satu grafik, satu pembuat grafik, satu pembuat grafik, dan satu kelas untuk menggunakan pembuat grafik / pemecah untuk menyelesaikan suatu masalah dunia nyata. Tidak ada yang sangat kompleks atau panjang (solver adalah yang terpanjang di ~ 150 baris). Namun, diputuskan bahwa kelas-kelas tersebut memiliki "tanggung jawab" terlalu banyak, sehingga rekan kerja saya mulai memperbaiki kode itu. Ketika mereka selesai, 5 kelas saya telah diperluas menjadi 25 kelas, yang total baris-kode-nya lebih dari tiga kali lipat dari aslinya. Alur kode tidak lagi jelas, juga bukan tujuan dari unit-tes baru; Saya sekarang kesulitan mencari tahu apa yang kode saya lakukan.

Di tempat yang sama, hampir setiap kelas hanya memiliki satu metode (satu-satunya "tanggung jawab"). Mengikuti alur dalam program hampir tidak mungkin, dan sebagian besar unit-test terdiri dari pengujian bahwa kelas ini memanggil kode dari kelas lain , yang tujuannya sama-sama merupakan misteri bagi saya. Ada ratusan kelas di mana seharusnya (IMO) hanya puluhan. Setiap kelas hanya melakukan satu "hal" , tetapi bahkan dengan konvensi penamaan seperti "AdminUserCreationAttemptorFactory" , sulit untuk mengatakan hubungan antara kelas.

Di tempat lain (yang juga memiliki mentalitas kelas-seharusnya-hanya-memiliki-satu-metode ), kami mencoba mengoptimalkan metode yang menghabiskan 95% waktu selama operasi tertentu. Setelah (agak bodoh) mengoptimalkannya sedikit, saya mengalihkan perhatian saya mengapa itu disebut bajillion kali. Itu disebut dalam loop di kelas ... yang metodenya disebut dalam loop di kelas lain .. yang juga disebut dalam loop ..

Semua mengatakan, ada lima tingkat loop yang tersebar di 13 kelas (serius). Apa yang sebenarnya dilakukan oleh satu kelas tidak mungkin ditentukan hanya dengan melihatnya - Anda harus membuat sketsa grafik mental tentang metode apa yang disebutnya, dan metode apa yang disebut metode itu, dan seterusnya. Jika semuanya disatukan dalam satu metode, panjangnya hanya sekitar 70 baris dengan metode-masalah kita bersarang dalam lima tingkat loop yang jelas.

Permintaan saya untuk mengubah 13 kelas menjadi satu kelas ditolak.

Sekarang setelah Anda menyebutkan Kode Bersih, sementara itu berisi beberapa ide bagus, saya pikir obsesinya untuk memperbaiki semua metode menjadi submethods dan yang menjadi sububmethods dll diambil terlalu jauh. Alih-alih beberapa metode sepuluh-baris Anda seharusnya memilih dua puluh (seharusnya nama baik) satu-liners. Jelas seseorang berpikir itu bersih, tetapi bagi saya tampaknya jauh lebih buruk daripada versi aslinya.

Juga, mengganti hal-hal sederhana seperti SD

0 == memberArray.length

dalam kelas dengan panggilan ke metode kelas sendiri seperti

isEmpty()

adalah IMHO "perbaikan" dipertanyakan. Tambahan: Perbedaannya adalah bahwa pemeriksaan pertama tidak persis seperti yang dikatakan: memeriksa apakah panjang array adalah 0. Oke, isEmpty()mungkin memeriksa panjang array juga. Tetapi bisa juga diimplementasikan seperti ini:

return null != memberArray ? 0 == memberArray.length : true;

Yaitu, itu termasuk cek kosong implisit! Ini mungkin perilaku yang baik untuk metode publik - jika arraynya nol, maka ada sesuatu yang benar-benar kosong - tetapi ketika ketika kita berbicara tentang internal class, ini tidak begitu baik. Sementara enkapsulasi ke luar adalah suatu keharusan, internal kelas harus tahu persis apa yang terjadi di dalam kelas. Anda tidak dapat merangkum kelas dari dirinya sendiri . Eksplisit lebih baik daripada implisit.

Ini bukan untuk mengatakan bahwa memecah metode panjang atau perbandingan logis yang terlibat tidak baik; tentu saja, tetapi sampai sejauh mana melakukannya - di mana sweet spot - jelas merupakan masalah selera. Memecah metode yang panjang menghasilkan lebih banyak metode, dan itu tidak gratis. Anda harus melompat-lompat kode sumber untuk melihat apa yang sebenarnya terjadi, ketika Anda bisa melihatnya sekilas jika semua itu ada dalam satu metode.

Saya bahkan akan mengatakan bahwa dalam beberapa kasus metode 1-line terlalu pendek untuk pantas menjadi metode.

"Jadilah liberal dengan komentar"

Komentar jelas merupakan hal yang baik, tetapi terlalu banyak sama buruknya jika tidak lebih buruk daripada tidak cukup. Mengapa? Yah, orang cenderung mengabaikan komentar jika mereka melihat terlalu banyak komentar yang tidak perlu. Saya tidak mengatakan bahwa Anda dapat memiliki kode dokumentasi diri yang sempurna, tetapi lebih baik daripada kode yang membutuhkan komentar untuk penjelasan.

GoTo Dianggap Berbahaya

Jika Anda menerapkan mesin negara, pernyataan GOTO dapat lebih masuk akal (keterbacaan dan kode efisien) daripada pendekatan "pemrograman terstruktur". Ini benar-benar mengkhawatirkan beberapa rekan kerja ketika potongan kode pertama yang saya tulis dalam sebuah pekerjaan baru tidak hanya mencakup satu tetapi beberapa pernyataan. Untungnya mereka cukup pintar untuk menyadari bahwa itu sebenarnya solusi terbaik dalam kasus khusus ini.

"Praktik terbaik" apa pun yang tidak memungkinkan pengecualian yang masuk akal dan terdokumentasi pada aturannya hanyalah menakutkan.

Pengorbanan yang kami lakukan untuk membuat kode dapat diuji

Saya melompati banyak rintangan untuk membuat kode saya dapat diuji, tetapi saya tidak berpura-pura bahwa saya tidak akan jika diberi pilihan. Namun, saya sering mendengar orang-orang mendorong gagasan bahwa ini adalah "praktik terbaik." Praktik-praktik ini termasuk (ditulis dalam bahasa .Net, tetapi juga berlaku untuk bahasa lain) :

• Membuat antarmuka untuk setiap kelas. Ini menggandakan jumlah kelas (file) untuk menangani, dan menggandakan kode. Ya, pemrograman antarmuka itu baik, tetapi itulah yang dimaksudkan untuk specifier publik / swasta.
• Setiap kelas yang tidak dipakai pada saat startup membutuhkan pabrik. Jelas, new MyClass()jauh lebih sederhana daripada menulis sebuah pabrik, tetapi sekarang metode yang membuatnya tidak dapat diuji secara terpisah. Kalau bukan karena fakta ini, saya hanya akan membuat 1/20 jumlah kelas pabrik yang saya lakukan sekarang.
• Jadikan setiap kelas publik, yang mengalahkan tujuan memiliki penentu akses pada kelas sama sekali. Namun, kelas non-publik tidak dapat diakses (dan dengan demikian, diuji) dari proyek lain, sehingga satu-satunya pilihan lain adalah memindahkan semua kode pengujian ke proyek yang sama (dan dengan demikian melepaskannya dengan produk akhir).
• Injeksi Ketergantungan. Jelas harus memberi setiap kelas lain saya menggunakan bidang dan parameter-konstruktor secara signifikan lebih berfungsi daripada hanya membuat mereka ketika saya membutuhkannya; tapi kemudian saya tidak bisa lagi menguji kelas ini secara terpisah.
• Prinsip Tanggung Jawab Tunggal, yang telah menyebabkan saya sangat sakit kepala, saya memindahkannya ke jawabannya sendiri .

Jadi apa yang bisa kita lakukan untuk memperbaikinya? Kami membutuhkan perubahan drastis dalam arsitektur bahasa:

• Kami membutuhkan kemampuan untuk mengejek kelas
• Kami membutuhkan kemampuan untuk menguji metode privat dari kelas internal, dari proyek lain (ini mungkin terlihat seperti kerentanan keamanan, tapi saya tidak melihat masalah jika peserta ujian dipaksa untuk menyebutkan kelas penguji) .
• Injeksi ketergantungan (atau lokasi layanan), serta sesuatu yang setara dengan pola pabrik kami yang ada, harus menjadi bagian inti dari bahasa tersebut.

Singkatnya, kita membutuhkan bahasa yang dirancang dari bawah ke atas dengan kemampuan untuk diuji .

Memisahkan aplikasi menjadi Tiers; Lapisan Data, Lapisan Bisnis, Lapisan UI

Alasan utama saya tidak suka ini adalah karena sebagian besar tempat yang mengikuti metode ini, menggunakan kerangka kerja yang sangat rapuh untuk menyelesaikannya. IE UI Layer adalah kode tangan untuk menangani objek lapisan bisnis, objek lapisan bisnis kode tangan untuk berurusan dengan aturan dan basis data bisnis, basis data adalah SQL dan sudah cukup rapuh dan dikelola oleh kelompok "DBA" yang tidak menyukai perubahan.

Mengapa ini buruk? Permintaan peningkatan yang paling umum adalah "Saya perlu bidang pada layar X yang memiliki Y." Bang! Anda hanya memiliki fitur baru yang memengaruhi setiap layer, dan jika Anda memisahkan layer dengan programmer yang berbeda, itu hanya menjadi masalah besar yang melibatkan banyak orang dan grup, untuk perubahan yang sangat sederhana.

Selain itu, saya tidak tahu sudah berapa kali saya bertengkar seperti ini. "Bidang nama terbatas pada panjang maksimal 30, apakah ini lapisan UI, atau lapisan bisnis, atau masalah lapisan data?" Dan ada seratus argumen, dan tidak ada jawaban yang benar. Jawabannya sama, itu mempengaruhi semua lapisan, Anda tidak ingin membuat UI bodoh dan harus melalui semua lapisan, dan gagal di basis data, hanya saja pengguna mengetahui entrinya terlalu panjang. Jika Anda mengubahnya, itu mempengaruhi semua lapisan, dll.

"Lapisan" cenderung bocor juga; Jika ada lapisan yang secara fisik dipisahkan oleh batas proses / mesin (IE web UI dan logika backend bisnis), aturan akan diduplikasi untuk membuat semuanya berfungsi dengan baik. Yaitu beberapa logika bisnis berakhir di UI, meskipun itu adalah "aturan bisnis", karena pengguna perlu UI untuk responsif.

Jika kerangka kerja yang digunakan, atau arsitektur yang digunakan, tahan terhadap perubahan dan kebocoran kecil, yaitu berdasarkan data meta, dan disesuaikan secara dinamis melalui semua lapisan, itu bisa kurang menyakitkan. Tetapi sebagian besar kerangka kerja ini adalah masalah besar, membutuhkan perubahan UI, perubahan lapisan bisnis, dan perubahan basis data, untuk setiap perubahan kecil, dan menyebabkan lebih banyak pekerjaan dan lebih sedikit bantuan daripada teknik yang seharusnya dihasilkan.

Saya mungkin akan dibanting karena ini, tapi itu dia :)

JavaBeans

Penggunaan JavaBeans di Jawa. Lihat pertanyaan saya. Mengapa saya tidak menggunakan POJO yang tidak dapat diubah sebagai ganti JavaBeans? di StackOverflow.

Kisah Pengguna / Kasus Penggunaan / Persona

Saya memahami kebutuhan akan ini ketika Anda memprogram untuk industri yang tidak Anda kenal, tetapi saya pikir ketika mereka diterapkan dengan kekuatan penuh mereka menjadi terlalu korporat dan menjadi buang-buang waktu.

Batas 80 char / line bodoh

Saya memahami bahwa beberapa kompromi perlu dibuat agar sesuai dengan kecepatan pelari paling lambat di sisi GUI (batasan resolusi layar, dll.) Tetapi, mengapa aturan itu berlaku untuk pemformatan kode?

Lihat ... Ada penemuan kecil ini yang disebut bilah gulir horizontal yang dibuat untuk mengelola ruang layar virtual di luar batas piksel paling kanan. Mengapa tidak pengembang, yang telah berhasil membuat alat peningkatan produktivitas yang hebat seperti penyorotan sintaksis dan pelengkapan otomatis menggunakannya?

Tentu, ada editor CLI yang digunakan secara religius oleh dinosaurus * nix yang mengikuti batasan lama yang lelah dari terminal VT220 mereka, tetapi mengapa kita semua berpegang pada standar yang sama?

Saya katakan, sekrup batas 80 char. Jika dinosaurus cukup epik untuk meretas emacs / vim sepanjang hari, mengapa tidak bisa harus mampu membuat ekstensi yang secara otomatis membungkus garis atau memberikan kemampuan gulir horizontal ke IDE CLI mereka?

Monitor piksel 1920x1080 pada akhirnya akan menjadi norma dan pengembang di seluruh dunia masih hidup di bawah batasan yang sama tanpa memedulikan mengapa mereka melakukannya kecuali, itulah yang mereka perintahkan untuk dilakukan oleh orang tua mereka ketika mereka baru saja mulai memprogram.

Batas char bukan merupakan praktik terbaik tetapi praktik khusus untuk sebagian kecil programmer dan harus diperlakukan seperti itu.

Sunting:

Dapat dimengerti bahwa banyak pengembang tidak menyukai bilah gulir horizontal karena memerlukan gerakan mouse jadi ... Mengapa tidak menambah batas lebar kolom ke angka yang lebih tinggi (dari 80) bagi kita yang menggunakan layar modern.

Ketika monitor komputer 800x600 menjadi norma bagi sebagian besar pengguna, pengembang web meningkatkan lebar situs web mereka untuk mengakomodasi mayoritas ... Mengapa pengembang tidak dapat melakukan hal yang sama.

Mengukur, Mengukur, Mengukur

Sangat bagus, ukur saja, tetapi untuk mengisolasi bug kinerja, pengukuran bekerja serta eliminasi berturut-turut. Inilah metode yang saya gunakan.

Saya sudah berusaha melacak sumber "kebijaksanaan" ukuran-ukuran. Seseorang dengan kotak sabun yang cukup tinggi mengatakannya, dan sekarang ia bepergian.

Guru saya menuntut saya memulai semua pengidentifikasi saya (tidak termasuk konstanta) dengan huruf kecil, misalnya myVariable.

Saya tahu ini sepertinya hal kecil, tetapi banyak bahasa pemrograman memerlukan variabel untuk memulai dengan huruf besar. Saya menghargai konsistensi, jadi kebiasaan saya memulai semuanya dengan huruf besar.

Gunakan Lajang

Ketika Anda hanya harus memiliki satu contoh dari sesuatu. Saya tidak bisa tidak setuju lagi. Jangan pernah menggunakan singleton dan hanya mengalokasikannya sekali dan melewati pointer / objek / referensi yang diperlukan. Sama sekali tidak ada alasan untuk tidak melakukan ini.

Menggunakan unsigned int sebagai iterator

Kapan mereka akan belajar bahwa menggunakan int yang ditandatangani jauh lebih aman dan lebih sedikit rawan bug. Mengapa sangat penting bahwa indeks array hanya dapat berupa angka positif, sehingga semua orang senang mengabaikan kenyataan bahwa 4 - 5 adalah 4294967295?

Metode seharusnya tidak lebih dari satu layar

Saya setuju dengan prinsip tanggung jawab tunggal sepenuhnya tetapi mengapa orang menganggapnya berarti "suatu fungsi / metode tidak dapat lebih dari satu tanggung jawab tunggal pada tingkat granularitas logis terbaik"?

Idenya sederhana. Fungsi / metode harus menyelesaikan satu tugas. Jika bagian dari fungsi / metode itu dapat digunakan di tempat lain, potonglah ke fungsi / metode itu sendiri. Jika itu dapat digunakan di tempat lain pada proyek, pindahkan ke kelasnya sendiri atau kelas utilitas dan membuatnya dapat diakses secara internal.

Memiliki kelas yang berisi 27 metode pembantu yang hanya dipanggil satu kali dalam kode adalah bodoh, buang-buang ruang, peningkatan kompleksitas yang tidak perlu, dan tenggang waktu yang sangat besar. Kedengarannya lebih seperti aturan yang baik untuk orang-orang yang ingin terlihat sibuk mengembalikan kode tetapi tidak menghasilkan banyak.

Ini peraturan saya ...

Tulis fungsi / metode untuk mencapai sesuatu

Jika Anda menemukan diri Anda akan menyalin / menempelkan beberapa kode, tanyakan pada diri Anda apakah akan lebih baik untuk membuat fungsi / metode untuk kode itu. Jika suatu fungsi / metode hanya dipanggil satu kali pada fungsi / metode lain, apakah benar-benar ada gunanya memilikinya di tempat pertama (akan lebih sering dipanggil di masa depan). Apakah berharga untuk menambahkan lebih banyak lompatan keluar / keluar dari fungsi / metode selama debugging (Yaitu, apakah lompatan yang ditambahkan membuat debugging lebih mudah atau lebih sulit)?

Saya sepenuhnya setuju bahwa fungsi / metode yang lebih besar dari 200 baris perlu diteliti tetapi beberapa fungsi hanya menyelesaikan satu tugas dalam banyak baris dan tidak mengandung bagian yang berguna yang dapat diabstraksi / digunakan pada sisa proyek.

Saya melihatnya dari perspektif pengembang API ... Jika pengguna baru melihat diagram kelas dari kode Anda, berapa banyak bagian dari diagram itu yang masuk akal dalam keseluruhan proyek yang lebih besar dan berapa banyak yang akan ada hanya sebagai pembantu ke bagian lain di dalam proyek.

Jika saya memilih antara dua programmer: yang pertama memiliki kecenderungan untuk menulis fungsi / metode yang mencoba melakukan terlalu banyak; yang kedua memecah setiap bagian dari setiap fungsi / metode ke tingkat granularity terbaik; Saya akan memilih tangan pertama ke bawah. Yang pertama akan mencapai lebih banyak (yaitu, menulis lebih banyak daging dari aplikasi), kodenya akan lebih mudah untuk di-debug (karena lebih sedikit lompatan masuk / keluar dari fungsi / metode selama debugging), dan dia akan membuang lebih sedikit waktu melakukan pekerjaan yang sibuk menyempurnakan cara kode terlihat vs menyempurnakan cara kerja kode.

Batasi abstraksi yang tidak perlu dan jangan mencemari autocomplete.