Hari ini adalah hari yang cerah. Anda mengemudi di sepanjang jalan menuju desa tempat tinggal semua teman, keluarga, dan anjing kesayangan Anda. Hari yang indah! Tiba-tiba Anda mendengar tangisan mengerikan, mimpi buruk merobek-robek lingkungan. Hydra menjijikkan besar mendekati desa untuk menghancurkannya! Anda mengambil pedang (tentu saja, Anda memiliki pedang!) Dan cobalah untuk melindungi semua orang yang Anda cintai. Tetapi ada masalah kecil: monster itu memiliki banyak tujuan, dan ketika Anda memenggal salah satu dari mereka, yang baru tumbuh dengan cepat!

Tampaknya Anda tidak dapat memenangkan pertempuran ini. Mungkin Anda bisa bermain dengan Hydra cukup lama sehingga seluruh desa punya waktu untuk terbang menjauh dari ancaman yang mengerikan? Akhirnya, Anda akan menjadi pahlawan sejati seluruh dunia! Siapa yang tidak menginginkan ini?

Peran Hydra adalah entropi dalam perangkat lunak: itu adalah musuh Anda, dia melelahkan Anda, tetapi Anda tidak pernah bisa sepenuhnya menghilangkannya. Tetapi Anda masih harus bertarung dengannya sehingga aplikasi Anda (dan kolega) tetap sehat dan waras.

Kami akan mencari tahu:

1. Apa itu entropi dalam perangkat lunak dan bagaimana melihatnya dalam kode Anda.
   
2. Apa penyebabnya dan bagaimana menjaga entropi tetap rendah.
   

Cukup bicara, to the point!

Kenali musuhmu

Apa itu entropi dan bagaimana akhirnya dalam aplikasi saya?

Kadang-kadang berguna untuk mengetahui etimologi dari kata-kata yang digunakan, terutama yang spesifik seperti entropi. Diterjemahkan dari bahasa Yunani, itu berarti "transformasi." Ubah Sesuatu yang harus Anda biasakan sebagai pengembang perangkat lunak.

Entropi mengacu pada hukum kedua termodinamika. Dikatakan bahwa dalam sistem tertutup dan terisolasi, jumlah kekacauan tidak berkurang seiring waktu. Itu tetap stabil atau tumbuh.
Gagasan entropi dalam perangkat lunak muncul melalui buku Object-Oriented Software Engineering . Semakin banyak perubahan program, semakin banyak kekacauan yang dimilikinya, entropinya meningkat.

Hal pertama yang perlu dijelaskan oleh pengembang miskin adalah kebenaran tragis: kita dapat melawan jumlah entropi dalam program kita, tetapi kita tidak pernah bisa menyingkirkannya.

Buat tim terbaik (dengan partisipasi Anda, tentu saja!), Lingkungan terbaik, manajemen terbaik, budaya terbaik di perusahaan, proyek terbaik. Apa yang akan terjadi seiring waktu?

1. Anda akan bersenandung setiap pagi, "Ini adalah proyek terbaik!" Proyek hijau yang terlihat seperti bidang yang indah, diterangi oleh matahari terbit yang indah.
   
2. Anda dan tim akan menambah lebih banyak fitur. Karena Anda adalah yang terbaik dari yang terbaik, untuk sementara semuanya tampak hebat.
   
3. Bulan atau tahun akan berlalu. Tidak ada yang mau mengerjakan proyek lagi. Bahkan jika itu dirancang dengan baik, teknologinya sudah ketinggalan zaman, proyek membutuhkan terlalu banyak usaha dan waktu untuk memahami, itu mahal untuk skala. Terlalu sulit untuk membangun model mentalnya yang baik.
   

Bagaimana Anda menciptakan kompleksitas ini? Anda hanya perlu meningkatkan skala proyek. Lebih banyak elemen sering berarti lebih banyak ketergantungan dan kompleksitas yang lebih tinggi. Saya sudah menulis artikel terperinci tentang ini.

Jika Anda menjelaskan ini kepada Lyokha, rekan pengembang Anda, dia akan menjawab:

“Nifiga! Apakah kamu bodoh? Kekacauan dan kekacauan tidak memiliki tempat di aplikasi saya yang indah! Reputasi saya tidak akan ternodai oleh omong kosong! Saya adalah penguasa takdir saya! Jika saya tidak mengubah program saya, maka kompleksitasnya tidak akan tumbuh, dan sehubungan dengan bukti kontradiksi ini, saya menyatakan bahwa Anda salah, dan saya yang terbaik! ”

