Mengapa beberapa programmer berpikir ada perbedaan antara teori dan praktik? [Tutup]

Membandingkan rekayasa perangkat lunak dengan teknik sipil, saya terkejut mengamati cara berpikir yang berbeda: insinyur sipil mana pun tahu bahwa jika Anda ingin membangun gubuk kecil di kebun, Anda bisa mendapatkan bahan dan pergi membangunnya sedangkan jika Anda ingin membangun rumah 10 lantai (atau, misalnya, sesuatu seperti ini ) Anda perlu melakukan beberapa matematika untuk memastikan bahwa itu tidak akan berantakan.

Sebaliknya, berbicara dengan beberapa programmer atau membaca blog atau forum saya sering menemukan pendapat yang tersebar luas yang dapat dirumuskan kurang lebih sebagai berikut: teori dan metode formal adalah untuk ahli matematika / ilmuwan sementara pemrograman lebih banyak tentang menyelesaikan sesuatu .

Apa yang biasanya tersirat di sini adalah bahwa pemrograman adalah sesuatu yang sangat praktis dan bahwa meskipun metode formal, matematika, teori algoritma, bahasa pemrograman bersih / koheren, dll, mungkin merupakan topik yang menarik, mereka seringkali tidak diperlukan jika semua yang diinginkan adalah mendapatkan sesuatu dilakukan .

Menurut pengalaman saya, saya akan mengatakan bahwa sementara Anda tidak perlu banyak teori untuk menyusun skrip 100-baris (pondok), untuk mengembangkan aplikasi yang kompleks (gedung 10 lantai), Anda memerlukan desain yang terstruktur, baik metode -defined, bahasa pemrograman yang baik, buku teks yang bagus di mana Anda dapat mencari algoritma, dll.

Jadi teori IMO (jumlah yang tepat) adalah salah satu alat untuk menyelesaikan sesuatu .

Pertanyaan saya adalah mengapa beberapa programmer berpikir bahwa ada perbedaan antara teori (metode formal) dan praktik (menyelesaikan sesuatu)?

Apakah rekayasa perangkat lunak (software bangunan) dianggap oleh banyak orang sebagai mudah dibandingkan dengan, katakanlah, teknik sipil (building houses)?

Atau apakah kedua disiplin ini benar-benar berbeda (terlepas dari perangkat lunak mission-critical, kegagalan perangkat lunak jauh lebih dapat diterima daripada membangun kegagalan)?

Saya mencoba merangkum, apa yang saya pahami dari jawaban sejauh ini.

1. Berbeda dengan rekayasa perangkat lunak, dalam teknik sipil jauh lebih jelas berapa jumlah teori (pemodelan, desain) yang dibutuhkan untuk tugas tertentu.
2. Ini sebagian disebabkan oleh kenyataan bahwa teknik sipil sama tuanya dengan manusia sementara rekayasa perangkat lunak telah ada selama beberapa dekade saja.
3. Alasan lain adalah kenyataan bahwa perangkat lunak adalah jenis artefak yang lebih tidak stabil, dengan persyaratan yang lebih fleksibel (dapat dibiarkan crash), strategi pemasaran yang berbeda (desain yang baik dapat dikorbankan untuk mendapatkannya di pasar dengan cepat), dll.

Akibatnya, jauh lebih sulit untuk menentukan jumlah yang tepat dari desain / teori yang sesuai dalam rekayasa perangkat lunak (terlalu sedikit -> kode berantakan, terlalu banyak -> Saya tidak pernah bisa selesai) karena tidak ada aturan umum dan hanya (Banyak) pengalaman bisa membantu.

Jadi, jika saya menafsirkan jawaban Anda dengan benar, ketidakpastian tentang seberapa banyak teori ini benar-benar dibutuhkan berkontribusi pada perasaan cinta / benci yang dicampur beberapa programmer terhadap teori.

Saya pikir perbedaan utama adalah bahwa dengan teknik sipil, fisika dunia nyata bertindak sebagai konstan, pengecekan realitas kuat yang membuat teori tetap waras dan juga membatasi praktik buruk, sedangkan dalam rekayasa perangkat lunak tidak ada kekuatan yang sama kuatnya untuk menjaga konsep menara gading yang tidak praktis juga. sebagai pengerjaan buruk di cek.

Banyak programmer memiliki pengalaman buruk dengan teori pelarian menjadi hambatan aktif untuk menyelesaikan sesuatu (misalnya "UML yang dapat dieksekusi", proses pengembangan super-birokrasi). Sebaliknya, peretasan dan tambalan yang kotor bisa membuat Anda sangat jauh, meskipun pada akhirnya lambat. Dan seperti yang Anda amati dalam paragraf terakhir Anda: kegagalan biasanya tidak final dan dengan demikian tidak bermasalah.

Rekayasa perangkat lunak dan teknik sipil tidak memiliki banyak kesamaan. Upaya teknik sipil dibatasi oleh sifat fisik material dan lingkungannya. Insinyur sipil menghabiskan banyak waktu untuk mempelajari sifat-sifat tanah dan karakteristik material. Pengembangan perangkat lunak secara fisik hanya dibatasi oleh kecepatan prosesor dan penyimpanan yang tersedia. Keduanya mudah dipahami, dan kami tidak menghabiskan banyak waktu untuk mempelajarinya. Keterbatasan utama untuk pengembangan perangkat lunak adalah kecerdasan manusia. Dan tidak ada dua pengembang yang sama. Apakah kode ini dapat dikelola? Oleh siapa? Implementasi quicksort tiga baris di Haskell mungkin jelas benar untuk beberapa orang, tetapi tidak dapat dipahami oleh orang lain. Sebuah tim yang terdiri dari dua orang dapat menyelesaikan aplikasi dalam sebulan, sementara tim lain yang terdiri dari sepuluh orang berjuang untuk memberikannya dalam setahun.

