Topik-topik pengembangan perangkat lunak yang berubah pikiran setelah 10 tahun di industri

• Empat tahun lalu saya juga menulis tentang topik yang sama, dan karena ingin meninjau kembali setelah 10 tahun, saya menulisnya lagi

Pemikiran yang berubah

• Kesederhanaan tidak datang dengan sendirinya, melainkan sesuatu yang memerlukan upaya berkelanjutan
• Saya sadar tidak ada alasan untuk merasa bangga karena mampu mengelola atau memahami kompleksitas
• Dalam tim yang berisi campuran tingkat pengalaman yang beragam, bahasa bertipe adalah keharusan
• Java adalah bahasa yang justru hebat karena membosankan
• REPL tidak terlalu berguna sebagai alat desain, tetapi berguna untuk eksplorasi
• Pemrograman yang sebenarnya seharusnya hampir seluruhnya selesai pada tahap sebelum menulis kode
• Pengembangan frontend telah menjadi wilayah seperti mimpi buruk Kafkaesque, dan tidak lagi menyenangkan
• Konsep keanggunan tidak bisa menjadi metrik yang benar-benar terukur
• Manajemen yang benar-benar baik sangatlah berharga (sepanjang karier saya, saya hampir tidak pernah melihat manajemen yang benar-benar baik)
• DynamoDB adalah database yang bagus jika benar-benar cocok dengan workload tertentu
• Pemrograman berorientasi objek adalah pendekatan yang sangat unggul di domain yang cocok. Sikap yang hanya memuja Functional adalah kebodohan

Pendapat yang saya peroleh

• Inti dari engineering adalah komunikasi
• Jangan menerapkan konsep Monad terlalu berlebihan di Java
• Query Planner adalah sesuatu yang kejam
• Saat merasa sesuatu itu 'mudah', sebenarnya itu tanda bahwa kita belum benar-benar memahaminya
• Pengembang junior perlu diberi ruang untuk bereksplorasi dan membuat kesalahan
• Soft skill harus dikembangkan secara aktif. Efek investasinya terlihat seketika
• Dalam pengembangan aplikasi umum, hampir tidak ada yang namanya 'abstraksi benar-benar serbaguna'. Lebih baik menulis hanya kode yang dibutuhkan
• Sebaliknya, pengembangan library adalah pekerjaan merancang abstraksi. Perlu meluangkan waktu untuk menemukan struktur yang tepat (bentuk aljabar)
• ORM bermasalah di semua bahasa dan semua implementasi. Lebih baik langsung menulis SQL sendiri
• Masalah Functional programming sering kali ada pada para pengikut fanatiknya
• Jika waktunya cukup panjang, Anda akan sangat menyesal membangun sistem di atas Serverless Functions
• Type adalah pernyataan yang kita buat saat memandang dunia
• Distributed lock tetap merupakan masalah yang sangat sulit
• Kemampuan pemodelan formal dan analisis adalah kompetensi yang wajib dimiliki
• Sifat terpenting dalam integration test suite adalah isolasi
• DynamoDB juga bisa menjadi pilihan terburuk untuk pengembangan aplikasi umum
• Kebanyakan orang tidak terlalu peduli pada 'craftsmanship' kode. Hargai mereka yang peduli, tetapi dengan yang lain, kita harus bekerja sama dari posisi mereka saat ini
• Saya pikir bahasa gradual, dependently typed adalah masa depan
• Saya yakin komentar di kode pengujian tidak akan pernah terlalu banyak

Pendapat yang tidak berubah

• Saya masih menganggap orang yang terobsesi pada hal-hal sepele seperti gaya kode dan aturan linting adalah golongan yang aneh. Kita harus fokus pada hal yang lebih penting
• Saya tetap berpendapat bahwa code coverage tidak ada hubungannya dengan kualitas kode (dalam banyak kasus bahkan cenderung berbanding terbalik)
• Monolith masih merupakan pilihan yang baik
• Saya mengakui sulit mengalahkan penelitian dan perbaikan RDBMS yang telah terakumulasi selama puluhan tahun
• Diperlukan alasan yang benar-benar masuk akal untuk menerapkan micro-service (sangat disayangkan belakangan ini semakin dianggap sebagai sesuatu yang wajar)
• Sebagian besar proyek (bahkan proyek internal AWS sekalipun) sebenarnya tidak membutuhkan 'scaling', dan sering kali justru merugikan jika dirancang dengan asumsi scaling sejak awal
• Saya pikir 93% manajer proyek, atau mungkin sekitar 95,2%, bisa hilang tanpa banyak dampak, atau bahkan efisiensi justru meningkat (persentasenya naik dibanding empat tahun lalu)

