Estetika Penghancuran Perangkat Lunak - Cara Melawan Ketidakpastian

• Ada banyak hal yang tidak pasti dalam perangkat lunak.
• Mengapa tidak pasti?
  • Alasan terbesar adalah karena kompleksitas bisnis memang ada.
  • Karena kompleksitas, situasi terus berubah dan akibatnya prediksi pengembang sangat mungkin meleset.
  • Menara yang dibangun dengan susah payah runtuh dan berubah begitu saja menjadi utang teknis.
  • Alasan yang lebih kecil adalah kurangnya pengetahuan dan pengalaman.
  • Jika tidak memiliki pengetahuan dan pengalaman, pengembang bisa menciptakan sendiri utang teknis yang mereka buat.
  • Kompleksitas bisnis adalah faktor eksternal yang tidak dapat dikendalikan pengembang, sedangkan pengetahuan dan pengalaman adalah faktor internal yang dapat dikendalikan pengembang.
• Ada tiga jalan bagi pengembang.
  • Jalan pesimistis yang menganggap melawan kompleksitas itu tidak bermakna
    • Akhirnya mengatakan hal seperti 'toh nanti akan berubah, jadi kerjakan saja', 'teknologi itu tidak berarti'.
    • Karena ini jalan yang nyaman dan enak, tanpa sadar seseorang bisa memilih jalan ini.
  • Jalan yang mengabaikan kompleksitas dan hanya memikirkan idealisme semu
    • Percaya bahwa satu teknologi yang dianggap ideal oleh diri sendiri dapat menyelesaikan segalanya.
    • Menjadi memiliki pola pikir yang kaku dan seragam.
    • Ini jalan yang mudah membuat pengembang terjatuh, tetapi sulit untuk keluar darinya.
  • Jalan yang menerima kompleksitas dan melawannya
    • Meski menerima bahwa kesempurnaan itu mustahil, tetap berusaha mencari jalan yang lebih baik.
    • Jalan yang sulit dan harus dijalani dengan tabah.
  • Pengembangan perangkat lunak terus melawan kompleksitas.
    • Arsitektur, metodologi, agile, dan lain-lain…
    • Apa yang akan muncul berikutnya?
• Pengembangan berorientasi penghancuran
  • Jika melihat kenyataan, mudah terjebak pada pemikiran pesimistis bahwa pada akhirnya semuanya akan dihapus juga.
  • Karena sangat menyakitkan ketika kode yang kita tulis dengan sungguh-sungguh terasa sebagai karya gagal lalu kita hapus sendiri.
  • Bagaimana jika dibalik cara berpikirnya, dan justru membuatnya agar mudah dihapus?
• Apakah penghancuran itu hal yang baik?
  • Tanpa penghancuran, hal baru tidak bisa lahir.
  • Penghancuran yang dapat dilihat dalam perangkat lunak secara besar ada dua - pivot dan refactoring
  • Pivot memungkinkan organisasi dan produk memilih jalan yang lebih baik.
  • Refactoring adalah hal yang mutlak diperlukan untuk memperpanjang umur perangkat lunak.
• Jadi, apa itu pengembangan berorientasi penghancuran?
  • Sebuah metodologi pengembangan yang menerima fakta bahwa suatu hari kode akan dihancurkan, lalu mengembangkan dengan berorientasi pada hal itu.
  • Mengarah pada tiga prinsip besar
    • Jika ada ketidakpastian, kurangi ketidakpastian itu sejauh mungkin.
    • Jika ada beberapa metode yang bisa dipilih, pilih sisi yang lebih mudah dihancurkan.
    • Pertahankan hanya yang diperlukan. Karena itu, hapus semua yang tidak diperlukan.
  • Analisis -> pemisahan batas -> implementasi kode -> penghapusan kompleksitas
  • Intinya adalah mengurangi ketidakpastian akibat faktor internal dan bersiap menghadapi penghancuran akibat faktor eksternal yang tidak terhindarkan.
• Pemisahan batas
  • Ketidakpastian adalah laju perubahan, dan berdasarkan itu pemisahan bisa dilakukan.
  • Pengembang harus bersiap terhadap faktor eksternal sambil sebisa mungkin mengurangi laju perubahan yang disebabkan faktor internal.
  • Karena laju perubahan tiap faktor bisa berbeda di setiap organisasi, tidak mungkin mengekspresikannya dengan angka yang tetap -> diukur dengan cara heuristik
    • ex) pengukuran story point
  • Harus ditentukan level abstraksi untuk memisahkan berdasarkan apa.
