Pemrograman sebagai Pembentukan Teori (1985)

geesecross · 2026-05-14T20:30:06+09:00

"Programming as Theory Building" karya Peter Naur memandang pemrograman bukan sebagai aktivitas menghasilkan teks program, melainkan sebagai aktivitas membentuk teori di dalam diri programmer tentang masalah dan solusinya. Di sini, "teori" bukan sekadar proposisi abstrak atau penjelasan desain yang terdokumentasi. Memahami makna suatu masalah di dunia nyata Mampu menjelaskan bagaimana struktur program berkorespondensi dengan dunia nyata tersebut Membenarkan alasan desain dibuat seperti itu Mampu menilai bagaimana mengintegrasikan kebutuhan baru ke dalam struktur yang ada Karena itu, pengetahuan inti dari sebuah program tidak sepenuhnya terkandung dalam kode atau dokumen, melainkan ada di dalam kepala programmer yang memahami program tersebut. Pemrograman dan pengetahuan Naur memandang pemrograman sebagai aktivitas memetakan kegiatan di dunia nyata ke manipulasi simbol formal yang dapat dijalankan komputer. Dalam sudut pandang ini, modifikasi program juga merupakan bagian dari pemrograman. Karena ketika aktivitas di dunia nyata berubah, program juga harus berubah. Hakikat pemrograman bukanlah dokumen atau artefak kode, melainkan pengetahuan tertentu yang dibangun para programmer. Dokumen itu penting, tetapi bersifat pendukung. Dokumen tidak dapat sepenuhnya menggantikan teori. Dokumen lebih dekat pada alat yang membantu pembentukan teori. Kasus 1: transfer compiler dan kegagalan Kelompok A membuat compiler untuk bahasa L. Kelompok B menerima kode compiler, dokumentasi, dan saran dari A untuk membuat compiler bagi bahasa perluasan L + M. Kode dan dokumen sudah diberikan secara memadai, tetapi B gagal memanfaatkan kekuatan struktur yang ada pada beberapa desain dan justru mengusulkan solusi tambal sulam. A segera mengenali masalahnya dan mengusulkan solusi yang lebih sederhana serta lebih alami di dalam struktur yang sudah ada. Inti dari kasus ini: Teks program dan dokumentasi saja tidak cukup untuk menyampaikan teori desain yang mendalam. "Mengapa" dari desain yang ada dan "bagaimana cara memperluasnya" tidak tersampaikan dengan cukup hanya lewat dokumen. Setelah itu, programmer lain yang tidak dibimbing oleh A memodifikasi compiler tersebut, dan struktur kuat aslinya perlahan melemah oleh tambahan-tambahan tak berbentuk. Ini menunjukkan bahwa teks program dan dokumentasi memiliki keterbatasan dalam melestarikan teori desain inti. Kasus 2: sistem real-time berskala besar Disajikan contoh sistem real-time industri dengan ukuran sekitar 200 ribu baris. Programmer yang bertanggung jawab atas instalasi dan diagnosis cacat telah lama terhubung erat dengan sistem sejak awal desainnya. Saat mendiagnosis cacat, mereka terutama mengandalkan pemahaman sistem yang langsung mereka miliki serta kode yang diberi komentar. Sebaliknya, programmer operasi eksternal yang hanya menerima dokumentasi dan pelatihan berulang kali mengalami kesulitan. Programmer berpengalaman dari pembuat sistem dapat menyelesaikan masalah itu dengan mudah. Kesimpulan: Pemeliharaan dan modifikasi program besar pada dasarnya bergantung pada pengetahuan yang dimiliki orang-orang yang telah lama terhubung dengan program tersebut. Penjelasan yang terdokumentasi saja tidak bisa sepenuhnya menggantikan pengetahuan itu. Konsep "teori" menurut Ryle Naur mengambil konsep teori dari Gilbert Ryle. Memiliki teori bukan sekadar mengetahui proposisi. Tahu bagaimana melakukan sesuatu Mampu menjelaskan hal tersebut Bisa menjawab pertanyaan Dapat membenarkan penilaiannya sendiri Aktivitas cerdas tidak harus direduksi menjadi aktivitas mengikuti aturan. Karena tindakan mengikuti aturan itu sendiri juga harus dilakukan secara cerdas. Jika cara mengikuti aturan memerlukan aturan lain lagi, akan terjadi regresi tak berhingga. Karena itu, aktivitas intelektual bukan sekadar menjalankan aturan, tetapi juga mencakup kemampuan menangkap kemiripan situasi dan meresponsnya dengan tepat. Teori tidak bisa sepenuhnya dinyatakan sebagai aturan Orang yang memiliki suatu teori dapat mengenali kemiripan yang bermakna di antara berbagai situasi di dunia nyata. Namun, kemiripan seperti ini sulit dinyatakan sepenuhnya lewat kriteria atau aturan yang jelas. Contoh: kemiripan wajah kemiripan melodi kemiripan rasa anggur Demikian pula dalam pemrograman, sulit mereduksi ke aturan sederhana bagaimana kebutuhan baru menyerupai struktur yang ada dan di mana ia harus diintegrasikan. Di sinilah inti dari tacit knowledge berada. Teori yang harus dimiliki programmer Programmer yang memiliki teori tentang suatu program harus mampu melakukan hal-hal berikut. 1. Mampu menjelaskan korespondensi antara dunia nyata dan program Ia harus mampu menjelaskan bagian mana dari program yang berkorespondensi dengan aktivitas atau konsep tertentu di dunia nyata. Sebaliknya, ia juga harus bisa menjelaskan bagaimana suatu aktivitas di dunia nyata direpresentasikan di dalam program. Untuk menilai apa yang relevan dan apa yang tidak, diperlukan pemahaman atas keseluruhan dunia nyata tersebut. 2. Mampu membenarkan mengapa program dibuat seperti itu Ia harus dapat menjelaskan mengapa struktur program dan detail implementasinya dirancang dengan cara tersebut. Pembenaran ini dapat menggunakan aturan, penalaran, prinsip desain, estimasi kuantitatif, dan sebagainya. Namun pada akhirnya, keputusan tentang prinsip mana yang diterapkan bergantung pada wawasan langsung programmer. 3. Mampu merespons kebutuhan modifikasi baru secara konstruktif Ia harus mampu mengenali fitur atau struktur mana dalam program yang mirip dengan kebutuhan baru tersebut. Berdasarkan kemiripan itu, ia harus bisa merancang agar modifikasi menyatu secara alami ke dalam teori yang sudah ada. Kemampuan ini sulit digantikan hanya dengan prosedur yang terdokumentasi. Modifikasi program dan biaya Software pada akhirnya pasti dimodifikasi. Karena dalam proses penggunaan akan muncul kebutuhan baru dan kondisi dunia nyata juga berubah. Sering diasumsikan bahwa memodifikasi program yang ada lebih murah daripada membuat yang baru. Namun dari sudut pandang Naur, harapan ini tidak selalu valid. Biaya modifikasi program bukanlah biaya mengedit teks. Biaya utamanya adalah memahami teori dari program yang ada dan mengintegrasikan kebutuhan baru ke dalam teori tersebut. Karena itu, fakta bahwa kode adalah teks yang mudah diedit tidak otomatis berarti modifikasi itu mudah. Batas fleksibilitas Gagasan untuk menanamkan fleksibilitas lebih dulu ke dalam program demi mengantisipasi perubahan masa depan hanya sebagian benar. Fleksibilitas tidak gratis. Harus diputuskan situasi masa depan seperti apa yang ingin diantisipasi parameter dan struktur harus dirancang ada biaya implementasi, pengujian, dan penjelasan Kegunaannya bergantung pada peristiwa masa depan yang belum pasti. Karena itu, fleksibilitas tidak dapat menjadi solusi umum untuk menghadapi perubahan. Yang penting bukan memasukkan struktur untuk semua perubahan sejak awal, melainkan kemampuan menilai dengan tepat berdasarkan teori program ketika perubahan benar-benar datang. Modifikasi yang baik dan modifikasi yang buruk Bahkan modifikasi yang memenuhi perilaku eksternal yang sama dapat diimplementasikan dengan banyak cara. Di permukaan, semuanya bisa tampak benar. Tetapi dari sudut pandang teori program, perbedaannya besar. Ada modifikasi yang secara alami memperluas teori yang ada. Ada modifikasi yang hanya bekerja seperti patch tambahan di atas struktur lama. Jika modifikasi jenis kedua berulang terus, program akan perlahan menjadi tambal sulam. Kemampuan bertahan jangka panjang suatu program bergantung pada seberapa baik setiap modifikasi berakar pada teori yang sudah ada. Hidup, mati, dan kebangkitan program Hidupnya program Program tetap hidup selama programmer yang memiliki teorinya masih secara aktif mengendalikan program tersebut. Mereka dapat merespons kebutuhan modifikasi secara intelektual. Kematian program Ketika tim yang memiliki teori program bubar, program itu mati. Program yang mati tetap bisa dijalankan dan masih menghasilkan hasil yang berguna. Namun kematian itu tampak ketika ia tidak lagi mampu merespons kebutuhan modifikasi dengan baik. Kebangkitan program Ini adalah upaya tim baru untuk membangun kembali teori dari program yang sudah ada. Naur memandang hal ini mustahil dalam arti yang ketat. Karena dokumentasi dan kode saja tidak cukup untuk sepenuhnya memulihkan teori yang dimiliki tim asli. Kalaupun kebangkitan mungkin terjadi, biayanya mahal, sulit, dan sangat mungkin menghasilkan teori yang berbeda dari teori semula. Dalam beberapa kasus, daripada menyelamatkan kode lama, bisa jadi lebih baik dan lebih murah bagi tim baru untuk memecahkan masalah itu kembali dari awal. Kritik terhadap metodologi Naur memandang metodologi pemrograman sebagai "sekumpulan aturan yang menentukan urutan pekerjaan apa yang harus dilakukan programmer". Dari sudut pandang pembentukan teori, metodologi dalam pengertian seperti ini gagal menangkap hakikat pemrograman. Alasannya: pembentukan teori tidak memiliki urutan yang tetap. teori pada dasarnya bukan gabungan linear dari bagian-bagian. notasi atau format dokumentasi dapat membantu pembentukan teori, tetapi bukan teori itu sendiri. Karena itu, muncul kesimpulan bahwa tidak ada metode yang secara universal benar untuk aktivitas utama pemrograman. Bukan berarti metodologi sepenuhnya tidak bernilai Yang ditolak Naur adalah metodologi sebagai prosedur yang secara mekanis menjamin desain yang baik. Metodologi, teknik desain, notasi, dan teknik verifikasi tetap dapat memiliki nilai edukatif. Programmer yang akrab dengan contoh yang baik, prinsip penataan struktur, dan teknik verifikasi lebih mungkin membentuk teori yang lebih baik. Namun keputusan tentang teknik mana yang dipakai, kapan dipakai, dan dalam urutan apa, harus diserahkan pada penilaian programmer yang memahami masalah nyata tersebut. Kedudukan programmer Jika pemrograman dipandang seperti produksi industri, programmer akan diperlakukan seperti komponen yang bisa diganti. Ini adalah pandangan bahwa siapa pun akan menghasilkan hasil yang sama jika mengikuti prosedur dan aturan. Naur menolak pandangan ini. Jika produk inti program adalah teori yang dimiliki programmer, maka programmer bukan pekerja yang mudah diganti. Programmer lebih dekat pada profesi yang secara bertanggung jawab mengembangkan dan mengelola keseluruhan aktivitas yang melibatkan komputer. Karena itu, programmer perlu diberi kedudukan dan tanggung jawab yang berkelanjutan. Pendidikan pun harus melampaui sekadar tata bahasa, notasi, dan teknik pemrosesan data, menuju pengembangan kemampuan membentuk teori. Metafora XP dan pembentukan teori "Metafora" dalam XP dapat dijelaskan dengan baik melalui sudut pandang pembentukan teori ala Naur. Metafora yang baik membantu tim membuat dugaan yang serupa tentang struktur program. Contoh: memahami program sebagai "jalur perakitan" memahami program sebagai "restoran" Metafora yang baik bukan sekadar perumpamaan sederhana. Ia membantu desainer menilai struktur seperti apa yang seharusnya diharapkan di mana kode baru harus ditambahkan dan bagaimana ia harus berpadu dengan kode yang dibuat orang lain Semakin banyak anggota tim dan semakin banyak pekerjaan paralel, semakin besar nilai dari metafora bersama. Tanpa teori bersama, setiap programmer akan membangun teorinya sendiri, dan sistem akan makin tidak selaras serta makin rumit. Peran dokumentasi Dokumen sulit selalu mengikuti keadaan terkini program secara sempurna. Meski begitu, bukan berarti dokumen tidak diperlukan. Tujuan dokumentasi bukan merekam semuanya, melainkan membantu programmer berikutnya membentuk teori yang tepat. Dokumentasi yang baik merangsang ingatan dan pengalaman pembaca, serta membuka jalur berpikir yang benar. Dokumentasi seperti ini bertahan lebih lama daripada dokumen yang sekadar mencantumkan daftar class, function, atau module saat ini. Susunan dokumen desain yang baik Desainer berpengalaman biasanya memulai dokumen dengan hal-hal berikut. metafora inti penjelasan tujuan komponen utama gambar interaksi inti antar komponen utama Ketiga hal ini sangat membantu tim berikutnya membentuk teori desain. Kode sumber itu sendiri juga merupakan sarana penyampaian teori. penamaan yang konsisten struktur yang sederhana pola yang dapat diprediksi meminimalkan pengecualian yang tidak perlu Sebagian besar dari "clean code" berkaitan dengan seberapa mudah pembaca dapat membentuk teori yang konsisten tentang sistem.

