Sudah lama sejak saya membaca artikel tentang pemrograman dengan senyum terus-menerus di wajah saya.

Grug seperti kebanyakan dari kita, bukan pengembang berotak besar, tetapi manusia gua sederhana yang ingin menulis kode dengan kualitas yang layak dan menyelesaikan sesuatu.

Grug tidak sepandai itu, tapi itu mungkin kekuatan supernya. Ada banyak hikmah dalam teks tersebut.

Bagi saya, butuh beberapa menit untuk meresapi cara Grug mengekspresikan dirinya, tetapi itu sepadan!

Baca artikel lengkapnya di grugbrain.dev

Berikut adalah beberapa nugget emas dari Grug :

Kompleksitas

kompleksitas adalah iblis roh yang memasuki basis kode dengan maksud baik tetapi pada akhirnya pengembang dan manajer proyek non grug-brain sangat clubbable yang tidak takut kompleksitas roh iblis atau bahkan tahu tentang kadang-kadang

Mengatakan tidak

senjata terbaik melawan kompleksitas roh iblis adalah kata ajaib: "tidak"

tidak, grug tidak membangun fitur itu
tidak, grug tidak membangun abstraksi itu

perhatikan, saran teknik yang bagus ini tetapi saran karier yang buruk: "ya" adalah kata ajaib untuk rock yang lebih bersinar dan bertanggung jawab atas suku besar pengembang

sedih tapi benar: belajar "ya" lalu belajar menyalahkan orang lain ketika gagal, saran karir yang ideal

Memfaktorkan Kode Anda

jangan memperhitungkan aplikasi Anda terlalu dini!

pengembang otak besar sering tidak menyukai ini sama sekali dan menciptakan banyak abstraksi di awal proyek

grug tergoda untuk meraih klub dan berteriak “otak besar tidak ada kode pemeliharaan! otak besar bergerak pada kode cuti komite arsitektur berikutnya untuk kesepakatan grug!”

alih-alih grug, cobalah untuk membatasi kerusakan otak besar pengembang di awal proyek dengan memberi mereka hal-hal seperti diagram UML (tidak merusak kode, mungkin membuangnya) atau dengan menuntut demo kerja besok

demo yang bekerja terutama trik yang bagus: paksa otak besar membuat sesuatu untuk benar-benar bekerja untuk dibicarakan dan kode untuk melihat hal itu, akan membantu otak besar melihat kenyataan di lapangan lebih cepat

Pagar Chesterton

grug mengerti semua programmer platonis pada tingkat tertentu menginginkan kesempurnaan musik bola dalam kode. tetapi bahaya ada di sini, dunia ini jelek dan kotor berkali-kali dan begitu pula kodenya

grug tidak mengatakan tidak pernah memperbaiki sistem, cukup bodoh, tetapi merekomendasikan luangkan waktu untuk memahami sistem terlebih dahulu terutama sistem yang lebih besar dan menghargai kode yang berfungsi hari ini meskipun tidak sempurna

Peralatan

alat cinta grug

debugger yang baik bernilai berat di batu-batuan yang bersinar, sebenarnya juga lebih: ketika dihadapkan dengan bug grug akan sering menukar semua batu yang bersinar dan mungkin beberapa anak untuk debugger yang baik dan lagipula debugger tidak menimbang apa pun sejauh yang dapat dikatakan oleh grug

grug selalu merekomendasikan programmer baru untuk mempelajari debugger yang tersedia dengan sangat mendalam, fitur-fitur seperti break point bersyarat, evaluasi ekspresi, navigasi tumpukan, dll sering mengajarkan grug baru lebih banyak tentang komputer daripada kelas universitas!

Jenis Sistem

grug sangat menyukai sistem tipe membuat pemrograman lebih mudah. untuk grug, ketik systems most value when grug hit dot on keyboard and list of things grug can do pop up magic. ini 90% dari nilai sistem tipe atau lebih ke grug

selalu kebanyakan sistem tipe nilai datang: tekan titik lihat apa yang bisa dilakukan grug, jangan pernah lupa!

Pemisahan Kekhawatiran

Pemisahan Kepedulian (SoC) adalah ide kuat lainnya di benak banyak pengembang

di sini grug jauh lebih masam daripada KERING dan bahkan menulis esai berotak besar tentang prinsip desain alternatif lokalitas perilaku (LoB) terhadap SoC

