Bagaimana saya bisa menjadikan refactoring prioritas untuk tim saya?


57

Basis kode yang saya gunakan sehari-hari tidak memiliki tes otomatis, penamaan yang tidak konsisten, dan banyak komentar seperti "Mengapa ini ada di sini?", "Tidak yakin apakah ini diperlukan" atau "Metode ini tidak dinamai benar" dan kode ini dikotori dengan "Changelogs" meskipun kami menggunakan kontrol sumber. Cukuplah untuk mengatakan, basis kode kami dapat menggunakan refactoring.

Kami selalu memiliki tugas untuk memperbaiki bug atau menambahkan fitur baru, jadi tidak ada waktu yang disisihkan untuk kode refactor menjadi lebih baik dan lebih modular, dan itu tampaknya tidak menjadi prioritas tinggi.

Bagaimana saya bisa menunjukkan nilai refactoring sehingga ditambahkan ke daftar tugas kami? Apakah itu layak untuk sekadar refactor saat saya pergi, meminta pengampunan daripada izin?


Ulasan kode institusi dan masalahnya akan teratasi dengan sendirinya (hampir)
dukeofgaming

4
Jangan memperlakukan refactoring sebagai tugas terpisah - bukan.
Vetle

2
In-code changelogs membuat saya ingin menangis ... Saya minta maaf atas kehilangan Anda.
Mark Canlas

@ Mark Canlas Saya dulu berpikir dengan cara yang sama sampai saya menemukan basis kode berusia 20 tahun dengan ratusan perubahan dalam kontrol sumber. Semoga berhasil menemukan mengapa (atau bahkan jika) blok kode tertentu berubah menggunakan hanya sejarah kontrol sumber
Michael J.

@Michael Apa yang membuatnya sangat sulit? Secara umum, beberapa operasi menyalahkan / membubuhi keterangan harus memberi Anda hak atas komitmen yang relevan, tidak peduli berapa banyak perubahan yang dilakukan. ("Ratusan" perubahan selama 20 tahun kecil, BTW.)
Marnen Laibow-Koser

Jawaban:


51

"Lebih baik meminta maaf daripada izin" itu benar.

Kenapa kuatir tentang itu? Hanya refactor bagian yang paling mengerikan.

Anda sudah tahu kesalahan apa yang paling mahal , bukan?

Jika tidak, maka langkah 1 adalah untuk secara positif dan jelas menentukan kode masalah yang paling mahal, kompleks, penuh kesalahan, dipenuhi bug.

Mengidentifikasi jumlah tiket masalah, jam debugging, dan sangat spesifik lainnya, sangat terukur biaya .

Kemudian perbaiki sesuatu pada daftar masalah biaya tinggi itu .

Ketika Anda harus meminta maaf, Anda bisa menunjukkan pengurangan biaya.


Jika Anda tidak sadar, refactoring memerlukan tes unit untuk membuktikan bahwa perilaku sebelum dan sesudah cocok. Idealnya, ini harus berupa tes kode otomatis, misalnya, tes unit.

Ini berarti memilih satu hal. Tulis tes unit. Perbaiki satu hal itu. Anda telah membuat dua peningkatan. (1) menulis tes dan (2) memperbaiki kode.

Pengulangan.


4
Jika Anda melakukan ini, dapatkan metrik sebelum Anda mulai, maka ketika meminta maaf, Anda memiliki bukti yang Anda perlukan untuk mempertahankan pekerjaan Anda.
mattnz

15
"Kenapa khawatir tentang itu? Hanya refactor bagian yang paling mengerikan." Ini akan menjadi saran yang sangat berbahaya tanpa unit test. Dalam kombinasi dengan saran Anda yang lain untuk meminta pengampunan daripada izin, OP mungkin meminta pengampunan secara besar-besaran. Tunggu saja sampai tiket dibuka karena perubahan perilaku yang tidak diinginkan yang dapat dilacak kembali ke refactoring yang tidak sah. Ada kemungkinan besar itu akan disalahkan pada praktik refactoring daripada kurangnya unit test, dan kemudian ini akan berfungsi sebagai "bukti" abadi di kantor ini bahwa "refactoring itu jahat".
PeterAllenWebb

2
Juga, saya jarang pernah melihat perusahaan yang menggunakan tes unit, jadi bagaimana Anda bahkan mulai memperbaiki dalam situasi seperti itu? Ini tampaknya merupakan spiral ke bawah yang mengalahkan diri sendiri: Anda tidak dapat melakukan refactor karena Anda tidak memiliki tes, Anda tidak dapat menulis tes karena basis kode terlalu besar dan / atau tidak ada waktu di luar menulis fitur baru untuk kembali dan menulis tes untuk kode yang telah ditulis selama bertahun-tahun, sehingga Anda tidak dapat refactor apa pun, sehingga kode hanya membengkak dan membusuk sampai runtuh.
Wayne Molina

8
Seringkali jawabannya adalah "Tinggalkan dan temukan orang yang kompeten yang mengerti bagaimana menjadi seorang profesional sejati, bukan peretasan." :)
Wayne Molina