Pengembangan perangkat lunak adalah semua desain, artefak yang dirancang adalah urutan besarnya lebih kompleks daripada artikel yang diproduksi, dan masing-masing unik.

Sebagai insinyur mesin yang lebih atau kurang jujur-to-gosh (dengan beberapa sipil) berubah menjadi programmer, kemudian CS (AI) PhD, kemudian guru, kemudian programmer lagi (permisi, Insinyur Perangkat Lunak ), saya punya kata-kata kasar di subjek umum ini.

Dalam teknik tradisional

• Anda harus tahu matematika dan sains Anda karena semua yang Anda lakukan didasarkan padanya
• "pahlawan" di lapangan adalah orang-orang yang menemukan hal-hal baru, menemukan ide-ide baru, menyelesaikan masalah yang dianggap tidak dapat diselesaikan

Ada "fisika" yang berlaku untuk perangkat lunak - teori informasi, tetapi insinyur perangkat lunak mendapatkan sedikit paparan padanya, dan tentu saja tidak ada yang diterapkan. Teori yang paling mereka dapatkan adalah kemampuan komputasi dan big-O.

Saya juga terus kagum pada orang-orang yang berpikir bahwa mengetahui pemrograman sudah cukup, dan mereka tidak perlu memahami pokok permasalahan tentang program mereka.

Terlebih lagi, daya cipta tidak dianjurkan. Ini tidak dianjurkan, demi metode berpikir kelompok-penyebut-kurang-umum, menyamar sebagai "keterbacaan". (Bayangkan jika insinyur penerbangan atau nuklir didorong untuk tidak melakukan apa pun yang mungkin sulit dipahami oleh rekan-rekan junior mereka.)

Hal-hal yang mereka pelajari, seperti cara memprogram aplikasi web, sangat berharga. Begitu juga keterampilan tukang ledeng atau tukang listrik, tetapi itu bukan teknik.

Jika saya memotong sudut sebagian besar perangkat lunak, dan melakukan sesuatu yang bukan desain terbaik, tetapi akan menyelesaikan pekerjaan, tidak ada yang akan mati. Itu alasan yang sama gubuk di taman tidak membutuhkan standar yang sama dengan bangunan 10 lantai. Namun, saya dapat membangun aplikasi yang sangat besar seperti facebook, dan jika itu merusak dan kehilangan beberapa data, atau apa pun, itu bukan masalah besar. Lebih mudah untuk memperbaiki fondasi aplikasi besar setelah fakta, daripada mengganti fondasi bangunan 10 lantai. Semuanya bermuara pada konteks, dan menghitung risiko.

Saya juga bisa, dengan aman dan terus menambahkan ke aplikasi. Anda tidak dapat dengan mudah melemparkan di lantai ketiga gedung 10 lantai yang baru (menjadikannya 11). Saya bisa melemparkan fitur baru ke aplikasi besar setiap hari jika saya mau.

Sekarang, desain yang baik membuat semua ini lebih mudah dalam pemrograman. Tapi bukan tidak mungkin dengan desain yang buruk, dan risikonya, adalah ... perangkat lunak kereta. Tidak biasanya mati.

Bersabarlah dengan saya dalam hal ini. Saya ada benarnya.

Saya mempunyai seorang profesor yang pernah mengatakan kepada saya bahwa menunda-nunda menyebabkan lebih banyak menunda-nunda, walaupun kebanyakan orang setelah satu malam menulis makalah yang sibuk / menjejalkan / pemrograman berkata kepada diri mereka sendiri, "Saya tidak akan pernah melakukannya lagi. Lain kali, saya akan mulai lebih awal dan selesai lebih awal. " Dalam pengalaman saya sebagai penunda yang sempurna, saya telah menemukan ini benar, dan inilah penjelasan profesor mengapa: tidak peduli betapa tidak menyenangkannya pengalaman menunda-nunda, dalam banyak kasus, Anda telah selesai telah mencapai kesuksesan relatif. Ini adalah risiko tinggi / perilaku imbalan tinggi. Setelah beberapa saat, Anda melupakan semua ketidaknyamanan ini, dan hanya mengingat hadiahnya. Dengan demikian, godaan berikutnya untuk menunda-nunda adalah lebih menarik, karena Anda berhasil terakhir kali.

Saya pikir analogi dapat dibuat di sini untuk teknik pemrograman "menyelesaikan sesuatu" yang terlalu sering kita lihat. Seorang programmer atau tim programmer, mungkin karena ketidaktahuan, kemalasan, atau mungkin kendala waktu, mengambil pendekatan "menyelesaikan sesuatu" untuk pemrograman, membuang semua teori dan matematika Anda dan praktik-praktik baik ke luar jendela. Dan tahukah Anda? Mereka menyelesaikan sesuatu. Itu tidak elegan, cantik, atau bisa dipelihara, tapi itu menyelesaikan pekerjaan. Mungkin atasan non-teknis yang tidak tahu titik koma dari semaphore memberi mereka pujian tinggi untuk "menyelesaikan sesuatu". Jadi, waktu berikutnya programmer tergoda untuk mengambil pendekatan kendur ini untuk pemrograman, itu semua lebih mudah, karena hei, itu berhasil terakhir kali bukan? Itu jalan keluar yang "mudah", kecuali jika Anda yang miskin,