• Kemungkinan untuk dihancurkan
  • Saat melakukan implementasi, pilih sisi yang lebih mudah dihancurkan sesuai prinsip besar.
  • Kemungkinan untuk dihancurkan dapat dinilai dengan mempertimbangkan independensi, keterpahaman, dan keterkendalian
    • Independensi dinilai dari tingkat coupling dan cohesion, serta sejauh mana prinsip tanggung jawab tunggal dipatuhi.
    • Keterpahaman adalah sejauh mana pengembang dapat melihat dan memahami kode.
    • Keterkendalian adalah menilai apakah itu termasuk area yang bisa dikendalikan pengembang.
• Penghapusan kompleksitas
  • Harus memeriksa apakah ada hal yang tidak perlu lalu menghapusnya. Artinya, pada akhirnya hanya hal yang diperlukan yang harus tersisa di codebase.
  • Jika sulit mengerjakannya karena tenggat waktu dan masalah lain, tidak masalah untuk hanya mencatatnya lalu mengerjakannya nanti.
    • Karena faktor internal dapat dikendalikan.
  • Kuncinya adalah menjaga kesederhanaan semaksimal mungkin untuk bersiap menghadapi penghancuran.
• Teknik penghancuran kode
  • Ada berbagai prinsip dan metode untuk menghapus kode dengan baik.
  • Memecah tahapan (pola refactoring)
  • Menjaga referential transparency
  • Menjaga prinsip tanggung jawab tunggal
  • Menjaga prinsip pemisahan antarmuka
  • Pola strangler fig
  • Spesialisasi method
  • Menulis kode duplikat
  • Mencatat laju perubahan

[annonymous1]

Saya kurang setuju dengan pernyataan bahwa utang kode muncul karena kurangnya pengetahuan dan pengalaman.

-> Bisa saja waktu yang diberikan untuk mengimplementasikan kebutuhan tidak cukup, dan dalam kerja kolaboratif kadang kita juga perlu menoleransi sedikit utang teknis demi menjaga keselarasan dengan orang lain; menurut saya situasinya beragam.

Saya juga kurang paham melihat pengetahuan dan pengalaman sebagai faktor internal yang bisa dikendalikan oleh developer.

-> Bisnis itu kompleks sehingga kita tidak bisa memprediksi situasi apa yang akan datang, dan tidak mungkin mempelajari semua kemungkinan kasus satu per satu saat itu juga. Bahkan jika kita belajar ketika situasi itu datang, pada kesempatan berikutnya bisa muncul masalah yang sama sekali baru sehingga pengetahuan tadi menjadi tidak berguna.

[kciter1]

Halo. Terima kasih atas pendapat Anda.
Saya berpikir bahwa kita baru bisa melihat esensi ketika menelaah sesuatu secara ekstrem. Dari sudut pandang itu, saya berpikir bahwa jika seseorang memahami pengetahuan dan pengalaman secara sempurna, maka ia bisa menghasilkan kode yang bukan utang teknis dalam batas waktu yang ada.

Kekurangan waktu dapat dibagi menjadi dua hal. Pertama adalah ketika waktu yang dibutuhkan untuk implementasi memang benar-benar tidak cukup. Dalam kasus ini, terlepas dari pengetahuan dan pengalaman, waktu fisik untuk menulis kode memang menjadi tidak cukup. Karena itu, sejak awal kondisinya memang membuat pencapaian tujuan menjadi mustahil. Kedua adalah ketika tidak ada cukup waktu untuk mencari tahu apa yang baik. Dalam kasus seperti ini, karena waktu untuk memahami metode implementasi atau mencari pilihan yang lebih baik tidak cukup, pekerjaan diselesaikan dengan menulis kode hanya berdasarkan pengetahuan yang dimiliki saat itu. Jika pekerjaan diselesaikan dengan cara seperti ini, kita tahu bahwa ada sesuatu yang salah, tetapi tidak tahu persis bagaimana harus memperbaikinya. Jika sejak awal ada pengetahuan yang akurat dan kepercayaan diri yang lahir dari pengalaman terkait hal itu, masalah seperti ini tidak akan muncul.

