Apakah saya memiliki ide yang salah tentang rekayasa perangkat lunak? [Tutup]

Saya memiliki pertanyaan yang diajukan oleh pekerjaan terakhir saya (agak magang).

Hanya untuk memasukkan segala sesuatunya ke dalam konteks - Saya berusia 21 tahun dan saya telah menyelesaikan tahun ke-2 di universitas sebelum saya memiliki sekitar 2 tahun pengalaman melakukan pekerjaan sys admin / QA dan pada dasarnya saya dapat mengatakan bahwa saya telah melihat betapa berbedanya Sektor TI dioperasikan. Berkedip maju ke masa sekarang dan inilah saya mendapatkan pekerjaan magang di salah satu lembaga penelitian terkemuka di Inggris.

Apa yang harus saya lakukan adalah membuat beberapa alat internal menggunakan campuran teknologi - terutama AWS / Java / Bash - Anda mendapatkan gambar. Semuanya baik-baik saja, saya melakukan pekerjaan saya TETAPI saya tidak bahagia. Kenapa begitu - karena saya diharapkan bekerja dalam masalah ad-hoc. Yaitu menciptakan sesuatu dengan cepat, tanpa menghabiskan waktu untuk mendesain. Manajer saya secara eksplisit mengatakan bahwa itu diharapkan "tergesa-gesa" melalui masalah saat mereka muncul dan kami pada dasarnya. Akibatnya ternyata hal-hal yang harus dilakukan kembali dan rekayasa ulang dan mereka masih belum sempurna. Sejauh menyangkut pengujian - pertahankan seminimal mungkin, selama masih berfungsi maka itu OK.

Apakah saya salah untuk tidak setuju dengan cara melakukan pekerjaan ini? Apakah salah jika ingin memikirkan sistem secara keseluruhan, kemudian fokus pada komponen yang berbeda dan melihat bagaimana mereka dapat beroperasi, untuk membidik "titik-titik kunci" yang berbeda yang mungkin ternyata bermasalah di masa depan? Apakah kejahatan ingin melakukan pekerjaan dengan baik dan bukan "pekerjaan cepat"? Apakah itu kesalahan atau sikap yang salah untuk ingin meneliti struktur data yang berlaku untuk masalah sehingga Anda dapat memilih yang terbaik tergantung pada set masalah tertentu? Sejauh yang saya mengerti, "Rekayasa" dalam "Rekayasa Perangkat Lunak" harus benar-benar dilakukan dengan ini - meneliti domain masalah Anda dan menghasilkan solusi yang tepat lalu memperbaiki yang diperlukan?

Saya pernah ke sebuah wawancara di kantor Arm di Inggris dan mereka menunjukkan kepada saya kamar SCRUM mereka dan tampaknya mereka memiliki ide yang cukup bagus tentang bagaimana mengelola proyek mereka - mereka memiliki tumpukan, mereka memiliki metrik tentang berapa lama masing-masing masalah mungkin diperlukan untuk menyelesaikan - hal-hal biasa untuk SCRUM - benar-benar berbeda dari cara menjalankan "di sini"

Sudahkah saya membangun ide yang salah tentang industri perangkat lunak secara umum? Saya ingin mendengar masukan Anda tentang itu. Maksud saya, saya "memasuki" pengembangan perangkat lunak semata-mata karena saya ingin membuat sesuatu - sederhana dan sederhana, tetapi saya ingin membuat barang berkualitas. Saya ingin melihat perangkat lunak saya digunakan dalam berbagai skenario, saya ingin melihatnya sebagai bukti - bukankah itu kekuatan pendorong untuk semua insinyur perangkat lunak? Saya pikir semua orang bisa menjadi programmer / programmer dengan hanya mempelajari sintaksnya tetapi bagi saya di mana kesenangan sebenarnya dimulai adalah ketika Anda benar-benar harus datang dengan desain yang bisa dilakukan di dunia nyata.