Anda dapat dengan tenang, meyakinkan dan tegas menjelaskan kepada Lyokha bahwa bahkan jika Anda tidak mengubah program, semua yang ada di sekitarnya akan berubah. Jika Anda memiliki perpustakaan pihak ketiga yang tidak diperbarui, akan ada masalah keamanan. Dan jika Anda memperbaruinya, itu akan membuka pintu untuk berubah dan entropi.

Apalagi, jika suatu hari Anda perlu mengubah sesuatu dalam perangkat lunak Anda setelah waktu yang lama, maka Anda tidak akan mengingat semua detailnya. Dan bahkan dokumentasi terbaik tidak akan membantu Anda. Dunia telah berubah, dan apa yang benar kemarin mungkin tidak pernah benar, baik di tingkat teknologi maupun di tingkat bisnis.

Perubahan seperti itu sekaligus membawa sejumlah besar entropi.

Jadi pertanyaannya bukan pada menyingkirkannya, tetapi dalam jumlah sedang. Ini adalah pertarungan nyata yang dilemparkan oleh kami para pengembang.

Definisi Entropi dalam Perangkat Lunak

Kualitas perangkat lunak

Bagaimana mengetahui bahwa aplikasi Anda memiliki tingkat entropi yang tinggi? Indikator yang baik adalah kualitas kode.

Apa itu dan bagaimana mengukurnya? Menurut Accelerate: The Science Behind Devops :

• Jika rasio perubahan / kegagalan meningkat, maka kualitasnya menurun. Lacak perubahan, bug, dan kerusakan, bandingkan satu sama lain. Jika setiap perubahan mengarah ke bug atau crash baru, maka entropi dalam program Anda meningkat.
  
• Peran penting dimainkan oleh persepsi subjektif dari proyek oleh pengembang. Jika setiap orang merasa bahwa semakin sulit untuk mengukur aplikasi tanpa merusaknya, maka entropinya mungkin tinggi. Namun, sensasi ini harus umum.
  
• Jika tim menghabiskan banyak waktu untuk memperbaiki bug atau pulih dari kegagalan, maka entropi harus membuat sarang di aplikasi Anda.
  

Jika Anda dapat memperoleh beberapa informasi tentang rasio perubahan dan kegagalan, dan menghabiskan waktu memperbaiki bug, Anda dapat membuat jadwal yang baik untuk meyakinkan manajemen tentang perlunya semacam refactoring.

Setan Kesulitan

Bahkan jika Anda memiliki kode dengan kualitas terbaik, kompleksitas dapat dengan mudah meningkat ketika datang ke kemampuan program. Bisnis itu sendiri adalah sumber dari kompleksitas yang diperlukan yang tidak dapat Anda singkirkan.

Mengingat kompleksitas bisnis yang berlebihan, pengembang harus menghabiskan banyak upaya untuk membangun model mental yang baik dari bisnis perusahaan. Oleh karena itu, mereka akan membuat kesalahan dengan mencoba menerjemahkan persyaratan bisnis ke dalam kode.

Mari kita bicara lebih rinci tentang kompleksitas bisnis: apakah kita benar-benar membutuhkan semua fitur kompleks yang mengecewakan kita?

Alasan entropi, dan cara menghadapinya

Air Terjun Entropy

Masalah

Lebih atau kurang jelas, penyebab utama entropi dalam perangkat lunak adalah pengembang itu sendiri. Mereka malas, mereka tidak memiliki kualifikasi, terutama Sanka, dengan siapa Anda bekerja. Dia mengajukan begitu banyak pertanyaan!

Saya sangat tidak setuju dengan pendapat ini. Dalam pengalaman saya, alasan utama untuk entropi adalah kepemimpinan, terutama di perusahaan dengan gaya manajemen air terjun.

Seperti yang dicatat Gerald Weinberg dalam The Secret of Consulting :

Bahkan jika ini adalah masalah teknis semata, asalnya selalu dapat ditelusuri kembali ke tindakan atau tidak adanya tindakan manajemen.

Saya tahu apa yang Anda pikirkan: "Anda salah! Manajemen tidak selalu bertanggung jawab atas segalanya! Sangat mudah bagi pengembang untuk menyalahkan bos atas segalanya! ”