Saya rasa penjelasan tentang kekurangan waktu di atas mendukung pendapat saya. Tentu saja, dalam kenyataannya ini adalah masalah yang sangat sulit. Saya hanya menyampaikan sesuatu yang ideal. Kondisi memiliki pengetahuan dan pengalaman yang sepenuhnya lengkap itu jarang terjadi, dan seperti yang Anda katakan, memang ada kasus ketika hal itu sengaja ditanggung demi organisasi. Bisa saja terasa tidak adil, tetapi jika dilihat secara ekstrem, saya memandang masalah ini muncul karena kurangnya pengetahuan dan pengalaman.

Kedua, faktor internal yang Anda sebutkan itu sederhana. Bagian bisnis itu kompleks sehingga tidak bisa diprediksi situasi seperti apa yang akan datang … adalah pembahasan tentang kompleksitas bisnis dalam tulisan saya. Artinya, itu adalah masalah yang berasal dari faktor eksternal. Karena merupakan faktor eksternal, pengembang tidak bisa mengendalikannya dan karena itu merasa takut. Jika ini juga dilihat secara ekstrem dan kita berasumsi bahwa tidak ada kompleksitas bisnis, maka yang tersisa hanyalah kode yang ditulis pengembang. Jika demikian, yang tersisa hanyalah masalah pengetahuan dan pengalaman yang bisa dikendalikan secara internal.

Tentu saja, tulisan saya juga hanyalah pendapat pribadi saya. Sangat mungkin ada contoh tandingan yang valid. Saya pikir bertukar pendapat adalah kesempatan untuk menuju jalan yang lebih baik. Saya berharap bisa terus menerima banyak pendapat dari Anda ke depannya. Terima kasih.

[annonymous1]

Terima kasih telah menjawab dengan ramah.

[winterjung]

Saya membaca artikelnya dengan baik. Sepertinya, tergantung pada tahap organisasi, apa yang dianggap optimasi prematur dan overengineering juga bisa berbeda. Titik sulitnya adalah bahwa ini adalah kode yang pada akhirnya memang harus ditulis ulang, namun juga kode yang belum tentu akan benar-benar sampai pada momen untuk ditulis ulang. Saya kadang menilainya dengan pertanyaan seperti, jika layanan xxx atau fiturnya dihapus, di mana sebaiknya kode dan data yyy berada? Saya juga penasaran dengan cara orang lain menentukannya.

[savvykang]

Saya cenderung memikirkan apakah bukan hanya kode, tetapi juga data atau skema bisa hilang atau berubah.

1. Saya memikirkan di mana posisi kode dalam tiga klasifikasi: skema DB, protokol (seperti REST API), dan fitur. Skema dan protokol pada akhirnya akan menyebar ke kode internal perusahaan atau ke pihak luar, sehingga jika nanti ingin diubah, itu tidak bisa diselesaikan sendirian hanya dalam beberapa hari dan akan memerlukan kolaborasi. Karena itu, saya menghabiskan sedikit lebih banyak waktu pada tahap perancangan.
2. Saya memikirkan siklus hidup dan volatilitas data yang ditangani kode. Sepertinya ini juga mencakup situasi saat layanan yang sedang dipikirkan oleh winterjung dihapus. Klasifikasi tabel ledger, transaksi, dan riwayat yang dibahas dalam OLTP juga tampaknya bisa menjadi cara untuk mulai memikirkan hal semacam ini.

[kciter1]

Saya juga ingin memasukkan pembahasan tentang data, tetapi sulit mendapatkan gambaran yang jelas. Karena ini bagian yang kritis, tidak mudah untuk disentuh sembarangan, dan ada kekhawatiran bisa terjebak dalam neraka migrasi jika salah langkah, jadi saya cukup berhati-hati.

Seperti yang Anda katakan, tahap desain awal tampaknya sangat penting. Intinya kemungkinan adalah membangun agar RAW dapat ditumpuk sebaik mungkin. Atau, dari sisi penghapusan, arsitektur event sourcing mungkin bisa lebih menguntungkan. Tentu saja, saya belum pernah benar-benar menggunakan arsitektur tersebut dengan baik, jadi saya tidak yakin apakah itu benar-benar efektif.