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


15

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?


7
Pertimbangkan untuk meneliti terlebih dahulu mengapa hal ini terjadi. Mungkin ada alasan bagus yang belum Anda pelajari.

Seperti negara lain, mungkin alasan yang bagus - ingat ini mungkin diberikan kepada Anda karena prioritasnya rendah. Mereka tidak punya waktu / anggaran untuk menulis ulang setiap proyek yang Anda kerjakan, belajar merusak - semua orang mungkin punya.
Jonno

2
Perlu diingat bahwa solusi apa pun yang Anda usulkan harus memenuhi 2 dari 3 kondisi berikut: bagus, cepat, murah. Sepertinya Anda hanya mengusulkan apa yang menurut Anda "baik". Saya tidak melihat rekomendasi Anda cepat atau murah untuk perusahaan, jadi Anda akan kesulitan meyakinkan orang-orang yang diharapkan membayarnya.
Joel Etherton

1
Saya tidak tahu mengapa Anda memiliki refactor dan penulisan ulang seolah-olah keduanya sama. Mereka tidak.
CaffGeek

Saya tahu mereka tidak, tetapi jika Anda melihat aplikasi Anda akan tahu betapa miripnya mereka dalam konteks ini
7983879342

Jawaban:


5

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.


Saya pikir saya akan tetap pada ini. Saya akan mencoba untuk membersihkannya sedikit sebelum saya pergi, tetapi sepertinya perubahan besar tidak akan diterima.
7983879342

Maaf terdengar sangat keras pada subjek, tetapi, refactoring bisa sangat sulit dan kecuali Anda dapat menunjukkan manfaat nyata bagi pengguna Anda, ini cukup berterima kasih.
James Anderson

22

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.


11
+1, terutama untuk "di dunia profesional, hanya karena ada sesuatu yang salah diterapkan bukan berarti itu rusak"
StuperUser

4
+1 dan sebaliknya ... hanya menjadi sesuatu yang diimplementasikan dengan benar bukan berarti itu berfungsi.
Joel Etherton

11

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.


1
+1 untuk manfaat rendah dalam penulisan ulang utama aplikasi internal yang digunakan rendah. Waktu Anda bisa lebih menguntungkan digunakan di tempat lain (kecuali jika mereka ingin menggunakan ini sebagai latihan untuk Anda)
uɐɪ

10

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.


4

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.


2

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.


2

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.


1

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.


0

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.


0

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.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.