Saya biasa mengerjakan tugas universitas saya hanya dengan melihatnya dan langsung memulai pengkodean dan dapat dengan mudah mendapatkan nilai di atas 75% dan tidak pernah benar-benar menghargai modul "siklus pengembangan perangkat lunak". Tapi sekarang ketika saya melihat di dunia nyata betapa buruknya bekerja tanpa proses formal dan frustrasi yang melekat dalam situasi di mana Anda tidak tahu apakah persyaratannya akan berubah besok (oh, apakah saya mengatakan bahwa kami tidak dapat memiliki analisis persyaratan yang jelas?)

Saya benar-benar ingin percaya bahwa saya baru saja mendapatkan posisi di mana beberapa orang hanya memerlukan kode monyet untuk melakukan pekerjaan kotor mereka dan ini bukan kasus bagaimana dunia perangkat lunak beroperasi secara luas.

Membuat perangkat lunak dapat digunakan kembali dan bukti peluru bukanlah kekuatan pendorong rekayasa perangkat lunak. Rekayasa adalah tentang menyelesaikan masalah dunia nyata secara optimal dalam batasan dunia nyata . Sebagian besar insinyur lebih suka bekerja dengan Ferrari - tetapi station wagon hanya membutuhkan banyak teknik, dan alasan station wagon tidak berkinerja baik (dalam beberapa hal) adalah karena kendala desain yang lebih sulit, bukan karena teknik yang lebih buruk .

Ketika Anda mengatakan Anda ingin melakukan "pekerjaan bagus" daripada "pekerjaan cepat", kebanyakan insinyur melakukannya, tetapi kadang-kadang bagian dari apa yang mendefinisikan baik adalah seberapa cepat penyelesaiannya. Jadi tidak benar menganggap "baik" dan "cepat" sebagai pilihan yang berlawanan. Atau untuk berpikir Anda melakukan pekerjaan yang buruk, atau hanya "monyet kode", untuk melakukan pekerjaan sebaik mungkin dalam waktu yang tersedia.

Tentu saja, sangat mungkin bahwa prosesnya tidak optimal, dan akan lebih baik dengan sedikit lebih banyak desain di muka. Tes asam akan, apakah cara saat ini melakukan hal-hal menciptakan lebih banyak masalah daripada memecahkan untuk pengguna , atau apakah itu hanya mengganggu pengembang yang harus bekerja seperti itu? Jika itu benar-benar menyebabkan masalah bagi pengguna, bagian dari pekerjaan Anda adalah mencoba untuk menunjukkan bahwa inilah masalahnya, dan mencoba untuk memenangkan orang ke proses yang sedikit lebih terkontrol.

Sebenarnya, ini menggangguku. Anda berada dalam profesi di mana Anda mengembangkan alat untuk ilmuwan riset, benar. Namun, Anda diperintahkan untuk membuat program ini cepat dan membuatnya berfungsi minimal. Kejutan kejutan. Ini hanyalah pendekatan khas peneliti untuk pemrograman dengan uang yang diteruskan ke programmer yang sebenarnya.

Perhatian utama di sini adalah bahwa kurangnya pengujian pada khususnya dapat secara etis meragukan jika alat memiliki tujuan penting. Jika seseorang tidak yakin perangkat lunaknya cacat karena terbatas pada waktu pengujian minimal, ini berarti TIDAK ADA yang bertanggung jawab atas kondisi kerja perangkat lunak tersebut, dan Atlas mengangkat bahu.

Mari kita berhenti dan memikirkan ini sebentar. Alat apa yang Anda kembangkan? Jika Anda mengembangkan perangkat lunak yang memodelkan data, ada dilema etika yang besar di sini. Dalam beberapa situasi, penelitian ilmiah mengarah pada keputusan yang memengaruhi banyak orang dalam skala besar.

