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


63

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.


9
tidak, 90% programmer adalah;)
jk.

24
Nah, dalam perangkat lunak Anda bisa mulai dengan membangun atap dan kemudian turun ke fondasi, sementara bagian yang sudah selesai mengambang di udara. Jika ada sesuatu yang tidak pas, maka Anda bisa menggunakan lakban agar pas. Coba ini ketika membangun gedung pencakar langit. ;)
Aman

65
Secara teori tidak ada perbedaan antara teori dan praktik, tetapi dalam praktiknya ada.
Joris Timmermans

6
Buku bagus untuk mencari alogrithm? Sebagian besar perangkat lunak hanya CRUD sederhana tanpa sesuatu yang dekat dengan apa yang termasuk dalam kursus algoritma atau buku apa pun.
Gilles

44
Teori adalah tentang bahasa dan algoritma modern. Praktik tiba di tempat kerja pada hari pertama Anda dan diberi tugas untuk menambahkan fitur minor ke perangkat lunak Point of Sale yang berjalan di mesin kasir yang menggunakan perangkat lunak yang diubah tangan dari BASIC ke K&R C oleh orang-orang yang tidak tahu C , menggunakan kompiler buggy dari vendor yang bangkrut dan diharapkan memiliki fitur paling lambat hari Jumat.
Gort the Robot

Jawaban:


61

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.


1
Saya setuju dengan Anda bahwa dalam rekayasa perangkat lunak, penting untuk memiliki jumlah formalisme yang tepat. Terlalu banyak berarti Anda tidak pernah bisa memulai dan mungkin ketika Anda tahu Anda telah melakukan kesalahan sudah terlambat. Terlalu sedikit berarti Anda dapat membuat kekacauan. Saya pikir Anda memiliki poin yang sangat kuat mengatakan bahwa produktivitas dan kualitas jauh lebih sulit untuk diukur dalam rekayasa perangkat lunak daripada teknik sipil.
Giorgio

2
"... sedangkan dalam rekayasa perangkat lunak tidak ada kekuatan yang sama kuatnya untuk tetap tidak praktis ..." Saya pikir maksud Anda tidak ada kekuatan seperti itu lagi . Kembali pada hari itu, keterbatasan yang ditimbulkan oleh prosesor yang lebih lemah, lebih sedikit memori dan sedikit / tidak ada penyimpanan bertindak sebagai kekuatan seperti itu.
blesh

1
@blesh: Saya rasa tidak. Batas perangkat keras yang ketat membatasi rekayasa yang baik dan buruk secara merata.
Michael Borgwardt

Contoh Anda bukan teori pemrograman. Kendala pada perangkat lunak berkaitan dengan teknologi yang digunakan dan kapasitas matematika penulis.
Paul Nathan

5
Pasti ada sesuatu yang "teoretis" tentang UML ... ... kegunaannya!
ObscureRobot

29

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.


1
Saya setuju dengan pengamatan Anda bahwa faktor manusia jauh lebih kuat dalam perangkat lunak, tetapi tetap saja, saya berpikir bahwa mencoba menganalisis masalah atau menyusun solusi Anda adalah sikap / alat umum. Pertanyaan saya adalah mengapa beberapa programmer menganggap itu bukan pendekatan yang berguna (atau bahkan buang-buang waktu). Anda menyebutkan Haskell: Saya berusaha mempelajari beberapa Haskell walaupun saya tidak menggunakannya dalam proyek apa pun karena saya pikir itu akan membantu saya untuk menulis kode yang lebih baik (bahkan di C ++ atau Java). Bahkan jika saya tidak dapat mengukur ini, perasaan saya adalah saya menjadi lebih produktif: saya menyelesaikan lebih banyak hal.
Giorgio

2
Quicksort tiga baris Haskell? Hmm ... mungkinkah untuk mengimplementasikan Quicksort dalam bahasa di mana semuanya tidak dapat diubah oleh desain?
Mason Wheeler

3
@MasonWheeler Hasil pertama dari Google: Quicksort di Haskell .
chrisaycock

3
@ Alasan: runtime masih O (n log n). Ini juga membutuhkan memori O (n log n), tidak seperti quicksort di tempat, yang hanya membutuhkan O (log n) memori tambahan untuk rekursi.
kevin cline