4
Pada beberapa titik, kode yang mengerikan atau sulit dirawat itu sendiri adalah bug. Buat backlog item dan tetapkan prioritasnya. Saya bekerja di lingkungan yang gesit di mana kami melakukan sprint stabilisasi singkat dari waktu ke waktu ketika klien terlalu lapang untuk memberi kami informasi spesifik atau tidak mengikuti pelatihan. Kami tidak berhenti karena mereka tidak tersedia. Dan ketika sprint berikutnya dimulai, kami punya waktu untuk membiasakan diri dengan kontribusi masing-masing dan lebih akurat dalam perkiraan upaya kami. Anda hanya harus mulai dari suatu tempat, bahkan kecil, dan terus berjalan. Jangan membuatnya lebih buruk dengan melanjutkan gaya saat Anda berada di sana.
Erik Noren

32

Ikuti aturan pramuka: tinggalkan perkemahan (kode) sedikit lebih baik daripada yang Anda temukan. Saya belum pernah mendengar seseorang ditulis untuk membuat perbaikan kode kecil "ketika mereka ada di sana."


7
Sangat tergantung pada seberapa dekat Anda dengan tenggat waktu. Mengubah perpustakaan dapat membatalkan semua pengujian sebelumnya.

3
Poin bagus, @ Thorbjørn. Sesuatu seperti itu saya mungkin tidak akan diklasifikasikan sebagai perbaikan "kecil" karena memiliki lingkup pengaruh yang besar.
Karl Bielefeldt

jika Anda kebetulan melewati suatu fungsi yang dapat ditingkatkan sedikit. Anda tidak tahu bahwa itu ditempatkan di perpustakaan umum?

@ Thorbjørn Saya akan mengatakan Anda harus memiliki ide bagus tentang di mana fungsi tersebut digunakan. Jika file sumber yang diberikan sedang dikompilasi untuk sesuatu yang internal, yaitu sehingga Anda memiliki akses lengkap ke semua peneleponnya, saya tidak melihat masalah dengan memperbaikinya dan memperbarui tempat-tempat yang disebut sebagai diperlukan. Jika file sumber sedang dikompilasi sebagai bagian dari perpustakaan di mana API tidak dapat diubah, Anda setidaknya bisa memperbaiki detail implementasi.
Maks.

Saya telah melihat komentar "ini perlu di refactored" menyelinap masuk pada kode yang digunakan kembali di tempat lain tetapi di mana tidak terlalu jelas yang mana. Biasanya pengembang tidak ingin menghabiskan waktu untuk melakukan analisis dampak, dan mereka memberikan komentar untuk meredakan rasa bersalah mereka.
Joeri Sebrechts

23

Saya mungkin akan mengambil sudut pandang yang mungkin terlalu sinis.

Refactoring adalah pil yang sulit untuk ditelan. Anda mendapatkan tanggung jawab dan kesalahan, dan hasil kerja Anda sering kali jatuh ke orang lain yang membangun berdasarkan kode bersih Anda.

Saya akan mengatakan bahwa jika praktik rekayasa seperti itu telah menjadi budaya di perusahaan Anda, Anda mungkin perlu berjuang di tingkat yang lebih tinggi. Anda tidak benar-benar berjuang untuk refactoring, Anda berjuang untuk keunggulan teknik, dan itu adalah jenis perubahan yang hanya muncul di manajemen ketika itu menampar wajah mereka. Dalam skenario itu, mereka mungkin akan mencari di luar untuk praktik terbaik tsar, dan semua ide-ide besar Anda akan dimasukkan lagi.

Pertimbangkan untuk bergabung dengan perusahaan lain di mana mereka melakukan praktik rekayasa dengan lebih serius.


2
Pengalaman saya adalah bahwa keunggulan Teknik jarang membayar tagihan. Ini adalah tindakan penyeimbang yang hanya dilakukan oleh beberapa programmer. Asalkan OP tidak berusaha untuk keunggulan rekayasa berlebihan, komentar Anda valid.
mattnz

8
Ini hampir selalu merupakan saran terbaik IMO. Jika perusahaan tidak mengerti mengapa memiliki kode kualitas adalah sesuatu yang harus didorong dan tidak dianggap sebagai pemborosan waktu, itu adalah usaha yang hilang - mereka tidak cukup pintar untuk memahami pemrograman yang sebenarnya.
Wayne Molina

17

Saya perhatikan bahwa banyak poster di sini tampaknya diyakinkan bahwa masalah dalam manajemen - sementara pertanyaannya tidak menyebutkan itu.

Saya akan melangkah lebih jauh dari itu: menurut saya basis kode yang buruk hampir tidak pernah secara langsung merupakan kesalahan manajemen. Manajemen tidak menulis kode itu, para pengembang melakukannya (ada beberapa pengecualian di perusahaan saya di mana beberapa manajemen kami saat ini benar-benar menulis basis kode awal). Oleh karena itu masalah budaya ada pada pengembang - jika mereka ingin budaya berubah, mereka sendiri harus berubah.

