menurut orang ini siapa? Apa yang dia ketahui tentang menulis kode "hebat"?!

Anda akan 100% benar untuk memikirkan itu - dan sejujurnya… Saya memiliki lebih banyak pengalaman menulis kode yang tidak bagus.

kode yang tidak bagus ditulis karena berbagai alasan (beberapa tercantum di bawah)

1. sulit
2. "hebat" itu subyektif
3. perangkat lunak tidak pernah selesai (tidak bisa "menjadi" hebat, harus "tetap" hebat)
4. kualitas dapat berubah berdasarkan kebutuhan saat ini
5. banyak perangkat lunak yang berfungsi tidak bagus (panutan buruk)
6. orang yang menginginkan perangkat lunak seringkali bukan insinyur perangkat lunak
7. …

Terlepas dari pengalaman mendalam saya dengan kode suboptimal — saya memiliki hampir satu dekade pengalaman meminta komputer (seramah mungkin) untuk melakukan hal-hal yang saya dan orang lain inginkan.

Selama ini saya mulai menghargai berbagai konsep dan pola, dan juga mempelajari ketidakpercayaan yang mendalam terhadap orang lain.

Pada artikel ini saya akan menjelaskan beberapa hal baik dan buruk dari perangkat lunak — dan memberikan bukti pendukung dari orang-orang pintar yang sebenarnya.

Selamat datang di perjalanan

Apa itu "hebat"

Mari kita mulai dengan mendefinisikan apa itu "hebat". Namun mungkin lebih mudah untuk mendefinisikan dengan cepat menyatakan apa yang bukan.

Kode yang bagus adalah

1. tidak sulit dibaca
2. tidak sulit untuk alasan tentang
3. tidak menyebabkan Anda membenci diri sendiri hari ini atau 7 hari setelah menulisnya

1. 90% struktur dan 10% sintaks
2. fungsi abstraksi informasi dipasangkan dengan manajemen sumber daya yang diprediksi
3. teman matematika (khusus teori himpunan/kategori)
4. ditulis untuk manusia bukan perangkat keras

1. Struktur 90% dan sintaks 10%.

Semua ide tesis ini terinspirasi oleh topik yang jauh lebih komprehensif dan mendalam. Mengenai struktur kita dapat melihat paradigma pemrograman SOLID.

SOLID adalah singkatan dari 5 "aturan" yang harus diikuti untuk membangun perangkat lunak yang dapat dipelihara. Konsep yang tercantum di bawah ini

S - Single-responsiblity Principle
O - Open-closed Principle
L - Liskov Substitution Principle
I - Interface Segregation Principle
D - Dependency Inversion Principle

Prinsip-prinsip ini berputar di sekitar kekuatan Pemrograman Berorientasi Objek (suka atau benci) dan menjelaskan cara elegan untuk mengiris abstraksi Anda menjadi potongan-potongan yang ramah perangkat lunak.

Dengan mengikuti prinsip-prinsip ini, Anda dapat menghindari banyak kerumitan buruk yang muncul dalam perangkat lunak fungsional.

Misalnya, dengan prinsip SOLID Anda akan mengurangi jejak kode Anda dan memusatkan file di sekitar fungsionalitas umum; membuatnya lebih mudah untuk menavigasi dan menambahkan/menghapus fitur tanpa memengaruhi bagian lain dari basis kode Anda.

Masalah ini sepenuhnya dihindari pada level struktur aplikasi Anda — bukan pada level kode

Kebersihan tingkat struktur adalah cara ampuh untuk menegakkan organisasi yang langgeng.

Artikel yang mudah dicerna di SOLID by Digital Ocean: di sini

Jika itu tidak cukup — Paman Bob terus menjatuhkan bangers .

Saya akan sangat merekomendasikan bukunya yang lebih baru dirilis pada tahun 2017 (dan sejujurnya semuanya juga lebih baru).

“Arsitektur Bersih: Panduan Pengrajin untuk Struktur dan Desain Perangkat Lunak” —https://www.oreilly.com/library/view/clean-architecture-a/9780134494272/

Buku ini mengeksplorasi bagaimana Anda dapat memperluas konsep ini ke tingkat sistem .

Saat kami memindahkan lebih banyak aplikasi ke "awan" dan memanfaatkan layanan terdistribusi. Prinsip desain ini semakin berdampak pada kehebatan kode Anda.

