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

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'?

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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

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.

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.

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.