Saya mencoba membawa realisasi dan perubahan sikap ini kepada pengembang "saya" juga. Setiap kali mereka bertanya kepada saya "kapan kita punya waktu untuk refactor?", Saya bertindak terkejut dan menjawab, "Anda seharusnya sudah refactoring sepanjang waktu!". Satu-satunya cara saya yakin Anda dapat menjaga basis kode tetap sehat adalah tiga kali lipat:

  1. Hanya pernah menambahkan kode sehat.
  2. Selalu perbaiki kode yang tidak terlalu sehat segera setelah Anda melihatnya.
  3. Jika karena alasan tenggat waktu Anda tidak dapat melakukan 1 atau 2, selalu miliki daftar masalah "perbaiki segera setelah batas waktu", dan jangan terima alasan untuk tidak mengerjakan daftar itu setelah batas waktu.


Selalu komentar berikutnya dari pengembang adalah "tetapi bagaimana kita mendapatkan waktu untuk melakukan ini - kita tidak punya waktu sekarang?". Satu-satunya jawaban yang benar (lagi IMHO) adalah "Anda tidak punya waktu untuk TIDAK melakukan ini.". Jika Anda tidak menjaga kode basis tetap sehat, Anda akan menemukan waktu penyelesaian semakin lama, jadwal semakin tidak terduga, bug semakin nastier, dan nilai semakin rendah.

Perubahan sikap terbesar yang perlu Anda lakukan dalam tim pengembangan adalah bahwa "kualitas" bukanlah sesuatu yang Anda lakukan pada saat tertentu ("ketika kami punya waktu untuk melakukan refactor") - itu adalah sesuatu yang harus Anda lakukan SEMUA waktu.

Akhirnya, sebuah kisah peringatan. Jika ditekan, saya akan menyangkal ini pernah terjadi. Di perusahaan tempat saya bekerja, ada aplikasi lama dengan basis kode warisan besar yang berasal lebih dari 10 tahun yang lalu. Banyak pengembang termasuk saya percaya basis kode warisan ini buruk atau setidaknya sudah ketinggalan zaman, bukan canggih. Jadi kami berhasil melakukan lobi untuk proyek refactoring besar dengan sukses, dan memulai proyek penulisan ulang setelah itu kami percaya semuanya akan lebih baik.
Kami bekerja keras dan lama mengimplementasikan hampir semua hal dengan cara yang baru dan modern, menggunakan perpustakaan baru, fitur bahasa baru. Menjelang akhir, kami berupaya keras untuk menyatukan semuanya untuk memungkinkan rilis baru aplikasi lama dengan basis kode yang baru dan lebih baik.
Seperti yang diharapkan rilis baru memiliki beberapa masalah gigi, karena perpustakaan baru yang belum kita kenal, dan beberapa interaksi dalam kode kita yang belum kita ramalkan. Namun, kami akhirnya berhasil mendapatkan rilis dengan standar yang sama dengan rilis kami sebelumnya dan keluar dari pintu. Kami menghela nafas lega pada "kesuksesan" kami. Kemudian sub-kelompok pengembang kembali ke manajemen, meminta proyek refactoring baru karena kode baru kami tidak cukup seperti yang diharapkan, dan mereka melihat beberapa peluang untuk sepenuhnya menulis ulang beberapa hal ...

Moral dari kisah ini: sering kali hal-hal yang terjadi tidak serusak kelihatannya, dan 'memulai kembali' biasanya berarti Anda akan menukar serangkaian masalah yang diketahui dengan serangkaian masalah yang paling tidak sama berbulunya. Perbaiki satu bagian sekaligus!


2
Saya pikir ini adalah kasus untuk modularisasi, seperti yang saya sebutkan dalam tanggapan saya, IMO ini dapat mengatasi beberapa masalah dengan memecah hal-hal menjadi aplikasi yang lebih kecil, jika mungkin, maka Anda dapat menulis ulang satu bagian dari itu setiap minggu jika Anda ingin sambil meninggalkan modul stabil sendiri
programmx10


Lihat juga Hal - hal yang tidak boleh Anda lakukan dari Joel Spolsky.
Jan Hudec

Saya semua untuk saran bahwa "Anda tidak punya waktu untuk TIDAK refactor." Tetapi untuk mengklaim bahwa ini adalah masalah pengembang? Apakah kamu bercanda? Saya tidak dapat memberi tahu Anda berapa kali manajemen (non-programmer) benar-benar memanggil saya ke kantor untuk meminta saya berhenti refactoring, meninggalkan kode dalam versi terbaru, dan dengan cepat melakukan sesuatu yang lain. Kami memiliki beberapa pengembang yang terus-menerus berargumen bahwa kami harus melakukan refactoring, tetapi manajemen benar - benar tidak menghargainya. Ini umum ketika manajer adalah pekerja teknis di beberapa domain selain perangkat lunak.
ely

Nah, dari pengalaman saya ini selalu merupakan masalah manajemen. Manajemen ada untuk mengelola orang sehingga mereka melakukan pekerjaan mereka dengan benar. Jika programmer tidak melakukan pekerjaan mereka dengan benar (dan tidak menulis kode kualitas berarti persis seperti itu), maka kita memiliki masalah besar dalam manajemen!
Kaiserludi

12