2
@kevincline Sejauh proyek perangkat lunak tipikal adalah unik, saya memulai proyek unik dalam renovasi kamar mandi saya. Perbedaannya adalah jika saya mengacaukan kode saya, tes saya menjadi merah, dan jika saya mengacaukan kabel saya, rumah saya terbakar. Tentu saja, proyek itu juga lembur dan anggaran, karena saya tidak berpengalaman dalam memecahkan masalah renovasi. Masalah utama yang saya lihat pada proyek perangkat lunak adalah serupa ... bukan karena orang yang tepat tidak dapat menyelesaikan masalah ini dengan lebih cepat, ini karena orang yang tepat tidak tersedia dan kita harus menjadi orang yang tepat di terbang.
philosodad

17

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.


5
Fisika dapat memberi tahu Anda apakah suatu struktur akan runtuh karena bebannya sendiri. CS memberi tahu Anda bahwa Anda tidak dapat memberi tahu apakah suatu program akan berhenti memberikan input tertentu. Skala metode formal IMO jauh lebih baik dalam teknik sipil atau mekanik daripada dalam perangkat lunak terutama karena sistemnya kurang kompleks dan kurang dinamis ...
Guy Sirton

6
@GuySirton "CS memberi tahu Anda bahwa Anda tidak dapat memberi tahu apakah suatu program tertentu akan berhenti diberi input tertentu." jika hanya itu yang Anda pikirkan tentang CS, saya pikir Anda mungkin tidak tahu banyak tentang CS seperti yang Anda pikirkan ...
gregghz

2
Guy, sangat tidak mungkin bahwa Anda pernah menggunakan materi perangkat lunak yang belum pernah digunakan sebelumnya. McCarthy melakukannya, dan Turing melakukannya, tapi sungguh, rekayasa perangkat lunak tidak terlalu luar biasa. Jika tidak apa-apa bangunan itu tenggelam ke dasar lautan karena Anda hanya bisa reboot, itu akan seperti rekayasa perangkat lunak.
philosodad

3
Saya akan memberi Anda +1 kecuali celah tentang keterbacaan. Maintainability adalah 80% dari biaya perangkat lunak sehingga keterbacaan bukan masalah kecil. Selain itu, ketika insinyur penerbangan atau nuklir itu membuat sesuatu yang akan diproduksi setelah orang lain mengerti itu penting. Militer, pemerintah atau bahkan institusi besar tidak senang dengan penemuan ajaib yang tidak dapat ditiru atau dipahami oleh orang lain selain penemunya.
Thomas

2
@ Thomas - Pernyataan bahwa solusi yang layak sering dibuang pada perubahan "keterbacaan," oleh pikiran di bawah standar, tidak berarti solusi tidak dapat dibaca seperti seharusnya. Saya sudah melihatnya terjadi. Sial, saya sudah menahan diri saya melakukannya.
Erik Reppen

13

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.


Yah Anda berharap mereka tidak akan mati ... tergantung pada perangkat lunak Anda;)
Rig

3
@Rig, itu sebabnya saya mengatakan 'paling' dan 'biasanya'. Beberapa perangkat lunak jauh lebih penting.
CaffGeek

Saya pikir ini semakin menjadi sudut pandang yang sangat buruk, tentu sebagian besar perangkat lunak tidak memiliki implikasi keamanan tetapi ada uang dan privasi yang terlibat dalam banyak perangkat lunak, jika salah ini juga bisa membuat Anda masuk pengadilan
jk.

11

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! :)


3
Jika Anda harus menyelesaikannya sekali dan lupakan saja itu baik-baik saja. Tetapi jika Anda harus memperpanjang dan memeliharanya setelah itu Anda mencari masalah. Anda perlu memiliki perasaan untuk berapa banyak teori: terlalu banyak berarti Anda tidak akan pernah menyelesaikannya, terlalu sedikit berarti Anda akan melakukannya 10 kali sebelum benar-benar dilakukan. 2 sen saya.
Giorgio