kode hebat hanyalah alat yang mengisi struktur desain aplikasi Anda, sistem Anda harus diekspresikan melalui strukturnya, bukan sintaks.

2. fungsi abstraksi informasi dipasangkan dengan manajemen sumber daya yang diprediksi

um… apa. Anda benar-benar kehilangan saya dengan yang satu itu. fungsi dari apa?

mari kita hancurkan.

“fungsi abstraksi informasi” adalah cara ringkas untuk menyatakan bahwa kode kita adalah keluaran dari abstraksi kita .

Dengan kata lain — kode kita adalah cerminan dari bagaimana kita memutuskan untuk membagi konsep aplikasi kita.

Lebih konkret; jika kita dihadapkan pada masalah dan memutuskan bahwa kita harus membuat "Pengguna" dan "Sesi", kita telah secara efektif mengiris masalah kita ke dalam ide abstrak pengguna dan sesi tersebut.

…oke Saya pikir kita telah membahas “fungsi abstraksi informasi”.

Selanjutnya kami memasangkannya dengan "pengelolaan sumber daya yang diprediksi" yang merupakan cara yang bagus untuk mengatakan bahwa insinyur perangkat lunak ditugaskan untuk dapat melihat ke masa depan — dan membangun sistem yang dapat menahan perubahan di masa depan

Jika Anda tidak tahu — itu salah Anda sebagai programmer bahwa Anda tidak menggunakan kerangka kerja terbaru setahun sebelum dibuat. Bagaimana kamu tidak tahu !? (tolong dibaca sebagai sarkasme — saya berjanji ini bukan masalah pribadi).

Jadi, untuk meringkas; kualitas kode kita tidak selalu kompleksitas komputasional, jumlah baris, atau nama variabel yang elegan.

Ini adalah kemampuan untuk secara efektif mengiris masalah Anda menjadi potongan-potongan abstrak yang akan bertahan dari perubahan yang tidak terduga di masa depan.

Ya ya ya, saya tahu; itu sepertinya tidak mungkin. Memang tidak — dan itu tugas kami sebagai pengembang untuk mengelola hal-hal yang kami ketahui, dan hal-hal yang kami tahu tidak kami ketahui.

Ini adalah latihan dalam penilaian risiko dan perencanaan biaya - ya, tidak tahu Anda mendaftar untuk itu, bukan?

Namun, ada harapan!

Dengan mengikuti konsep yang dapat dipercaya (lebih banyak lagi akan segera hadir) kita dapat memperkuat diri kita sendiri dan aplikasi untuk dunia yang terus berubah.

Sebelum kita membahas hal-hal yang benar-benar bagus — kita dapat mengakui beberapa ide yang layak "dipercaya" di sini.

• Badan standar (ada orang yang telah memikirkannya secara mendalam — dan mereka akan sangat menghargai jika Anda memanfaatkan karya hebat mereka. Ini terutama berlaku untuk algoritme, keamanan, lintas platform, dan hal penting lainnya seperti kode QR).
• Bahasa statis dan sangat diketik (sejujurnya ini bukan tentang masalah keamanan tingkat rendah yang akan Anda hindari. Ini tentang sifat tipe yang berpusat pada manusia. Satu, jika Anda melanggar jenis dalam kode Anda, kompiler akan meneriaki Anda, dan dua, pengembang lain akan benar-benar tahu apa yang dilakukan kode Anda).
• Puisi (lebih sedikit tentang kata-kata dan lebih banyak tentang kemampuan untuk mengkomunikasikan makna yang kompleks dengan sedikit simbol. Kode Anda adalah puisi, meskipun audiensnya sangat tidak imajinatif tetapi tetap harus dibaca pendek dan manis).

Meskipun Anda mungkin tidak - kode Anda harus menjadi sobat matematika.

Ya, saya tahu — matematika itu membosankan dan Anda tidak pernah menggunakan turunan dalam kehidupan nyata.

Tetapi…. Saya berjanji - ini bisa sangat membantu. Ini sebenarnya alat paling tepercaya yang kami miliki.

Ini dapat dipercaya karena memiliki sejarah panjang dalam kontribusi sumber terbuka dan mereka telah mengatasi sebagian besar bug dalam perangkat lunak inti. Sekarang para devs (ahli matematika) sibuk memikirkan hal-hal gila seperti fisika kuantum.