Seseorang pernah mengatakan kepada saya bahwa ketika saya pergi ke sebuah wawancara, saya tidak boleh lupa bahwa saya juga mewawancarai perusahaan. Apakah ini tempat saya ingin bekerja? Apakah mereka melakukan review kode? Apakah mereka memiliki tes integrasi otomatis? Tes unit? Apa yang mereka pikirkan tentang pemrograman pasangan? Secara pribadi saya akan mencari pekerjaan lain, dan jangan lupa untuk menanyakan beberapa pertanyaan juga kali ini.


Saran yang bagus, tetapi mengajukan pertanyaan tidak selalu berhasil. Saya telah mewawancarai beberapa perusahaan yang berbohong tentang hal itu - misalnya mengatakan mereka menggunakan kontrol versi tetapi tidak diatur dengan benar dan tidak ada yang benar-benar tahu bagaimana menggunakannya, mengatakan mereka melakukan pengujian tetapi tidak ada tes unit, mengatakan mereka gunakan teknologi terbaru dan terhebat tetapi sebenarnya tidak menggunakan salah satu fitur di versi terbaru (atau versi apa pun melewati yang pertama).
Wayne Molina

5
@Wayne M: Dalam hal ini, mulailah mencari pekerjaan baru dengan segera. Jika mereka berbohong kepada Anda dalam wawancara, bagaimana mereka akan memperlakukan Anda nanti?
David Thornley

1
Setuju, tapi sayangnya sering lebih mudah diucapkan daripada dilakukan.
Wayne Molina

@WayneM Tepat. Saya pernah mengalami hal yang sama. Saya bertanya tentang peluang kreatif untuk melakukan penelitian matematika dalam suatu pekerjaan, dan perusahaan pada dasarnya berbohong tentang hal itu untuk membuat saya menerima dan kemudian menjebak saya dengan proyek-proyek yang saya pikir telah saya hilangkan dengan bertanya selama wawancara. Saran "mencari pekerjaan baru" jatuh cukup datar - tentu saja saya akan melakukan itu, itu tidak mewakili "solusi" apa pun untuk masalah ini.
ely

6

Temukan perusahaan lain, jujur. Peningkatan pada proses pengembangan seperti itu membutuhkan lompatan budaya besar yang akan membutuhkan waktu yang signifikan sebelum semua orang masuk ke halaman yang sama dan pada saat itu Anda tidak akan terlalu peduli.

Jika Anda merasa masih memiliki beberapa pertengkaran di dalam diri Anda dan belum gagal, maka lakukan dorongan terakhir. Cobalah untuk mendapatkan sebanyak mungkin dukungan dari anggota tim yang berpikiran sama, ungkapkan kelelahan Anda kepada atasan yang benar-benar peduli terhadap kesejahteraan Anda, jalan pintas dan jauhi siapa pun yang mungkin menentang keyakinan Anda dan cobalah untuk mendorong beberapa jam refactoring wajib ke dalam perencanaan untuk yang baru proyek / fitur.

Jika Anda bersemangat tentang apa yang Anda lakukan dan pedulikan perusahaan Anda, itu akan menjadi upaya terpuji di pihak Anda. Jika itu tidak dihargai, maka hargai diri Anda dan bailout sebelum Anda berubah menjadi programmer kosong.


5

Jika saya harus memperkenalkan satu latihan untuk membuat segalanya lebih baik dalam konteks semacam ini, itu akan menjadi ulasan kode. Ulasan kode

  • umumnya diterima secara intuitif oleh pengembang sebagai faktor untuk kode yang lebih baik, lebih sedikit bug, dll.
  • kolaboratif dan demokratis
  • tidak terlalu memakan waktu jika Anda timebox dengan benar
  • tempat yang baik untuk melakukan refactoring jika Anda tidak punya waktu untuk melakukannya selama pengembangan "normal"
  • kuda Trojan yang cukup efektif untuk secara bertahap memperkenalkan semua jenis praktik terbaik dalam hal desain kode, pengujian unit ...

Anda tidak harus melakukan tinjauan kode secara sistematis, hanya ketika melakukan bagian kode besar / kompleks pada awalnya.

Tentu saja jika Anda merasa Anda perlu pengesahan resmi sebelum memperkenalkan ulasan kode, Anda mungkin harus meyakinkan bos Anda terlebih dahulu bahwa basis kode kemungkinan akan runtuh jika semuanya dibiarkan apa adanya.


2
Itu mengasumsikan yang lain tahu praktik pembangunan yang baik sejak awal. Saya pernah bekerja di mana anggota tim lainnya bahkan tidak tahu mengapa cara saya lebih efektif; kode saya yang ditulis dengan baik yang mengikuti pola desain SOLID dan terapan sebenarnya ditolak dalam "tinjauan kode" karena itu berbeda dan pengembang senior tidak memahaminya dibandingkan dengan gaya tim lainnya hanya menggunakan acara di belakang kode dan App_Code / folder.
Wayne Molina

Seringkali Anda dapat mengatasi kesulitan seperti itu dengan meminta orang untuk mencoba cara Anda dan melihat sendiri apakah itu berhasil. Jika mereka menolak untuk melakukannya atau masih tidak melihat manfaatnya, saya harus mengakui bahwa ini mungkin saatnya untuk berhenti.
guillaume31