(gwern.net)

24 poin oleh geesecross 2026-05-14 | 3 komentar | Bagikan ke WhatsApp

"Programming as Theory Building" karya Peter Naur memandang pemrograman bukan sebagai aktivitas menghasilkan teks program, melainkan sebagai aktivitas membentuk teori di dalam diri programmer tentang masalah dan solusinya.
Di sini, "teori" bukan sekadar proposisi abstrak atau penjelasan desain yang terdokumentasi.
- Memahami makna suatu masalah di dunia nyata
- Mampu menjelaskan bagaimana struktur program berkorespondensi dengan dunia nyata tersebut
- Membenarkan alasan desain dibuat seperti itu
- Mampu menilai bagaimana mengintegrasikan kebutuhan baru ke dalam struktur yang ada
Karena itu, pengetahuan inti dari sebuah program tidak sepenuhnya terkandung dalam kode atau dokumen, melainkan ada di dalam kepala programmer yang memahami program tersebut.

Pemrograman dan pengetahuan

Naur memandang pemrograman sebagai aktivitas memetakan kegiatan di dunia nyata ke manipulasi simbol formal yang dapat dijalankan komputer.
Dalam sudut pandang ini, modifikasi program juga merupakan bagian dari pemrograman.
- Karena ketika aktivitas di dunia nyata berubah, program juga harus berubah.
Hakikat pemrograman bukanlah dokumen atau artefak kode, melainkan pengetahuan tertentu yang dibangun para programmer.
Dokumen itu penting, tetapi bersifat pendukung.
- Dokumen tidak dapat sepenuhnya menggantikan teori.
- Dokumen lebih dekat pada alat yang membantu pembentukan teori.

