Apakah pengalaman magang negatif saya mewakili dunia nyata? [Tutup]

Saya ingin tahu apakah pengalaman saya saat ini sebagai magang mewakili industri yang sebenarnya.

Sebagai latar belakang, saya melalui bagian yang lebih baik dari dua jurusan komputer dan jurusan matematika di sebuah universitas besar; Saya telah mengakses setiap kelas dan mengagumi mereka semua, jadi saya ingin berpikir bahwa saya tidak buruk dalam pemrograman. Saya mendapat magang di salah satu perusahaan perangkat lunak utama, dan setengah jalan sekarang saya terkejut dengan kualitas kode yang sangat rendah. Komentar tidak ada, itu semua kode spageti, dan segala sesuatu yang bisa salah bahkan lebih buruk. Saya telah melakukan banyak pengajaran / TAing, jadi saya sangat terbiasa membaca kode yang buruk, tetapi produk-produk industri utama saya telah melihat semua itu. Saya bekerja 10-12 jam sehari dan tidak pernah merasa seperti berada di tempat lain, karena itu s jam tanpa henti mencoba untuk mencari tahu API tidak berdokumen atau menentukan perilaku beberapa bagian lain dari produk (benar-benar tidak berdokumen). Saya meninggalkan pekerjaan membenci pekerjaan setiap hari sejauh ini, dan saya sangat ingin tahu apakah ini yang ada di toko selama sisa hidup saya.

Apakah saya menggambar sedotan singkat di magang (gaji besar bukan kepalang menyiratkan bahwa itu bukan posisi berkualitas rendah), atau apakah ini seperti apa dunia nyata?

Mereka menyebutnya Dunia Nyata ™ karena suatu alasan.

99% dari apa yang akan Anda temui di dunia korporat nyata akan dianggap omong kosong, dan untuk alasan yang baik saya akan jelaskan. 1% yang tidak dianggap omong kosong pada akhirnya akan menjadi omong kosong.

# 1 Tulis Kode, # 2 ????, # 3 Untung!

Bisnis pertama ada untuk menghasilkan untung, mereka tidak ada untuk menghasilkan gunung kode akademik yang dirancang dengan sempurna bersih dan murni disimpan dalam repositori emas kesempurnaan. Bahkan tidak dekat, bahkan yang dalam bisnis penjualan kode sumber yang mereka hasilkan.

Dalam dunia bisnis kode adalah sarana untuk mencapai tujuan . Jika beberapa kode memecahkan masalah bisnis dan menghasilkan lebih banyak uang daripada biaya untuk membuat dan memeliharanya, maka itu diinginkan untuk bisnis. Mempekerjakan Anda untuk menulis kode hanyalah satu cara bagi bisnis untuk mendapatkan kode.

Teori 0 - Praktek ∞

Idealnya pemeliharaan harus lebih menjadi perhatian tetapi biasanya tidak, karena dalam jangka pendek tidak menang secara finansial. Dalam jangka panjang, perangkat lunak biasanya memiliki siklus hidup yang relatif singkat, terutama aplikasi berbasis web, mereka menjadi usang dengan cepat dan lebih sering ditulis ulang.

In-house line aplikasi bisnis adalah yang terus berputar seperti yang dianggap sebagai proyek zombie tanpa akhir karena banyak alasan berbasis momentum. Proyek-proyek ini sebenarnya adalah kesuksesan yang terus mereka jalani karena mereka terus membuat bisnis ini untung.

Secara teori tidak ada perbedaan antara teori dan praktik. Dalam praktiknya ada. - Yogi Berra

Secara teori, arsitek yang benar-benar bersih, basis kode yang benar-benar bersih dengan cakupan kode 100% akan menghemat uang perusahaan, dalam praktiknya bahkan tidak mendekati memberikan sesuatu yang mendekati pengembalian investasi yang valid.

Fisika Siklus Hidup Perangkat Lunak

Ada juga kekuatan entropi yang sangat kuat yang bekerja di dunia perangkat lunak. Ini adalah lubang hitam keniscayaan yang mengutuk semua perangkat lunak untuk berubah menjadi Big Ball of Mud .

Semakin jauh Anda memulai dari BBM semakin baik, tetapi setiap sistem perangkat lunak pada akhirnya akan sampai di sana dengan waktu yang cukup. Seberapa cepat Anda mendekati 100% entropi ditentukan oleh di mana Anda memulai dan seberapa cepat Anda menimbun utang teknis dan seberapa tinggi bunganya.

Sistem perangkat lunak merosot dan membusuk karena pemeliharaan, bukan karena kekurangannya. Sebuah sistem yang sudah ada selama bertahun-tahun tanpa perubahan kode menurut definisi memenuhi semua persyaratan dan sasarannya dan sukses.

Ini adalah sistem yang membutuhkan perubahan konstan karena mereka mulai lebih dekat dengan entropi maksimum adalah sistem yang terus-menerus disodok dan didorong dan pemeliharaanlah yang mempercepat perubahan negatif.

Cukup Baik Cukup Baik

Sistem siklus hidup pendek seperti situs web yang berubah terus-menerus tidak mendapat manfaat dari desain awal yang sangat besar, cakupan kode 100% dalam pengujian unit, karena waktu amortisasi terlalu singkat untuk memperbesar biaya.

Sistem siklus hidup yang panjang seperti garis internal aplikasi bisnis yang disebutkan di atas, tidak benar-benar diuntungkan oleh investasi besar-besaran dari 100% tes cakupan unit, juga, karena tingkat perubahan selama masa proyek mendekati konstanta yang mendekati nol dalam mode non-linear.