Misalkan sesaat, topik kontroversial perubahan iklim buatan manusia. Katakanlah mereka menempatkan standar yang sama pada perangkat lunak pemodelan yang mereka gunakan untuk sampai pada kesimpulan yang mereka miliki saat ini. Topik ini memiliki dampak besar pada cara kami mengelola lingkungan dengan benar, dan kebijakan internasional.

Apakah tidak etis untuk memastikan bahwa perangkat lunak pemodelan tidak memiliki masalah besar dengan prediksinya?

Seluruh masalah bukanlah gas rumah kaca yang menghangatkan bumi. Masalahnya adalah apakah hasil bersih dari efek umpan balik adalah kenaikan suhu yang dipercepat, yang setelah menembus ambang batas tidak akan lagi dapat dibalikkan.

Jika keuntungan tersebut terjadi, bukti hasil bersih akan menjadi marjinal, mungkin dalam kisaran err.

Jadi, sedikit salah perhitungan, bahkan metodologi yang melibatkan penyimpanan dan pengambilan data di bagian belakang, dapat mengakibatkan mengabaikan masalah lingkungan yang serius pada satu ujung kegagalan, atau kebijakan internasional yang memengaruhi banyak orang (menghancurkan pekerjaan, menghancurkan pensiun, dll. ) di sisi lain.

Jadi, ya, Anda benar. Saya tidak peduli apa kecepatan penelitiannya ... Jika para peneliti ingin mengandalkan alat perangkat lunak untuk mengelola data dan melakukan perhitungan untuk mereka, mereka perlu belajar untuk menunggu perangkat lunak dilakukan dengan benar. Kalau tidak, perangkat lunak ini menjadi titik kelemahan dalam teori mereka bahwa mereka tidak bertanggung jawab, yang mengakibatkan pelanggaran etika.

Anda tidak memiliki gagasan yang salah tentang apa itu rekayasa perangkat lunak. Namun, Anda kehilangan aspek yang sangat penting: ini adalah industri jasa. Beberapa dari kita dapat mengerjakan produk selama bertahun-tahun, dan melalui desain dan kemudian banyak iterasi sebelum di v1. Yang lain harus menghasilkan sesuatu dalam 3 jam. Itu tergantung pada siapa yang Anda layani dan apa tujuannya.

Jika Anda dapat menghasilkan aplikasi dalam 3 jam (atau berhari-hari) yang melakukan apa yang seharusnya dilakukan, mengapa menghabiskan lebih banyak waktu untuk merancang di muka? Anda hanya membuang-buang uang. Membuang-buang uang pada umumnya bukan Ide Bagus ™.

Seperti yang telah dikatakan orang lain, sebagian besar dari rekayasa perangkat lunak adalah "kendala ekstrinsik". misalnya. Waktu, anggaran, layanan, dukungan, pemenuhan tuntutan idiot irasional, dll.

Banyak dari kita (termasuk saya) masuk ke pemrograman berpikir itu semua tentang pemrograman itu sendiri - coding perangkat lunak yang indah dan elegan dalam ruang hampa (atau setidaknya vakum relatif). Ini jarang terjadi. Mungkin ada beberapa pekerjaan akademis atau R&D yang jarang terjadi, tetapi sebagian besar pekerjaan pengembangan perangkat lunak tidak seperti itu. Terutama dalam tahap pemeliharaan - yang biasanya 90% seumur hidup produk - dan rutinitas roti dan mentega setiap hari dari sebagian besar pekerjaan perangkat lunak komersial permanen.

Untuk waktu yang lama, saya mengalami konflik internal tentang hal ini yang sering membuat saya tidak senang dengan pekerjaan saya (dan itu adalah bagian dari apa yang akhirnya menyebabkan kelelahan tahun lalu). Saya selalu merasa bahwa pekerjaan itu menyebalkan jika ini bukan soal membuat kode yang indah dan meluangkan waktu untuk melakukannya dengan benar. Tapi sungguh, inilah kenyataannya - dan beberapa orang benar-benar berhasil dalam alur kerja yang sangat berorientasi layanan. Itulah yang membuat mereka merasa pragmatis dan bermanfaat. Bahkan jika sebenarnya "rekayasa perangkat lunak murni" aspek proyek mendapatkan relatif terburu-buru dan ceroboh.