Kasus 1: transfer compiler dan kegagalan

Kelompok A membuat compiler untuk bahasa L.
Kelompok B menerima kode compiler, dokumentasi, dan saran dari A untuk membuat compiler bagi bahasa perluasan L + M.
Kode dan dokumen sudah diberikan secara memadai, tetapi B gagal memanfaatkan kekuatan struktur yang ada pada beberapa desain dan justru mengusulkan solusi tambal sulam.
A segera mengenali masalahnya dan mengusulkan solusi yang lebih sederhana serta lebih alami di dalam struktur yang sudah ada.
Inti dari kasus ini:
- Teks program dan dokumentasi saja tidak cukup untuk menyampaikan teori desain yang mendalam.
- "Mengapa" dari desain yang ada dan "bagaimana cara memperluasnya" tidak tersampaikan dengan cukup hanya lewat dokumen.
Setelah itu, programmer lain yang tidak dibimbing oleh A memodifikasi compiler tersebut, dan struktur kuat aslinya perlahan melemah oleh tambahan-tambahan tak berbentuk.
Ini menunjukkan bahwa teks program dan dokumentasi memiliki keterbatasan dalam melestarikan teori desain inti.

Kasus 2: sistem real-time berskala besar

Disajikan contoh sistem real-time industri dengan ukuran sekitar 200 ribu baris.
Programmer yang bertanggung jawab atas instalasi dan diagnosis cacat telah lama terhubung erat dengan sistem sejak awal desainnya.
Saat mendiagnosis cacat, mereka terutama mengandalkan pemahaman sistem yang langsung mereka miliki serta kode yang diberi komentar.
Sebaliknya, programmer operasi eksternal yang hanya menerima dokumentasi dan pelatihan berulang kali mengalami kesulitan.
Programmer berpengalaman dari pembuat sistem dapat menyelesaikan masalah itu dengan mudah.
Kesimpulan:
- Pemeliharaan dan modifikasi program besar pada dasarnya bergantung pada pengetahuan yang dimiliki orang-orang yang telah lama terhubung dengan program tersebut.
- Penjelasan yang terdokumentasi saja tidak bisa sepenuhnya menggantikan pengetahuan itu.