6
Tetapi kadang-kadang Anda perlu mengeluarkan perangkat lunak Anda SEKARANG . Anda harus mengalahkan pesaing untuk memasarkan. Atau Anda memiliki persyaratan hukum untuk memberikan beberapa informasi. Atau Anda hanya perlu mendapatkan arus kas sehingga Anda akan tetap ada ketika kekacauan yang Anda buat dalam pendekatan "selesaikan" adalah masalah ... yang terkadang merupakan masalah yang baik. Karena jika Anda tidak memilikinya, Anda tidak merilisnya tepat waktu, dan perusahaan Anda sudah mati sebelum dimulai.
CaffGeek

1
@Chad - Saya setuju dengan Anda. Itu adalah keseimbangan. Semua hal yang Anda sebutkan akan berada di bawah "batasan waktu asli" sebagai alasan untuk pemrograman yang dilakukan, dan dalam jangka pendek, tidak apa-apa dan bahkan menguntungkan ketika Anda menunjukkannya.
FishBasketGordo

@FBG: Kata cemerlang.
Kuba Ober

@Chad, poin bagus. Martin Fowler membuat poin serupa di martinfowler.com/bliki/TechnicalDebt.html . Terkadang itu merupakan tradeoff yang bermanfaat.
John M Gant

9

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.


"Ada titik dalam pengembangan perangkat lunak di mana biaya desain meningkat di luar nilai yang dikembalikan.": Saya telah secara eksplisit menulis "jumlah teori yang tepat". Saya tahu bahwa teknik berlebihan tidak meningkatkan produktivitas.
Giorgio

Ada proyek IMO hampir nol yang dirancang di depan yang benar-benar mengikuti desain mereka. Teknik sipil adalah (umumnya?) Membangun hal yang sama berulang-ulang (jalan, sialan, terowongan, bangunan, jembatan). Teknik-tekniknya sudah dikenal luas. Ini tidak benar dalam perangkat lunak. Karena itu dapat diubah dengan mudah dan karena orang tidak tahu apa yang mereka inginkan atau apa yang berhasil sampai mereka mencobanya dengan serius, desain di muka adalah buang-buang waktu. Kami membangun, menguji dan beralih. Sesuatu yang tidak mungkin dengan Teknik Sipil sebagaimana ditunjukkan di atas. 2 disiplin tidak sebanding.
GM

5
Maaf, saya harus menunjukkan kesalahan ketik: Saya tidak berpikir insinyur sipil membuat masalah. ;-)
Giorgio

2
Saya membayangkan di masa depan, ketika kita insinyur perangkat lunak, membangun perangkat lunak simulasi teknik sipil yang keren, insinyur sipil dapat menghapus semua hal matematika ini. Hanya membangun gedung pencakar langit virtual setinggi 10 km. Jika tidak runtuh karena beratnya sendiri dalam 100 tahun virtual pertama dan dapat menahan badai virtual kucing 5, maka gunakan printer pencakar langit 3D khusus untuk membangunnya.
emory

1
@RexKerr: Anda memotong setengah pernyataannya: "... yang memenuhi standar keamanan yang disyaratkan"
Lie Ryan

7

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.


6

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.


3
Ada juga banyak yang tidak diketahui yang tidak diketahui dalam pengembangan perangkat lunak - Anda mungkin mulai membangun gedung pencakar langit, tetapi ketika klien melihatnya, mereka memberi tahu Anda "sebenarnya saya menginginkan kubus Rubix setinggi sepuluh lantai".
Tacroy

@ Trac: Cukup menarik, seorang insinyur sipil mungkin akan menganggap ini klien yang buruk yang menghabiskan waktu dan sumber daya Anda, seorang insinyur perangkat lunak akan mencoba mengembangkan metodologi baru untuk memuaskannya. :-)
Giorgio

1
@Iorgio, atau tagihan yang sesuai ...
CaffGeek

5

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.


1
+1 untuk "ketika berbicara tentang 'teori', biasanya itu berarti sisi teori ilmu komputer".
Joshua Drake

5

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!


3
+1 untuk "Pengiriman adalah fitur"! Suatu kali saya mendengar kalimat yang serupa: "Kesempurnaan tidak ada. Perangkat lunak ini memiliki keunggulan yang ada." Tentu saja ini sedikit lelucon. Mengenai perangkat lunak mission-critical: pengecualian tanpa tertangkap dapat menyebabkan roket jatuh.
Giorgio

