Pemrograman sebagai Pembentukan Teori (1985)

• "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.