• Saya akan melihat lagi bagaimana pandangan ini berubah saat memasuki tahun ke-15

[gongon]

Sebagian besar adalah cerita yang terasa relevan.

[aer0700]

Sebagian besar proyek tidak pernah mencapai momen ketika scaling benar-benar dibutuhkan, atau keburu hilang sebelum itu menjadi perlu...

[roxie]

Apa itu Gradual, dependently typed languages..?

[botplaysdice]

Dari obrolan sepintas yang saya dengar di podcast, sepertinya ini sistem tipe di mana nilai memengaruhi tipe. Melihat penulis artikel ini menyebut bahasa fungsional, kemungkinan memang itu yang dimaksud. Karena ini sesuatu yang diteliti dan dikembangkan di ranah bahasa fungsional....

Misalnya, tipe List... kalau nilainya semua sudah terurut maka menjadi SortedList....

Kalau punya sifat seperti ini, pemeriksaan tipe saat kompilasi bisa membuktikan lebih banyak hal.

Kalau ada fungsi yang menerima SortedList lalu mengembalikan SortedList... tetapi kalau ternyata ada bug di kodenya sehingga merusak kondisi terurutnya, maka saat kompilasi akan muncul type error.

Tentu saja.... biaya pemeriksaan tipenya mungkin cukup mahal...

Saya sendiri sama sekali belum punya gambaran seberapa jauh kepraktisannya sudah berkembang.

[roxie]

Aha, terima kasih. Kedengarannya menarik dan keren...

[xguru]

Ini merujuk pada bahasa yang dapat diterapkan sambil berpindah secara fleksibel antara tipe statis dan dinamis.

[extendednoob]

Java membosankan, dan justru karena itu Java adalah bahasa yang hebat
Apa maksudnya?

[botplaysdice]

Siapa pun yang membuatnya hasilnya mirip-mirip, jadi lebih mudah dirawat; mungkin maksudnya seperti itu.

[vwjdalsgkv]

Mungkin maksudnya adalah bahwa tidak ada bagian yang perlu diberi perhatian khusus atau yang akan mengejutkan para developer, sehingga justru memberi rasa stabil karena itulah adanya.

[dbs0829]

Hal-hal terkait gaya kode atau linting sebagian besar bisa diselesaikan dengan tool, jadi sebaliknya, kalau bertemu orang yang tidak peduli soal itu, saya jadi tidak ingin bekerja bersama mereka.

[beoks]

Setuju. Saya menambahkan pemeriksaan gaya ke CI agar jika gaya tidak dipatuhi, proses merge juga diblokir.

[edunga1]

> Saya masih menganggap orang-orang yang terobsesi pada hal-hal sepele seperti gaya kode dan aturan linting sebagai golongan yang aneh. Kita harus fokus pada hal yang lebih penting.

https://www.youtube.com/watch?v=JcY35HD77lg&t=828s
Namun, ada juga pendapat bahwa hal-hal itu tidak boleh begitu saja diabaikan, karena sebagai manusia hal tersebut bisa menjadi faktor yang membuat kita sulit berkonsentrasi, jadi lebih baik diselesaikan lalu lanjut bekerja.

[yadameda]

> Kebanyakan orang tidak terlalu peduli pada 'keahlian kerajinan' dalam menulis kode. Hargai orang-orang yang memang peduli, tetapi dengan yang lain, kita harus berkolaborasi dari posisi mereka berada.

Setuju..

[jjpark78]

Saya salah satu orang yang menyesal membangun sistem di atas serverless.

Cold start masih tetap lambat,
pada titik tertentu trafik melonjak drastis hingga akhirnya hampir tidak ada bedanya dengan on-demand,
dan meski sudah mengerahkan segala cara, deployment tetap terlalu lambat.