Bagaimanapun, ada baiknya Anda mempertanyakan ini sekarang. Ini adalah salah satu hal yang mereka tidak pernah jelaskan dengan benar di sekolah. Dan perusahaan suka berpura-pura bahwa mereka mengikuti praktik rekayasa yang sangat baik bahkan jika mereka tidak melakukannya. Petunjuk: kebanyakan tidak.

Semua yang dikatakan, semuanya berbeda. Perusahaan-perusahaan tertentu (kebanyakan dari mereka yang memiliki perangkat lunak adalah bisnis inti mereka, dan mereka yang bekerja dengan perangkat lunak yang sangat kritis terhadap keselamatan seperti peralatan medis) mengikuti proses rekayasa yang sangat ketat. Tapi secara keseluruhan, ya, saya akan memberitahu Anda sekarang bahwa sebagian besar pekerjaan perangkat lunak komersial relatif ceroboh. Biasanya ada beberapa proses formal, tetapi mengikutinya dengan ketat hampir selalu membutuhkan kursi belakang untuk bereaksi terhadap input klien dan tekanan komersial lainnya. Ini tidak benar-benar "kecerobohan" per se, itu hanya kegunaan pragmatis. Triknya adalah menemukan ceruk pasar Anda, dan melihat peran dari sudut pandang layanan apa yang disediakannya, daripada seberapa keren aspek "pemrograman murni" itu.

EDIT : Saya pikir saya mungkin terdengar terlalu sepihak dalam penilaian awal saya. Saya ingin menambahkan bahwa sering ada yang juga masalah asli dengan hal-hal yang terlalu ceroboh, dan kurang dari proses yang baik - ke titik di mana itu mengemudi proyek menjadi utang teknis dan sebenarnya buruk bagi bisnis. Tetapi melihat ini datang dengan pengalaman. Poin awal pada dasarnya masih berlaku: sebagian besar pekerjaan perangkat lunak komersial saat ini tidak berorientasi pada rekayasa kaku seperti yang diinginkan oleh para puritan.

Pertanyaan yang sangat bagus! Terkadang Anda bisa membuat sesuatu yang berharga dengan menjadi cepat . Ini biasanya terjadi di laboratorium penelitian di mana semakin cepat kita dapat mempelajari apa yang tidak kita ketahui, semakin baik kita. Perangkat lunak yang Anda hasilkan hanya ada untuk menjawab pertanyaan. Itu adalah "membuang kode". Ini juga terjadi pada startup yang tidak tahu apa yang sebenarnya diinginkan pelanggan. Juga, saat pertama kali Anda membuat sesuatu, itu akan jelek. Baca The Mythical Man-Month .

Terkadang Anda bisa membuat sesuatu yang berharga dengan menjadi baik . Ini biasanya terjadi pada perangkat lunak yang menyusut seperti Adobe Photoshop. Penelitian telah dilakukan bertahun-tahun lalu dan sekarang pertanyaannya adalah bagaimana menambahkan daftar fitur yang diinginkan pelanggan dengan cara yang tidak menimbulkan bug. Ini adalah masalah arsitektur, desain, dan pengujian, pengujian, pengujian. Kode itu sendiri adalah apa yang berharga, bukan apa yang Anda pelajari darinya.

Jika Anda tidak senang dengan penelitian (membuat yang pertama dari sesuatu, mempelajari hal-hal baru yang tidak ada yang tahu sebelumnya) maka cobalah perangkat lunak yang dibungkus menyusut. Bahkan, pada usia Anda, Anda harus mencoba sebanyak mungkin hal. Ambil risiko! Anda akan belajar banyak dan Anda akan menjadi lebih baik dalam jangka panjang.

