Perbedaan antara pemrograman di sekolah vs pemrograman di industri? [Tutup]


50

Banyak siswa ketika mereka lulus dan mendapatkan pekerjaan pertama mereka, merasa seperti mereka tidak benar-benar tahu cara memprogram meskipun mereka mungkin pemrogram yang baik di perguruan tinggi.

Apa saja perbedaan antara pemrograman dalam lingkungan akademik dan pemrograman dalam 'dunia nyata'?



4
Saya akan mengatakan bahwa di dunia akademis Anda belajar secara mendalam: Anda mempelajari konsep, bertanya pada diri sendiri, meningkatkan pemikiran abstrak. Dalam industri Anda belajar secara mendalam: Anda belajar menggunakan banyak teknologi berbeda tanpa mengajukan terlalu banyak pertanyaan, Anda harus menyelesaikan sesuatu. Melalui pengalaman dalam industri ini, Anda juga belajar mengelola proyek-proyek besar dan kompleks: ini adalah masalah yang sangat praktis yang tidak dapat Anda pelajari di universitas karena kurangnya waktu.
Giorgio

9
Apakah pertanyaan ini menanyakan tentang akademik di tingkat doktoral, atau setelah lulus, atau hanya pengaturan umum, "ruang kelas vs dunia nyata"?
Bob

@ Bob. Ini lebih tentang akademisi umum. Bacaan kelas / penelitian / diarahkan / tugas vs pemrograman "dunia nyata" dalam industri.
rdasxy

Baik. Itu tidak terlalu jelas, karena ada yang namanya "pemrograman akademik" yang dilakukan oleh orang-orang yang ingin mengatakan, membantu ahli biologi mencari tahu simulasi sel.
Bob

Jawaban:


72

Dalam program ilmu komputer sarjana tradisional Anda belajar pemrograman saja . Tetapi dunia nyata tidak menginginkan orang yang hanya programmer. Dunia nyata menginginkan insinyur perangkat lunak yang nyata. Saya tahu banyak deskripsi pekerjaan tampaknya tidak mengungkapkan perbedaan ini, yang hanya membingungkan masalah ini. Di dunia nyata Anda harus dapat:

  • Kumpulkan dan analisis persyaratan yang tidak langsung diberikan kepada Anda
  • Desain dan analisis arsitektur dengan kemungkinan yang hampir tak terbatas
  • Buat rencana pengujian dan lakukan padanya untuk mengevaluasi dan meningkatkan kualitas sistem
  • Bekerja secara kolaboratif pada tim orang-orang dengan latar belakang dan tingkat pengalaman yang berbeda
  • Perkirakan dan rencanakan pekerjaan meskipun Anda tidak tahu persis apa yang harus dibangun
  • Berkomunikasi secara efektif dengan pemangku kepentingan yang memiliki kebutuhan berbeda yang belum tentu selaras
  • Negosiasikan jadwal, anggaran, kualitas, dan fitur tanpa pemangku kepentingan yang mengecewakan

Oh ya, dan Anda juga harus dapat menulis kode juga, meskipun itu membutuhkan rata-rata hanya 40 - 60% dari waktu seorang insinyur perangkat lunak.

Jadi, bukan undergrad ilmu komputer yang baru dicetak tidak tahu cara memprogram (banyak sebenarnya, programmer yang sangat baik). Banyak dari mereka tidak tahu bagaimana melakukan hal lain.


18
Oh yeah, and you also have to be able to write code too, but that's, on average, only 40 - 60% of a software engineer's time.- Atau bahkan 0-20% di toko perusahaan yang benar-benar buruk dan sangat besar.
Ritch Melton

1
+1 untuk jawaban yang sangat bagus dan +1 (harus lebih) untuk Ritch. Jika sebagai / insinyur insinyur menghabiskan lebih dari 20% dari siklus hidup proyek pada pengkodean maka ada sesuatu yang sangat, sangat salah. 50% desain, 30% tes,% 20 untuk sisanya .... segalanya, termasuk coding sepertinya benar. Dengan desain yang tepat, pengkodean harus sepele. Tanpa itu, apa yang orang-orang sebut "coding" sebenarnya penulisan ulang tanpa akhir, mencoba meretas bersama semacam desain saat mereka berjalan </rant>
Mawg

