Saya saat ini sedang magang dibayar, dan telah ditugaskan untuk mempertahankan sistem usang yang telah dikembangkan oleh beberapa pengembang (pada waktu yang berbeda) selama 5 tahun terakhir. Manajemen menyetujui "sistem ini mendukung hidup", dan saya menerima persediaan laporan bug yang cukup teratur dari pengguna akhir yang saat ini menggunakan sistem.
Manajemen sekarang ingin memperpanjang proyek untuk satu tahun lagi, dan dalam proses hampir tiga kali lipat basis pengguna.
Sebagai pekerja magang (atau posisi level pemula) bagaimana cara "mendorong kembali"? Saya sudah menulis laporan yang menyatakan keprihatinan saya, meskipun dalam dokumen terbuka. Apakah ada protokol atau tipe dokumen untuk menyarankan perubahan? Apakah saya dalam posisi untuk membuat saran, atau haruskah saya terus mendukung sistem yang lama?
- Untuk memperjelas, pengembangan perangkat lunak bukan bisnis utama perusahaan saya. Karena itu tidak ada protokol internal. Selain itu, proyek tidak memiliki dokumentasi formal sama sekali, dan tidak ada dokumen persyaratan juga. Pengembangannya sangat ad hoc.
Jawaban:
Sistem ini tidak usang jika orang masih menggunakannya dan itu mendukung kegiatan bisnis. Karena masih digunakan, bisnis tidak bisa begitu saja membuangnya - perlu didukung sampai kebutuhan untuk sistem tidak ada lagi. Itu bisa berupa perubahan tujuan bisnis atau sistem baru telah dikembangkan, diuji, dan disebarkan dengan sukses ke pengguna akhir.
Sungguh, 5 tahun tidak terlalu lama. Saya telah bekerja dengan kode yang berumur 10 tahun sebelumnya. Jika masih melayani kebutuhan pengguna, mengapa membuangnya? Itu membuang banyak uang yang dihabiskan untuk mengembangkannya. Sampai menjadi tidak layak untuk dipertahankan karena meningkatnya biaya atau persyaratan berubah secara drastis, tidak ada alasan bisnis untuk membuangnya.
Jika manajemen mengatakan bahwa sistem ini "mendukung hidup", mengapa mereka mencoba untuk menyebarkannya lebih lanjut? Adalah umum bahwa kegiatan pemeliharaan berlanjut pada sistem warisan sampai diganti, tetapi jika suatu sistem berada di akhir masa pakainya, biasanya tidak digunakan untuk lebih banyak orang. Memperluas pemeliharaan adalah satu hal, tetapi menambahkan pengguna yang mengandalkan sistem adalah situasi yang berbeda secara bersamaan.
Bagi saya, sepertinya itu tidak benar-benar berakhir, melainkan dalam fase pemeliharaan dan akan terus ada sampai sistem tidak lagi melayani kebutuhan pengguna.
Anda harus terus mendukung sistem yang lama. Kemudian, Anda menyebutkan bahwa perangkat lunak bukan bisnis utama perusahaan Anda. Dalam lingkungan seperti itu, tugas tim perangkat lunak adalah mendukung bisnis utama perusahaan. Namun, tim perangkat lunak juga perlu mengingat tujuan bisnis.
Sementara itu, tangkap saran Anda dengan cara yang tidak sombong. Tunjukkan teknologi atau teknik lain yang dapat diintegrasikan dengan sistem atau digunakan jika / ketika sistem baru dibuat dan pro / kontra mereka. Cara Anda melakukannya tergantung pada perusahaan, tetapi mempertimbangkan beberapa poin di kemudian hari, mungkin membangun wiki atau situs kolaboratif lainnya akan bermanfaat.
Dalam bisnis non-perangkat lunak, perangkat lunak adalah biaya dan tim perangkat lunak (terutama proyek perangkat lunak / manajer program) harus bekerja untuk meminimalkan biaya membangun dan memelihara sistem perangkat lunak sebanyak mungkin, sambil mendukung kebutuhan pengguna akhir . Membuang perangkat lunak yang (sejauh yang saya tahu, dari posting Anda, tetap) memenuhi kebutuhan pengguna bertentangan dengan apa yang menjadi kepentingan terbaik tim perangkat lunak.
Bagi saya, ini masalahnya. Tidak memproduksi dokumentasi, tidak mengembangkan ke spesifikasi, dan kurangnya konsistensi cenderung meningkatkan biaya pengembangan perangkat lunak. Bekerja ke arah memperbaiki ini akan menjadi prioritas tertinggi saya, dan saya akan melakukannya dengan mengerjakan hal-hal seperti standar pengkodean, kontrol versi, menghasilkan kode dokumentasi dan dokumen desain mandiri, pelacakan cacat, dan spesifikasi persyaratan.
sumber
I've worked with code that was 10 years old beforeBagaimana sekitar 25 tahun :) Masih memenuhi kebutuhan perusahaan dan melakukan pekerjaan yang luar biasa pada apa yang dirancang untuk dilakukan, meskipun fakta bahwa menyentuh kode itu sama menyenangkannya dengan berenang di Arktik.Baik. Itu tentang sejauh apa yang dapat Anda lakukan sebagai magang. Untuk referensi di masa mendatang ketika menulis laporan seperti itu, saya menekankan penyajian fakta-fakta sulit dengan cara yang tidak memihak dan profesional yang tidak memiliki prasangka emosional. Anda tidak tahu siapa yang akan membaca laporan, mungkin seseorang yang mungkin atau mungkin tidak menyebabkan beberapa masalah yang Anda gambarkan atau membuat keputusan yang mengarah ke masalah ini. Apa pun selain fakta dingin dapat dianggap oleh orang-orang seperti penghinaan, atau pelanggaran dan akan menyebabkan mereka tidak menyukai Anda dan mungkin tidak menganggapnya serius.
Perlu diingat bahwa keputusan bisnis seperti ini dibuat karena mereka berusaha membuat karena dengan sumber daya yang mereka miliki tersedia untuk mereka. Saya yakin bahwa manajemen mungkin menyadari masalah dengan perangkat lunak warisan, dan mungkin menyadari keluhan pengguna, tetapi apakah mereka memiliki sumber daya pengembangan perangkat lunak yang tersedia untuk menangani refactoring atau penulisan ulang?
Sebagian besar waktu mereka tidak, terutama jika perangkat lunak bukan roti dan mentega perusahaan dan kualitas dan kepuasan pengguna dengan perangkat lunak tidak akan secara langsung mempengaruhi garis bawah. Membuat keputusan semacam ini kadang-kadang mengapa menjadi manajer menyebalkan karena Anda sering berada dalam situasi kalah-kalah, apa pun yang Anda lakukan.
Kesalahan dibuat di seluruh proyek yang mengarah ke titik ini. Kurangnya input atau persyaratan pengguna yang solid, kurangnya manajemen produk yang tepat dan kontrol perubahan untuk mengelola perubahan kebutuhan dan kebutuhan, dan kurangnya sumber daya teknis yang memadai untuk mengimplementasikan menyebabkan masalah seperti yang ada saat ini. Saya tidak tahu apakah usang adalah kata yang tepat. Apakah teknologi yang mendasari dibangun di atas kerangka kerja dan teknologi yang tidak didukung, atau apakah itu tidak canggih atau teknologi ideal?
Anda berada dalam posisi paling tidak berkuasa dan Anda hanya sementara waktu. Tidak masalah jika Anda benar, saya tidak akan mengharapkan magang untuk "mendorong kembali" pada saya. Saya berharap mereka belajar, mendiskusikan masalah seperti yang mereka lihat, dan mengikuti perintah. Itu saja. Setelah pesanan diberikan, saya berharap itu dilakukan sesuai kemampuan mereka, karena waktu untuk diskusi selesai pada saat itu.
sumber
Anda seorang magang. Saya sangat meragukan apakah Anda bahkan sangat jauh dengan keharusan bisnis sehari-hari secara keseluruhan dan seperti yang orang lain perhatikan, basis kode 5 tahun tidak terlalu lama.
Keputusan tentang mengganti sistem warisan tidak selalu didorong secara teknis; mereka didorong oleh perubahan persyaratan bisnis. Masukan untuk itu bisa berupa kesulitan yang berkaitan dengan pemeliharaan; tetapi pada akhirnya, Anda perlu menyadari bahwa posisi Anda tidak selalu berarti Anda memiliki semua pengetahuan yang tersedia dan diperlukan. Saya akan mengatakan lebih jauh bahwa Anda sebenarnya hanya memiliki sedikit pengetahuan yang diperlukan untuk melakukan apa yang merupakan langkah terbaik saat ini.
Saran saya kepada Anda adalah ini: belajarlah dari pengalaman dan berhentilah berasumsi bahwa pengetahuan Anda melampaui pengetahuan orang-orang yang harus menjalankan bisnis sehari-hari.
Tugas Anda adalah membuat sistem bekerja, bukan untuk menyarankan pengganti baru yang mengkilap.
Tampak bagi saya bahwa banyak programmer muda tidak menyadari bahwa pemeliharaan sistem yang lebih lama adalah bagian yang lebih besar dari pekerjaan pemrograman daripada merancang sistem baru yang mengkilap /
sumber
Jangan mundur. Satu-satunya hal yang harus Anda lakukan adalah menyuarakan keprihatinan Anda dengan cara yang jelas dan singkat. Faktanya adalah bahwa sebagian besar bisnis di mana Anda akan bekerja di masa depan akan memiliki sistem warisan. Sistem warisan itu perlu dipertahankan karena dalam banyak kasus terlalu mahal untuk diganti.
Dalam banyak kasus Anda bahkan mungkin memiliki niat terbaik untuk mengganti sistem saat ini dengan sistem yang lebih baik, namun, Anda bisa saja memperkenalkan bug baru dan berbeda ... ketika Anda meninggalkan sistem akan dengan cepat berubah menjadi sistem warisan lagi dan perusahaan akan berada di tempat yang sama seperti sebelumnya. Tidak ada yang usang sampai tidak ada lagi server yang tujuannya atau sama sekali tidak kompatibel dengan sistem modern. Perusahaan saya memiliki sistem berumur 20 tahun ke atas yang baru saja kami konversi menjadi ASP.NET. Sistem masih berjalan tetapi dukungan untuk teknologi lama berkurang dan membuatnya bekerja dengan browser web modern menjadi semakin memakan waktu.
Apa yang dapat Anda lakukan:
Biarkan Segala Sesuatu Lebih Bersih
Ketika Anda mempertahankan sesuatu, biarkan lebih bersih daripada saat Anda mulai. perbaiki, tetapi bersihkan juga hal-hal lain sehingga pada saat seseorang perlu melakukan modifikasi, hal itu lebih mudah dipahami.
Buat Dokumentasi
Jika kurangnya dokumentasi merupakan masalah, buat dokumentasi. Ketika Anda sedang mengerjakan bagian tertentu dari sistem, dokumentasikannya.
Buat Itu Kurang Menyakitkan
Seperti yang saya katakan, Anda dapat menyuarakan keprihatinan Anda, tetapi hasil terbaik Anda hanya bekerja dengan rajin pada sistem dan membuatnya lebih baik untuk bekerja untuk orang-orang setelah Anda. Perbaiki bug dengan benar. Dokumen. Membubarkan bau kode. Membuatnya lebih baik. Dan ketika Anda melakukan hal-hal ini, beri tahu atasan Anda. Katakan kepada mereka bahwa Anda melakukan X, Y dan Z untuk meningkatkan proses pengembangan. Itu membangun kredibilitas dan dalam jangka panjang akan membantu Anda dan perusahaan Anda lebih dari apa pun.
sumber
ANDA TIDAK !!! Ini adalah Peluang BESAR!
Anda magang untuk belajar! Proyek ini adalah dunia nyata.
Anda sangat beruntung memilikinya. Fakta bahwa Anda tidak memenuhi syarat bukanlah urusan Anda. (Jika \ ketika manajemen menyadari ini, Anda akan mendapatkan banyak)
ANDA akan memenuhi syarat setelah Anda selesai dengan magang ini, Dan itu berita bagus.
PS: Buat cadangan secara religius, pastikan APA SAJA yang Anda lakukan dapat dibatalkan. Mulailah dengan Masalah yang merupakan "Perbaikan mudah" Tapi poin rasa sakit yang besar bagi pengguna. Ambil langkah kecil.
sumber
Saya kira, dalam pengertian yang sangat teoretis - tidak ada yang namanya sistem Legacy . Saya memiliki telepon yang sangat tua (sistem warisan), dan hari ini ada telepon android yang bagus (platform modern), tetapi telepon saya berfungsi dan melakukan apa yang saya butuhkan. Mengapa saya harus membuangnya?
Semua sistem yang Anda sebut "warisan" hari ini, pada suatu hari adalah yang paling canggih. Hanya waktu yang kita butuhkan. Juga, ketika ada pekerjaan yang cukup besar di tempat, itu tidak melakukan hal-hal yang sama sekali lagi di platform modern, berarti itu akan secara otomatis bebas bug (atau bebas rasa sakit).
Inilah yang saya sarankan Anda harus lakukan:
Tinggalkan ketidaksukaan Anda terhadap "sistem warisan" terlebih dahulu. Ini akan membuat Anda sangat kontra produktif.
Mulailah mendokumentasikan apa yang Anda lakukan sekarang dan apa yang Anda pikirkan. Meskipun secara bertahap. Tidak ada waktu yang lebih baik untuk melakukan dokumentasi daripada saat Anda menyadari bahwa Anda membutuhkannya.
Alih-alih mencoba Push-back memajukan "sistem warisan" - cobalah untuk menentukan jalur untuk keluar dengan lancar. Cobalah untuk melihat bahwa Anda dapat meyakinkan manajemen bahwa pengembangan baru yang dapat diisolasi, dapat dilakukan langkah demi langkah dalam bentuk plat baru tanpa memutus interoperabilitas dengan sistem lama. Perlahan (dan ini akan menjadi sangat lambat) ketika hal-hal berkembang, kebutuhan untuk menjaga sistem warisan akan hilang. Itulah satu-satunya cara untuk mengucapkan selamat tinggal pada sistem lama.
Dipan.
sumber
Kebenaran adalah tidak ada yang memberi pekerja magang pekerjaan yang ingin mereka lakukan. Ketika Anda adalah orang yang paling junior, Anda mendapatkan pekerjaan yang paling tidak menyenangkan. Seberapa baik Anda secara pribadi menangani itu mengatakan banyak kepada organisasi, apakah mereka dapat mempercayai Anda untuk melakukan lebih banyak pekerjaan yang menarik.
Jadi di sini adalah kesempatan yang tak ternilai untuk menunjukkan bahwa Anda dapat mengirimkan dengan melakukan perbaikan bug, bahwa Anda dapat melakukan refactor dengan membuat setiap bagian dari kode yang Anda sentuh sedikit lebih baik, bahwa Anda dapat membuat unit test, dengan mulai membuat mereka untuk sistem ini. dan bahwa Anda dapat mendokumentasikan dengan membuat dokumentasi untuk jiwa miskin berikutnya yang terjebak dengan sistem ini. Ini juga memberi Anda kesempatan untuk menunjukkan bahwa Anda dapat menangani pengguna secara efektif (untuk mendapatkan detail lebih lanjut tentang bug yang dilaporkan) dan memenuhi kebutuhan mereka. Jika proyek tidak sekarang dalam kontrol sumber, letakkan di sana dan jika bug tidak dilacak dalam pelacak bug, kemudian mulai satu. Jenis tindakan ini akan menunjukkan Anda tahu cara bekerja secara profesional.
Atau Anda bisa mengambil jalan yang berlawanan dan hanya mengeluh tentang seberapa buruk proyek itu dan betapa kerennya untuk menggantinya. Dalam hal ini, Anda hampir pasti tidak akan ditawari pekerjaan di perusahaan itu setelah magang.
sumber
Anda mungkin tidak memiliki informasi yang cukup untuk menentukan apakah biaya efektif untuk satu tahun lagi atau tidak. Akan menarik untuk memahami perusahaan dan mengapa mereka menambahkan pengguna. Sepertinya mungkin ada beberapa pertumbuhan yang terjadi dan mereka tidak mampu mengambil langkah mundur secara finansial atau dalam batasan waktu tertentu untuk membangun aplikasi lain. Membangun aplikasi baru jarang merupakan pilihan terbaik. 5 tahun tidak setua itu kecuali mereka membangunnya dengan teknologi lama.
sumber