Aku sudah menjadi jiwa yang malang dan malang itu, dan mungkin banyak di antara kalian juga. Saya mohon Anda semua. Jangan mengambil jalan keluar yang mudah! :)

Premis Anda cacat. Alasan utama insinyur sipil menggunakan teknik ketika merancang bangunan besar, jembatan, terowongan, dll. Adalah untuk memastikan bahwa mereka menggunakan jumlah minimum material (beton, baja struktural, dll) yang memenuhi standar keselamatan yang disyaratkan. Sangat mungkin untuk membangun gedung tinggi tanpa banyak cara matematika (misalnya piramida peradaban Mesir dan Maya kuno) jika biaya bahan dan tenaga kerja bukan objek, tetapi sekali dibangun, biasanya tidak ada gunanya memodifikasi mereka untuk membuat mereka menggunakan material dengan lebih efisien.

Ada dinamika yang agak berbeda dalam mendesain sistem perangkat lunak besar. Jika ada, mereka biasanya di bawah desain, tetapi ini karena desain dapat diubah secara dinamis sebagai hasil pekerjaan, yang tidak dapat dilakukan dengan mudah dengan proyek-proyek teknik sipil.

Faktor umum adalah biaya. Desain pada proyek teknik sipil tradisional mengurangi biaya (baik aktual, dalam hal bahan, dan potensi dalam hal kewajiban), sedangkan ada titik dalam pengembangan perangkat lunak di mana biaya desain meningkat melampaui nilai yang dikembalikan.

Saya juga akan menunjukkan, di samping beberapa tanggapan yang sangat baik lainnya bahwa umat manusia telah melakukan yang setara dengan "teknik sipil" sejak masa Mesir, jadi kami punya banyak waktu untuk menyempurnakan teori umum tentang bagaimana segala sesuatu harus dilakukan. dilakukan. Kami telah membangun perangkat lunak sekitar 70 tahun (tergantung pada apa yang Anda anggap sebagai "perangkat lunak" pertama); Maksud saya, kita tidak memiliki jumlah waktu yang sama untuk mengembangkan jenis pengalaman yang sama.

Cetak biru seorang arsitek / insinyur sipil hampir tidak pernah identik dengan rencana "seperti yang dibangun". Sesuatu SELALU berubah. Mengapa? Karena ada, dan akan selalu, "tidak diketahui tidak diketahui". Ada hal-hal yang Anda tahu dan bisa rencanakan, hal-hal yang Anda tahu tidak diketahui dan Anda bisa meneliti dan memperkirakan, dan kemudian ada hal-hal yang Anda tidak tahu Anda tidak tahu; "kejutan". Anda bertujuan untuk menghilangkan ini di sebagian besar sistem dengan mempelajari semua yang Anda bisa, tetapi yang diperlukan hanyalah satu pelanggaran kode bangunan kecil (yang mungkin didasarkan pada aturan yang tidak ada 2 tahun lalu ketika bangunan Anda dikonsep) dan semua Anda Rencana induk yang mencakup harus berubah, kadang-kadang cukup drastis.

Perangkat lunaknya sangat seperti ini; selalu ada yang tidak diketahui tidak dikenal. Namun, tidak seperti teknik sipil atau struktural, pengembangan perangkat lunak pada dasarnya jauh lebih toleran terhadap perubahan berdasarkan masalah yang tidak diketahui yang tidak diketahui. Jika Anda membangun gedung 10 lantai dan terlalu tinggi memperkirakan daya dukung fondasi yang Anda masukkan ke dalam desain, Anda tidak dapat membangun gedung hingga 10 lantai atau Anda harus merobohkan banyak pekerjaan untuk kembali ke fondasi dan memperkuat atau membangunnya kembali. Namun, dalam perangkat lunak, jika Anda meremehkan tuntutan pada tingkat tertentu dari keseluruhan struktur solusi, ada banyak opsi untuk memperbaiki tingkat yang tidak melibatkan pembatalan semua pekerjaan lainnya. Anda dapat mengganti satu server DB dengan yang lebih kuat, atau cluster replikasi / failover, atau cluster load-balancing / didistribusikan. Sama untuk server web. Jika Anda mengkodekan suatu algoritma yang tidak efisien tetapi sederhana berdasarkan pada asumsi ukuran input yang salah, Anda hampir selalu dapat dengan mudah menghapus dan menulis ulang implementasi dengan cara yang relatif bedah, tanpa memengaruhi kode lain yang memiliki pengetahuan tentang algoritma (memanggil dan meneruskan input ke atau mengharapkan output darinya).