36

Di Universitas...

Guru Anda memberi Anda:

  • Masalah yang terdefinisi dengan baik dan terisolasi, solusinya dapat diberikan dalam rentang waktu yang singkat dan terdefinisi dengan baik (dan akan dibuang sesudahnya)
  • Seperangkat alat yang terdefinisi dengan jelas sebelum Anda ditugaskan
  • Ukuran yang didefinisikan dengan baik untuk kualitas solusi Anda, yang dengannya Anda dapat dengan mudah menentukan apakah solusi Anda cukup baik atau tidak

Di "Dunia Nyata" ...

  • Masalahnya kabur, kompleks dan tertanam dalam konteks. Ini adalah serangkaian persyaratan yang bertentangan yang berubah seiring waktu dan solusi Anda harus fleksibel dan cukup kuat bagi Anda untuk bereaksi terhadap perubahan tersebut dalam waktu yang dapat diterima.
  • Alat harus dipilih oleh Anda. Mungkin sudah ada sesuatu yang dapat digunakan dalam basis kode 10 tahun tim Anda, mungkin ada beberapa proyek open source, atau mungkin perpustakaan komersial atau mungkin Anda harus menulisnya sendiri.
  • Untuk menentukan apakah iterasi perangkat lunak Anda saat ini merupakan peningkatan (karena Anda hampir tidak pernah benar-benar selesai dengan proyek perangkat lunak), Anda perlu melakukan pengujian regresi dan pengujian kegunaan, yang terakhir biasanya berarti bahwa buram, rumit, kontradiktif , persyaratan yang melekat pada konteks bergeser sekali lagi.

Kesimpulan

Pemrograman di sekolah dan pemrograman di dunia nyata sangat berbeda dengan titik di mana sebenarnya ada sedikit tumpang tindih. CS akan mempersiapkan Anda untuk pengembangan perangkat lunak "dunia nyata" seperti pelatihan atletik akan mempersiapkan pasukan untuk bertempur.


11
Ini pada dasarnya adalah apa yang akan saya jawab. Di sekolah Anda tahu masalahnya dan Anda tahu solusinya. Di "dunia nyata" Anda jarang tahu solusinya, dan seringkali bahkan tidak tahu masalah sebenarnya.
Bob

20

Mereka menghadapi aspek masalah yang berbeda:

Academia terutama berfokus pada "ilmu pemrograman" sehingga mempelajari cara membuat algoritma khusus yang efisien atau mengembangkan bahasa yang dirancang untuk membuat paradigma tertentu lebih ekspresif. Industri terutama fokus dalam menghasilkan barang-barang yang harus dijual. Itu harus bergantung pada "alat" yang tidak hanya bahasa dan algoritma, tetapi juga perpustakaan, kerangka kerja dll.

Perbedaan dalam "fokus" inilah yang membuat master akademis di C praktis tidak dapat menulis aplikasi windows (karena kita windows API tidak dalam standar C99!), Sehingga terasa seperti "tidak dapat memprogram". Tetapi, pada kenyataannya, dia memiliki semua kemampuan untuk belajar sendiri apa yang hilang. Sesuatu yang - tanpa studi akademis yang tepat (tidak harus dibuat di Academia) - cukup sulit ditemukan.


10

Jawaban yang bagus Izinkan saya menambahkan, pemrograman akademik cenderung hampir seperti mainan dalam skala. Ini bagus untuk mengajar. Sebagai seorang guru, Anda mencoba menyampaikan ide dengan paling efisien. The downside adalah pemrograman realistis sangat berbeda secara kualitatif, sulit untuk menjembatani kesenjangan.

Satu bidang perbedaan adalah dalam analisis kinerja. Saya telah menulis banyak posting yang mencoba menunjukkan hal ini. Analisis kinerja hanya secara dangkal tentang algoritma dan pengukuran. Untuk melakukannya dengan sangat efektif, Anda harus mendekatinya sebagai proses debugging.