Kami dapat mempercayai hal-hal berguna seperti kriptografi untuk mengamankan rekening bank dan komunikasi kami. Kita dapat mempercayai teori himpunan untuk menerapkan sistem tipe [TAMBAHKAN BAHASA PEMROGRAMAN FAVORIT DI SINI]. Kami bahkan dapat mempercayai aljabar linier untuk mengoptimalkan rute kami di peta Google dan ChatGPT untuk menjaga hal-hal konyol.

Penting untuk diingat bahwa di balik semua UI mewah dan layar mengkilap — komputer kita hanya itu; komputer.

Jika Anda menghapus semua kerumitan, Anda akan memiliki tulang punggung penjumlahan dan pengurangan.

Mungkin, mungkin saja… ada cara kita dapat menggabungkan semua kekuatan itu ke kode kita sendiri.

Mari menyelam lebih dalam

Saya akan mengambil tebakan liar dan berasumsi bahwa Anda (pembaca) sudah familiar dengan Pemrograman Berorientasi Objek,

Dan… Saya juga akan menebak lebih jauh bahwa Anda pernah mendengar tentang Pemrograman Fungsional - tetapi memutuskan itu adalah sesuatu untuk dipelajari di lain hari.

Jika Anda berada di kamp itu, maka Anda mungkin tidak menyadari keindahan dan keanggunan bahasa pemrograman yang lebih dekat mengikuti semantik matematika tradisional.

Kami (orang normal) dimanjakan dengan abstraksi yang disediakan oleh bahasa arus utama. Kami berharap dapat membuat variabel kapan pun kami mau, dan membangun aliran kontrol yang kompleks dengan menara ifdanelse

Namun, kami (orang normal) harus memperhatikan bagian penghitung pemrograman fungsional kami yang lebih cerdas.

Ada kekuatan super tersembunyi dalam bahasa yang sederhana dan membatasi. Mereka menyediakan metode yang dapat dibuktikan ( ⚡️ didukung oleh matematika ) untuk menunjukkan bahwa kode Anda mencakup semua kasus, atau dapat dipecah menjadi bagian-bagian pekerjaan terpisah yang dapat tersebar di seluruh mesin tanpa batas.

Infinity dan Proofs adalah ide yang sulit untuk programmer rata-rata tetapi ahli matematika mana pun memakannya untuk sarapan.

Misalnya salah satu pahlawan super ini dalam video di bawah ini, menunjukkan bagaimana pemodelan suatu sistem dapat memberikan cara untuk menemukan instruksi langkah demi langkah untuk mengeksploitasi bug kompleks yang luar biasa tanpa melihat kode sebenarnya

Rahasianya terletak pada kekuatan matematika formal yang diterapkan pada desain sistem.

Jika diterapkan dengan benar (dan tidak, ini tidak memerlukan penulisan ulang semuanya dalam bahasa fungsional), maka Anda mendapatkan semua manfaat matematika secara gratis.

Manfaat ini termasuk tetapi tidak terbatas pada

• secara otomatis menghasilkan tes untuk setiap kemungkinan cara program Anda dapat digunakan
• jelajahi implikasi menambahkan komponen atau sistem yang dihapus ke aplikasi Anda
• menjadi 100% yakin bahwa kode akan bekerja. Anda ingin benar-benar yakin bahwa perangkat lunak roda pendarat pesawat Anda berfungsi, bukan.
• hal-hal lain yang lebih kompleks yang dapat diajarkan oleh pembicara dalam video ini kepada Anda. Oh dan jika Anda benar-benar serius mempelajari ini, lihat TLA+

Mungkin kita bisa menggunakan beberapa konsep yang luar biasa membosankan itu untuk membuat kode kita luar biasa membosankan.

kode hebat harus bercita-cita untuk memiliki ide-ide konkret sehingga ide-ide yang sama itu berlaku lebih dari 1000 tahun dari sekarang

Pathagotem datang dengan beberapa perangkat lunak hebat untuk segitiga di ~570 SM…. itu seperti 1500 tahun yang lalu!

Mungkin kita harus belajar dari, atau menggunakan matematika jika memungkinkan — ini adalah cara terbaik yang kita ketahui sebagai manusia untuk mengekspresikan abstraksi yang tahan lama.