Saya tidak mengatakan bahwa kepemimpinan harus disalahkan atas segalanya, tetapi dia selalu memiliki tingkat tanggung jawab tertentu . Apakah pengembang melakukan sesuatu yang buruk? Anda perlu meninjau proses perekrutan. Spesifikasi tidak diterapkan dengan baik? Mungkin beberapa pemimpin tidak tahu apa yang sebenarnya mereka inginkan, dan oleh karena itu spesifikasinya tidak penting baginya.

Karena itu, sangat sulit untuk menjadi pemimpin! Semakin tinggi Anda dalam hierarki, semakin sulit.

Sebagai pengembang, seberapa besar Anda memengaruhi pengambilan keputusan? Jika 100%, maka selamat, Anda yang harus disalahkan untuk semuanya. Jika 0%, maka kesalahan Anda tidak. Di antara kutub-kutub ini terletak seluruh spektrum pengaruh. Dan air terjun itu tidak menyiratkan jumlah yang besar.

Menggunakan Perencanaan Scrum, Kanban dan Poker? Tentu saja Anda tidak menggunakan air terjun! Anda menggunakan Agile seperti halnya anak membangun rumah dengan obeng.

Tentu saja, alat itu penting, tetapi signifikansinya jauh lebih rendah daripada pentingnya cara berpikir Anda , yang diperlukan untuk pengembangan perangkat lunak yang benar. Mengutip manifest Agile:

Kepribadian dan interaksi lebih penting daripada proses dan alat.

Menggunakan Scrum tidak berarti Anda menggunakan Agile, terutama jika Anda tidak memiliki cara berpikir bahwa metodologi ini mencoba untuk mengajar.

Dengan manajemen air terjun, seseorang yang lebih tinggi dari Anda membuat keputusan, lebih tinggi, orang lain membuat keputusan baru, dan sebagainya.

Di tingkat bawah hierarki adalah karyawan yang kutukannya mengikuti semua keputusan yang dibuat. Apa tugas mereka? Untuk membuatnya, seolah-olah pekerja di jalur perakitan pabrik mobil. Mereka tidak perlu berpikir, mereka harus membuat mobil .

Berita buruk: sebagai pengembang, Anda akan berada di bagian bawah hierarki.

Jika seseorang di atas membuat keputusan tentang fungsi aplikasi, dan Anda praktis tidak memiliki kesempatan untuk mempengaruhi proses pengambilan keputusan, maka selamat datang di air terjun! Sayangnya, manajemen senior paling sering tidak melihat bahwa di dunia pengembangan perangkat lunak tidak ada fase produksi . Pengembang terlibat dalam desain sistem , dan tugas ini jauh dari perakitan conveyor kabin.

Mengapa Karena, tidak seperti mobil, aplikasi terus berubah! Anda perlu mendesainnya dengan benar sehingga berfungsi, memenuhi kebutuhan pengguna, bahwa aplikasi memiliki kinerja yang dapat diterima, bahwa mereka dapat diukur dan tahan terhadap perubahan, sambil mempertahankan entropi pada level rendah. Untuk melakukan ini, Anda perlu membuat banyak keputusan tentang cara mencerminkan pengetahuan bisnis dalam kode Anda.

Jika Anda tidak memengaruhi kerumitan yang dibawa oleh kepemimpinan kepada Anda, maka Anda harus menghabiskan banyak upaya untuk mengelolanya dalam kode. Ini akan dianggap sebagai kompleksitas "perlu": yang tidak dapat dihindari.

Hasil yang mungkin? Tingkat entropi dapat tumbuh sangat, sangat cepat.

Solusi yang mungkin

Perusahaan perlu mempraktikkan pengambilan keputusan bersama dan tanggung jawab seaktif mungkin.

Jika Anda mengenali perusahaan Anda dalam model air terjun yang saya jelaskan, maka Anda perlu berbicara dengan mereka yang membuat keputusan:

• Berikan data dan argumen kuat mengapa dan bagaimana menyederhanakan fitur X atau Y. Jelaskan kemungkinan harga mengembangkan fitur yang kompleks sekarang dan di masa depan .
  
• Jelaskan mengapa pengembangan perangkat lunak Agile berarti bahwa orang perlu bekerja bersama. Manajer, perancang, pengembang, dan semua orang harus menjadi bagian dari proses pengambilan keputusan tergantung pada persyaratan bisnis.
  