1
Saya pernah diberitahu bahwa jalan saya "lebih bagus" tetapi saya harus mengajukan keluhan bahwa itu lebih sulit untuk dipahami. Cara lain FWIW menyalin file 300 baris, mengubah dua baris, dan melakukan. Pembenaran untuk copy / paste dalam kasus itu (dan biasanya menurut pengalaman saya) adalah "dengan cara itu Anda tahu Anda tidak merusak apa pun".
Kevin

4

Inilah yang saya lakukan dalam situasi seperti itu (dalam 15 tahun karir saya sebagai pengembang, saya telah menemukan kode seperti itu hampir setiap hari)

  1. Pimpin dengan memberi contoh - Saya memastikan untuk memasukkan kembali faktor kode yang saya sentuh. Saya dengan kejam menghapus kode komentar lama dan paragraf komentar besar.
  2. Meminta anjak piutang setiap kali saya diminta untuk meninjau perubahan kode, yang tanpanya saya tidak menyetujui peninjauan kode.
  3. Perlahan-lahan orang melihat perubahan, ketika kode menjadi lebih ramping, lebih mudah dibaca dan dengan demikian kurang buggy. Butuh waktu tetapi perlahan-lahan seluruh tim menghargai dan mengadopsi latihan ini.

Manajemen tidak pernah menyisihkan waktu untuk kode anjak piutang (mereka tidak pernah memiliki sumber daya yang cukup!), Jadi melakukannya perlahan dan pasti adalah pendekatan yang tepat.


Saya tidak keberatan bahkan jika satu atau dua bug merayap masuk sementara selama pembuatan ulang kode, cacat seperti itu ditangkap dan diperbaiki jauh lebih cepat dan mudah dalam kode yang lebih bersih / ramping!
Penasaran

3

Mintalah manajemen melakukan riset tentang "utang teknis". Juga merujuk mereka ke "Teori Jendela Rusak", kedua efek ini berdampak langsung pada efisiensi, kualitas, dan moral.

"Tempat kerja yang bersih adalah tempat kerja yang aman dan produktif", dan setiap kontribusi terhadap kekacauan menambah kekacauan dengan cara yang eksponensial, bukan linier.

Jika situasi tidak ditangani, pada akhirnya Anda akan melewati titik tidak bisa kembali, di mana ia menjadi tidak layak secara ekonomi, dengan menanganinya secara bertahap sebelum itu terjadi manfaatnya akan melambung, memberi Anda lebih banyak bahan bakar untuk menangani masalah saat Anda pergi.


3

Sepertinya masalah Anda lebih umum.
Masalah refactoring adalah gejala dan kemungkinan bantuan dari sebagian masalah.

Pimpinan Perangkat Lunak dan Tim Mengalokasikan Waktu Tim

Dari pengalaman saya, saya pikir Anda mungkin menghadapi masalah yang saya sebut, "semua orang adalah manajer perangkat lunak." Manajer produk, manajer proyek dan kadang-kadang insinyur sistem dan penguji bisa terkenal karena mencoba mengelola pengembang mikro yang mungkin sudah memiliki manajer perangkat lunak yang berpengalaman. Anda bahkan mungkin memiliki beberapa anggota di tim Anda yang percaya bahwa peran mereka adalah mengelola.

Jika Anda adalah manajer perangkat lunak, buat tugas untuk refactoring yang Anda inginkan, atau lebih baik lagi, minta tim Anda mengusulkan refactoring kepada Anda untuk persetujuan Anda. Agar tidak pengelolaan mikro, Anda mungkin memiliki pedoman tentang usia / penulis / ukuran / konteks kode yang akan di refactored yang dapat di-refactored secara bebas vs membutuhkan persetujuan. Jika seorang anggota tim Anda ingin secara besar-besaran memperbaiki empat kelas kode lama yang rumit yang tidak ia tulis yang bukan bagian dari fiturnya, pengalihan dua minggu adalah masalah Anda, jadi Anda perlu kesempatan untuk mengatakan tidak.

Anda dapat menyelinap, tetapi saya pikir lebih baik hanya membuat perkiraan dengan hati-hati dengan waktu untuk analisis, desain, pengkodean, berbagai bentuk pengujian (setidaknya unit dan integrasi), refactoring, dan risiko yang dinilai secara historis dan oleh kurangnya pengalaman atau kejelasan yang terkait dengan tugas tersebut. Jika Anda terlalu terbuka tentang cara kerja tim Anda (atau memiliki anggota dalam tim Anda), mungkin bijaksana untuk mempersempit saluran komunikasi sehingga mereka menelusuri Anda dan mendiskusikan sumber daya dan hasil, bukan metode.

Pilihan Proyek Awal Membuat Siklus Vicious untuk Refactoring

Pemeliharaan perangkat lunak sulit. Sangat sulit jika orang lain dalam organisasi membuat pilihan dengan biaya Anda. Ini salah, tetapi ini bukan hal baru. Ini telah ditangani oleh Barry Boehm yang merupakan salah satu penulis perangkat lunak hebat kami yang mengedepankan model manajemen yang ia gambarkan sebagai Theory W.