Kemudahan perubahan yang relatif ini memungkinkan seorang insinyur perangkat lunak untuk membuat kode berdasarkan apa yang dia ketahui tanpa terlalu khawatir tentang apa yang tidak dia ketahui. Ini memungkinkan aplikasi teori yang lebih longgar dan desain konseptual di muka; Anda menyelam dan menyelesaikannya, dan di sepanjang jalan Anda menemukan hal-hal yang Anda kodekan yang perlu diubah, dan mengubahnya. Anda masih harus tahu konsep dan teori, karena ketika masalah terungkap itu adalah hal-hal yang akan membantu Anda mengidentifikasi penyebab dan menciptakan solusi. Tapi, Anda diizinkan untuk mengambil keputusan cepat tanpa menyerah pada "analisis kelumpuhan", karena jika ternyata Anda membuat keputusan yang salah berdasarkan sesuatu yang Anda tidak tahu atau tidak memperhitungkan "perhitungan" Anda, kesalahan lebih mudah diperbaiki.

Perbedaannya terutama karena persyaratan yang diketahui:

• Di sisi teori, semuanya didefinisikan di muka, sehingga Anda bisa tahu persis apa yang Anda butuhkan sebelum memulai.
• Dalam praktiknya, seringkali tidak semuanya ada, atau Anda menemukan sesuatu di tengah implementasi yang menyebabkan Anda harus mendesain ulang sesuatu. Jadi jauh lebih baik untuk melompat dengan setidaknya desain yang belum sempurna, sehingga Anda dapat menemukan masalah ini sejak awal.

Selain itu, ketika berbicara tentang "teori", itu biasanya berarti sisi teori ilmu komputer, daripada rekayasa perangkat lunak. Ini adalah bagian dari ilmu komputer yang sebagian besar tentang menemukan algoritma yang lebih baik dan lebih efisien, membuktikan apakah sesuatu itu mungkin atau tidak mungkin (P dan NP, misalnya), dan sebagainya. Meskipun ada baiknya mengingat hal ini, mereka tidak sering muncul dalam pengembangan perangkat lunak.

Kami menggunakan perpustakaan untuk hal semacam itu sebanyak mungkin.

Sebenarnya ada beberapa level rekayasa perangkat lunak tergantung pada apa yang sedang Anda lakukan.

NASA membutuhkan perangkat lunak untuk mengontrol antar-jemput berawak di luar angkasa sehingga secara alami tingkat proses rekayasa jauh lebih ketat daripada membangun situs web untuk menampilkan gambar roket.

Salah satu rekan kerja saya yang bekerja untuk NASA sebelumnya menggambarkan proses rekayasa perangkat lunak mereka sebagai menulis ratusan halaman pembenaran dan ratusan jam pertemuan untuk membenarkan penulisan satu baris kode!

Jangan salah paham dengan saya karena saya tidak berusaha terdengar tidak sopan ketika saya mengatakan ini, tetapi bahkan setelah semua biaya waktu, sumber daya, dan miliaran dolar, pesawat ruang angkasa masih meledak.

Bahkan insinyur sipil tahu bahwa tidak peduli berapa banyak teori yang mereka masukkan ke dalam desain, sesuatu yang pada akhirnya akan merusaknya sehingga mereka juga perlu mengembangkan rencana kontingensi.

Ketika membangun perangkat lunak, biaya kerusakannya jarang menyebabkan hilangnya nyawa sehingga jauh lebih mudah untuk membuang barang-barang di luar sana dan mengujinya. Mari kita sepakat bahwa menyelesaikan sesuatu dengan cepat menghasilkan kode yang lemah. Bahkan jika ini selalu terjadi, melihat perangkat lunak dalam tindakan adalah cara terbaik bagi pengembang untuk melihat di mana itu lemah dan perlu dibuat lebih kuat versus di mana itu lemah dan masih berkali-kali lebih kuat daripada yang dibutuhkan untuk mengimbangi muatan.

Singkatnya, Premature optimization is the root of all evil atau seperti yang selalu dikatakan bos sayaShipping is a feature!

Banyak jawaban bagus di sini, tapi saya pikir perbandingan antara Ilmu Komputer dan Teknik Sipil cacat.

Sebenarnya, yang dilakukan pengembang perangkat lunak profesional lebih seperti Rekayasa Perangkat Lunak daripada Ilmu Komputer. Analogi yang lebih baik adalah bahwa Ilmu Komputer adalah Fisika untuk Rekayasa Perangkat Lunak. Demikian pula, Civil Engieering adalah kumpulan penyederhanaan dan perkiraan Fisika untuk hal-hal praktis membangun.

Saya membayangkan bahwa Insinyur Sipil jarang harus mempertimbangkan relativitas umum ketika melakukan pekerjaan mereka. Banyak Teknik Sipil dapat dibangun dengan aman di Mekanika Newton. Demikian pula, Rekayasa Perangkat Lunak dapat dicapai dengan sangat sukses dengan pemahaman kasar tentang ilmu komputer teoretis.

Perbedaan besar adalah bahwa jembatan, gedung pencakar langit, dan produk lain dari Teknik Sipil adalah hal-hal yang cukup dipahami. Insinyur perangkat lunak sering membangun konstruksi novel, atau menggunakan metode baru untuk membangun hal-hal yang dipahami dengan baik. Rekayasa Perangkat Lunak JAUH kurang matang daripada Teknik Sipil, dan itu kemungkinan akan terus benar untuk masa mendatang.

