Bagian mana dari Kode Lengkap yang belum teruji oleh waktu? [Tutup]


14

Saya sedang melihat Kode Lengkap di rak, berpikir, "Di luar Bulan Manusia Mythical, ini mungkin salah satu dari sedikit buku Rekayasa Perangkat Lunak pasar massal untuk bertahan dalam ujian waktu." Untuk alasan ini, saya berpikir untuk melompat untuk membaca ulang.

Saya ingin tahu - apakah ada orang lain yang melihatnya baru-baru ini? Saya jadi, apakah Anda melihat sesuatu yang salah?

Ini bukan serangan, dan bukan permintaan untuk review buku - saya lebih tertarik dengan ide yang telah berubah selama bertahun-tahun.

Dan tolong - tidak ada komentar tentang, "Demarco / Spewak / Zachman bertahan dalam ujian waktu ..." Saya secara khusus tertarik pada Kode Lengkap karena luasnya tanah yang dicakupnya, dan luasnya dampak di lapangan.


1
Pemeriksaan ulang yang cepat telah mengingatkan saya pada gangguan di mana teks tampak bertentangan dengan contoh-contoh, dan bagian-bagian berbeda dari buku ini menyarankan hal-hal yang berbeda. Selain itu, sepertinya masih cukup bagus.
Izkata

@Izkata - contoh?
MathAttack

Ditambahkan sebagai jawaban
Izkata

1
Pertanyaan bagus, baru-baru ini saya telah mempertimbangkan apakah akan membaca ulang sendiri. Saya ingin tahu apakah ada rencana untuk edisi baru?
Antonio2011a

2
Saya mempelajari Kode Lengkap (Edisi 2) musim panas lalu dan tidak ada yang terasa usang di sana. Kecuali jika akan ada perubahan radikal yang tak terduga dalam pengembangan perangkat lunak, saya pikir saya akan merasa aman merekomendasikan buku ini setidaknya dalam lima tahun dari sekarang.
nyamuk

Jawaban:


11

Kode Lengkap mencakup banyak konsep abadi seperti:

  • kohesi yang kuat
  • kopling longgar
  • nama rutin yang bagus
  • pemrograman defensif
  • kode dokumentasi diri
  • ulasan perangkat lunak
  • pengujian unit

yang tentunya relevan hari ini.

Beberapa konsep yang diperjuangkan dalam CC sekarang secara sintaksis ditegakkan dalam bahasa yang lebih baru, misalnya C # tidak memungkinkan variabel dalam sub-lingkup didefinisikan dengan cara yang menyembunyikan definisi super-lingkup.

Konsep lain, seperti notasi Hongaria untuk nama-nama variabel telah jatuh di pinggir jalan dalam pemrograman arus utama (meskipun siapa pun yang masih bekerja dengan Win32 API akan membantah keras bahwa mereka masih hidup dan sehat). Namun demikian, konsep sebenarnya di balik konvensi penamaan variabel adalah untuk menyampaikan makna yang diperlukan dan mengklarifikasi kode, konsep yang saya berpendapat juga abadi.

Semua mengatakan, dari apa yang dapat saya ingat (dan mengintip ke dalam salinan CC saya yang terhormat), saya akan mengatakan itu pasti layak ditinjau.

Saya tidak berpikir, bagaimanapun, bahwa itu naik ke sifat benar-benar abadi dari The Mythical Man Month. MMM membahas masalah siapa yang melakukan pekerjaan, bagaimana dan mengapa mereka melakukannya; serta biaya dan kompleksitas komunikasi (manusia). MMM membahas masalah yang mendasar bagi semua yang kita lakukan. CC, sebagai perbandingan, berfokus pada masalah praktis dan pragmatis tentang bagaimana kita melakukannya. Dengan kata lain, jika suatu proyek terlambat, dan seorang manajer memutuskan untuk menambah 100 orang ke dalam tim, menulis kode yang dapat dipahami tidak akan benar-benar membuat perbedaan.

CC tidak benar-benar mengatasi masalah signifikan yang mengganggu industri kita; tetapi itu memberikan landasan yang baik untuk berjuang untuk hasil terbaik dalam situasi yang seringkali tidak mungkin.

Saya pasti akan menganggap mereka berdua wajib membaca untuk siapa pun yang peduli tentang pengembangan perangkat lunak; dan saya akan merekomendasikan membaca kembali MM setiap kali Anda membutuhkan penyegaran. CC layak dibaca ulang jika Anda memimpin tim pengembangan, menetapkan standar grup, atau melatih pengembang baru; di luar itu, saya pribadi menemukan bahwa saya sudah lama menginternalisasi materi dalam CC dan mempraktikkannya setiap hari.

Harapan itu bisa membantu. Mereka tentu saja dua favorit saya.


Mungkin saya harus membuat Q serupa untuk MM. Mungkin Brooks lebih mudah sejak dia menulis buku manajemen.
MathAttack

Tidakkah CC membahas masalah "siapa yang melakukan pekerjaan" di bab 33: Karakter Pribadi?
mg1075

4

Secara keseluruhan, buku ini masih bagus. Namun, saya punya beberapa masalah kecil dengan itu:

  • Bab 17 ("Struktur Kontrol Tidak Biasa") memang menyebutkan pernyataan penjaga sebagai kembali dari fungsi lebih awal, tetapi contoh-contoh yang diberikan dalam Bab 15 tentang "jika" pernyataan menyarankan terhadap pernyataan penjaga. (Disebut klausa penjaga / pengembalian awal dalam buku)
  • Contoh di bagian 14.2 tampaknya bertentangan dengan dirinya sendiri. Pertama memberikan contoh kode "buruk", dan cara membuatnya "baik". Ini kemudian menyatakan bahwa, ketika mengelompokkan pernyataan terkait bersama-sama, baik dengan data atau kesamaan tugas akan "baik". Contoh "buruk" seharusnya juga dianggap "baik" - dan, saya pikir, lebih mudah dibaca daripada contoh "baik", karena semua data sedang dihitung pada tingkat yang sama - ada lebih sedikit keadaan untuk disimpan di kepala Anda .
  • Bab 23, Debugging, di mana pernyataan cetak dipersonifikasikan dalam poin-poin. Sementara saya setuju bahwa mereka seharusnya tidak menjadi satu-satunya alat, mereka sangat membantu dalam mengurangi rentang kode di mana bug terjadi. Taburkan beberapa bagian untuk melihat di mana data tiba-tiba tidak seperti yang Anda harapkan, memberikan titik awal yang baik untuk debugging, tergantung pada kode yang Anda gunakan.

Saya memiliki memori yang tidak jelas dari argumen fungsi lain yang melibatkan, tetapi tidak dapat menemukannya saat ini. Itu mungkin buku lain.


6
Ya, dia salah tentang pernyataan cetak waktu itu dan dia masih salah sekarang. Ketika dihadapkan dengan bug di lokasi yang tidak dikenal, cetakan dan log umumnya adalah alat pilihan saya.
Loren Pechtel
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.