Area perbedaan lainnya adalah rawatan. Ini mencakup segalanya mulai dari gaya hingga desain bahasa khusus domain. Anda tidak dapat melakukannya secara efektif kecuali Anda benar-benar tahu apa yang Anda coba untuk meminimalkan.

Hal-hal ini tidak diajarkan, dan mereka membuat perbedaan besar dalam produktivitas.


1
Saya bertanya-tanya bagaimana hal-hal ini dapat diajarkan, karena mereka membutuhkan banyak waktu dan pengalaman untuk memperolehnya. Saya membantu kursus rekayasa perangkat lunak di mana tim yang terdiri dari 10 siswa masing-masing harus mengembangkan produk perangkat lunak kecil dalam beberapa bulan (dua semester, dari Oktober hingga April). Ini memungkinkan mereka untuk memahami pemrograman, perencanaan, memprioritaskan persyaratan dan tugas, komunikasi, dan sebagainya. Tapi, tentu saja, ini sedikit dibandingkan dengan apa yang akan mereka hadapi di dunia nyata. Tetapi Anda tidak dapat menghabiskan 4 tahun belajar hanya untuk ini.
Giorgio

@Iorgio: Untuk kinerja, saya memiliki basis kode yang sudah ada sebelumnya (tidak terlalu besar) yang saya tunjukkan bagaimana mengoptimalkan melalui serangkaian iterasi, mendapatkan faktor percepatan yang besar. Ini adalah keterampilan yang mudah untuk diajarkan. Untuk DSL dan rawatan saya juga punya beberapa contoh favorit yang bisa digunakan untuk mengajar. Keduanya bisa dengan mudah masuk ke kursus semester, dengan ruang luang. Jadi saya pikir itu bisa dilakukan.
Mike Dunlavey

1
Oke, saya mengerti: gunakan contoh besar, dunia nyata dan biarkan siswa mengerjakannya. Ide yang sangat bagus.
Giorgio

@Iorgio: Saya adalah seorang profesor 30 tahun yang lalu, jadi saya masih ingat beberapa cara melakukannya. Saya juga memasukkan ide-ide ini ke dalam buku yang penjualannya buruk, yang hanya berarti saya punya waktu untuk memikirkan dan menjelaskan bagaimana semuanya cocok.
Mike Dunlavey

Saya tidak punya banyak pengalaman, saya adalah asisten pengajar selama beberapa tahun selama waktu PhD saya. Saya sekarang bekerja di sebuah perusahaan. Mengenai pemrograman di Universitas, IMHO kebenaran ada di suatu tempat di tengah: Ada beberapa pengajaran yang sangat berguna di Universitas tetapi sulit untuk mencakup semua masalah penting yang akan dihadapi oleh seorang insinyur perangkat lunak melalui karirnya. Dengan sedikit usaha, Anda dapat benar-benar mengajarkan beberapa hal di dunia nyata, seperti yang telah Anda tunjukkan. Tidak semua profesor universitas bersedia melakukannya tentu saja.
Giorgio

8

Di dunia akademis, kebanyakan orang mempelajari ilmu komputer atau kursus terkait. Dijkstra pernah mengamati bahwa "Ilmu komputer tidak lebih tentang komputer daripada astronomi adalah tentang teleskop." Seseorang yang mempelajari ilmu komputer adalah pembelajaran pertama dan terutama untuk menjadi seorang ilmuwan, dan bukan seorang programmer. Sebagai seorang programmer, ia akan tetap menjadi amatir, dan transisi ke programmer profesional menjadi sulit.


8

Pembaruan: Seolah-olah seseorang sedang membaca pikiranku: Harapan lulus versus kenyataan ...

Saya ambil, dua faktor lain:

Ukuran masalah : Di dunia akademis, saya sebagian besar harus mengembangkan perangkat lunak "dari awal", yang berarti bahwa sebagian besar waktu, program terbesar yang saya temui adalah yang terbesar yang saya tulis. Ini menekankan kemampuan yang diperlukan untuk menangani dan mengatasi kompleksitas yang muncul dari berbagai perangkat lunak yang berinteraksi bersama. Jika saya menyadari upaya yang diperlukan untuk memahami dengan kompleksitas, saya mungkin memilih untuk tidak berada di industri sama sekali.

