menyarankan perubahan besar / penulisan ulang sebagai pegawai magang [ditutup]

Isi:

• ini adalah proyek internal (yang saya pikir tidak banyak orang gunakan)
• ini sudah tua
• kami memperbaruinya

Masalah:

1. itu menyalahgunakan kerangka MVC (tidak menggunakan model, logika bisnis dalam tampilan, dll)
2. apa yang diminta adalah kecil, tetapi karena kohesi yang rendah, kami memiliki dua opsi:
   1. terus merusak barang-barang
   2. pindahkan potongan besar kode di sekitar atau menulis ulang hal itu

Solusinya (saya mengerti):

1. terus bekerja dengannya, abaikan praktik terbaik agar tidak segera dilakukan dan tidak memperkenalkan bug baru dengan refactoring / penulisan ulang
2. refactor / menulis ulang

Saya kira pertanyaan saya benar-benar: jika saya ingin membuat perubahan besar pada proyek ini, bagaimana saya mengusulkan itu tanpa menghina siapa pun? Atau akan lebih baik bagi saya untuk mengikuti arus meskipun itu kadang-kadang berarti (metaforis) lakban?

Baiklah, ini dia.

Anda pikir aplikasi ini terstruktur dan ditulis dengan buruk.

Pelanggan berpikir itu berhasil.

Anda ingin menulis ulang tanpa alasan lain selain untuk meningkatkan "keindahan internalnya".

Jadi Anda meminta pelanggan untuk mengeluarkan uang untuk mendapatkan aplikasi untuk melakukan apa yang dilakukannya sekarang - hanya bagian-bagian yang tidak dilihat atau dipahami oleh pengguna akan menjadi "lebih baik".

Keberatan utama terhadap kode terstruktur yang ditulis dengan buruk adalah sulit dipahami.

Kode ini sulit dipahami dan memiliki fungsionalitas dan fitur yang hanya dapat dengan mudah diimplementasikan dalam aplikasi yang terstruktur dengan buruk. Jadi, kecuali Anda sangat pandai dalam hal ini, aplikasi baru tidak akan melakukan persis seperti apa yang dilakukan aplikasi saat ini, dan, karena Anda tidak sepenuhnya memahami apa yang dilakukan kode asli, mungkin akan melakukan kesalahan.

Jadi pelanggan Anda sekarang telah menghabiskan banyak uang untuk mendapatkan aplikasi yang jauh lebih buruk daripada aplikasi asli. Anda tidak akan menjadi populer!

Untungnya, perguruan tinggi Anda yang lebih berpengalaman siap untuk menghibur Anda (mungkin karena mereka membuat kesalahan yang sama ketika mereka memulai, dan, bahkan mungkin memiliki ketidakberuntungan untuk mendapatkan persetujuan manajemen untuk proyek yang ditakdirkan seperti itu).

Jadi saran saya adalah menjaga agar basis kode lama tetap berjalan, dan, tetap diam. Pelanggan hanya menginginkan sistem yang berfungsi mereka tidak terlalu peduli jika Anda menganggap kodenya jelek.

Usulkan perubahan Anda. Jadilah yang jelas tentang kasus bisnis untuk setiap: Mengapa akan diusulkan Anda perubahan bantuan sistem secara keseluruhan? Jika tidak, harap dorong kembali. Mengapa menghabiskan uang memperbaiki sesuatu yang tidak rusak? Alasan seperti membuat sistem lebih dapat diperluas dan pemisahan kekhawatiran mungkin valid (tergantung pada siapa yang Anda ajak bicara), tetapi 99% dari waktu, hanya mengatakan "itu tidak diterapkan dengan benar" akan membuat Anda ke mana-mana. Pastikan bahwa Anda menambahkan nilai pada proyek dan tidak hanya mengusulkan membuat pekerjaan (bahkan jika itu membersihkan kode).

Sayangnya, di dunia profesional, hanya karena sesuatu telah dilaksanakan salah tidak berarti bahwa itu rusak, dan karenanya tidak perlu diperbaiki. Juga, dalam memperbaikinya, Anda dapat memperkenalkan masalah knock-on yang tidak terduga yang dapat berdampak pada area lain dari proyek.

Membaca pertanyaan Anda, saya sebenarnya ragu bahwa menulis ulang aplikasi tidak sia-sia. Mungkin Anda tidak repot-repot membuat kasus lengkap dalam pertanyaan Anda. Tetapi seberapa besar manfaat menulis ulang sebanding dengan biayanya jika itu merupakan aplikasi internal yang lama dan jarang digunakan? Biaya penulisan ulang kemungkinan lebih dari jumlah semua pembaruan dan tambalan yang pernah ada.