http://csse.usc.edu/csse/TECHRPTS/1989/usccse89-500/usccse89-500.pdf

Seringkali pengembang perangkat lunak dipalu untuk menghasilkan di bawah pendekatan manajemen Theory-X yang mengatakan bahwa pekerja pada dasarnya malas dan tidak akan melakukan kecuali didorong untuk tunduk. Boehm merangkum dan membandingkan model yang diusulkannya sebagai berikut:

"Daripada mengkarakterisasi seorang manajer sebagai otokrat (Teori X), pelatih (Teori Y), atau fasilitator (Teori Z), Teori W mencirikan peran utama manajer sebagai negosiator antara berbagai konstituennya, dan satu paket solusi proyek. dengan kondisi menang untuk semua pihak. Di luar ini, manajer juga merupakan penentu tujuan, pemantau kemajuan menuju tujuan, dan seorang aktivis dalam mencari konflik proyek menang-kalah atau kalah-kalah sehari-hari, menghadapi mereka, dan mengubahnya menjadi situasi win-win. "

Cepat dan Kotor seringkali hanya Kotor

Boehm kemudian menunjukkan alasan mengapa hal itu sangat menyedihkan bagi pengembang di tim pemeliharaan.

"Membangun produk yang cepat dan ceroboh mungkin merupakan" win "jangka pendek yang murah untuk pengembang dan pelanggan perangkat lunak, tetapi itu akan menjadi 'kerugian' bagi pengguna dan pengelola." Harap dicatat bahwa dalam model Boehm, pelanggan lebih merupakan administrator kontrak daripada pengguna akhir. Di sebagian besar perusahaan, anggap manajer produk sebagai pengganti pelanggan, atau mungkin orang yang membeli produk untuk daftar fiturnya.

Solusi saya adalah dengan tidak merilis tim pengembangan asli (atau setidaknya pemimpin asli) sampai kode tersebut di refactored untuk setidaknya memenuhi standar pengkodean.

Untuk pelanggan, saya pikir masuk akal untuk menghitung manajer produk sebagai pengganti pelanggan, dan sekelompok orang yang diberi imbalan karena mengirimkan sesuatu dengan cepat dan kotor tentu dapat diperluas, sehingga ada pemilih besar untuk melakukan sesuatu dengan cara yang salah.

Refactoring tidak dapat dinegosiasikan

Tolong jangan mundur dari peran Anda sebagai manajer perangkat lunak. Anda harus memiliki wewenang dan keleluasaan untuk menggunakan waktu tim Anda dalam proses dan peningkatan produk. Dalam peran itu, Anda mungkin perlu menegosiasikan pilihan Anda untuk membuat tim Anda lebih profesional. Namun, berkenaan dengan proses, jangan bernegosiasi dengan pemasaran, karena dalam pengalaman saya, itu adalah permainan yang kalah. Bernegosiasi dengan manajemen teknik. Itu menunjukkan Anda memiliki visi. Membangun tim perangkat lunak profesional merupakan perpanjangan dari peran mereka, dan jauh lebih mungkin dilihat sebagai win-win.


2

Anda selalu bisa menunggu saja. Akhirnya, tim akan kehilangan tenggat waktu yang cukup, dan menghasilkan perangkat lunak yang cukup buggy, bahwa manajemen akan mengangkat tangannya dan mengatakan bahwa demi Tuhan ada sesuatu yang lebih baik berubah!

Oke, itu proposisi yang berisiko. Tapi sebenarnya apa yang terjadi di toko kami beberapa tahun yang lalu (bagian dari kesulitan adalah dalam berkomunikasi dengan manajemen tentang tenggat waktu, tapi itu cerita lain), dan banyak alasan kita sekarang memiliki puluhan ribu tes otomatis, kepemilikan kode bersama, kebebasan untuk refactor, kesediaan untuk menghapus kode mati, dan rilis berkualitas tinggi yang pernah kita miliki.

Mungkin yang paling mengejutkan, tidak ada yang kehilangan pekerjaan mereka dalam proses - sesuatu yang saya kreditkan kepada bos kami datang untuk memukul kami, dan seorang konsultan yang berpendapat kasus untuk refactoring dan integrasi berkelanjutan atas nama kami. Itu selalu terdengar lebih meyakinkan ketika seseorang dari luar mengatakannya.


Setuju, tetapi dalam kasus OP itu benar-benar terdengar seperti dia bekerja dengan banyak peretasan yang tidak kompeten, jadi ketika semuanya runtuh di sekitar mereka itu tidak akan pernah tenggelam di dalamnya karena mereka tidak memperbaiki kode jelek, karena jika mereka dapat memahami bahwa kode tidak akan seburuk kedengarannya seperti itu. Pengembang nyata mengetahui manfaat refactoring dari awal dan mengambil langkah-langkah untuk melakukannya sejak awal.
Wayne Molina

1

Saya pikir jawaban untuk bagaimana menemukan waktu tergantung, mengapa Anda ingin kode refactor.

Jika berhasil, tidak perlu refactor khusus dan Anda dapat melakukannya ketika menyentuh bagian kode itu. Karena itu Anda tidak perlu waktu khusus untuk itu.