Itulah sebabnya rencana akhir masa hidup lebih penting dan sistem penggantian harus direncanakan seperti sesuatu yang dirilis, bukan ketika telah melewati itu prima beberapa tahun dan tidak dapat didukung sehingga sistem baru harus dilarikan ke tempatnya.

Mereka tidak mengajarkan tentang BBM sejauh yang saya tahu, saya belum pernah menemukan lulusan CS baru-baru ini yang tahu apa itu, apalagi mengapa itu terjadi.

Itulah sebabnya Cukup Baik itu Cukup Baik , ada yang kurang lebih baik.

Perampasan Perangkat Lunak

Ada tuan tanah kumuh real estat karena suatu alasan, mereka membuat keuntungan pada bangunan kumuh yang mereka miliki. Menghasilkan lebih banyak keuntungan daripada yang mereka habiskan untuk pemeliharaan tambahan properti yang rusak. Jika tidak, mereka akan merobohkan bangunan dan menggantinya. Tetapi mereka tidak melakukannya, karena biaya tambahan jauh lebih sedikit daripada merombak atau mengganti seluruh bangunan. Ada juga pelanggan (penyewa) yang bersedia membayar untuk properti yang rusak.

Tidak ada pemilik gedung, penguasa kumuh atau tidak yang akan menghabiskan uang untuk sebuah properti hanya karena beberapa gagasan akademis tentang kesempurnaan yang tidak diterjemahkan ke dalam laba yang substansial atas biaya yang terkait.

Tidak ada pelanggan yang akan membayar untuk upgrade ke sistem perangkat lunak yang berfungsi diterima oleh mereka. Tidak ada bisnis yang akan menghabiskan uang hanya untuk menulis dan menulis ulang kode tanpa keuntungan besar yang nyata.

Microsoft adalah yang paling mendominasi dan slumlord perangkat lunak yang sukses ada. Windows tidak mulai mendapatkan dasar menulis ulang dasar sampai baru-baru ini. Dan mereka masih belum menjatuhkan semua kode lama dari kernel. Tidak masuk akal secara bisnis bagi mereka, orang lebih dari rela menerima bar harapan yang rendah yang telah mereka tetapkan selama dekade terakhir.

Prognosa

Ini telah menjadi pola selama 20 tahun lebih saya dalam pengembangan perangkat lunak. Itu tidak akan berubah dalam waktu dekat. Ini bukan cara orang ingin keluar dari suatu sistem kepercayaan, itu adalah kenyataan kekuatan eksternal pada bisnis. Bisnis mendorong pengambilan keputusan, laba bukanlah kejahatan, mereka membayar gaji Anda, visi jangka pendek atau jangka panjang tidak relevan, ini adalah industri jangka pendek dengan perubahan konstan menurut definisi. Siapa pun yang berpendapat cukup baik untuk mendapat untung tidak memahami bisnis.

Saya menghabiskan 15 tahun berkonsultasi dan belajar dengan sangat cepat bahwa cukup baik hanya itu, apa pun yang saya lakukan memerlukan biaya. Ya saya ingin semuanya menjadi sempurna, tetapi kecuali jika Anda menjual basis kode, yang 99,99999% dari waktu Anda menjual solusi , semua kode rapi bersih yang anggun dan rapi hilang dan Anda hanya membuang-buang waktu Anda, Anda tidak akan pernah mendapatkan penggantian untuk .

Kemajuan dan Harapan

Metodologi tangkas adalah langkah yang baik ke arah yang benar, setidaknya secara filosofis. Mereka mengatasi kekacauan dan perubahan konstan sebagai warga negara kelas satu dan menerimanya. Mereka menolak praktik dogmatis, mengakui bahwa metodologi dan praktik harus berubah serta persyaratan dan teknologi.

Mereka menerima entropi yang diperkenalkan oleh kurangnya waktu atau persyaratan yang berubah, staf yang berubah, dan semangat sistem perangkat lunak dengan konsep utang teknis.

Tapi Agile bukan obat mujarab, itu tidak akan mengubah hukum dasar fisika dan basis kode akan membusuk terlepas. Terserah manajemen untuk merencanakan berurusan dengan busuk sebelum benar-benar lepas kendali dan tidak dapat dikelola.

Agile ketika dilakukan dengan benar, membantu mengelola entropi, memperlambatnya, melacaknya, mengukurnya dan menghadapinya secara terencana. Itu tidak akan menghentikannya!

Keputusan Karier

Jika ini adalah masalah filosofis yang nyata bagi Anda, Anda mungkin harus mempertimbangkan pilihan karier lain, karena cara kerja memiliki kelebihan bisnis yang valid di belakangnya. Proyek Open Source tidak memiliki rekam jejak yang lebih baik, dan dalam banyak kasus kode ini bahkan lebih buruk daripada kebanyakan kode perusahaan yang saya lihat.

Saya ingin tahu apakah pengalaman saya saat ini sebagai magang mewakili industri yang sebenarnya.

Tidak, bukan. Ini mewakili tingkat karir dan pengalaman Anda. Ini semua adalah bagian dari pembelajaran tentang bagaimana bisnis bekerja dari perspektif kontrol kualitas internal.