Saya pikir Anda sudah memperhatikan sejak awal karir Anda bahwa melakukan sesuatu dengan cepat, tanpa desain yang tepat atau pengujian yang tepat, cenderung kembali menggigit Anda. Anda jelas tidak suka ini dan Anda punya alasan kuat untuk tidak melakukannya. Sangat konyol untuk diharapkan "menyelesaikan masalah", terutama jika Anda harus mengunjungi mereka nanti ketika solusi awal salah atau tidak lengkap. Anda hanya dapat memberikan solusi untuk masalah jika Anda memahaminya sepenuhnya, dan itu membutuhkan waktu dan perencanaan yang matang.

Saran saya kepada Anda adalah memberi tahu atasan Anda bahwa ini mengganggu Anda dan menyarankan mereka pendekatan yang lebih baik untuk melakukan pekerjaan Anda. Jika mereka tidak setuju dan ingin Anda terus "terburu-buru" melalui pekerjaan Anda, saya akan mulai mencari pekerjaan di tempat lain. Tidak ada gunanya melakukan sesuatu dengan cara yang tidak sesuai dengan standar Anda sendiri, apalagi standar kualitas pengembangan perangkat lunak yang diharapkan industri.

Berikut adalah saran saya berdasarkan pengalaman saya, saya 20 dan saat ini di penempatan bekerja untuk lembaga keuangan utama di Inggris dan memiliki perasaan yang sama seperti yang Anda miliki beberapa bulan yang lalu, yang saya perhatikan adalah bahwa ini mungkin disebabkan oleh sifat pekerjaan yang Anda lakukan.

Yang saya maksud dengan itu adalah Anda berkata:

"Apa yang harus saya lakukan adalah membuat beberapa alat internal menggunakan campuran teknologi - terutama AWS / Java / Bash"

Saya juga harus membuat alat internal untuk membantu mengelola dan mengotomatisasi proses tertentu dan faktanya adalah bahwa dalam lingkungan yang serba cepat, hal-hal kecil diperlukan untuk diimplementasikan dengan cepat. Saya tidak memiliki kemewahan menerapkan sebagian besar rekayasa perangkat lunak atau algoritma dan prinsip-prinsip struktur data yang saya pelajari di tahun ke-2 saya karena versi kerja dari alat ini diperlukan dalam beberapa minggu. Saya sangat frustrasi dengan ini, tetapi itu tidak semuanya buruk karena saya belajar menulis kode yang lebih baik dan lebih mudah dibaca.

Saya harus bersabar dan saya baru-baru ini dirotasi ke tim baru yang sedang mengerjakan iterasi baru sistem in-house yang digunakan oleh pengguna 10K + dan saya dapat meyakinkan Anda bahwa aspek rekayasa perangkat lunaknya sangat serius. Saya telah diberitahu bahwa saya akan mendapatkan paparan siklus hidup perangkat lunak yang lengkap dari penangkapan / analisis persyaratan hingga implementasi dan pengujian. Saya percaya saya akan mendapatkan pengalaman ini karena saya tidak bekerja pada alat internal tetapi saya sedang bekerja pada sistem skala penuh dengan basis pengguna yang besar.

Apa yang saya sarankan adalah Anda bersabar, selesaikan membuat alat dan lakukan pekerjaan dengan sangat baik sehingga penyelia Anda mendapatkan kepercayaan lebih pada Anda dan berikan tugas yang lebih menantang kepada Anda yang membutuhkan penggunaan prinsip-prinsip rekayasa perangkat lunak. Dapatkan pengetahuan tambahan dari melakukan beberapa bacaan ekstra dan terapkan pengetahuan itu pada apa yang sedang Anda lakukan, saya ingat menggeledah seluruh perpustakaan e-book di perusahaan hanya untuk menambah pengetahuan saya muhahah, dari semua buku yang saya baca saya merasa bahwa java yang efektif adalah buku yang sangat bagus yang banyak membantu saya.