• Jika kepemimpinan Anda secara otomatis menolak tawaran itu, maka Anda perlu memahami mengapa itu berhasil. Ajukan pertanyaan.
  
• Bicara tentang apa yang oleh para pembuat keputusan dianggap paling penting: uang dan waktu. Tunjukkan pada mereka bahwa pemikiran Agile-style (dan bukan hanya alat) dapat menyelamatkan Anda berdua.
  

Namun, sulit untuk mencoba menyelesaikan masalah jika Anda belum ditanya tentangnya. Banyak manajer sangat senang dengan model air terjun, dan seringkali bahkan tidak tahu bahwa mereka mengikutinya. Anda akan membutuhkan banyak diplomasi dan kebijaksanaan.

Mengingat semua ini, jika Anda merasa bahwa solusi bisnis menambah terlalu banyak kerumitan pada aplikasi Anda, dan bahwa Anda tidak dapat melakukan apa-apa walaupun Anda mencobanya, maka saya menyarankan Anda untuk mencari pekerjaan lain. Melelahkan - bekerja dengan entropi tinggi setiap hari, dan membuat produk kesenangan yang membengkak tidak cukup ... atau menggunakannya. Ini mungkin memberi Anda petunjuk mengenai kesuksesan yang diharapkan produk Anda.

Dan yang terakhir: apa yang terlihat rumit di tingkat bisnis dapat disederhanakan jika Anda mengetahui proses bisnis dengan baik. Ini sangat penting. Oleh karena itu, pelajari lebih lanjut tentang kegiatan perusahaan Anda, apa yang mereka lakukan dan apa yang tidak mereka lakukan, ini akan membantu menyederhanakan fitur dan basis kode.

Saat kami mengekspresikan arsitektur kami, kami menjelaskan sesuatu ke komputer. Dan untuk ini kita perlu memahami dengan baik apa yang kita jelaskan.

Donald cambuk

Kualitas kode dan tugas teknis

Masalah

Selain kompleksitas "perlu" yang diperkenalkan oleh bisnis, entropi dalam perangkat lunak terkait erat dengan kualitas kode dan hutang teknis.

Apa itu utang teknis? Sederhananya, ini adalah penyederhanaan (peretasan) yang Anda gunakan untuk menghemat waktu, mengetahui bahwa nanti ini dapat kembali kepada Anda. Terutama dalam kasus di mana fitur lain bergantung pada peretasan ini: Anda harus memperbaikinya dengan bunga, seperti halnya utang nyata, dalam bentuk kesulitan dan sakit kepala.

Bergantung pada tugas aplikasi Anda, utang teknis mungkin lebih atau kurang dapat diterima. Jika program harus hidup beberapa bulan, maka Anda tidak dapat memikirkan utang teknis, entropi atau kualitas sama sekali. Letakkan potongan-potongan kode bersama dan Anda selesai!

Misalnya, ini mungkin solusi sementara sebelum membuat aplikasi yang lebih kompleks dari awal. Atau agar Anda dapat dengan cepat menulis prototipe untuk mengilustrasikan ide, dan kemudian menulis ulang semuanya atau meninggalkan konsep.

Di sisi lain, perusahaan biasanya ingin mengembangkan aplikasi yang berumur panjang. Ini masuk akal: menulis ulang aplikasi bisa sangat mahal (terutama jika itu besar), dan tidak ada yang bisa menjamin bahwa tingkat entropinya akan lebih rendah. Menyalin adalah bisnis yang sangat berisiko.

Dalam kasus seperti itu, Anda harus sangat berhati-hati dengan tugas teknis dan kualitas kode. Ini adalah bagian penting dari pekerjaan Anda sebagai pengembang.

Dalam buku terkenal The Pragmatic Programmer (di mana, antara lain, prinsip KERING diperkenalkan), analogi yang menarik dari utang teknis diberikan. Sebuah penelitian dijelaskan di sini yang membandingkan perusakan bangunan kota dengan ... jendela yang dihancurkan. Jendela yang pecah memberikan kesan ditinggalkan, menginspirasi setiap pelaku intimidasi di daerah tersebut. Akibatnya, bangunan dengan jendela pecah dirusak lebih cepat daripada bangunan dengan jendela utuh.

Utang teknis adalah penyederhanaan atau peretasan dalam kode Anda, jendela rusak. Ketika pengembang lain, atau bahkan Anda sendiri di masa depan, perhatikan ini, akan ada godaan untuk menambahkan lebih banyak utang teknis, karena "masih ada kode yang buruk di sini, jadi mengapa mandi uap?"