Sebagai latar belakang, saya melalui bagian yang lebih baik dari dua jurusan komputer dan jurusan matematika di sebuah universitas besar; Saya telah mengakses setiap kelas dan mengagumi mereka semua, jadi saya ingin berpikir bahwa saya tidak buruk dalam pemrograman. Saya mendapat magang di salah satu perusahaan perangkat lunak utama, dan setengah jalan sekarang saya terkejut dengan kualitas kode yang sangat rendah.

Keterampilan Anda, pengalaman Anda, pendidikan Anda tidak berdampak pada kualitas pekerjaan yang dilakukan oleh orang lain. Hanya karena Anda tidak memiliki wewenang untuk mengubah praktik-praktik itu. Tidak masalah apakah Anda baik atau buruk di universitas. Itu tidak mengubah cara perusahaan tempat Anda bekerja saat ini beroperasi. Jadi sementara ini bagus, Anda memiliki semua latar belakang ini. Ini benar-benar untuk keuntungan Anda sendiri dan bukan untuk mereka. Itulah mengapa penting untuk mempelajari apa yang Anda sukai.

Saya mendapat magang di salah satu perusahaan perangkat lunak utama, dan setengah jalan sekarang saya terkejut dengan kualitas kode yang sangat rendah. Komentar tidak ada, itu semua kode spageti, dan segala sesuatu yang bisa salah bahkan lebih buruk. Saya telah melakukan banyak pengajaran / TAing, jadi saya sangat terbiasa membaca kode yang buruk, tetapi produk-produk industri utama saya telah melihat semua itu.

Apa yang saya pelajari selama bertahun-tahun pemrograman adalah bahwa ada perbedaan antara "kualitas kode" dan "kode yang dapat diterima". Yang benar adalah bahwa seseorang dengan otoritas menemukan kode sumber dalam kondisi yang dapat diterima, atau mereka merasa tidak dapat diterima tetapi perlu. Meskipun alangkah baiknya jika kita semua bisa membersihkan proyek yang melibatkan kita. Sering kali bukan kepentingan bisnis atau anggaran untuk mengalokasikan sumber daya untuk melakukan pekerjaan itu. Argumen logis dapat dibuat sampai matahari terbit pada hari berikutnya mengapa ini akan menjadi hal yang baik untuk diperbaiki, tetapi ketika manajemen telah memutuskan keadaan saat ini "dapat diterima" maka sedikit yang bisa dilakukan. Itu semua terkait langsung dengan siapa yang menjalankan sesuatu. Entah mereka menghargai kualitas internal yang baik atau tidak. Anda dengan jelas menghargainya dan karena itu keadaan saat ini mengganggu Anda.

Anda akan menemukan contoh jenis masalah ini di industri apa pun yang bergantung pada kontrol kualitas internal. Mulai dari pengembangan perangkat lunak hingga manufaktur. Anda perlu belajar untuk melihat ini bukan sebagai masalah, tetapi hanya sebagai kondisi saat ini dari kode sumber mereka. Ini adalah bagaimana, dibutuhkan X jumlah menit untuk menemukan sesuatu, dibutuhkan X jumlah menit untuk memperbaiki sesuatu.

Bisnis itu tidak peduli dengan waktu tambahan ini, atau bisnis itu dapat diterima.

Saya bekerja 10-12 jam sehari dan tidak pernah merasa seperti berada di tempat lain, karena ini adalah waktu tanpa henti untuk mencoba mencari tahu API yang tidak berdokumen atau menentukan perilaku beberapa bagian lain dari produk (yang sepenuhnya tidak berdokumen). Saya meninggalkan pekerjaan membenci pekerjaan setiap hari sejauh ini, dan saya sangat ingin tahu apakah ini yang ada di toko selama sisa hidup saya.

Mengapa Anda bisa menghabiskan waktu berjam-jam di universitas untuk mempelajari subjek, tetapi sekarang tidak dapat diterima untuk menghabiskan waktu berjam-jam untuk mempelajari kode sumber? Saya yakin alasan majikan mempekerjakan Anda adalah karena mereka pikir Anda bisa mengatasinya.

Biarkan saya memberi Anda beberapa saran. Pengembang yang baik tahu kapan harus meminta bantuan dari rekan setimnya. Jangan berpikir jawabannya selalu ada dalam kode. Saya telah menghemat banyak waktu dengan mengajukan beberapa pertanyaan kepada orang-orang. Sepertinya Anda perlu bantuan untuk mempercepat.

Kedua, kita tidak tahu kondisi kerjanya. Bekerja berjam-jam adalah fakta kehidupan di banyak industri. Anda perlu menyelesaikannya sendiri, tetapi saya dapat memberi tahu Anda. Membenci pekerjaan Anda bukanlah pertanda baik. Anda harus berurusan dengan perasaan itu dan sampai ke akarnya. Maaf, Anda mendapati pengalaman ini negatif.

Apakah saya menggambar sedotan singkat di magang (gaji besar bukan kepalang menyiratkan bahwa itu bukan posisi berkualitas rendah), atau apakah ini seperti apa dunia nyata?

Anda melakukannya dengan sangat baik di sekolah, tetapi sekarang Anda memiliki magang dan Anda tidak melakukannya dengan baik. Sepertinya Anda sudah berada di dunia nyata. Itu bagian dari kehidupan. Pertanyaannya adalah, apa yang akan Anda lakukan? Itu temanku, adalah satu-satunya hal yang penting. Kami tidak dapat memberi tahu Anda apa yang harus dilakukan. Anda harus mengambil keputusan sendiri.