TL; DR : Teori dan praktik berbeda dalam Rekayasa Perangkat Lunak seperti halnya di tempat lain. Analogi yang tepat adalah Rekayasa Perangkat Lunak: Teknik Sipil :: Ilmu Komputer: Fisika. Namun dalam praktiknya, ini sedikit lebih kompleks dari itu :)

Jadi pertanyaan saya adalah mengapa beberapa programmer berpikir bahwa ada perbedaan antara teori (metode formal) dan praktek (menyelesaikan sesuatu)?

Membangun perangkat lunak tidak seperti membangun jembatan. Dalam perangkat lunak, ada banyak objek yang akan dibangun yang mungkin atau mungkin tidak ditentukan saat permulaan. Ada standar untuk meningkatkan kemudahan pemeliharaan dan kolaborasi pengembang, bukan untuk mematuhi formula matematika yang sewenang-wenang atau cita-cita semacam itu. Misalnya, ketika memilih perilaku berdasarkan variabel kadang-kadang masuk akal untuk menggunakan switch, di lain waktu pola pabrik. Itu tergantung pada kemudahan perawatan dan mengidentifikasi titik-titik nyeri seperti masalah kinerja.

Contoh lain dapat dibuat dengan manipulasi data. Seringkali masuk akal untuk menggunakan delegasi dalam konteks .NET. Ini tidak begitu mudah di Jawa karena tidak memiliki dukungan kerangka kerja untuk gaya pemrograman fungsional yang dimiliki .NET. Dengan kata lain, dalam kasus umum itu tidak mungkin untuk melakukan X dalam situasi Y. Hal ini disebabkan oleh fakta bahwa X dan Y bergantung pada N sejumlah faktor variabel.

Apakah rekayasa perangkat lunak (membangun perangkat lunak) dianggap oleh banyak orang sebagai mudah dibandingkan dengan, katakanlah, teknik sipil (bangunan rumah)?

Saya tidak yakin "mudah" adalah istilah yang benar. Kurangnya bukti nyata dapat mengarah pada persepsi bahwa tidak ada pekerjaan yang dilakukan. Atau, sama halnya, pekerjaan yang ada mudah diubah.

Atau apakah kedua disiplin ini benar-benar berbeda (terlepas dari perangkat lunak mission-critical, kegagalan perangkat lunak jauh lebih dapat diterima daripada membangun kegagalan)?

Teknik Tradisional dan Rekayasa Perangkat Lunak sangat berbeda karena alasan yang telah saya nyatakan.

Persepsi Anda mungkin salah di sini, atau itu mencakup banyak sumber daya dari orang-orang yang belum menulis perangkat lunak yang cukup kompleks.

Pengalaman Anda sejalan dengan apa yang dikatakan kebanyakan orang (yang telah merancang dan menulis perangkat lunak yang cukup kompleks).

Yang mengatakan, ketika datang ke sebagian besar programmer , ketika tugas menulis sesuatu sampai kepada mereka desain ("matematika" seperti yang Anda katakan) telah dilakukan oleh arsitek / lead / etc. sebelum tugas menulis sampai kepada mereka. Jadi mungkin terlihat seperti itu dari tingkat garis depan.

Saya pikir alasan untuk kontras ini adalah bahwa siklus hidup proyek perangkat lunak dan proyek perangkat keras atau arsitektur berbeda. Sebagian besar perangkat lunak berevolusi secara bertahap, tidak direncanakan dari awal hingga akhir. Pengembang perangkat lunak dapat menerapkan pendekatan berulang untuk pengembangan: merencanakan, mengimplementasikan, dan mendengarkan umpan balik. Jika umpan balik positif, teruskan, jangan - mundur dan pertimbangkan kembali strategi Anda. Itu sebabnya pengembang perangkat lunak memiliki hal-hal seperti pengembangan lincah, produk yang layak minimum dan sebagainya.

Insinyur sipil tidak memiliki kemewahan seperti itu. Bagi mereka, begitu sesuatu telah direncanakan, Anda tidak dapat mengubahnya dengan mudah, seperti pada perangkat lunak, karena biaya dari perubahan tersebut dapat mengerikan. Untuk pengembangan perangkat lunak, di sisi lain, tidak memerlukan biaya banyak, dan ini dapat digunakan untuk keuntungan mereka.

Tetapi tidak setiap cabang pengembangan perangkat lunak mampu melakukan pendekatan seperti itu. Membuat perangkat lunak, misalnya, untuk penerbangan atau layanan medis memerlukan perencanaan yang sangat hati-hati dan banyak perhitungan sebelumnya.

Sepertinya sama dengan saya. Anda membangun gedung besar dari balok standar, beton mutu standar, baja standar. Anda membangun aplikasi besar dari perpustakaan standar.

Anda tidak mencoba dan secara matematis secara formal membuktikan aplikasi besar yang benar dengan cara yang sama Anda tidak mencoba dan menulis fungsi gelombang untuk bangunan bertingkat 100

Saya adalah seorang insinyur mekanik dan manufaktur sebelum saya menemukan sekitar 20 tahun yang lalu bahwa bakat saya terletak pada perangkat lunak. Saya bersimpati dengan banyak elemen yang telah Anda susun.