Jika memperlambat pengembangan tim Anda, Anda perlu berbicara dengan ketua tim tentang hal itu dan membuat tugas khusus untuk refactoring dan Anda akan punya waktu.

Sama untuk kecepatan lari dan kasus lainnya, jika refactor dapat meningkatkan sesuatu dan tidak hanya "mencari kode yang baik" atau pendapat Anda tentang, bagaimana kode seharusnya terlihat, dan memberikan manfaat nyata, membuat tugas atau berbicara dengan seseorang yang bertanggung jawab untuk itu.


1

Saya tertawa sedikit pada cara Anda menggambarkan hal-hal yang kedengarannya sangat mirip dengan basis kode yang saya kerjakan jadi saya pikir situasi kami sangat mirip. Untungnya, dalam situasi saya, saya memiliki manajer yang berpikiran maju yang telah memutuskan cara terbaik untuk membuat basis kode lebih baik adalah melalui modularisasi menggunakan kerangka pengembangan web modern daripada hanya refactor seluruh basis kode. Dengan cara ini bintik-bintik bermasalah pada aplikasi utama dapat ditulis ulang sebagai modul terpisah dan kemudian diintegrasikan ke dalam aplikasi utama (tetapi pada dasarnya masih independen). Ini mungkin pendekatan yang ingin Anda kemukakan karena tidak akan memerlukan refactoring seluruh basis kode (mungkin besar?) Yang Anda gunakan.

Tentu saja, saya mungkin agak kecewa dengan apa yang Anda katakan karena mungkin basis kode Anda tidak seburuk yang saya kerjakan, dalam hal ini saya akan mengatakan mengapa tidak melakukan sedikit optimasi saat Anda melanjutkan? Pengembang di tim saya tidak memiliki masalah menghapus komentar bodoh atau ketinggalan jaman dan hal-hal semacam itu dan saya tidak berpikir itu sesuatu yang seharusnya memerlukan masukan dari manajemen karena biasanya pengembang diberikan pemberdayaan untuk mengoptimalkan hal-hal yang diperlukan.

Jika basis kode benar-benar rapuh maka Anda harus berhati-hati dan ini bisa menjadi alasan mereka tidak ingin melanjutkan refactoring besar karena ini bisa berakhir menjadi proyek berbulan-bulan dan mungkin akan memerlukan percabangan proyek dan menempatkan dev pada itu memproyeksikan dan mengambil dari tugas pengembangan lainnya, seperti perbaikan bug langsung yang dapat menyebabkan mereka kehilangan pelanggan, dll

Semua hal dipertimbangkan, sejauh orang lain mengatakan Anda harus berhenti, dll. Saya pikir itu tergantung pada bagaimana manajemen melihat sesuatu, jika mereka memahami situasi dan menyadari mengapa beberapa hal mungkin memakan waktu lebih lama daripada yang seharusnya, maka semuanya bisa baik-baik saja. Sejauh lingkungan kerja, tetapi jika mereka terus-menerus membuat Anda tentang tumpukan pekerjaan, itu bisa menjadi merugikan dari waktu ke waktu. Saya beruntung memiliki manajemen yang pada dasarnya menyadari bahwa aplikasi ini adalah omong kosong, tetapi ia memiliki banyak pelanggan dan menghasilkan uang, sehingga masih berharga dan layak membuat perbaikan bug, bahkan jika hanya untuk jangka pendek .


1

Masalah utama Anda adalah bahwa kode tidak mendapatkan visibilitas yang cukup.

Saya suggets menggunakan alat integrasi berkesinambungan seperti Jenkins , dan alat analisis kode statis yang diintegrasikan dengannya yang mengukur kompleksitas siklomatik, standar penamaan, panjang kode, dll.

Ketika seorang programmer melakukan perubahan, Jenkins akan menjalankan tes unit, menjalankan alat analisis kode statis di atasnya dan menghasilkan laporan web yang dapat dilihat semua orang, dengan status warna traffic-light-like.

Ketika kualitas kode terlihat oleh semua orang (khususnya lider tim dan bos) dan kontrol versi serta tes unit ada untuk mendukung Anda ... orang merasa terdorong untuk melakukan refactor.


1

Kode ini menjadi lambat karena banyak perubahan kecil. Ini perlu diperbaiki juga.

Anda dapat melakukan ini seiring berjalannya waktu, pertama-tama - tingkatkan semua perkiraan sebesar 10% untuk memungkinkan peningkatan kode dan pemeliharaan jangka panjang. Jika ada yang mengeluh, tanyakan apakah lebih baik memeriksa oli di mesin mobil setiap minggu atau menunggu sampai mesin benar-benar terkunci.

Adakan pertemuan dan tentukan standar pengkodean yang konsisten.

Perkenalkan aturan dasar untuk digunakan saat Anda berjalan:

Setiap kali kode baru diperkenalkan ke kelas, tes otomatis harus ditulis untuk membuktikan bahwa kelas berfungsi (bukan hanya kode baru).

Setiap kali bug diperbaiki, tes otomatis harus ditulis untuk membuktikan kelas berfungsi (bukan hanya kode tetap).