Jika Anda pikir itu tidak benar, Anda perlu membuat lebih banyak kasus untuk itu daripada yang Anda lakukan di sini.

Sedangkan untuk meningkatkan aplikasi, Anda mungkin memiliki beberapa kesempatan untuk sedikit refactoring yang terjadi secara alami selama pembaruan Anda.

Anda seorang magang. Agaknya, Anda baru. Mereka mungkin mencurigai Anda karena idiot.

Jadi saat Anda membuat saran, melangkahlah dengan ringan . Bersikaplah rendah hati dan sederhana. Biarkan ide-ide Anda mengalir secara percakapan saat Anda mengizinkan anggota lain untuk juga mendiskusikan ide-ide mereka sendiri tentang basis kode dan tekanan apa yang mungkin mereka alami (mungkin ada alasan yang sangat bagus mengapa upaya belum dilakukan untuk membersihkan semuanya).

Anda ingin mendapatkan kepercayaan mereka. Anda melakukan ini dengan menulis kode yang baik untuk tugas yang diberikan. Tulis dengan bersih, gunakan praktik terbaik yang ingin Anda terapkan, tetapi hanya pada apa yang ditugaskan untuk Anda lakukan. Ini mungkin hal-hal kecil, hal-hal yang mungkin dianggap tidak penting oleh anggota tim lainnya. Lakukan hal-hal itu dengan baik. Cerahkan sudut di mana Anda berada, dan ketika tim datang untuk meninjau kode Anda dengan baik, ide-ide Anda pada gilirannya juga akan tumbuh tinggi.

Akhirnya , saat Anda menunjukkan kompetensi dan pengetahuan Anda, Anda mungkin dapat memberikan satu atau dua saran.

Saya benar-benar akan membuat saran ini, tetapi hanya untuk sesama pengembang . Saya tidak akan membahasnya dengan manajemen, seperti yang saya bayangkan manajemen akan melihat itu sebagai semacam melangkahi batasan.

Setelah membuat saran kepada pengembang yang bekerja dengan Anda, mereka mungkin akan memiliki beberapa alasan bagus mengapa basis kode itu mengapa demikian. Alasannya bisa berkisar dari "tidak, sebenarnya kodenya baik-baik saja, Anda hanya tidak mengerti MVC (dan itulah sebabnya Anda magang)" hingga "itu ide bagus, mari kita arsitekkan aplikasi baru bersama-sama!"

Perlu diingat bahwa jawaban untuk refactoring aplikasi ini kemungkinan besar adalah tidak; Saya tidak akan pernah ingin magang mengambil alih penulisan ulang aplikasi internal (apa yang terjadi ketika magang Anda selesai dan penulisan ulang hanya setengah jadi?) Plus, mungkin ada hal-hal yang lebih penting yang bisa Anda kerjakan daripada mencari-cari aplikasi internal .

Tetapi tidak ada salahnya untuk bertanya pada rekan-rekan Anda, dan jika Anda melakukannya, Anda akan belajar sesuatu. Dan itu, 7983879342, adalah tujuan magang.

Apa pun yang terjadi, saya harap Anda mengambil pesan berikut. Seperti beberapa tanggapan di atas menunjukkan kadang-kadang kode menulis ulang, untuk alasan teknis terbaik kadang-kadang tidak layak karena alasan bisnis / biaya. Terlalu banyak programmer hidup dalam solusi teknis dan menolak untuk mempertimbangkan bahwa pencarian pribadi mereka untuk keanggunan teknis / keterbacaan / praktik terbaik harus seimbang dengan kebutuhan bisnis untuk menyelesaikan sesuatu. Dalam pengalaman pribadi saya, orang yang tidak mencapai keseimbangan itu (dari arah manapun) sering dianggap sebagai pertanggungjawaban dalam tim.

Namun, jangan berhenti mempertanyakan hal-hal, bahkan jika Anda mendapatkan beberapa pukulan, itu adalah cara kita belajar dan tumbuh.

Jawaban lain telah banyak berbicara tentang politik situasi Anda, dan saya cenderung setuju. Kecuali Anda dapat menyajikan kasus bisnis yang menarik, menulis ulang mungkin tidak ada di kartu.

Namun, itu tidak berarti bahwa Anda harus melupakan Aturan Pramuka :

Selalu tinggalkan perkemahan lebih bersih daripada yang Anda temukan.