Saya dapat memberitahu Anda bahwa sepertinya pengalaman Anda di usia Anda jauh lebih baik daripada peluang yang saya miliki. Kehidupan bagi saya di tahun 90-an adalah perjuangan untuk membayar sewa dan menemukan kontrak berikutnya. Anggap diri Anda beruntung.

Setelah 25 tahun dan berbagai perusahaan dan industri saya dapat mengatakan:
Ya, itu cukup umum.
Inilah sebabnya mengapa insinyur dibayar dengan cukup baik biasanya, mereka harus pandai menghadapi berantakan hodge-podges dan masih dapat melakukan perubahan sambil menolak keinginan mendesak untuk refactor seluruh barang sialan dan mencari tahu apa yang sebenarnya seharusnya perbuatan. Saya melemparkan emosi untuk Anda di sana - itu normal untuk merasa seperti itu tentang kode yang Anda temui!

Kode yang Anda lihat akan sering mengalami iterasi tanpa akhir oleh programmer yang berbeda dengan pendekatan dan standar yang berbeda dan konvensi penamaan yang berbeda, dll. Dll.

Yang terjadi adalah tekanan $ selalu menyala. Itu selalu tergoda untuk menggambarkan bagaimana dan mengapa kode yang lebih baik adalah satu-satunya cara dalam jangka panjang tetapi dalam banyak pekerjaan jam terus berdetak untuk solusi perbaikan cepat jangka pendek. Hanya perlu 1 insinyur waktu singkat untuk menghancurkan standar dalam suatu proyek. Dibutuhkan manajer yang sangat baik yang tahu bagaimana mencegahnya dan mempertahankan pendekatan yang tepat (jika memungkinkan) untuk benar-benar mengatasinya.

Satu hal yang pasti, istilah 'kode yang baik' terlalu subjektif untuk berguna. Ini tidak subyektif bagi Anda tentu saja, Anda dapat membuat daftar alasan / item tertentu. Namun orang lain membuat daftar item dan prioritas yang berbeda, beberapa bahkan tidak teknis, yang mereka anggap penting, dan karenanya subyektif.

Seperti Drekka, ini mulai terdengar menyedihkan, jadi izinkan saya mencoba untuk sedikit lebih positif, karena memang benar bahwa: -

• Ada organisasi, sering dengan komponen teknis terbesar yang sedang melakukan hal yang benar.
• Semakin baru perusahaan ... dan kodenya ... cenderung bersih . spaghetti tumbuh karena waktu dan manusia.
• Beberapa orang melakukan TDD dan BDD, yang lain tidak. Kisarannya sangat besar.
• Setelah sekitar 10 tahun, saat ini, seluruh basis teknologi berubah sehingga mereka yang tinggal di industri dapat memiliki waktu yang sulit seperti halnya pemula.

Akhirnya, seperti yang ditunjukkan Anthony Blake, selalu ada 3 faktor - waktu, biaya dan kualitas.
Saya suka ungkapan terkait: "pick 2" !

Ada banyak pendapat tentang ini karena pengalaman setiap orang berbeda.

Milik saya adalah bahwa sekitar setengah dari pengembang yang saya temui bermaksud baik, tetapi kemampuan rata-rata. Ada sekelompok kecil orang-orang cerdas di atas, dan sekelompok kecil di bagian bawah yang berusaha tetapi pada dasarnya harus melakukan sesuatu yang lain karena mereka tidak benar-benar mendapatkannya. Sayangnya ada juga kelompok kecil lain dari orang-orang bodoh yang tidak kompeten yang berpikir bahwa mereka jauh lebih pintar daripada orang lain dan biasanya cukup di hadapan Anda tentang bagaimana Anda harus mengikuti mereka.

Dari segi proyek, saya telah pergi ke banyak pekerjaan dan segera diminta untuk "merawat" beberapa proyek yang sudah mapan, biasanya yang baru saja ditemukan oleh bisnis yang sangat dibutuhkan setelah kehilangan pengembang terakhir. Saya biasanya menemukan persis apa yang telah Anda sebutkan di atas - spaghetti tidak berdokumen, over-engineered, buggy. Kadang saya bisa memperbaikinya, kadang saya baru mulai lagi. Bahkan tidak perlu kode lama, saya telah menemukan ini di proyek baru saya juga diminta untuk "membantu".

Anda harus mengambil hati dari kenyataan bahwa sebagian besar perusahaan akan memberikan pekerja magang pekerjaan buruk. Yang menyenangkan datang setelah Anda melakukan dua hal: 1 - membuktikan diri Anda dan 2 - meluangkan waktu untuk mengerjakan hal-hal selain memperbaiki kesalahan orang lain. Dengan kata lain Anda harus menunjukkan kemampuan dan inisiatif.

Trik nyata untuk menangani kode buruk adalah mencari tahu apa yang bisa diselamatkan dan apa yang tidak. Ini berasal dari pengalaman dan penelitian.

Pilihan karier lain yang Anda miliki adalah berhenti bekerja untuk perusahaan yang sudah mapan dan mencari pekerjaan di perusahaan pemula. Maka tidak akan ada kode warisan omong kosong untuk dipelihara sehingga Anda akan memiliki kesempatan untuk membantu membangun sesuatu yang lebih baik. Kelemahannya adalah bahwa tekanan untuk memberikan ditempatkan pada proyek-proyek startup sering berarti bahwa jalan pintas dan peretasan digunakan ketika mereka seharusnya tidak.