Membaca VS Menulis : Efek samping lain dari ukuran masalah adalah bahwa seringkali, di "dunia nyata" kita dihadapkan pada pekerjaan yang telah ditulis oleh orang lain, baik untuk tujuan pemeliharaan (saya tidak melakukan pemeliharaan di akademia di mana pun), ekstensi, atau hanya pembagian kerja. Karenanya, membaca kode menjadi lebih penting daripada menulisnya.

Proposal untuk peningkatan pendidikan pemrograman : Akademisi harus mengekspos kita lebih ke situasi dunia nyata tanpa mundur ke pelatihan kejuruan. Dokter harus menghadapi mayat di beberapa titik untuk melihat apakah mereka "dibuat untuk itu" (Saya pernah mendengar kisah orang-orang menjatuhkan kursus setelah pengalaman ini). Jika saya telah melihat di awal dua puluhan saya proyek 20K LOC terdiri dari gaya pemrograman yang berbeda, yang saya harus mengerti dalam satu hari dan mengubah bug dalam tiga, saya mungkin telah mempertimbangkan pilihan karir lain - walaupun mungkin tidak.


Untuk memperluas metafora Anda dan dari pengalaman saya sendiri di bidang kedokteran: dokter mempelajari konsep umum di sekolah kedokteran, tetapi kita semua belajar mur dan baut dan jalan pintas dunia nyata dalam pelatihan di tempat kerja sebagai magang dan penduduk.
Hovercraft Full Of Belut

2
Ini! Pertama kali Anda menyelam ke dalam basis kode LOC 1 juta Anda menyadari bahwa ini tidak akan menjadi seperti semua yang Anda lakukan di universitas. Jelas sangat cepat bahwa Anda tidak akan pernah memahami keseluruhan basis kode itu, dan apa pun yang Anda pahami harus berasal dari membaca dan memahami kode orang lain, bukan dari merancang dan menulis kode Anda sendiri.
Roman Starkov

4

Perbedaan terbesar yang saya temukan antara pemrograman akademik vs industri adalah tentang ketahanan. Kebanyakan orang telah mengalami paradoks "itu bekerja untuk saya" dalam karier mereka, dan ini merupakan perpanjangan dari kondisi ini. Di dunia akademis, fokusnya adalah pada algoritma dan fungsi dan sedikit perhatian ditempatkan pada kegunaan dan stabilitas perangkat lunak dalam kondisi sehari-hari.

Sebagai contoh, di kantor saya, kami memiliki insinyur yang akan mengambil perangkat lunak dan ahli dalam menyebabkan crash dari kondisi sudut. Dia akan mengklik tombol secepat mungkin sampai sesuatu crash ... jika operasi terlalu lama, dia hanya akan mulai mengklik secara acak di sekitar layar (karena frustrasi? IDK ....)

Mengubah filosofi pemrograman kami sehingga kami membuat hal-hal "Steve proof" secara umum meningkatkan stabilitas aplikasi kami.


3

Saya tidak memiliki pengalaman pribadi dengan pelatihan pemrograman di sekolah - saya adalah seorang jurusan bahasa Inggris. Tanya saya tentang Keats dan Byron! - tetapi saya telah menerima beberapa lulusan baru dan membesarkan mereka dan membimbing mereka dalam dunia pengembangan perangkat lunak profesional. Jadi saya bisa berbicara dari perspektif itu.

Pengalaman saya adalah bahwa benar-benar SEMUA yang mereka dapatkan dari sekolah mereka adalah minat dalam pemrograman. Keterampilan mereka bervariasi dari nol hingga dapat diabaikan. Kemampuan mereka untuk mengarahkan diri sama sekali tidak ada, bahkan dalam keterampilan mereka yang paling tinggi sekalipun. Pemikiran mereka bukan hanya berskala kecil; mereka sebenarnya berpikir dalam miniatur. Sebuah sistem yang terdiri dari lebih dari beberapa lusin baris kode membuatnya hancur berantakan.