Konsep "teori" menurut Ryle

Naur mengambil konsep teori dari Gilbert Ryle.
Memiliki teori bukan sekadar mengetahui proposisi.
- Tahu bagaimana melakukan sesuatu
- Mampu menjelaskan hal tersebut
- Bisa menjawab pertanyaan
- Dapat membenarkan penilaiannya sendiri
Aktivitas cerdas tidak harus direduksi menjadi aktivitas mengikuti aturan.
- Karena tindakan mengikuti aturan itu sendiri juga harus dilakukan secara cerdas.
- Jika cara mengikuti aturan memerlukan aturan lain lagi, akan terjadi regresi tak berhingga.
Karena itu, aktivitas intelektual bukan sekadar menjalankan aturan, tetapi juga mencakup kemampuan menangkap kemiripan situasi dan meresponsnya dengan tepat.

Teori tidak bisa sepenuhnya dinyatakan sebagai aturan

Orang yang memiliki suatu teori dapat mengenali kemiripan yang bermakna di antara berbagai situasi di dunia nyata.
Namun, kemiripan seperti ini sulit dinyatakan sepenuhnya lewat kriteria atau aturan yang jelas.
Contoh:
- kemiripan wajah
- kemiripan melodi
- kemiripan rasa anggur
Demikian pula dalam pemrograman, sulit mereduksi ke aturan sederhana bagaimana kebutuhan baru menyerupai struktur yang ada dan di mana ia harus diintegrasikan.
Di sinilah inti dari tacit knowledge berada.