Pemrogram terlalu sering bersedia untuk mengambil utang teknologi untuk memberikan lebih awal atau tepat waktu. Sayangnya dampak dari utang teknologi ini sering ditutup-tutupi, diminimalkan, diabaikan atau diberhentikan oleh pengembang dan manajemen sampai semuanya terlambat dan mereka dalam masalah.

Maaf jika ini terdengar menyedihkan. Saya yakin orang lain dapat melakukan hal yang lebih positif. :-)

Ada beberapa jawaban bagus di sini, tetapi izinkan saya menambahkan bagian saya;

Selamat datang di dunia nyata - sayangnya ini sangat umum.

Lihat diagram di bawah ini;

Dengan perangkat lunak perusahaan, Anda hanya dapat memilih 2 atau yang di atas, dan Anda harus mengorbankan satu.

Seperti yang tampaknya sudah Anda temukan, sebagian besar dunia korporat berjalan dengan kecepatan dan harga.

Tidak sepenuhnya menunjukkan industri, tetapi dari pengalaman saya yang terbatas 5+ tahun. Saya akan bekerja melalui magang Anda dan mengambil sebanyak mungkin pelajaran dari pengalaman. Cari tanda dan indikator. Misalnya untuk posisi Anda berikutnya, Anda tanpa ragu harus melalui serangkaian wawancara. Proses ini adalah jalan dua arah, dan memberi Anda kesempatan untuk merasakan perusahaan. Ini sangat penting dan kemungkinan akan mengarah pada kebahagiaan dan kesejahteraan Anda sendiri.

Singkatnya, temukan tanda-tanda dongeng;

• Siapa yang menjalankan perusahaan? Apakah itu manajer tunggal, tim pemasaran (jika demikian, menjauhlah), tim pengembangan, dll. Sudut ini berarti Anda mungkin mendapatkan lebih banyak atau lebih sedikit pengaruh untuk proyek, waktu yang dihabiskan untuk proyek, dll.
• Apakah ada penghargaan teknis? Lihatlah bagaimana manajemen, penyelia, dan anggota tim memperlakukan satu sama lain. Saya telah dalam sebuah wawancara di mana para manajer telah melakukan semua jenis gerakan alis begitu pemimpin teknis mulai berbicara. Setelah itu dan belajar mereka tidak menggunakan kontrol sumber - Anda tidak bisa menunjukkan pintu cukup cepat.
• Tujuan bisnis? Apakah perusahaan hidup hari demi hari, seperti dalam target keuangan harian, atau apakah ia memiliki rencana jangka panjang yang menjadi bagian Anda. Pengembangan perangkat lunak umumnya dilakukan selama berbulan-bulan sehingga memiliki perusahaan dengan sifat skizofrenik biasanya mengarah pada perangkat lunak yang berantakan.
• Gali sekitar - ketika mengajukan pertanyaan teknis dan lihat apakah orang-orang mengocok. Kontrol sumber, kontrol dokumen, proses rilis, laporan bug, gaya manajemen, T&C, dll.

Jadi hiduplah dan pelajari, dan pikirkan tentang peran Anda selanjutnya. Memiliki pengalaman buruk tidak terlalu buruk, karena Anda akan lebih terdidik tentang dunia kerja & bisnis.

Yah, saya menjalankan pada dekade kedua saya dalam bisnis, dan saya dapat memberitahu Anda bahwa kode bersih sempurna sangat jarang terjadi, dan ketika itu terjadi, itu tidak lama tetap seperti itu. Pada umumnya Anda akan menemukan diri Anda terus-menerus berusaha memperbaiki kesalahan masa lalu, sementara (sedih) dipaksa oleh kendala waktu dan kepemimpinan yang buruk untuk melakukan kesalahan saat ini.

Kecuali jika Anda berada dalam jenis bisnis perangkat lunak yang sangat spesifik, tekanan untuk mengeluarkan produk fungsional keluar dari pintu mengesampingkan semua masalah lain, dan pengoptimalan di luar titik tertentu dianggap tidak ada gunanya. Jika program berjalan dalam 5 menit, dan kami hanya perlu menjalankannya dalam 5 menit, tidak ada yang akan memberi Anda beberapa minggu untuk menjalankan runtime menjadi 2 menit.

Jika, dengan suatu keajaiban, Anda memiliki pertemuan sempurna dari manajemen yang kompeten, tujuan yang jelas, uang, bakat, dan waktu, dan Anda menghasilkan produk yang bersih dan unggul ... Satu-satunya cara itu akan tetap seperti itu adalah jika Anda tidak pernah menyentuh lagi . Pemeliharaan dan ekstensi hampir selalu diberikan prioritas yang sangat rendah, perubahan selalu diperlukan pada pemberitahuan nol secara efektif, dan akhirnya dikurung secara tidak teratur.

Saya sedang memikirkan proyek yang satu ini kemarin. Bagiku itu adalah mimpi pipa yang sangat jelas, sehingga aku memantulkan sedikit omong kosong yang sangat fungsional keluar dari pintu. Saya melihatnya sebagai pemborosan waktu dan sumber daya.

Nah, kejutan, kejutan, semua orang menyukainya dan itu berhasil dengan baik. Jadi saya melompat kembali ke papan gambar dan melakukannya dengan benar. Dan versi baru itu luar biasa! Tapi kemudian ada pergantian dalam manajemen dan semuanya dibatalkan demi "arah bisnis baru."