Tapi tahukah Anda? Mereka memperoleh minat , dan itu masalah besar. Minat banyak . Saya bisa bekerja dengan seseorang yang tertarik. Saya dapat mengubahnya menjadi pengembang, asalkan mereka datang kepada saya dengan minat untuk menjadi pengembang. Sial, itu saja yang saya mulai. Itu dan penghargaan untuk novelis Amerika post-modern.


2

Di akademisi,

DRAWBACKS

  • Kami memiliki tenggat waktu yang terutama untuk mencetak poin.
  • Bug tidak benar-benar menyebabkan masalah, karena sebagian besar proyek tidak pernah digunakan dalam aplikasi dunia nyata.

PLUSes

  • Kami mendapat banyak waktu untuk penelitian.
  • Berayun dari tujuan awal tidak menimbulkan banyak masalah.

Dalam industri,

  • Kami mengerjakan proyek yang sebenarnya akan digunakan oleh perusahaan.
  • Kami bekerja di bawah tekanan kebutuhan klien yang terus berubah.
  • Tenggat waktu jarang fleksibel, karena dapat menyebabkan kerugian finansial yang besar bagi perusahaan Perangkat Lunak maupun klien.

Lihat ini:

http://www.dodgycoder.net/2011/10/how-to-become-better-programmer.html


Saya harus tidak setuju tentang bagian "benar-benar digunakan". Selama awal pertengahan pertengahan 90-an, saya pergi 5 tahun, di 3 perusahaan yang berbeda, besar, kecil dan menengah, dan tidak ada yang saya tulis masuk ke produksi. Saya rasa ini bukan pengalaman yang tidak biasa.
Bruce Ediger

2

Pemrograman akademik lebih tentang kode itu sendiri. Ini penting dalam mempelajari cara kerjanya. Kualitas kode dan kontrol revisi tidak masuk hitungan. Dengan pengecualian penting, kode tidak memiliki masa hidup di luar penugasan. Ruang lingkup proyek cenderung sangat terbatas, dan tidak mungkin merangkak.

Di dunia nyata, Anda harus memiliki kode asli sesedikit mungkin. Banyak kode yang dikembangkan oleh tim. Lebih baik menggunakan rutinitas perpustakaan daripada kode sendiri. Kualitas kode dan kontrol revisi menjadi lebih penting. Kode cenderung memiliki masa pakai yang jauh melampaui apa yang semula diharapkan. Lingkup proyek biasanya cukup luas dan cenderung merayap secara signifikan jika tidak dikelola.


1

Sebenarnya,

tidak mungkin untuk sepenuhnya membedakan antara pemrograman tingkat akademik dan pemrograman dunia nyata.

Saya akan mengatakan perbedaan terbesar mungkin ini: dalam pemrograman dunia nyata - Anda harus tahu lebih banyak daripada pemrograman, dan harus dapat beradaptasi dengan cepat.

Bergantung pada sektor mana Anda melakukan pekerjaan, Anda harus mematuhi hukumnya.

Michael hanya menyentuh ujung gunung es dengan menyatakan tugas-tugas terkait pemrograman, yang akan saya klasifikasikan sebagai hal-hal yang mudah (jika Anda sepadan dengan adonan Anda dibayar).

Secara umum, Anda akan menghadapi setidaknya beberapa tantangan per subjek dalam suatu industri:

  • Hukum yang mengatur (mis. Kerahasiaan klien untuk medis)
  • Pengetahuan subjek (mis. Sistem faktur pajak, inventaris, manajemen sumber daya, skema medis, standar industri)
  • Persyaratan klien yang kurang atau tidak ada atau berbeda dari standar industri / hukum yang mengatur

Jika Anda membandingkan proyek pemrograman tingkat Phd penelitian dengan dunia nyata, kemungkinan mereka sangat mirip dalam kesulitan, pengetahuan tingkat pintu masuk dan semacamnya.

Satu-satunya perbedaan nyata adalah proyek dunia nyata

  • punya klien
  • memiliki anggaran (waktu, uang, sumber daya manusia)