Saya menduga bahwa sifat sebenarnya dari masalah adalah tentang bagaimana kita menyelesaikan sesuatu. Kami sekarang memiliki sepuluh tahun atau lebih pengembangan tangkas di bawah ikat pinggang kolektif kami, dan pesannya jelas. Jangan maju selangkah demi selangkah; maju dengan fitur. Tentu - akan ada proyek ketika Anda perlu maju secara berlapis-lapis (mis. Membangun tumpukan jaringan Anda sebelum server web Anda) tetapi untuk sebagian besar proyek dunia nyata, kami telah mempelajari pelajaran yang menghadirkan fitur-fitur yang berfungsi, satu atau beberapa di suatu waktu, jauh lebih efektif membangun teori-teori besar yang belum diuji, dan kemudian mencoba menerapkannya.

Jadi, mari kita ambil contoh gubuk Anda (saya biasanya berbicara tentang membuat jembatan dengan melemparkan log melintasi sungai vs jembatan gantung sepanjang satu kilometer ... terserah!), Dan membawanya ke dunia rekayasa perangkat lunak. Perbedaan utama yang saya lihat adalah bahwa dalam perangkat lunak, sebagian besar pekerjaan adalah skala yang tidak memerlukan pemodelan besar di muka untuk berhasil. Kesalahan pemula adalah sering berasumsi bahwa hal-hal membutuhkan lebih banyak dari ini daripada yang sebenarnya mereka lakukan, dan bagi kebanyakan dari kita, setelah melakukan kesalahan itu beberapa kali, kita harus membuatnya lagi terlalu sering.

Tanpa argumen - ada proyek yang perlu dimulai dengan komite 17 arsitek perangkat lunak. Sebenarnya mereka jarang ditemukan seperti berlian 20 karat.

Saya pikir analoginya cacat. Sejauh yang saya ketahui, teknik sipil tidak memiliki dasar teori yang sama dengan ilmu komputer; ilmu komputer lahir dari teori matematika — seperti mesin Turing. Teknik sipil adalah tentang menciptakan struktur yang tahan terhadap alam ibu dan bahkan mungkin terlihat indah. Sekali lagi, saya benar-benar tidak tahu banyak tentang teknik sipil, tetapi saya tidak berpikir ada insinyur sipil yang setara dengan P vs NP, salesman keliling, dan hal-hal menyenangkan lainnya untuk membuat otak Anda menentang. Dan pasti ada tempat untuk teori ilmu komputer kita — jika seseorang memecahkan wiraniaga keliling atau masalah yang sedang kita hadapi untuk banyak kemajuan baru yang mengagumkan. Tetapi untuk seorang insinyur perangkat lunak, yang bisnisnya adalah untuk perangkat lunak arsitek, masalah seperti itu benar-benar hanya permainan dan kesenangan.

Sekarang, saya juga berpikir itu tergantung pada apa yang Anda maksud dengan "teori." Apakah kita berbicara pola desain, atau memompa lemma? Karena memiliki pemahaman yang baik tentang pola desain sangat penting untuk menjadi insinyur perangkat lunak yang baik. Namun, ketika merancang sistem perangkat lunak besar, berteori tentang masalah P / NP tidak berguna. Dalam hal itu, saya percaya ada perbedaan yang sangat mencolok antara rekayasa perangkat lunak dan ilmu komputer teoretis.

Atau apakah teori merujuk pada algoritma? Anda tidak menghabiskan banyak waktu untuk menulis algoritma yang Anda pelajari di kelas algoritme Anda. Mengapa? Karena Anda biasanya hanya membutuhkannya dalam kasus-kasus tertentu (dan kemudian Anda mencarinya dan meneliti), atau Anda menggunakan perpustakaan yang sudah ditulis untuk Anda. Tidak perlu menulis classifier bayesian lain. Abstraksi adalah prinsip penting dalam ilmu komputer. Saya pikir insinyur perangkat lunak cenderung tidak belajar bagaimana suatu algoritma bekerja sampai mereka perlu.

Alasan lain adalah saat ini ada beberapa metode pengembangan perangkat lunak "menyelesaikannya" yang populer yang efektif. Misalnya, dalam pengembangan tangkas, Anda tidak merancang seluruh sistem sebelumnya. Alasannya adalah karena Anda belum tahu persis apa yang sedang Anda bangun — Anda ingin apa yang Anda buat menjadi fleksibel dan beradaptasi dengan informasi dan persyaratan baru. Mendesain semuanya dari awal dan kemudian membangun hanya itu tidak selalu menghasilkan perangkat lunak terbaik. Namun, itu bukan solusi untuk semuanya. Sebagai contoh, katakanlah Anda sedang merancang beberapa hal baru yang didistribusikan-komputasi-cluster-gila-baru. Anda tidak dapat membuat sketsa serbet dan memulai SCRUM Anda.

TL; DR. Saya pikir ada beberapa penyangkalan di sekitar kata "teori." Secara tradisional, teori mengacu pada aspek matematika teoretis dari ilmu komputer. Kecuali jika Anda mencari cara komputasi yang lebih baru, sebagian besar ilmu komputer teoretis tidak berperan dalam kehidupan sehari-hari seorang insinyur perangkat lunak. Insinyur perangkat lunak peduli dengan pola desain dan arsitektur sistem. Detail implementasi spesifik dari algoritma tertentu tidak penting. Sering kali dengan ide-ide yang tidak terlalu rumit, sangat tepat untuk tidak banyak mendesain dan hanya memulai coding. Dan saya pikir ini adalah ide dari mana programmer tidak suka teori.