Teori yang harus dimiliki programmer

Programmer yang memiliki teori tentang suatu program harus mampu melakukan hal-hal berikut.

1. Mampu menjelaskan korespondensi antara dunia nyata dan program

Ia harus mampu menjelaskan bagian mana dari program yang berkorespondensi dengan aktivitas atau konsep tertentu di dunia nyata.
Sebaliknya, ia juga harus bisa menjelaskan bagaimana suatu aktivitas di dunia nyata direpresentasikan di dalam program.
Untuk menilai apa yang relevan dan apa yang tidak, diperlukan pemahaman atas keseluruhan dunia nyata tersebut.

2. Mampu membenarkan mengapa program dibuat seperti itu

Ia harus dapat menjelaskan mengapa struktur program dan detail implementasinya dirancang dengan cara tersebut.
Pembenaran ini dapat menggunakan aturan, penalaran, prinsip desain, estimasi kuantitatif, dan sebagainya.
Namun pada akhirnya, keputusan tentang prinsip mana yang diterapkan bergantung pada wawasan langsung programmer.

3. Mampu merespons kebutuhan modifikasi baru secara konstruktif

Ia harus mampu mengenali fitur atau struktur mana dalam program yang mirip dengan kebutuhan baru tersebut.
Berdasarkan kemiripan itu, ia harus bisa merancang agar modifikasi menyatu secara alami ke dalam teori yang sudah ada.
Kemampuan ini sulit digantikan hanya dengan prosedur yang terdokumentasi.

Modifikasi program dan biaya