Ini permainan bola yang berbeda ketika orang lain membuat aturan :)


0

Jika Anda melihat mata pelajaran yang dipelajari di IT dalam dunia akademis, Anda akan menemukan sekitar setengah dari waktu yang dihabiskan dalam matematika, sains, pilihan, dll. Dan setengah lainnya pada mata pelajaran akademik seperti: Desain kompiler, Teori algoritma, Arsitektur Komputer, Optimasi, Sistem Operasi, Elektronik Digital, dan beberapa kursus lain yang terkait dengan industri seperti pemrograman C dan Pemrograman Web.

Sebagian besar mata pelajaran yang disebutkan di atas adalah baik untuk diketahui tetapi tidak akan secara langsung memberikan latar belakang yang kuat dalam apa yang diperlukan dalam TI sehari-hari.

Ambil persyaratan Pemrograman Web Microsoft (yaitu, area yang diperlukan oleh seseorang untuk menjadi anggota tim yang produktif dalam suatu organisasi):

1- C # .NET atau VB.NET

2- ASP.NET

3- HTML dan CSS

4- SQL Server (atau database lain)

5- OO pemrograman dan desain aplikasi

6- Java Script

7- Kerangka MVC

8- Beberapa paparan alat kontrol sumber

9- Beberapa paparan alat pengujian otomatis

Alat pelacakan 10-Bug

Konsep 11-E-Commerce (opsional)

12-ORM

13-Beberapa keterampilan analisis bisnis

14-Beberapa keterampilan komunikasi

15-Mungkin, beberapa dasar komputasi awan

Seperti yang Anda lihat bahwa sebagian besar persyaratan di atas jarang difokuskan (Anda mungkin mendapatkan 1 mata kuliah paling banyak) selama kuliah / universitas.

Seseorang tidak dapat sepenuhnya menyalahkan institusi karena ada banyak tumpukan teknologi dan mereka terus berubah.

Sebagian besar di atas dari Microsoft tidak akan membantu seseorang yang ingin mengembangkan aplikasi di Jawa.

Masalah sebenarnya adalah bahwa tidak ada satu pun tumpukan teknologi yang dibutuhkan oleh bisnis saat ini yang tercakup secara penuh.

Di atas mencakup pertanyaan tentang kelayakan lulusan untuk pekerjaan bisnis seperti pemrograman di lingkungan bisnis. Kebutuhan untuk meneliti laboratorium, dll. Tidak tercakup oleh jawaban ini. Juga area lain membutuhkan lebih banyak keterampilan daripada yang di atas, seperti Pengembangan Game, Pengembangan Tertanam, Pengembangan Sistem Real-Time, dll.


12
Anda memiliki 15 item dalam daftar Anda. Saya kira saya bisa menambahkan 30. Bukan tugas akademia untuk mengajari Anda semua hal itu, melainkan mengajarkan Anda cara menemukan jalan Anda melalui semua hal itu. Dan juga, untuk memiliki pengetahuan yang masih dapat digunakan ketika semua teknologi saat ini akan usang (dalam 10 tahun dari sekarang?) Itulah semua teori yang baik dan tidak membuang - buang waktu !
Giorgio

2
@Iorgio, terima kasih atas komentar Anda, poin Anda valid. Saya secara eksplisit menyatakan bahwa "Seseorang tidak dapat sepenuhnya menyalahkan institusi". Sementara pertanyaan aslinya bukan tentang sifat pendidikan akademis, pandangan poersonal saya adalah bahwa ada kesenjangan BESAR antara apa yang diajarkan akademisi dan apa yang diharapkan bisnis. Tagihan untuk menjembatani kesenjangan yang dulu harus dibayar oleh bisnis dalam pelatihan on-the-job yang mahal. Dengan kompetisi yang hebat dan masa-masa sulit yang dilalui semua ekonomi, saya bertanya-tanya siapa yang akan membayar harga untuk menjembatani kesenjangan ini hari ini?
NoChance