Kesenjangan antara teori dan praktik saat ini terlalu besar. Ketika melakukan teori, Anda diberikan tiga aksioma dan selanjutnya ditunjukkan bahwa teorema satu-baris memiliki bukti seribu halaman, atau tidak ada bukti sama sekali. Dalam rekayasa perangkat lunak, Anda diberi API yang tidak konsisten dari ribuan fungsi yang memberi Anda banyak sekali (buruk) cara menerapkan fitur yang tidak ditentukan.

Rekayasa perangkat lunak yang nyata akan mendorong sebagian besar dari mereka di bidang formal gila, dan pengembangan perangkat lunak matematika yang nyata mendorong mereka yang gila rekayasa. Kedua bidang membutuhkan orang-orang dengan bakat berbeda, dan saya tidak berpikir bakat sering tumpang tindih.

Teori formal mengasumsikan bahwa Anda dapat secara akurat merencanakan segala sesuatu di muka seperti produk yang diproduksi, bahwa perangkat lunak akan ada tanpa batas dalam lingkungan yang sama, dan bahwa menyelesaikan masalah abstrak umum selalu menjadi tujuannya. Ini mengasumsikan siklus hidup perangkat lunak-sebagai-produk-4D: merancang, mengembangkan, menyebarkan, selesai. Teori formal adalah tentang memecahkan masalah desain perangkat lunak menggunakan analisis, abstraksi, generalisasi, dan memprediksi perubahan di masa depan. Ini bagus jika Anda memiliki masalah yang jelas dalam domain langsung yang mudah dianalisis, diprediksi, dan cukup statis.

Pemrograman praktis adalah tentang menyelesaikan masalah yang tepat (bukan desain perangkat lunak) dengan cara yang benar saat ini, sehingga rekan kerja Anda dapat melakukan pekerjaan mereka dengan lebih baik / lebih cepat / sama sekali, atau agar pendapatan dapat mengalir ke perusahaan. Banyak perangkat lunak tidak seperti produk, tidak pernah 'selesai', tetapi lebih seperti makhluk hidup, yang dimulai dengan spesialisasi khusus untuk satu ceruk ekologis, dan mungkin memiliki masa hidup yang sangat bervariasi di mana ia perlu menyelesaikan masalah baru yang tidak terduga dalam suatu berbagai macam lingkungan yang selalu berubah. Dalam dunia bisnis, dengan politik dan legalitas dan persaingan serta organisasi, struktur, dan tren yang selalu berubah, persyaratannya seringkali ambigu, berbelit-belit dengan semua jenis kasus khusus, tidak didefinisikan dengan baik, dan dapat mengalami perubahan cepat yang tak terduga. Mereka tidak dapat dianalisis, diprediksi, atau statis, dan seringkali tidak logis atau masuk akal. Perangkat lunak ini sepertinya tidak relevan dalam 2 minggu dan masih digunakan dalam 20 tahun. Itu datang ke dunia tidak tahu banyak atau mampu melakukan banyak, dan perlu dipupuk, dirawat, dan dilatih sepanjang masa hidupnya untuk tumbuh kuat, fleksibel, dan mampu beradaptasi dengan lingkungannya yang selalu berubah dan masalah baru. Jika Anda mengabaikannya setelah lahir, itu akan menjadi liar jika bertahan cukup lama, dan menyebabkan rasa sakit dan penderitaan, memecahkan masalah dengan kekuatan tumpul.

Teori formal tidak membahas kebutuhan banyak perangkat lunak bisnis dunia nyata. Ini menipu kita agar percaya bahwa perangkat lunak dapat dirancang dan dilakukan. Itu adalah produk yang kadang-kadang dapat diperbaiki, dipoles, atau ditempelkan dengan benda, tetapi bukan makhluk hidup yang perlu diangkat dengan benar dengan perhatian dan perhatian yang konstan sepanjang masa pakainya. Jadi kita berakhir dengan kode warisan feral yang benar-benar jelek, tetapi teori formal mungkin tidak akan membantu dengan itu.

Itu semua terdengar sangat negatif, tetapi dalam kenyataannya saya suka menggunakan teori formal. Desain yang indah selalu menghadirkan senyum di wajah saya. Namun, itu sebagian besar dalam pemrograman hobi saya yang tidak tunduk pada perubahan bisnis. Di tempat kerja, saya kebanyakan berurusan dengan kode organik dan hanya berharap bahwa saya bisa memberikan perhatian yang cukup sehingga akan tumbuh dengan benar, membuat saya bangga, dan tidak menjengkelkan dan kasar kepada orang lain yang harus menghadapinya.

Taruhannya lebih rendah, pekerjaannya lebih mudah, dan manajemen jarang melihat nilai dalam desain yang baik. Ketidakstabilan sistem, pemeliharaan, dan integritas adalah masalah "TI" - bukan masalah "Bisnis". Semua eksekutif memiliki satu kesamaan. Mereka baik 95% berfokus pada uang, atau mereka melapor kepada seseorang yang.

Sisa pertempuran adalah dengan sesama programmer Anda. Banyak dari mereka tidak bisa atau tidak mau berkomitmen untuk memikirkan masalah sebelum pengkodean dimulai. Karena hal di atas, banyak dari orang-orang ini adalah pengembang senior, sehingga semakin sulit untuk mendapatkan desain yang baik dalam produksi.