Iterasi kedua memiliki penyebaran yang benar-benar setengah-setengah dalam perusahaan, dan saya tidak pernah mendengar hal lain tentang itu, yang lucu karena saya tahu setidaknya ~ 10 unit bisnis masih menggunakannya (perangkat lunak yang kami siapkan untuk melakukan pekerjaan itu) hampir 2 tahun terlambat dari jadwal) dan tampaknya tidak pernah putus.

Ini membawa kita ke titik akhir saya. Bahkan jika Anda menghasilkan sesuatu yang ajaib, fakta bahwa itu bekerja dengan sangat baik berarti bahwa TIDAK seorang pun akan mengenalnya, dan ketika itu rusak (biasanya karena mereka melakukan sesuatu yang bodoh) maka mereka akan mengutuk nama Anda lebih buruk daripada mereka pernah mengutuk si idiot yang menulis hal yang merusak setiap Selasa ketiga.

Sulit untuk mengatakan apa yang Anda anggap kode kualitas sangat buruk, tapi ya beberapa programmer sangat baik (menurut definisi). Sebagai perangkat lunak berkembang, orang membuat kesalahan. Seiring berjalannya waktu ini, dan tekanan bisnis (dan kemalasan / kebodohan programmer) membuat refactoring ... Jarang.

Tidak bisa bicara untuk semua orang, tapi ini yang bisa saya katakan.

Saya belum bekerja 30+ tahun di domain, tetapi saya melihat cukup untuk mengatakan beberapa hal. Sebuah proyek memiliki masa hidup yang sangat mirip manusia. Desain awal mungkin tidak sesuai dengan kebutuhan saat ini untuk katakanlah satu proyek setelah 20 tahun pembangunan. Yang mengatakan dalam jumlah waktu itu, banyak orang mengubah kode yang berantakan dengannya dan menambahkan hal-hal yang pada awalnya tidak mungkin dilakukan.

Tidak terlalu sulit membayangkan kode jelek pada proyek lawas atau proyek yang cukup lama. Kami tidak dapat mengharapkan semua orang untuk sepenuhnya memahami desain awal. Sedih, tapi memang begitu.

Yang mengatakan, Anda harus ingat bahwa refactoring proyek warisan tidak selalu mungkin dan kadang-kadang bahkan tidak diinginkan. Saya bekerja di perusahaan tempat mereka mengembangkan pengganti untuk proyek yang sedang saya kerjakan. Saya tidak diizinkan untuk terlalu banyak memperbaiki proyek saya karena takut itu akan bekerja lebih baik daripada proyek baru. Saya cukup yakin tidak ada cara proyek ini bisa bekerja lebih baik daripada yang baru. frasa itu agak seperti "Jangan membuatnya lebih baik, hanya membuatnya bekerja".

Akhirnya Anda tidak akan sering memiliki proyek semacam itu, karena saya sering membaca dan mendengarkan. Anda harus mencoba mencari pekerjaan dengan perusahaan rintisan alih-alih perusahaan besar. Startup cukup menarik dan pada akhirnya Anda bisa bergerak cepat jika Anda melihat itu tidak berjalan seperti yang Anda inginkan juga.

Juga satu hal yang dapat Anda lakukan, saya benar-benar tidak menjanjikan apa pun, tetapi jika Anda merasa kode itu benar-benar buruk dan perlu refactoring. Bagikan dengan tim. Ingatlah bahwa orang-orang yang menulis kode jelek itu mungkin bekerja dengan Anda. Ini bukan tentang menyakiti perasaan orang, tetapi jika Anda melihat bahwa proyek yang sedang Anda kerjakan akan runtuh setelah beberapa waktu dan orang akan menghabiskan lebih banyak waktu untuk memahami apa yang dilakukannya daripada meningkatkannya. Lebih baik berbicara dan mengomunikasikan masalah daripada menyimpannya sendiri. Jika Anda cukup beruntung, Anda mungkin akhirnya akan refactoring proyek.

Jika Anda akhirnya refactoring proyek, Anda mungkin menjadi orang yang ditunjuk untuk pilihan desain yang buruk! Dan Anda mungkin mengerti mengapa refactoring tidak sering terjadi. Mudah-mudahan jika seluruh tim harus refactor, maka tidak ada yang bisa menunjuk. Mereka hanya akan memecat semua orang =)

Saya akan mencoba meringkas jawaban untuk pertanyaan ini dengan kutipan sederhana:

All code turns to crap given enough time and hands.

Sisanya hanya cerita ...

Kualitas Kode terutama tergantung pada dua faktor.

Pertama selalu uang. Perusahaan yang memiliki tekanan selamat tinggi biasanya membayar upah rendah, melibatkan pengembang yang kurang berpengalaman, memiliki jadwal yang ketat dan tidak punya waktu atau uang untuk memanfaatkan pengembang mereka.

Kedua adalah manusia. Pertama-tama mereka yang memutuskan anggaran harus memilih pengeluaran dalam kualitas kode, maka mereka harus melibatkan orang-orang yang ingin "menjalaninya". Seperti yang dapat Anda bayangkan, Mungkin akan sulit untuk mengubah seorang programmer Delphi top-down-Delphi berusia lima puluh tahun yang dibayar (tidak berniat membuat stereotip, maaf) menjadi Pengembang Java Terkini yang melakukan CI Builds dan memproduksi kode yang digabungkan secara longgar. Banyak pengembang tidak menyukai pelajaran oleh orang-orang (mungkin yang lebih muda), mereka tidak suka seseorang memancing di kolam mereka - atau menggetarkan takhta mereka.