@Emmad Kareem: Ya ada celah besar, saya setuju. Seringkali profesor universitas tidak memiliki petunjuk tentang apa yang terjadi di "dunia nyata" karena mereka berfokus pada penelitian abstrak. Namun, keterampilan berpikir abstrak inilah yang sekarang memungkinkan saya untuk belajar bahasa baru dalam beberapa minggu (mempelajari Scala sekarang). Saya juga mengerti bahwa mungkin bagi Anda masalah uang dirasakan lebih kuat. Saya tumbuh di Italia dan ketika saya mempelajari biaya universitas di mana sekitar $ 200 per tahun (ditambah kita harus membeli buku sendiri). Saya kira ini sangat sedikit dibandingkan dengan apa yang Anda bayar di AS.
Giorgio

3
Demikian juga, jika Anda mempelajari teknik dan mempelajari cara membuat mobil, tidak ada yang akan mengajari Anda cara mengendarai mobil tertentu: ini hanya sesuatu yang mereka harapkan Anda ketahui atau pelajari sendiri.
Giorgio

1
Terbuang? Jika Anda memiliki gelar yang Anda klaim miliki, maka Anda harus tahu lebih baik. Bahkan jika Anda tidak duduk di sana pemrograman matematika tingkat lanjut pelajaran yang dipelajari dalam mempelajarinya secara langsung diterjemahkan menjadi "melihat" solusi elegan bersih.
Rig

0

Skala & Fokus
Dari pengalaman saya, dalam lingkungan akademis, umumnya skala aplikasi yang sedang Anda kerjakan jauh lebih kecil, sesuatu yang dapat diselesaikan dalam satu hari atau minggu, atau mungkin sepanjang semester oleh satu atau dua progammers- -terutama semua yang Anda tulis akan menjadi kode yang dibuang setelah jangka waktu. Di dunia nyata, Anda mungkin mendapati diri Anda mengerjakan suatu aplikasi yang dibutuhkan tim yang lebih besar berbulan-bulan, jika tidak bertahun-tahun, untuk berkembang sepenuhnya. Anda menghabiskan lebih banyak waktu dan men-debug kode orang lain, dan mencoba memahami struktur basis kode, juggling tidak merusak bagian-bagian yang ada untuk menambahkan beberapa persyaratan baru atau modifikasi.

Persyaratan, Integrasi, Pelanggan
Juga, ada beberapa aspek dalam pengembangan kode, seperti analisis persyaratan, pengujian integrasi, dll. Yang cenderung kurang terwakili dalam proyek akademik. Demi penilaian yang adil, biasanya persyaratan sudah ditetapkan untuk Anda oleh instruktur, dan itu tidak diputuskan bersama dalam rapat. Anda tidak cenderung harus "menjual pelanggan" pada pendekatan tertentu yang tidak sesuai dengan yang mereka inginkan, tetapi tidak seperti keinginan mereka sebenarnya layak dari sudut pandang teknis. Dalam lingkungan akademik, pelanggan Anda (siswa kelas atau instruktur) cenderung memiliki gagasan yang cukup konkret tentang apa yang mereka inginkan, di dunia nyata, Anda dapat bertemu dengan pelanggan yang tidak benar-benar tahu apa yang mereka inginkan dan harus memilih otak mereka untuk memahami apa yang mereka inginkan. harus dibangun.


0

Pemeliharaan & Pemeliharaan

Di dunia akademis (setidaknya di tingkat sarjana), perangkat lunak dibangun dengan tujuan jangka pendek, biasanya untuk menyelesaikan beberapa pekerjaan rumah atau proyek jangka. Setelah tugas selesai, kode dibuang dan tidak pernah terlihat lagi.

Dalam lingkungan profesional, sebagian besar perangkat lunak ditulis dengan mempertimbangkan penggunaan jangka panjang; perangkat lunak dimaksudkan untuk digunakan setidaknya selama beberapa tahun dan perlu dibangun agar mudah dipelihara dan diperbarui dari waktu ke waktu.

Terkait dengan ini adalah pekerjaan pemeliharaan. Mayoritas pekerjaan pemrograman profesional melibatkan memperbarui atau memelihara perangkat lunak yang ada. Apa yang disebut proyek "lapangan hijau" adalah pengecualian, bukan norma.

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.