4. ditulis untuk manusia bukan perangkat keras

Oke cukup pada hal-hal matematika. Ketika kita berbicara tentang perangkat lunak — sebanyak kita berusaha menghindari manusia. Mereka selalu masuk ke dalam campuran.

Mari kita bicara tentang manusia. Bagaimana manusia cocok?

Yah… merekalah yang pertama-tama menginginkan perangkat lunaknya, dan sebenarnya merekalah yang menciptakan bahasa-bahasa ini.

Selain itu, merekalah yang peduli dengan semua ini — komputer tidak memiliki pendapat tentang kode yang mereka jalankan.

Orang-orang melakukannya. Orang mendefinisikan apa yang "bekerja" dan apa yang tidak.

Jadi - saya kira kita harus mengarahkan segalanya untuk hak asasi manusia?

Ya! dan itu tidak hanya berarti bahwa kita memerlukan aplikasi seluler yang cantik dan ergonomis.

Kita perlu memperluas kemanusiaan ke dalam pengembangan perangkat lunak. Kita harus merasakan ini di banyak tingkatan.

Kemanusiaan harus dalam pengalaman pengembang di semua tingkatan. Berikut ini adalah beberapa pertanyaan yang berpusat pada manusia.

• Orang-orang diarahkan ke basis kode. Apakah dokumentasi Anda memfasilitasi itu?
• Berapa banyak alat/perintah atau langkah penyiapan khusus yang harus saya lakukan?
• Seperti apa rasanya menambahkan tes baru? fitur baru?
• Berapa banyak kerangka kerja/bahasa yang diberlakukan oleh proyek Anda? Mungkinkah kurang?
• Berapa banyak upaya untuk beralih dari yang benar-benar baru menjadi produksi penuh?
• Seperti apa bentuk putusnya? dan apakah saya harus bangun untuk memperbaikinya?

Tapi tim kecil pengembang yang baik lebih besar dari jumlah jika itu bagian (bila dilakukan dengan benar).

Jadi bagaimana kita mendapatkan kode hebat dari sebuah tim?

Beberapa solusi lebih mudah daripada yang lain. Misalnya yang mudah tetapi efektif adalah menstandarkan segalanya — singkirkan semua kepribadian dari kontribusi individu.

Meskipun kedengarannya kasar — ​​sistem yang solid akan memiliki cara/jenis/pola khusus untuk melakukan sesuatu. Harus ada sedikit penyesuaian dan kreativitas di dalam sintaks kode.

Mengapa ini hal yang baik? Ini sangat meringankan beban mental pengembang. Jika ada "cara" untuk melakukan sesuatu - maka itu harus dilakukan dengan "cara" itu.

Ini secara efektif memindahkan solusi dari level kode ke level struktur (disebutkan sebelumnya). Karena kita perlu mengandalkan keputusan dan pola tingkat sistem daripada yang dipesan lebih dahulu.

Lebih sederhananya, semua pengembang harus berbagi jenis yang sama. Ini menghilangkan penyesuaian dan membuatnya lebih mudah untuk mengintegrasikan berbagai pekerjaan pengembang.

Ide ini harus diperluas lebih jauh daripada tipe dan karena banyak konsep yang dapat distandarisasi secara efektif pada tingkat sistem, semakin besar kode Anda.

kode hebat ditulis dengan sangat baik kontribusi dari anggota tim yang berbeda seringkali tidak dapat dibedakan dari bagian lain dari basis kode. Selain itu, Anda seharusnya tidak dapat melihat di mana satu orang memulai dan yang lainnya selesai.

Dalam video berikut, strategi untuk membangun tim dan meningkatkan produktivitas saat sistem menjadi lebih kompleks dieksplorasi secara mendetail.

Ini adalah topik yang menarik karena ide desain sistem yang kompleks berada di luar cakupan komputer dan menyentuh fenomena alam seperti biologi hewan/tanaman, interaksi sosial, dan planet.

Kami manusia biasa / pengembang memegang banyak kekuatan di tangan kami. Kita dapat membangun tumpukan besar kotoran yang rumit dan tidak berguna - dan dengan tangan yang sama itu dapat membangun sistem dinamis kompleks kita sendiri yang tidak berbeda dari planet tempat saya menulis ini.

Sampai lain kali, teruslah membuat kode, sebarkan cinta dan kedamaian ✌️