Contoh: Anda menulis solusi untuk satu bug kompleks, karena tidak ada waktu untuk mencarinya. Pengembang lain (atau Anda sendiri nanti) di atas pemecahan masalah ini dapat menulis kode yang berbeda, memecahkan masalah lain. Lapisan penyelesaian yang tidak akan pernah dipikirkan orang dengan cepat akan tumbuh.

Solusi

Pertama, bagaimana Anda tahu jika suatu kode memiliki hutang teknis?

Tanyakan pada diri sendiri:

• Bisakah saya secara sederhana dan logis menjelaskan apa yang dilakukan kode?
  
• Apakah nama yang benar digunakan di sini? Apakah mereka membantu menjelaskan apa yang dilakukan kode?
  
• Apakah nama panjang dengan "dan" berlaku, seperti "deleteUserAndShutDown"? Ini adalah pertanda baik bahwa Anda perlu memisahkan fungsi, metode, atau konstruksi lainnya.
  
• Apakah rasanya beberapa kode ditambahkan karena kemalasan? Apakah itu melanggar logika dan merusak pemahaman?
  

Semakin banyak pengetahuan dan pengalaman Anda tumbuh, semakin penasaran Anda dan semakin sering Anda mengadakan diskusi sehat dengan pengembang lain, semakin sering Anda akan melihat pola utang teknis. Ini adalah kode dengan choke .

Saat menemukan pola seperti itu, mohon jangan menganggapnya sebagai izin untuk menambahkan lebih banyak hutang teknis:

1. Peningkatan panjang teknis akan menyebabkan masalah baru. Mereka akan kembali dan akan mengejar Anda (dan tim Anda) bahkan lebih.
   
2. Setelah bertemu hutang teknis, refactor saja. Ini pilihan terbaik. Jika Anda tidak punya waktu atau energi, tambahkan saja komentar // TODO: refactor untuk alasan ini dan itu. Laporkan masalah, jangan biarkan tersembunyi di basis kode.
   

Jangan lupa bahwa Anda harus memperbaiki secara paralel dengan pengembangan fitur-fitur lain agar sesuai dengan arsitektur saat ini. Sederhananya, memperbaiki utang teknis seharusnya bukan tugas yang independen, tetapi proses yang berkelanjutan yang mungkin tidak terkait dengan tugas saat ini. Saat mengembangkan fitur, beri diri Anda hak untuk memperbaiki utang teknis yang ditemui.

Refactor kode kecil sekaligus dan sering menjalankan tes untuk memastikan sistem berperilaku seperti yang diharapkan.

Akhirnya, selama refactoring, Anda mungkin memerlukan beberapa argumen yang bagus:

1. Pertama, untuk dirimu sendiri. Sangat mudah untuk berpikir bahwa kolega Anda tidak dapat memprogram dan bahwa Anda lebih tahu daripada yang lain. Tetapi jika Anda tidak melihat manfaat spesifik dari refactoring, maka jangan. Mungkin semuanya hanya ada dalam ego Anda, dan Anda dapat merusak sesuatu.
   
2. Jika refactoring terkait dengan gaya kode, itu berarti bahwa tim Anda belum mendefinisikannya dengan jelas. Lakukan rapat dan putuskan bersama gaya kode apa yang ingin Anda adopsi. Ini perlu ditulis di suatu tempat, sehingga semua orang dapat menangani sesuai kebutuhan. Edit perjanjian sesuai dengan kebutuhan tim. Kalau tidak, kode Anda akan diisi dengan komentar seperti “kami menggunakan tab !!! BUKAN RUANG !!!!! 11! 1 !!! ”. Ini adalah suara yang tidak berguna.
   
3. Akhirnya, jika seseorang bertanya kepada Anda mengapa Anda mengubah kode indahnya, Anda akan memiliki argumen nyata untuk menjelaskan keputusan Anda.
   

Argumen yang baik selalu memainkan peran positif di masa depan. Misalnya, membungkus perpustakaan pihak ketiga sehingga tidak menyebabkan kebocoran pada basis kode Anda. Jika Anda tidak mengerti mengapa saya berbicara tentang kebocoran, maka bacalah apa yang saya tulis tentang abstraksi .