Saya telah menyaksikan proyek memimpin tahun-tahun limbah menambahkan fitur ad-hoc dan perbaikan untuk proyek-proyek yang sulit untuk memulai, dan kemudian menembak setiap upaya untuk menertibkan kekacauan dengan frasa seperti "terlalu rumit" atau "membuang-buang waktu." Tidaklah menyenangkan menyaksikan spiral proyek besar menuju kehancuran yang tak terhindarkan karena manajemen tidak akan mengakui bahwa mereka membangun penjara mereka sendiri setiap hari; Namun, saya khawatir ini adalah kenyataan yang disayangkan bahwa banyak pengembang telah menyaksikan dan - baik atau buruk - belajar dari.

Saya mencoba mencari media dalam pekerjaan saya. Saya menulis tidak ada kode lebih "tercemar" proyek dari yang diperlukan, dan saya mengambil setiap kesempatan untuk bergerak fungsi keluar dari mereka. "Antara proyek," saya menghabiskan waktu untuk desain dan pembersihan dalam proyek yang sebenarnya saya kendalikan.

Pada akhirnya, ini adalah kekacauan politik dan integritas pribadi yang besar yang tidak diinginkan oleh 75% programmer di dunia. Saya hampir tidak tahan, sendiri.

Pertama-tama, saya suka pertanyaan ini. Saya telah menulis seperti tiga jawaban 1.000 kata dan semuanya salah pada saat saya sampai di akhir.

Masalah dengan mencoba membandingkan keduanya sebagai analog, saya pikir, adalah pemrograman adalah proses pemodelan yang dapat abstrak atau terikat erat dengan beton seperti yang Anda inginkan.

Teori rekayasa struktural, di sisi lain, sangat terikat dengan set yang sangat spesifik dari hukum berbasis kenyataan yang harus Anda ikuti. Anda tidak bisa hanya mengubah konteks atau hukum. Masalahnya sendiri berakar pada hukum-hukum itu. Namun, dalam pemrograman, kadang-kadang solusinya sebenarnya mengubah sifat pertanyaan atau hanya menempatkannya dalam konteks yang berbeda.

Apakah pola MVC, misalnya, sangat cocok, ada banyak hubungannya dengan konteks itu. Aplikasi desktop biasanya menangani satu bahasa dan satu bahasa saja, tidak termasuk file konfigurasi.

Di sisi lain, aplikasi web terutama terdiri dari dua bahasa deklaratif (non-pemrograman) dan JavaScript. Satu hal fisik yang Anda tidak bisa sepenuhnya abstrak adalah kenyataan bahwa selalu ada dinding http ini untuk membuang hal-hal antara server dan browser. Terlepas dari bagaimana Anda menguburnya dalam kode, itu membutuhkan waktu dan desain yang tidak sinkron.

Jelas Anda tidak dapat menggunakan pola yang populer dan terkenal seperti MVC untuk menangani masalah ujung depan di web secara eksklusif tanpa mengubah cara Anda dapat mengatasinya dalam konteks aplikasi desktop. Bahkan saya berpendapat, Anda harus menyadari apa yang membuat MVC berguna tetapi bahkan tidak mencoba mengimplementasikannya dengan cara yang sangat menuntut atau grosir. Paradigma aplikasi web ini unik karena semua hal yang melihat saya ditangani oleh browser pengguna dan semua hal data / model-ish biasanya ada di server di suatu tempat. Tapi di mana itu meninggalkan controller? Semua di server atau semua di ujung depan? Harus ada yang memilikinya. Atau mungkin MVC tidak 100% paling cocok untuk skenario. Tidak cocok untuk .NET back end stuff. Tidak mengerikan dalam konteks widget UI tertentu.

Membangun rumah memecahkan masalah. Masalah pemrograman yang umum, bagaimanapun, sering melibatkan penyelesaian masalah di dalam masalah dan kadang-kadang solusinya adalah mendefinisikan kembali masalah luar. Sayangnya, kenyataan tidak terlalu tertarik pada gagasan itu.

Glenn Vanderburg menyajikan pandangan yang bagus tentang perbedaan antara rekayasa perangkat lunak dan disiplin teknik yang lebih tradisional: http://www.youtube.com/watch?v=NP9AIUT9nos

Jika seorang insinyur sipil dapat menguji desainnya tanpa biaya sebelum membangun hal terakhir, ia akan menggunakan teori jauh lebih sedikit. Jika dalam hitungan detik ia bisa membangun jembatan seribu kali secara gratis untuk menguji kapan akan rusak ia akan melakukannya daripada menghabiskan waktu berbulan-bulan menghitung kapan itu akan berubah secara teori ...

Dalam pengembangan perangkat lunak, itulah tepatnya yang Anda lakukan. Alih-alih menghitung seberapa cepat algoritma Anda dalam teori, Anda bisa mengujinya dan mengetahui jawabannya dalam hitungan detik.

Bahkan sebagian besar perangkat lunak saat ini tidak dibatasi lagi oleh kendala fisik seperti daya komputasi atau memori. Batasan perangkat lunak adalah kompleksitas yang berjumlah dalam sistem yang lebih besar dan lebih besar. Ini mengelola kompleksitas ini dengan menjaga sistem agar dapat dipahami oleh manusia apa yang membuat tantangan besar dalam pemrograman saat ini.