Bersabarlah, berinvestasi dalam pengetahuan Anda sendiri dan menerapkan pengetahuan itu jika memungkinkan. Jika Anda melakukan pekerjaan yang sangat baik, seseorang akan segera melihat.

Saya setuju bahwa cara kerja Anda saat ini beroperasi di bawah optimal, ya. Namun, jika Anda ingin mengatakan bahwa itu tidak berfungsi sama sekali, saya tidak setuju dengan Anda di sana karena ada berbagai hasil dan institusi masih ada.

Pertanyaan utama saya kembali kepada Anda adalah sejauh mana Anda menangani kebakaran yang memerlukan solusi segera yang dilakukan dengan cepat mirip dengan memberikan pertolongan pertama pasien medis versus permintaan yang dapat ditetapkan sebagai proyek dan ditangani pada skala yang jauh berbeda dengan pasien medis harus menjadwalkan tes dan berbagai prosedur yang tidak perlu dilakukan segera tetapi dalam waktu dekat.

Meluangkan waktu untuk melakukan pekerjaan dengan baik tergantung sedikit pada kematangan organisasi bersama dengan seberapa pentingkah sesuatu itu dilakukan dengan baik versus klaim telah dilakukan.

Pertanyaan tentang meneliti struktur data adalah berapa lama ingin melakukan ini. Jika Anda ingin mengambil satu dekade untuk meneliti struktur data yang sangat berbeda dari menginginkan beberapa jam. Meskipun saya dapat menghargai keinginan untuk mendapatkan jawaban terbaik, ada sesuatu yang bisa dikatakan untuk pengembalian yang berkurang setelah menghabiskan waktu untuk suatu masalah, misalnya bisakah Anda menghabiskan berjam-jam mencari solusi untuk FizzBuzz karena Anda dapat mencoba menyelesaikannya dalam berbagai bahasa di berbagai perangkat keras untuk mengoptimalkan seberapa cepat dapat berjalan.

Meskipun penting untuk meneliti, penting juga untuk menyampaikan sesuatu. Jika Anda tidak memberikan sesuatu, seberapa baik Anda sebenarnya? Duct Tape Programmer akan menjadi lebih banyak contoh tentang menyelesaikan berbagai hal di sini.

Scrum adalah metodologi khusus yang mungkin bisa Anda coba adopsi di tempat kerja Anda saat ini. Jangan berpikir Scrum adalah peluru perak. Dalam Keadaan Apa Proyek Dapat Di Bawah Scrum Dan Agile Gagal? akan menjadi posting blog tentang hal itu yang mungkin menarik.

Dugaan saya adalah bahwa Anda tidak melihat seberapa informal proses tempat Anda saat ini dan berpikir rumput jauh lebih hijau di sisi lain di mana ada metodologi formal. Meskipun mungkin lebih baik di sana, beberapa orang mungkin lebih suka apa yang Anda miliki sekarang dengan kebebasan besar untuk menjadi seorang koboi .

Saya pikir situasi Anda masih pada skala Dunia Nyata ke arah kurang penekanan pada sisi kualitas. Preferensi Anda ada di ujung dunia nyata. Spesifikasi berubah, lupakan saja. Hal-hal perlu diselesaikan.

Pertimbangkan cara untuk mengidentifikasi jenis-jenis perusahaan ini ketika Anda melamar pekerjaan Anda berikutnya. Beberapa tempat memiliki model bisnis di mana mereka mampu membuat pengembang menganalisis desain mereka selamanya (Bahkan profesor harus mengajar.). Klien jarang membayar jika pekerjaan Anda tidak meninggalkan papan penghapusan kering. Benci melihat Anda membuat diri Anda gila sejak awal karir Anda.