[jjpark78]

Code coverage tidak selalu berkaitan dengan kualitas kode jika

• coverage-nya sangat rendah hingga tidak bermakna (menurut standar saya, 80 persen) atau
• skenario pengujiannya hanya ditulis untuk skenario normal yang berjalan semata-mata pada kode yang benar

Saya rasa kemungkinan hanya ada dua hal itu.

Menurut saya, kode pengujian baru benar-benar bermakna ketika memiliki coverage yang tinggi dan menguji bagian yang sama berkali-kali dengan input yang berbeda melalui berbagai skenario yang memicu error.

[annyeong]

Saya lebih merasa cocok menafsirkannya dalam arti yang belakangan. Angka code coverage yang tinggi tidak otomatis berkaitan langsung dengan kualitas kode; yang penting adalah mengisinya dengan test case yang bermakna.

[carnoxen]

> Java justru bahasa yang hebat karena membosankan

Agak lucu juga wkwkwk

[richardk]

Saya setuju

> Dalam pengembangan aplikasi umum, hampir tidak ada yang namanya 'abstraksi generik yang benar-benar universal'. Lebih baik menulis hanya kode yang dibutuhkan

[xguru]

Topik pengembangan perangkat lunak yang berubah pandangannya setelah 6 tahun berada di industri

[GN⁺]

Opini Hacker News

• Ada pendapat yang memandang aneh orang-orang yang terobsesi dengan gaya kode atau aturan linting. Namun, memperhatikan detail berarti menghargai jiwa craftsmanship
  • Ada pengembang yang tidak setuju dengan pendapat bahwa sebagian besar pemrograman harus selesai sebelum menulis kode. Ia menganggap penting untuk melakukan coding dan perancangan secara berulang
  • Ada pendapat bahwa yang penting adalah mengelola dan memahami kompleksitas. Sistem yang sederhana hanya memindahkan kompleksitas ke tempat lain
  • Ada juga yang tidak setuju dengan pendapat bahwa Java adalah bahasa yang membosankan. Menurutnya, kode Java seperti Spring bukan membosankan, tetapi juga tidak menyenangkan
  • Ada juga yang tidak setuju dengan pendapat bahwa pemrograman seharusnya selesai tanpa menulis kode. Tanpa menulis kode, orang mudah lepas dari realitas
  • Ada juga yang tidak setuju dengan pendapat bahwa pemodelan dan analisis formal itu esensial. Menurutnya, eksperimen lebih penting
  • Ada pendapat bahwa memberi banyak komentar pada kode pengujian itu baik
  • Ada pendapat bahwa pengembangan frontend seperti mimpi buruk. Namun, tidak ada masalah besar saat memperbarui aplikasi React + Typescript + MobX
  • Ada pendapat bahwa pengembangan perangkat lunak harus dilihat berbeda sesuai tahap organisasi. Startup dan organisasi yang sudah mencapai product-market fit harus didekati dengan cara berbeda
  • Ada pendapat bahwa Checked Exceptions di Java adalah ide yang bagus. Hanya perlu sedikit perbaikan sintaks untuk penanganan error yang lebih baik
  • Ada pendapat bahwa arsitektur monolitik masih tetap bagus. Sulit mengungguli riset dan perbaikan pada RDBMS
  • Ada pendapat bahwa dalam tim dengan tingkat pengalaman yang beragam, bahasa bertipe adalah hal yang esensial. Sudut pandang programmer perlu dipertimbangkan
  • Ada pendapat bahwa meskipun sebagian besar project manager menghilang, dampaknya tidak akan besar
  • Ada pendapat bahwa stres soal gaya kode muncul karena penting untuk menyesuaikan diri dengan gaya proyek
  • Ada juga orang yang menganggap pengembangan frontend seperti mimpi buruk, tetapi kadang tetap menikmatinya
  • Ada pendapat bahwa keanggunan bukanlah indikator yang sesungguhnya. Solusi yang elegan tidak selalu praktis
  • Ada pendapat bahwa DynamoDB adalah pilihan terburuk untuk pengembangan aplikasi umum. Dalam banyak kasus, SQL lebih cocok