Setiap kali seorang programmer memodifikasi file dia harus memperbaiki semua peringatan kompiler dalam file itu dan memperbarui kode sehingga memenuhi standar pengkodean baru.

Setelah beberapa saat, kode yang paling sering digunakan akan diperbarui dan dicakup oleh pengujian otomatis. Kode yang lebih lama akan diperbarui ketika diubah, jika tidak pernah diubah maka Anda tidak perlu khawatir tentang hal itu.

Yang penting adalah untuk membangun kebiasaan ini ke dalam tugas pengkodean standar sehingga tidak satupun dari mereka mengambil banyak waktu dari pekerjaan 'nyata' tetapi semuanya memberikan manfaat nyata. Jangan mencoba membuat proyek dari refactoring kode lama, itu adalah rasa sakit yang mengerikan, membosankan, fiddly yang akan terlihat seperti banyak waktu yang terbuang untuk non-teknik!


0

Cara untuk mendapatkan sumber daya (waktu) yang Anda butuhkan adalah fokus pada menyelaraskan kemampuan dan keinginan. Bos Anda didorong oleh target (biasanya keuntungan atau waktu pengiriman untuk fitur baru), dan dia melihat refactoring sebagai insinyur yang membuang waktu dan menyantap target tersebut. Anda perlu menemukan cara untuk meyakinkannya bahwa target akan terpenuhi dan dilampaui jika Anda menghabiskan waktu refactoring.

Jadi langkah pertama adalah mencari tahu rasa sakit yang bos Anda rasakan. Identifikasi apa masalah terbesarnya. Kemudian cari tahu bagaimana apa yang ingin Anda lakukan selaras dengan memperbaiki masalahnya, dan sampaikan kasus bisnis yang kuat untuk melakukannya. Gunakan Anda cacat pelacakan dan sistem perencanaan proyek (time overruns) untuk memberikan bukti di mana letak masalahnya. Anda membutuhkan fakta, bukan perasaan. Tanpa metrik (jumlah bug / modul, biaya untuk memperbaikinya), refactoring hanyalah seorang programmer yang bermain dengan biaya seseorang. Bos Anda hanya akan memberi Anda sumber daya yang diperlukan jika Anda dapat menunjukkan alasan bisnis yang kuat untuk melakukannya.

Kode sampah lebih sering diperbaiki daripada tidak terlalu mahal. Tanpa uji regresi otomatis, biaya pengujian kode refactored sangat tinggi.

Sering kali saya telah melihat kode buruk yang benar-benar membutuhkan refactoring, ada sejumlah besar fitur dan kompleksitas tidak terdokumentasi dalam persyaratan yang tidak dapat dipahami sejak awal. Ini bukan pekerjaan ringan dan pengalaman saya adalah urutan besarnya lebih sulit untuk memperkirakan biaya pekerjaan refactoring daripada menambahkan fitur baru.

Saya akan menahan diri untuk tidak maju terus dan melakukannya di belakang bos Anda (Jika tidak rusak, dan Anda merusaknya, bagaimana tampilannya) - perbaiki kode yang perlu diubah, tetapi jika tidak rusak, jangan ' t memperbaikinya.


2
Untuk menjaga kewarasan - Anda perlu memahami apa yang memotivasi orang dalam organisasi. Setelah Anda memahami hal-hal kecil, seperti bos tidak peduli seperti apa kode itu, itu menjadi lebih mudah. Jika itu tidak berhasil, ganti pekerjaan atau terlibat dalam proyek sumber terbuka dan perbaiki semua yang Anda suka.
mattnz

3
"Jika tidak rusak, jangan memperbaikinya" adalah pepatah terburuk di seluruh bidang kami, dan perlu dihapus seluruhnya dari kata-kata. Ini menumbuhkan perilaku malas dan mendorong budaya meretas berbagai hal sebagai kebalikan dari melakukannya dengan benar, dan dengan asosiasi mencegahnya dari pernah dilakukan dengan benar di masa depan. Sikap itu adalah kanker.
Wayne Molina

1
Lihat komentar saya di atas, itu sebabnya.
Wayne Molina

2
@Wayne M: Saya tidak berpikir mattnz mengatakan "jangan perbaiki, pernah", saya pikir apa yang dia katakan adalah "jangan perbaiki kecuali itu baik untuk organisasi dan Anda dapat membangun dukungan" yang jauh berbeda dan cukup masuk akal, IMO.
PeterAllenWebb

3
@Wayne M: kata baik! Pepatah "jika tidak rusak, jangan memperbaikinya" dan kata "refactoring" sama sekali tidak cocok. Inti dari refactoring adalah bahwa pengembangan perangkat lunak bukanlah dunia hitam dan putih di mana "pecah" dan "diperbaiki" adalah absolut.
Carson63000

0

Anehnya tidak ada yang menyebutkan ini:

Untuk menjadikan hal-hal prioritas, buatlah mudah: Dapatkan alat refactoring yang baik.

Ada alat refactoring yang sangat baik di luar sana (setidaknya untuk. NET afaik). Oh, dan jangan lupa untuk menulis unit test sebelumnya (seperti yang sudah ditunjukkan orang lain).

Semoga berhasil!

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.