Software pada akhirnya pasti dimodifikasi.
- Karena dalam proses penggunaan akan muncul kebutuhan baru
- dan kondisi dunia nyata juga berubah.
Sering diasumsikan bahwa memodifikasi program yang ada lebih murah daripada membuat yang baru.
Namun dari sudut pandang Naur, harapan ini tidak selalu valid.
Biaya modifikasi program bukanlah biaya mengedit teks.
- Biaya utamanya adalah memahami teori dari program yang ada
- dan mengintegrasikan kebutuhan baru ke dalam teori tersebut.
Karena itu, fakta bahwa kode adalah teks yang mudah diedit tidak otomatis berarti modifikasi itu mudah.

Batas fleksibilitas

Gagasan untuk menanamkan fleksibilitas lebih dulu ke dalam program demi mengantisipasi perubahan masa depan hanya sebagian benar.
Fleksibilitas tidak gratis.
- Harus diputuskan situasi masa depan seperti apa yang ingin diantisipasi
- parameter dan struktur harus dirancang
- ada biaya implementasi, pengujian, dan penjelasan
Kegunaannya bergantung pada peristiwa masa depan yang belum pasti.
Karena itu, fleksibilitas tidak dapat menjadi solusi umum untuk menghadapi perubahan.
Yang penting bukan memasukkan struktur untuk semua perubahan sejak awal, melainkan kemampuan menilai dengan tepat berdasarkan teori program ketika perubahan benar-benar datang.

Modifikasi yang baik dan modifikasi yang buruk

Bahkan modifikasi yang memenuhi perilaku eksternal yang sama dapat diimplementasikan dengan banyak cara.
Di permukaan, semuanya bisa tampak benar.
Tetapi dari sudut pandang teori program, perbedaannya besar.
- Ada modifikasi yang secara alami memperluas teori yang ada.
- Ada modifikasi yang hanya bekerja seperti patch tambahan di atas struktur lama.
Jika modifikasi jenis kedua berulang terus, program akan perlahan menjadi tambal sulam.
Kemampuan bertahan jangka panjang suatu program bergantung pada seberapa baik setiap modifikasi berakar pada teori yang sudah ada.

Hidup, mati, dan kebangkitan program

Hidupnya program

Program tetap hidup selama programmer yang memiliki teorinya masih secara aktif mengendalikan program tersebut.
Mereka dapat merespons kebutuhan modifikasi secara intelektual.

Kematian program

Ketika tim yang memiliki teori program bubar, program itu mati.
Program yang mati tetap bisa dijalankan dan masih menghasilkan hasil yang berguna.
Namun kematian itu tampak ketika ia tidak lagi mampu merespons kebutuhan modifikasi dengan baik.

Kebangkitan program

Ini adalah upaya tim baru untuk membangun kembali teori dari program yang sudah ada.
Naur memandang hal ini mustahil dalam arti yang ketat.
Karena dokumentasi dan kode saja tidak cukup untuk sepenuhnya memulihkan teori yang dimiliki tim asli.
Kalaupun kebangkitan mungkin terjadi, biayanya mahal, sulit, dan sangat mungkin menghasilkan teori yang berbeda dari teori semula.
Dalam beberapa kasus, daripada menyelamatkan kode lama, bisa jadi lebih baik dan lebih murah bagi tim baru untuk memecahkan masalah itu kembali dari awal.

Kritik terhadap metodologi

Naur memandang metodologi pemrograman sebagai "sekumpulan aturan yang menentukan urutan pekerjaan apa yang harus dilakukan programmer".
Dari sudut pandang pembentukan teori, metodologi dalam pengertian seperti ini gagal menangkap hakikat pemrograman.
Alasannya:
- pembentukan teori tidak memiliki urutan yang tetap.
- teori pada dasarnya bukan gabungan linear dari bagian-bagian.
- notasi atau format dokumentasi dapat membantu pembentukan teori, tetapi bukan teori itu sendiri.
Karena itu, muncul kesimpulan bahwa tidak ada metode yang secara universal benar untuk aktivitas utama pemrograman.

Bukan berarti metodologi sepenuhnya tidak bernilai