this software has the advantage that it exists... saya belum pernah mendengarnya tetapi masuk ke dalam daftar kutipan perangkat lunak yang hebat. saya suka itu
Albert Lang

@Iorgio: JSF dan MISRA C ditulis sehingga tidak ada pengecualian. Pengecualian dan roket tidak tercampur.
Coder

5

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 :)


"Saya membayangkan bahwa Insinyur Sipil jarang harus memperhitungkan relativitas umum ketika melakukan pekerjaan mereka. Banyak Teknik Sipil dapat dibangun dengan aman dalam Mekanika Newton.": Sejauh yang saya tahu mereka harus menggunakan cukup banyak kalkulus (integral) dan hal-hal seperti itu). Ini bukan mekanika kuantum tetapi IMO itu pasti non-sepele.
Giorgio

2
Tentu, tetapi Anda tidak perlu menurunkan persamaan gelombang untuk setiap komponen jembatan Anda dan kemudian menjelaskan bagaimana mereka berinteraksi.
ObscureRobot

Kamu benar. Namun, maksud saya bukanlah berapa banyak teori yang digunakan dalam rekayasa sipil untuk rekayasa perangkat lunak. Sebaliknya, insinyur sipil tahu mereka harus menggunakan formula mereka dan melakukan perhitungan tentang cara membangun beberapa bangunan. Dalam rekayasa perangkat lunak saya memiliki kesan ada lebih banyak improvisasi dan kadang-kadang jika Anda ingin duduk dan menganalisis masalah (hanya untuk memperbaikinya, bukan untuk menulis tesis PhD tentang itu) Anda dapat disukai: kami ingin mendapatkannya: selesai, bukan untuk membuatnya sempurna. Tapi IMO beberapa teori (tidak terlalu banyak) adalah apa yang dapat membantu menyelesaikannya lebih cepat!
Giorgio

Anda perlu menemukan titik keseimbangan yang sesuai untuk proyek Anda. Pengembang junior biasanya lebih gung-ho tentang melemparkan omong kosong bersama untuk melihat apa yang akan menempel. Jika mereka datang dari latar belakang yang sangat teoretis, mereka mungkin bahkan memiliki ide-ide yang lebih gila dan rumit. Mengelola pengembang junior secara efektif seringkali melibatkan membantu mereka mengambil langkah mundur dan menganalisis pekerjaan mereka. Di sisi lain, pengembang senior dapat terlalu fokus pada masalah desain jangka panjang sampai pada titik di mana mereka kesulitan berfokus pada kebutuhan mendesak.
ObscureRobot

Wow, maaf ini di luar topik, tetapi tanpa membaca jawaban Anda, saya mengakhirinya persis sama — dengan TL; DR dan kemudian secara harfiah analogi yang persis sama. Format SAT. Saya mengeditnya dari jawaban saya sehingga sepertinya saya tidak menyalin Anda, tetapi itu masih membuat saya takut. Mungkin programmer terlalu banyak berpikir.
Jarsen

3

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.


1

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.


3
"matematika ... telah dilakukan": tidak hanya, pertimbangkan semua fungsi perpustakaan, kerangka kerja, DBMS, protokol, dan banyak hal berat lainnya yang dapat kita gunakan dalam kode kita dengan memanggil fungsi dengan beberapa parameter. Sebagai seorang programmer, kadang-kadang saya merasa lebih seperti pekerja yang berjalan di atas perancah daripada sebagai insinyur yang telah merancang bangunan.
Giorgio

1

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.


1

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


Jadi apa yang setara dengan perangkat lunak dari analisis elemen hingga dari gedung 100 lantai? Berapa banyak gedung tinggi yang memiliki bug dalam panas / rusak? :-)
Guy Sirton

@GuySirton - Anda hanya dapat menganalisis bangunan besar pada tingkat yang sangat kasar, kurang detail daripada unit yang akan Anda uji coba aplikasi yang khas. Banyak bangunan besar memiliki kesalahan, jendela jatuh, jalan setapak runtuh, mereka menciptakan efek terowongan angin. Atau dalam kasus salah satu hotel melengkung sangat reflektif di Vegas Anda membuat sinar kematian di kolam renang!
Martin Beckett