Jadi dengan mengatakan itu, dan juga mempertimbangkan fakta bahwa Anda memiliki kode warisan di sebelah setiap perusahaan, saya akan mengatakan Anda mendapatkan banyak dari itu di kehidupan nyata. Yang bisa Anda lakukan adalah berperilaku seperti pemboikot: Pergi ke hutan, ambil sampah dan bersihkan. Lain kali Anda akan memiliki sedikit kekacauan untuk melangkah.

Selamat datang di kode dengan anggaran! Ada perbedaan besar ketika pengembangan didorong oleh manajemen untuk dilakukan terlalu cepat, tanpa perencanaan, dan dengan memotong sudut. Saya memiliki pengalaman yang sama dengan kejutan dunia nyata ketika saya mendapatkan pekerjaan pemrograman pertama saya keluar dari perguruan tinggi. Tidak ada dokumentasi! Seiring waktu saya belajar banyak dari waktu ke waktu, menulis dan menjaga dokumentasi formal tetap terkini hanyalah buang-buang waktu. Beruntung bagi saya, itu adalah tim yang luar biasa. Itu dipimpin oleh seorang pria yang tahu apa yang dia lakukan dan anggota tim lainnya benar-benar peduli tentang menulis kode dengan cara yang benar. Sejak itu, pengalaman saya mirip dengan Anda. Banyak kode mengerikan, banyak kode buruk, banyak "pengembang" yang tidak mengerti. Untuk setiap pengembang yang baik, tampaknya ada 100 yang buruk.

Anda tidak ditakdirkan untuk membenci pekerjaan Anda selamanya. Anda hanya perlu menemukan perusahaan yang cukup pintar untuk mengenali manfaat jangka panjang yang bersedia berinvestasi sedikit di muka. Saya telah berhasil membuktikan melakukan hal-hal dengan cara yang benar alih-alih yang tercepat bermanfaat dan menjadi sangat dihormati dan dipercaya untuk itu di perusahaan tempat saya bekerja. Seiring waktu, kode spageti diperbaiki atau menjadi usang dan kode Anda mengambil alih. Bersiaplah untuk berkompromi. Terkadang cara paling keren atau paling kuat untuk pemrograman sesuatu hanya berlebihan dan tidak apa-apa untuk melakukannya dengan cara cepat dan kotor.

Saya mendapat magang di salah satu perusahaan perangkat lunak utama

Tidak semua perusahaan sama. Anda akan menemukan tim jelek dan basis kode perangkat lunak jelek di sebagian besar perusahaan. Tetapi Anda juga dapat menemukan tim yang hebat dan basis kode yang hebat.

Saya pikir orang-orang di Solaris melakukan deskripsi yang sangat baik dan jujur ​​tentang jenis basis kode yang akan Anda temukan di perusahaan besar: http://hub.opensolaris.org/bin/view/Community+Group+on/dev_solaris

Saya meninggalkan pekerjaan membenci pekerjaan setiap hari sejauh ini, dan saya sangat ingin tahu apakah ini yang ada di toko selama sisa hidup saya.

Tidak, saya telah mengkode selama lebih dari 15 tahun dan saya masih menyukainya.

Itu tidak berarti bahwa semuanya telah sempurna. Saya telah melihat beberapa basis kode yang mengerikan dan juga beberapa yang hebat. Kuncinya adalah menemukan tempat yang tepat untuk Anda.

Perusahaan besar sangat berbeda dengan yang kecil. Dalam tim perusahaan yang sama, A kadang-kadang sangat berbeda dengan tim B. Temukan yang memiliki keseimbangan yang tepat untuk Anda (misalnya proyek yang menantang, budaya yang Anda nikmati, bayaran baik, dan lain-lain)

Semoga berhasil!

Saya telah melihat hal yang sama seperti Anda. Saya memiliki dua pengalaman kasus ketika itu terjadi.

1. Ketika pengembangan terlalu didorong oleh proyek. Satu-satunya hal yang penting adalah memberikan fungsionalitas tepat waktu, lalu keluar. Perubahan selanjutnya akan dilakukan oleh orang lain, oleh beberapa manajer tim / proyek lain dengan anggaran baru.
2. Ketika sebuah perangkat lunak dikelola oleh hanya beberapa orang dalam waktu yang lama, pengembang cenderung menjadi malas, karena mereka tahu perangkat lunak mereka. Prinsip akademis jauh sekali.

Sedih, tapi begitulah di beberapa tempat.

Lihat apakah Anda dapat membuat perubahan kecil menjadi lebih baik, membiasakan diri atau mengubahnya ke perusahaan lain dan meminta untuk menyaring beberapa kode saat wawancara :-)

Ini akan menjadi jawaban singkat.

Pendidikan sangat berguna untuk membuat Anda merasa berkualitas dan idealis. Ini adalah hal yang baik, dan Anda harus berusaha mempertahankan idealisme.

Jika Anda benar-benar objektif, dan Anda dapat melihat kembali pekerjaan Anda sendiri di masa depan, itu tidak akan menjadi pengalaman yang sangat memuaskan. Kecuali Anda membohongi diri sendiri atau tidak belajar apa pun, Anda akan melihat banyak cara untuk meningkatkan apa yang telah Anda lakukan.