grug lebih suka meletakkan kode pada hal yang melakukan hal itu. sekarang ketika grug melihat benda itu, grug tahu benda apa yang dilakukan benda itu, selalu melegakan!

Penebangan

grug penggemar berat logging dan mendorong banyak hal, terutama di cloud yang diterapkan. beberapa non-grugs mengatakan penebangan mahal dan tidak penting. grug dulu tidak berpikir seperti ini lagi

tips grug tentang logging adalah:

• log semua cabang logis utama dalam kode (jika/untuk)
• jika "permintaan" menjangkau beberapa mesin di infrastruktur cloud, sertakan ID permintaan di semua sehingga log dapat dikelompokkan
• jika memungkinkan buat level log dikontrol secara dinamis, sehingga grug dapat dihidupkan/dimatikan saat membutuhkan masalah debug (banyak!)
• jika memungkinkan buat level log per pengguna, sehingga dapat men-debug masalah pengguna tertentu

pengembang otak ultra terbesar pernah berkata:

optimasi prematur adalah akar dari segala kejahatan

grug merekomendasikan untuk selalu memiliki profil kinerja dunia nyata yang konkret yang menunjukkan masalah kinerja tertentu sebelum mulai mengoptimalkan.

tidak pernah tahu apa masalah sebenarnya, grug sering mengejutkan! sangat sering!

Lebah

Pembuat API berpikir terlalu abstrak dan berotak besar

biasanya grug tidak terlalu peduli dengan detail api: ingin menulis file atau mengurutkan daftar atau apa pun, hanya ingin memanggil write() atau sort() atau apa pun

tetapi pengembang api otak besar mengatakan:

jangan terlalu cepat, grug! apakah file itu terbuka untuk menulis? apakah Anda mendefinisikan Pembanding untuk jenis itu?

grug menemukan tangan yang menahan diri meraih tongkat lagi

tidak peduli tentang hal itu sekarang, hanya ingin menyortir dan menulis file mr big brain!

Pengembangan Ujung Depan

beberapa non-grugs, ketika berhadapan dengan pengembangan web mengatakan:

Saya tahu, saya akan membagi basis kode front end dan back end saya dan menggunakan perpustakaan SPA baru yang panas berbicara dengan ujung belakang GraphQL JSON API melalui HTTP (yang lucu karena saya tidak mentransfer hypertext)

sekarang kamu memiliki dua sarang roh iblis yang rumit

grug tidak seperti perpustakaan front-end kompleks besar yang digunakan semua orang

grug make htmx dan hyperscript untuk dihindari

pertahankan kompleksitas rendah, HTML sederhana, hindari banyak javascript, eter alami dari iblis kompleksitas roh

mungkin mereka bekerja untuk Anda, tetapi tidak ada lowongan pekerjaan, maaf

bereaksi lebih baik untuk pekerjaan dan juga beberapa jenis aplikasi, tetapi juga Anda menjadi pendeta kompleksitas setan apakah Anda suka atau tidak, maaf seperti kehidupan ujung depan

Takut Terlihat Bodoh

catatan! sangat bagus jika grug senior bersedia mengatakan secara terbuka: "hmmm, ini terlalu rumit untuk grug"!

banyak developer Fear Of Looking Dumb (FOLD), grug juga sekaligus FOLD, tapi grug belajar melupakan: yang penting senior grug bilang “ini terlalu rumit dan membingungkan saya”

ini membuat siswa junior tidak masalah untuk mengakui terlalu rumit dan tidak mengerti juga, sering kali kasus seperti itu! LIPAT sumber utama kekuatan iblis kompleksitas atas pengembang, terutama grug muda!

Sindrom Penipu

grug perhatikan banyak penipu seperti itu merasa dalam pengembangan

sekarang, grug membuat perangkat lunak dengan banyak pekerjaan dan kesuksesan open source sedang, namun grug sendiri sering merasa tidak tahu apa yang harus dilakukan! sangat sering! grug masih takut membuat kesalahan memecahkan kode semua orang dan mengecewakan grug lain, penipu!

mungkin sifat pemrograman bagi sebagian besar grug untuk merasa penipu dan baik-baik saja adalah yang terbaik: tidak ada penipu jika semua orang penipu

setiap grug muda yang membaca sejauh ini mungkin baik-baik saja dalam karir program meskipun frustrasi dan kekhawatiran selalu ada, maaf