Anda dapat menggunakan FEA dan memprediksi perilaku hingga tingkat akurasi yang sangat tinggi. Orang masih melakukan kesalahan. IMO tidak mungkin membuat prediksi serupa pada perangkat lunak yang kompleks. Kesalahan yang Anda sebutkan adalah sebagian kecil dari total jumlah bangunan. Tingkat cacat pada perangkat lunak harus dua kali lipat lebih tinggi. Yang mengatakan, itu jelas sebuah kontinum antara di mana metode formal berguna dan di mana mereka tidak berguna.
Guy Sirton

@GuySirton - Saya pikir kesulitannya adalah Anda mengandalkan hal-hal lain. NASA dapat menguji penerbangan avionik ke tingkat yang sangat rinci (walaupun masih belum membuktikannya dengan benar) karena mereka juga menciptakan OS dan perangkat keras. Menulis di OS umum dengan toolkit dan lib adalah seperti membangun jembatan di mana Anda tidak diizinkan untuk mengetahui detail baja atau beton.
Martin Beckett

1
@ MartinBeckett, dan koefisien gravitasi berubah secara acak dari jam ke jam ... seperti ketika admin sistem Anda secara acak memutuskan untuk memutakhirkan server tanpa memberi tahu siapa pun karena "ini akan transparan".
CaffGeek

1

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.


1

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.


1
Saya melihat beberapa kesamaan antara jawaban kami, tetapi ide-ide Anda jelas asli dan ada beberapa perbedaan. Saya tidak setuju bahwa memahami P / NP tidak berguna. Anda tidak perlu mempelajari Teori Kompleksitas secara mendalam, tetapi seorang insinyur perangkat lunak yang bekerja harus dapat memperkirakan O (n) dari setiap potongan kode dan mengatakan hal-hal cerdas tentang biaya solusi alternatif. Poin yang hampir Anda buat, tetapi tidak, adalah bahwa teori sering kali dikemas dalam perpustakaan. Itu bagus untuk dipertimbangkan.
ObscureRobot

"Jika seseorang memecahkan ... masalah penghentian yang kita hadapi untuk banyak kemajuan baru yang mengagumkan.": Sayangnya, teori telah membuktikan bahwa ini tidak dapat diselesaikan (tidak ada program yang dapat memutuskannya) jadi saya tidak berpikir bahwa ada upaya penelitian dihabiskan untuk mencoba memecahkan masalah penghentian.
Giorgio

Mesin Turing tidak dapat "Namun, tidak semua mesin yang dapat dibayangkan oleh imajinasi manusia tunduk pada tesis Gereja-Turing ... Ini adalah pertanyaan terbuka apakah mungkin ada proses fisik deterministik aktual yang, dalam jangka panjang, menghindari simulasi oleh Mesin Turing, dan khususnya apakah proses hipotetis semacam itu dapat dimanfaatkan dalam bentuk mesin hitung (hypercomputer) yang dapat memecahkan masalah penghentian ... Ini juga merupakan pertanyaan terbuka apakah ada proses fisik yang tidak diketahui yang terlibat dalam cara kerja otak manusia ... "-Menangani Masalah, Wikipedia
Jarsen

Jadi, sejauh yang saya ketahui, dan mengoreksi saya jika saya salah, saya pikir kita masih memiliki banyak penemuan yang harus dilakukan tentang perhitungan. Seperti yang telah disebutkan beberapa kali dalam utas ini, ilmu komputer masih sangat muda; mungkin ada banyak di luar Mesin Pembalik dan arsitektur Von Neumann.
Jarsen

@Jarsen: Memang benar bahwa ilmu komputer masih sangat muda, tetapi setiap komputer yang telah dibangun hingga saat ini hanya dapat melakukan hal-hal yang dapat dihitung oleh Turing. Sejauh yang saya tahu (memang sangat sedikit) bahkan komputer kuantum tidak dapat berbuat lebih banyak (mereka dapat memecahkan masalah tertentu lebih cepat, tetapi mereka tidak akan mampu memecahkan lebih banyak masalah). Jadi, ya, siapa yang tahu apa yang bisa ditemukan, tetapi formalisme komputasi apa pun yang telah dibayangkan selama 70 tahun terakhir tidak dapat melakukan lebih dari mesin Turing.
Giorgio

1

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.


0

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.


0

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.


0

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.


0

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.

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.