Secara umum, seluruh dunia melakukan ini di sekitar Anda. Jadi, ketika Anda melihat pekerjaan dari masa lalu, kecuali pengecualian, itu akan tampak lebih rendah dan membutuhkan perbaikan. Jika Anda tidak merasa seperti ini, itu berarti Anda melakukan pekerjaan yang salah, atau membayarnya terlalu baik.

Berita baiknya adalah, Anda dapat mengambil manfaat dari kesalahan orang lain dan dari perbandingan dengan masa lalu. Jika semua aplikasi bekerja dengan baik dan mudah untuk mempertahankan pengembang baru tidak akan diperlukan. Menurut pendapat saya, mempertahankan beberapa pengembang lain merupakan pengalaman belajar yang berguna dan harus menjadi elemen pelatihan wajib untuk semua pengembang langit biru.

Pengalaman negatif Anda terlalu khas dari perusahaan merek-merek besar terkenal yang banyak pengembang pelajari untuk mendekati dengan lebih hati-hati dan gentar daripada yang mereka lakukan saat pertama kali mereka memiliki kesempatan untuk bekerja di satu. Pada dasarnya, semakin banyak lapisan manajemen yang Anda miliki, semakin biasa-biasa saja diperjuangkan. Manajer menengah tidak melaporkan kepada manajer atas tentang kualitas kode. Mereka melaporkan fitur-fitur yang dikirimkan dalam jumlah waktu X dan memberikan presentasi powerpoint pada fitur UI neato yang mereka harapkan berfungsi cukup lama untuk menyelesaikannya. Jika semuanya runtuh satu bulan kemudian, itu biasanya masalah orang lain dan mereka tahu itu.

Jadi ya, para devs yang hidup di tempat-tempat seperti itu cenderung tidak terlalu peduli. Mereka tidak bisa bertahan di sana jika mereka melakukannya. Saya pernah mendengar tentang Lembah Silikon, bahwa jika Anda ingin malas, bekerjalah untuk salah satu nama besar. Jika Anda ingin pekerjaan yang menarik, cari startup yang lebih baru yang belum menjadi nama rumah tangga. Saya bekerja di Chicago dan dapat menjamin fenomena serupa di sini.

Sebagai aturan umum (dengan banyak pengecualian saya yakin), Anda akan menemukan apresiasi yang lebih tinggi untuk kode kualitas di perusahaan yang lebih kecil dan dikelola atau dimiliki oleh orang-orang yang juga terus menulis kode. Kompensasi sering kurang, tetapi pekerjaan sering jauh lebih bermanfaat menurut saya.

Sebagai pengembang tingkat pemula, Anda tidak mungkin memiliki banyak kendali atas siapa Anda bekerja pada awalnya, tetapi saya akan mengatakan bahwa memiliki nama besar di resume Anda selama setahun atau lebih pasti menggairahkan perekrut dan SDM. Juga, Anda dapat belajar sedikit yang tidak akan Anda pelajari jika tidak bekerja untuk seseorang yang benar-benar mengerikan dalam enam bulan pertama atau lebih dan itu juga membantu Anda mendapatkan pegangan yang lebih baik mengenai praktik terbaik mana yang benar-benar penting dan mengapa dan mana yang hanya merupakan teknologi. mode.

Dan tentu saja ketika bekerja dengan alat korporat populer yang lebih utama, Anda akan cenderung menemukan bahwa tingkat bakat rata-rata akan sangat payah. Jika keterampilan utama Anda adalah kombinasi dari Java dan C #, perluas wawasan Anda sedikit. Anda mungkin menemukan ceruk yang lebih bahagia di tulisan tingkat menengah Erlang atau Python atau: o JavaScript.

Dan jangan biarkan orang lain memberi tahu Anda perbedaan. Anda mungkin tidak punya pilihan dalam hal bagaimana melanjutkan tetapi kode omong kosong! @ # $ Ing mahal.

Pertanyaan Anda terfokus pada magang. Saya tidak pernah punya pemrograman, tetapi magang di stasiun radio, tidak benar-benar berlaku di sini.

Pertanyaan Anda juga menyebutkan pengalaman Anda selama magang. Pengalaman magang Anda dan jawaban yang telah Anda terima sejauh ini semuanya meringkas pengalaman saya, setelah apa yang sekarang menjadi perangkat lunak penulisan selama dua puluh tujuh tahun (mulai pertengahan Juni 1985).

Saya tidak pernah percaya saat sekolah ketika instruktur kami mengatakan ada lebih banyak pemikiran daripada menulis kode. Mereka benar. Dan, jika Anda mencoba mencari tahu kode orang lain, itu lebih buruk tanpa komentar, dan hampir sama buruknya dengan komentar. Cobalah mempertahankan sistem pengumpulan pajak kota-rumah tanpa komentar, tanpa dokumentasi, tidak ada bangunan formal, dan tanpa kontrol kode sumber.

Kapan pun Anda bisa melakukannya dengan baik tanpa langsung melanggar perintah standar, maka lakukan dengan baik. Selalu ingat, lebih mudah untuk meminta maaf karena melakukan sesuatu yang Anda tidak minta izin untuk dilakukan daripada memiliki izin tidak diberikan dan bertentangan dengan perintah langsung.

Jangan lupa standar yang Anda pelajari di sekolah. Mereka tidak sia-sia, tetapi kemungkinan besar standar-standar itu adalah asimtot dalam batas Kalkulus. Anda selalu dapat mencoba mendekati mereka, tetapi Anda mungkin tidak pernah mencapai nilai mereka.

Semoga berhasil.