Sulit bagi kita manusia untuk membuat ramalan dalam jangka menengah dan panjang. Oleh karena itu, tidak selalu mudah untuk refactor atau "menjual" sesuatu dengan tujuan masa depan yang tidak diketahui.

Tugas teknis mencerminkan dualisme antara jalan yang sederhana dan yang benar . Yang pertama cepat dan menarik, yang kedua akan membuat proyek Anda scalable dan mudah dirawat. Anda perlu disiplin diri untuk memilih jalan kedua sesering mungkin. Kalau tidak, masa depan akan dipenuhi dengan penderitaan.

Jika Anda terlalu lelah, jengkel atau penuh dengan pikiran atau emosi lain yang mengurangi motivasi Anda untuk tetap pada jalan yang benar, dan bukan yang sederhana, maka lebih baik untuk tidak memprogram. Berjalan-jalan, berbicara dengan rekan kerja, istirahat. Kembali ke kode dengan otak segar.

Paling sering, utang teknis ditambahkan selama debugging. Jika Anda memperbaiki bug dengan menambahkan solusi, maka Anda belum memperbaiki apa pun. Bugnya tetap, itu hanya lebih sulit untuk dijalankan dan secara tidak sengaja menemukannya. Anda perlu memperbaiki bug menggunakan refactoring , mengubah, atau menghapus kode sepenuhnya. Kemudian uji kode untuk memastikan bahwa bug tidak terjadi lagi.

Terakhir: menyalahkan kolega karena kesalahan tidak produktif. Jika Anda berbicara dengan buruk atau sarkastis tentang basis kode Anda, ini juga tidak akan menyelesaikan masalah, itu hanya akan memperburuk situasi. Jangan hancurkan semangat tim. Anda perlu mengurangi entropi dalam proyek, dan tidak menghancurkannya secara lisan.

Tes Otomatis

Masalah

Ada sesuatu yang menarik bagi saya di dunia magis pengembangan perangkat lunak, terutama di pemula: banyak programmer masih tidak mau menulis tes otomatis.

Mengapa itu membuat saya terpesona? Di semua bidang teknik lainnya, mereka menguji apa yang mereka lakukan dengan mengikuti proses yang ketat. Ketika Anda membangun roket, Anda perlu menguji banyak sistem, atau roket akan jatuh. Hal yang sama berlaku untuk mobil, jembatan, pesawat terbang - apa pun.

Menyimpan uang .

Contoh sederhana: NASA sedang menguji kodenya secara menyeluruh (lihat aturan 5) .

, , , . , , .

. .

, , — , . ? , . , , ( ), , - .

, : , . , .

, .

Solusi

, , , .

. - 1,3 . , . «» .

:

• « ».
  
• « , ».
  
• « . , , ».
  

, , - ( ), :

• . , , .
  
• . , , - .
  
• . — , .
  
• , - . , - . !
  
• , . !
  

, .
, . , . , .

, , . .

, , . , , - .

, , . , , :

• , , .
  
• - , .
  

, . , . . , , , - , .

— , .

, .

,

:

• .
  
• , .
  
• , - .
  

. , , .

?

— . - , . , .

Itu saja! , .

, , .

, , : « , , ? , . !».

: , . , . , .

, , , . , , . !

. :

• .
  
• , .
  
• .
  

, . , . , , .

, , . ?

, . , , .

:

• , . «, ?» — , « ! ! !».
  
• , . , , , , . «, , ?» « , 289 ».
  

, . , !

( !) .

. , , .

, — , , . !

!

, , , , . ? ? - ? ?

. , . -, . , , , .

, , . . — .

Jadi ?

• — . . , .
  
• — .
  
• . / .
  
• , , .
  
• , . , .
  
• Ciptakan suasana yang memudahkan berbagi pengetahuan satu sama lain melalui pemrograman bersama, analisis kode, atau sekadar meletakkan tautan ke sumber informasi yang menarik (artikel, buku).
  

Perangkat lunak yang ideal tidak ada. Entropi akan selalu menjadi bagian dari pekerjaan kami. Ini tidak berarti bahwa kita telah kehilangan pertempuran ini. Ini berarti mengurangi entropi di seluruh basis kode sudah merupakan kemenangan!

Tautan yang bermanfaat:

• Programmer pragmatis
  
• Entropi Perangkat Lunak Dijelaskan: Penyebab, Efek, dan Pemulihan
  
• Entropi dalam perangkat lunak
  
• Busuk Perangkat Lunak, Entropi, dan Teori Jendela Rusak