[...] tidak ada yang berhasil menjelaskan kepada saya MENGAPA sangat penting untuk membatasi diri Anda dengan ruang lingkup pribadi untuk mencegah pemrogram lain merusak semacam konsistensi organisasi data.
Dalam tim yang cukup kecil dengan basis kode yang cukup kecil yang benar-benar terkoordinasi dengan baik dengan standar yang baik (bisa saja menjadi satu orang), Anda sering dapat menemukan perangkat lunak yang andal yang membiarkan semua data di tempat terbuka bagi siapa saja untuk disentuh dengan semua bidang data dari structterbuka lebar terbuka dan dengan structdefinisi terbuka lebar bagi siapa saja yang menyertakan header itu untuk diakses. Hukum Murphy tidak selalu berlaku dalam kasus-kasus itu.
Tapi saya telah bekerja dalam skenario yang berlawanan dari basis kode besar dengan jutaan LOC sejak tahun 80-an dengan tim pengembang besar dari seluruh dunia di mana kami hanya bertemu secara langsung setiap beberapa bulan, terkoordinasi secara longgar, kadang-kadang terkoordinasi secara longgar, kadang-kadang nyaris tidak berbicara bahasa yang sama, tidak ada standar pengkodean kecuali untuk SDK yang orang sering tidak mengikuti, tidak ada tes unit / integrasi, menggunakan SVN tanpa bercabang dan kadang-kadang pergi 6 minggu tanpa memeriksa kode, hanya untuk membom kami dengan bug, dan Baru pada saat itulah saya benar-benar memahami nilai menyembunyikan informasi dan mempertahankan invarian .
Saya berurusan dengan bug di mana saya bahkan tidak bisa mereproduksi masalah secara konsisten di mesin saya, dan kadang-kadang tidak ada dari kita yang bisa di antara seluruh tim. Dan ketika saya akhirnya beruntung dapat mereproduksi masalah yang dilaporkan pengguna atau sesuatu yang mirip setelah semua jenis coba-coba (dan coba-coba sering memakan waktu berjam-jam karena ketidakefisienan perangkat lunak kami dikombinasikan dengan menjalankannya dalam debug terhadap produksi pengguna akhir) data sering butuh 15+ menit hanya untuk mendapatkan data untuk dimuat), saya akan melacaknya ke sesuatu seperti structuntuk tipe string yang memiliki lenset ke nomor negatif sampah, seperti panjang string -921141282.
Itu seharusnya tidak pernah terjadi, tetapi siapa yang melakukannya? Jadi saya harus mengatur memory breakpoints dan mencari tahu, dan ketika saya akhirnya melakukannya, itu seperti interaksi cascading variabel tidak diinisialisasi yang digunakan secara hitung yang akhirnya ditambahkan ke lenbidang string yang diatur ke nomor sampah negatif, dan kode itu belum telah dimodifikasi bertahun-tahun. Itu terbang di bawah radar.
Dan sepanjang waktu setelah menemukan banyak bug seperti ini, saya berpikir, seberapa besar keandalan perangkat lunak kita jika hanya digunakan getters dan setters? Getters dan setters umumnya menunjukkan jenis terburuk dari desain antarmuka yang mungkin, tetapi setter setidaknya bisa memicu kegagalan pernyataan jika seseorang mencoba mengatur panjang string ke nilai negatif. Kita bisa menangkap bug itu bertahun-tahunsebelum pada waktu yang tepat diperkenalkan dalam hitungan detik, bukan titik puncak dari upaya investigasi. Dan itu hanya berpikir egois sebagai pengembang; itu tidak mencakup semua jam kesedihan itu bisa menyelamatkan pengguna dan tim QA juga. Anda tahu sistem Anda berada di tempat yang sangat buruk ketika Anda bermimpi tentang betapa lebih baiknya jika menggunakan setter dan getter dalam menghadapi 35 bug terakhir yang Anda habiskan untuk memperbaiki.
Kami bahkan punya kasus di mana structs didokumentasikan dengan cara yang menyatakan bahwa tidak ada orang lain yang harus mengakses bidang data tersebut, hanya untuk menemukan tempat di sistem mengakses bidang data tersebut.
Jadi ini adalah jenis hal yang hanya dapat Anda hargai sepenuhnya dengan menghadapi skenario terburuk, tetapi Anda akan sering kecuali Anda cukup beruntung untuk menghabiskan sisa hidup Anda bekerja pada basis kode yang lebih kecil dengan tim yang terkoordinasi dengan baik dan standar pengkodean yang kuat.
Apa kode cantik di C ++ [...]?
Itu yang sulit. Saya masih mencoba mencari tahu itu. Sebagian besar kode yang saya anggap indah telah saya tulis selama bertahun-tahun, atau setidaknya dapat diandalkan dan relatif tidak lekang oleh waktu dan stabil (tidak perlu / menginginkan perubahan) ditulis dalam C dan baru-baru ini Lua. Saya masih berjuang untuk menulis kode C ++ yang tampaknya lulus ujian waktu ke titik di mana saya tidak merenungkannya beberapa tahun kemudian dan setidaknya berharap saya bisa mengubahnya. Saya merasa sudah semakin mudah sejak C ++ 11, tetapi saya perlu beberapa tahun untuk mengetahui seberapa baik kode saya berhasil bertahan tanpa perlu perubahan untuk memastikannya. Bagi saya "keindahan" pamungkas adalah "stabilitas", seperti dalam kode yang tidak perlu dan bahkan tidak menggoda perubahan lebih lanjut tetapi masih relevan dan berguna untuk tahun-tahun mendatang, karena itu '