Yang ditolak Naur adalah metodologi sebagai prosedur yang secara mekanis menjamin desain yang baik.
Metodologi, teknik desain, notasi, dan teknik verifikasi tetap dapat memiliki nilai edukatif.
Programmer yang akrab dengan contoh yang baik, prinsip penataan struktur, dan teknik verifikasi lebih mungkin membentuk teori yang lebih baik.
Namun keputusan tentang teknik mana yang dipakai, kapan dipakai, dan dalam urutan apa, harus diserahkan pada penilaian programmer yang memahami masalah nyata tersebut.

Kedudukan programmer

Jika pemrograman dipandang seperti produksi industri, programmer akan diperlakukan seperti komponen yang bisa diganti.
Ini adalah pandangan bahwa siapa pun akan menghasilkan hasil yang sama jika mengikuti prosedur dan aturan.
Naur menolak pandangan ini.
Jika produk inti program adalah teori yang dimiliki programmer, maka programmer bukan pekerja yang mudah diganti.
Programmer lebih dekat pada profesi yang secara bertanggung jawab mengembangkan dan mengelola keseluruhan aktivitas yang melibatkan komputer.
Karena itu, programmer perlu diberi kedudukan dan tanggung jawab yang berkelanjutan.
Pendidikan pun harus melampaui sekadar tata bahasa, notasi, dan teknik pemrosesan data, menuju pengembangan kemampuan membentuk teori.

Metafora XP dan pembentukan teori

"Metafora" dalam XP dapat dijelaskan dengan baik melalui sudut pandang pembentukan teori ala Naur.
Metafora yang baik membantu tim membuat dugaan yang serupa tentang struktur program.
Contoh:
- memahami program sebagai "jalur perakitan"
- memahami program sebagai "restoran"
Metafora yang baik bukan sekadar perumpamaan sederhana.
- Ia membantu desainer menilai struktur seperti apa yang seharusnya diharapkan
- di mana kode baru harus ditambahkan
- dan bagaimana ia harus berpadu dengan kode yang dibuat orang lain
Semakin banyak anggota tim dan semakin banyak pekerjaan paralel, semakin besar nilai dari metafora bersama.
Tanpa teori bersama, setiap programmer akan membangun teorinya sendiri, dan sistem akan makin tidak selaras serta makin rumit.

Peran dokumentasi

Dokumen sulit selalu mengikuti keadaan terkini program secara sempurna.
Meski begitu, bukan berarti dokumen tidak diperlukan.
Tujuan dokumentasi bukan merekam semuanya, melainkan membantu programmer berikutnya membentuk teori yang tepat.
Dokumentasi yang baik merangsang ingatan dan pengalaman pembaca, serta membuka jalur berpikir yang benar.
Dokumentasi seperti ini bertahan lebih lama daripada dokumen yang sekadar mencantumkan daftar class, function, atau module saat ini.

Susunan dokumen desain yang baik

Desainer berpengalaman biasanya memulai dokumen dengan hal-hal berikut.
- metafora inti
- penjelasan tujuan komponen utama
- gambar interaksi inti antar komponen utama
Ketiga hal ini sangat membantu tim berikutnya membentuk teori desain.
Kode sumber itu sendiri juga merupakan sarana penyampaian teori.
- penamaan yang konsisten
- struktur yang sederhana
- pola yang dapat diprediksi
- meminimalkan pengecualian yang tidak perlu
Sebagian besar dari "clean code" berkaitan dengan seberapa mudah pembaca dapat membentuk teori yang konsisten tentang sistem.

3 komentar

baeba 2026-05-15

Terima kasih sudah membagikan materi yang bagus ini.
Tulisan seperti ini biasanya Anda menemukannya di mana? Apakah Anda melihatnya di forum lain lalu membagikannya di sini?
Saya akan berterima kasih jika Anda bisa membagikan situsnya.

geesecross 2026-05-15

Karena Naur disebut di https://id.news.hada.io/topic?id=29459#cid57382, saya mencari teks aslinya lalu membagikan ringkasan terjemahannya.

xguru 2026-05-15

Oh, bagus ya. Terima kasih.
Saya juga kadang menemukan tulisan baru dari komentar di Hacker News lalu membagikannya, jadi menurut saya fitur ringkasan komentar itu lumayan bagus. ^^;