Jika saat Anda mengimplementasikan sesuatu pada basis kode ini, Anda dapat mencari cara untuk membersihkan beberapa aspek dari desain atau implementasi, maka itu adalah sesuatu yang harus Anda pertimbangkan. Anda mungkin tidak perlu menulis ulang seluruh aplikasi untuk memanfaatkan model MVC dengan lebih baik, dan jika Anda menerapkan beberapa logika bisnis baru untuk tampilan tertentu, Anda dapat mempertimbangkan untuk memindahkan logika dari tampilan lama ke dalam model. dan menambahkan logika baru Anda untuk itu.

Seperti yang telah dinyatakan orang lain, minta pengembang lain (yang akrab dengan aplikasi ini) untuk melakukan langkah-langkah cepat hanya agar Anda dapat memahami bagaimana / mengapa implementasinya. Jelaskan bahwa sementara Anda dapat memahami aspek teknologi, tetapi Anda ingin dapat menghubungkan titik-titik dengan persyaratan bisnis (persyaratan bisnis mengalahkan semua).

Setelah Anda memiliki informasi ini, Anda dapat melakukan evaluasi. Jika Anda secara pribadi berpikir bahwa itu harus ditulis ulang, tetapi jangan berpikir orang lain akan melihatnya sebagai penggunaan waktu yang baik, anggap itu sebagai proyek pribadi. Bahkan jika satu jam di sini / di sana ketika Anda memiliki waktu henti, lakukan implementasi dengan "benar". Setelah Anda selesai, berikan ke pengembang lain sebagai "hei, saya merasa seperti ini bisa menggunakan beberapa pembersihan, jadi saya melakukan beberapa pekerjaan sampingan selama waktu tidak aktif. Bagaimana menurut Anda?" Jangan menekan perubahan pada mereka - hanya menawarkan kepada mereka sebagai "hei, kalian suka ini?" dan pergi dari sana.

Sebagian besar perubahan terjadi secara bertahap, sebagai aturan umum.

Beberapa hal yang perlu diingat;

• Bagaimana sejarah aplikasi?
• Mengapa hari ini jelek?
• Apa manfaat dari perubahan arsitektur?

Strategi yang baik adalah mengerjakan hal-hal kecil dan mengajukan banyak pertanyaan tentang hal-hal (pertanyaan yang tidak dapat Anda pelajari dari Google atau sumbernya, jangan buang waktu orang). Setelah Anda merasa nyaman dengan basis kode dan pengembang, Anda harus merasakan mengapa kode itu seperti itu. Terkadang, hanya, "Ya, kami harus meretas sesuatu bersama-sama dan mendorongnya keluar pintu". Jika Anda dapat mengusulkan perubahan ringan pada bagian kecil dari sistem yang terjadi saat Anda melakukan pekerjaan normal Anda, itu akan mendapatkan lebih banyak daya tarik daripada penulisan ulang radikal.

Tidak ada salahnya menyarankan penulisan ulang jika Anda bertanya dengan baik dan membuat kasus logis (bukan hanya firasat atau cara yang lebih baik untuk melakukannya). Ada kemungkinan besar bahwa menulis ulang aplikasi yang digunakan akan dijatuhkan, dan ada peluang bagus bahwa siapa pun yang awalnya menulis sistem masih ada (dan lebih tinggi dalam hierarki daripada Anda) dan mungkin tidak menerima kritik.

Jadi jangan katakan, "Kita perlu menulis ulang sistem yang dirancang mengerikan ini yang melanggar prinsip-prinsip dasar MVC", tanyakan sebagai pertanyaan terbuka kepada atasan yang sesuai (orang-orang tepat di atas Anda). Sesuatu seperti "Saya bertanya-tanya apakah menulis ulang sistem dalam model MVC mungkin menghemat banyak waktu dalam jangka panjang. Bagaimana menurut Anda? Saya yakin kita bisa membagi dua waktu pemeliharaan dengan penulisan ulang utama (misalnya 2 minggu) yang menggabungkan model MVC, TDD, dll. dilakukan dan bahwa setelah dua bulan pemeliharaan rutin kami akan mencapai titik impas ". Responsnya mungkin, tidak, kami pikir itu tidak perlu - saya tidak setuju dengan perkiraan waktu Anda dan kemungkinan sistem baru akan menjadi pengganti yang cocok. Atau jawabannya bisa, baik saja, tapi ingat jika sistem baru Anda tidak t bekerja sebagus / lebih baik daripada sistem baru dalam kerangka waktu yang Anda usulkan agar orang menyalahkan Anda. Dan bahkan jika sistemnya sedikit digunakan; mungkin tidak dapat diterima untuk berhenti memperbaruinya dengan perbaikan kecil selama periode penulisan ulang.