Top-down adalah cara yang bagus untuk menggambarkan hal-hal yang Anda ketahui, atau membangun kembali hal-hal yang sudah Anda bangun.
Masalah top-down terbesar adalah bahwa seringkali tidak ada "top". Anda akan berubah pikiran tentang apa yang harus dilakukan sistem saat mengembangkan sistem dan saat menjelajahi domain. Bagaimana bisa titik awal Anda sesuatu yang tidak Anda ketahui (yaitu apa yang Anda ingin sistem lakukan)?
Top down "lokal" adalah hal yang baik ... beberapa pemikiran di depan pengkodean jelas baik. Tetapi berpikir dan merencanakan terlalu banyak bukanlah, karena apa yang Anda bayangkan bukanlah skenario nyata (kecuali Anda sudah pernah ke sana sebelumnya, yaitu jika Anda tidak membangun, tetapi membangun kembali). Global top-down ketika membangun hal-hal baru tidak masuk akal.
Bottom-up harus (secara global) pendekatan kecuali Anda tahu 100% dari masalah, Anda hanya perlu solusi yang dikenal untuk dikodekan dan Anda tidak peduli mencari kemungkinan solusi alternatif.
Pendekatan Lisp adalah bottom-up yang disuling. Anda tidak hanya membangun dari bawah ke atas tetapi Anda juga dapat membentuk batu bata seperti yang Anda inginkan. Tidak ada yang tetap, kebebasan adalah total. Tentu saja kebebasan mengambil tanggung jawab dan Anda dapat membuat hal-hal mengerikan dengan menyalahgunakan kekuatan ini.
Tetapi kode mengerikan dapat ditulis dalam bahasa apa pun. Bahkan dalam bahasa-bahasa yang dibentuk sebagai sangkar pikiran, dirancang dengan harapan bahwa dengan bahasa-bahasa itu bahkan monyet bisa menjalankan dan menjalankan program yang baik (sebuah ide yang sangat keliru pada banyak tingkatan sehingga menyakitkan bahkan hanya memikirkannya).
Contoh Anda adalah tentang server web. Sekarang pada 2012 ini adalah masalah yang terdefinisi dengan baik, Anda memiliki spesifikasi yang harus diikuti. Server web hanyalah masalah implementasi. Terutama jika Anda bertujuan untuk menulis server web secara substansial identik dengan gajillion server web lain yang ada di luar sana maka tidak ada yang benar-benar tidak jelas, kecuali beberapa hal kecil. Bahkan komentar Anda tentang RSA masih berbicara tentang masalah yang jelas, dengan spesifikasi formal.
Dengan masalah yang didefinisikan dengan baik, dengan spesifikasi formal dan solusi yang sudah dikenal maka pengkodean hanya menghubungkan di titik-titik. Top down tidak masalah untuk itu. Ini adalah surga manajer proyek.
Namun dalam banyak kasus tidak ada pendekatan terkenal yang terbukti digunakan untuk menghubungkan titik-titik. Sebenarnya sangat sering sulit untuk mengatakan apa saja titiknya.
Misalkan misalnya Anda diminta untuk menginstruksikan mesin pemotong otomatis untuk menyelaraskan bagian-bagian yang akan dipotong ke bahan cetak yang tidak sepenuhnya sesuai dengan logo berulang teori. Anda diberi bagian dan gambar dari bahan yang diambil oleh mesin.
Apa itu aturan pelurusan? Kamu putuskan. Apa itu pola, bagaimana cara mewakilinya? Kamu putuskan. Bagaimana cara menyelaraskan bagian-bagian? Kamu putuskan. Bisakah bagian "ditekuk"? Tergantung, ada yang tidak dan ada yang ya, tapi tentu saja tidak terlalu banyak. Apa yang harus dilakukan jika bahan terlalu cacat untuk memotong sehingga dapat diterima? Kamu putuskan. Apakah semua bahan gulungan identik? Tentu saja tidak, tetapi Anda tidak dapat mengganggu pengguna untuk mengadaptasi aturan penyelarasan untuk setiap gulungan ... yang tidak praktis. Gambar apa yang dilihat kamera? Materi, apa pun artinya ... itu bisa warna, bisa hitam di atas hitam di mana hanya refleks cahaya membuat polanya jelas. Apa artinya mengenali suatu pola? Kamu putuskan.
Sekarang coba desain struktur umum solusi untuk masalah ini dan berikan penawaran, dalam bentuk uang dan waktu. Taruhan saya adalah bahwa bahkan arsitektur sistem Anda ... (ya, arsitekturnya) akan salah. Estimasi biaya dan waktu adalah angka acak.
Kami menerapkannya dan sekarang ini adalah sistem yang berfungsi, tetapi kami berubah pikiran tentang bentuk sistem itu berkali-kali. Kami menambahkan seluruh sub-sistem yang sekarang bahkan tidak dapat dijangkau dari menu. Kami mengganti peran master / slave dalam protokol lebih dari sekali. Mungkin sekarang kita memiliki pengetahuan yang cukup untuk mencoba membangun kembali dengan lebih baik.
Perusahaan lain tentu saja memecahkan masalah yang sama ... tetapi kecuali Anda berada di salah satu perusahaan ini, kemungkinan besar proyek rinci top-down Anda akan menjadi lelucon. Kita bisa mendesainnya dari atas ke bawah. Anda tidak bisa karena Anda belum pernah melakukannya sebelumnya.
Anda mungkin dapat memecahkan masalah yang sama juga. Namun bekerja dari bawah ke atas. Dimulai dengan apa yang Anda ketahui, pelajari apa yang tidak Anda ketahui dan tambahkan.
Sistem perangkat lunak baru yang rumit ditanam, tidak dirancang. Kadang-kadang seseorang mulai mendesain sistem perangkat lunak kompleks baru yang tidak ditentukan dengan spesifik dari awal (catat bahwa dengan proyek perangkat lunak besar yang kompleks hanya ada tiga kemungkinan: a] spesifikasinya kabur, b] spesifikasinya salah dan kontradiktif sendiri atau c] keduanya ... dan paling sering [c] adalah masalahnya).
Ini adalah proyek khas perusahaan besar dengan ribuan dan ribuan jam dilemparkan ke slide powerpoint dan diagram UML saja. Mereka selalu gagal total setelah membakar sejumlah sumber daya yang memalukan ... atau dalam beberapa kasus yang luar biasa mereka akhirnya memberikan perangkat lunak yang terlalu mahal yang hanya menerapkan sebagian kecil dari spesifikasi awal. Dan perangkat lunak itu selalu dibenci oleh pengguna ... bukan jenis perangkat lunak yang akan Anda beli, tetapi jenis perangkat lunak yang Anda gunakan karena Anda terpaksa melakukannya.
Apakah ini berarti saya pikir Anda harus berpikir hanya untuk kode? Tentu saja tidak. Tapi menurut saya konstruksi harus dimulai dari bawah (batu bata, kode beton) dan harus naik ... dan fokus dan perhatian Anda terhadap detail harus dalam arti "memudar" karena Anda semakin jauh dari apa yang Anda miliki. Top-down sering disajikan seolah-olah Anda harus meletakkan tingkat detail yang sama untuk seluruh sistem sekaligus: tetap membelah setiap node sampai semuanya jelas ... dalam modul realitas, subsistem "tumbuh" dari subrutin. Jika Anda tidak memiliki pengalaman sebelumnya dalam masalah khusus, desain top-down Anda dari suatu subsistem, modul atau pustaka akan mengerikan. Anda dapat mendesain perpustakaan yang baik setelah Anda tahu fungsi apa yang harus dimasukkan, bukan sebaliknya.
Banyak ide Lisp semakin populer (fungsi kelas satu, penutupan, pengetikan dinamis sebagai default, pengumpulan sampah, metaprogramming, pengembangan interaktif) tetapi Lisp masih hari ini (di antara bahasa yang saya tahu) cukup unik dalam cara mudah membentuk kode untuk apa yang Anda butuhkan.
Parameter kata kunci misalnya sudah ada, tetapi jika tidak ada, mereka dapat ditambahkan. Saya melakukannya (termasuk verifikasi kata kunci pada waktu kompilasi) untuk kompiler Lisp mainan yang saya coba dan tidak memerlukan banyak kode.
Dengan C ++ sebagai gantinya yang paling banyak Anda dapatkan adalah sekelompok pakar C ++ yang memberi tahu Anda bahwa parameter kata kunci tidak terlalu berguna, atau implementasi templat setengah didukung yang sangat kompleks, rusak, setengah didukung yang memang tidak terlalu berguna. Apakah kelas C ++ objek kelas satu? Tidak dan tidak ada yang bisa Anda lakukan tentang itu. Bisakah Anda melakukan introspeksi saat runtime atau pada waktu kompilasi? Tidak dan tidak ada yang bisa Anda lakukan tentang itu.
Fleksibilitas bahasa Lisp inilah yang membuatnya bagus untuk bangunan dari bawah ke atas. Anda tidak hanya dapat membangun subrutin, tetapi juga sintaks dan semantik bahasa. Dan dalam arti tertentu, Lisp itu sendiri adalah dari bawah ke atas.