Apakah ide yang bagus untuk menjadwalkan waktu reguler untuk membersihkan kode? [Tutup]


42

Saya mengelola tim kecil pengembang. Seringkali kita memutuskan untuk menghabiskan satu atau dua hari untuk membersihkan kode kita.

Apakah ide yang bagus untuk menjadwalkan waktu reguler, katakanlah 1 minggu setiap 2 bulan, untuk hanya membersihkan basis kode kita?


9
Saya lebih suka mulai mendaftarkan semua hal yang memerlukan pembersihan dalam alat pelacak masalah . Menganalisis masalah yang dicatat dalam pelacak mungkin memberikan satu ide yang lebih baik (jauh lebih baik) tentang apa yang akan menjadi pendekatan yang paling tepat untuk proyek tertentu
nyamuk

4
Akan lebih baik untuk menjadwalkan waktu reguler untuk review kode
l46kok

1
Apa maksud Anda ketika Anda mengatakan 'bersih-bersih'? Apakah prettifying kode atau menangani semua tag FIXME dan TODO atau mendapatkan lebih banyak kinerja dari kode yang ditulis dengan cepat? Atau sesuatu yang lain? Semua ini dapat diklasifikasikan sebagai pembersihan tetapi saya akan melampirkan prioritas yang berbeda untuk masing-masing.
paul

Lain "tertutup karena terlalu populer", kan?
MGOwen

Jawaban:


100

Tidak.

Perbaiki saat Anda sedang mengerjakannya:

  • Jika Anda menunggu untuk memperbaiki bit yang sedang Anda kerjakan, Anda akan lupa banyak tentangnya, dan harus menghabiskan waktu untuk membiasakannya lagi.
  • Anda tidak akan mendapatkan kode "pelapisan emas" yang akhirnya tidak pernah digunakan karena persyaratan berubah

2
Uang saya untuk jawaban ini ..
Soner Gönül

2
+1 untuk jawaban yang sangat bagus. Anda tidak akan mendapatkan kode "pelapisan emas" yang akhirnya tidak pernah digunakan karena persyaratan berubah
Md Mahbubur Rahman

8
Pada proyek yang sempurna dengan manajemen yang sempurna dan tim pengembang hebat yang seragam jawaban ini akan berlaku. Sayangnya saya belum pernah melihat atau mendengar proyek seperti itu dalam sepuluh tahun saya di industri ini.
Ben

3
Cobalah untuk melakukan ini tetapi ketika Anda tidak dapat (dan itu akan terjadi karena tekanan waktu atau karena Anda belum tahu bagaimana melakukannya dengan benar, belum) buat tiket di sistem tiket Anda. Dengan cara ini semoga Anda bisa kembali ke sana sementara masalah masih segar di pikiran Anda dan tidak hanya ketika akhirnya mulai menyebabkan masalah.
Sarien

1
Saya pikir ini saran yang baik, tetapi tidak menjawab pertanyaan yang diajukan. Haivng mengelola sebuah tim dengan basis kode yang menghebohkan (mengerikan sebelum saya sampai di sana). Sudah waktunya dihabiskan dengan sangat baik untuk menangani refactoring dan membersihkan fungsi-fungsi tertentu. Kami menyebut mereka proyek infrastruktur dan mengerjakannya dalam setiap sprint yang kami bisa. Seringkali hal-hal ini adalah item yang bukan bagian dari perubahan lain, tetapi hal-hal yang diidentifikasi tim sebagai bidang masalah. Kami melakukan retrospektif triwulanan dan akan memperbarui daftar ini secara teratur.
Bill Leeper

21

Pendapat pribadi saya: Ini mutlak diperlukan untuk 90% proyek.

Khusus untuk proyek-proyek yang sangat didorong oleh penjualan, biasanya ada dorongan besar untuk memasukkan fitur-fitur baru dalam setiap rilis, dan Anda akhirnya harus berkompromi dengan insting Anda yang lebih baik dan memperkenalkan beberapa kludges / retasan di sana-sini.

Akhirnya, Anda telah cukup mendapatkan 'utang teknis' melalui kompromi kecil ini sehingga Anda menghabiskan cukup banyak waktu untuk mengatasi kekurangan dalam basis kode, dan tidak dapat menggunakannya untuk potensi penuhnya.

Biasanya ada dua jenis masalah yang dihasilkan dengan cara ini:

  • Yang kecil yang dapat dengan mudah diperbaiki tetapi mungkin sistemik, misalnya parameter yang dinamai tidak benar, penanganan kesalahan yang tidak lengkap, dll. Mereka biasanya akan memiliki dampak kecil di luar blok kode tempat mereka muncul. Cara terbaik untuk menghadapinya adalah ulasan kode dan memeriksa kode yang sedang ditulis / dimodifikasi. Seperti yang telah dinyatakan orang lain, tidak perlu menyisihkan siklus refactor khusus untuk memperbaiki kesalahan ini.
  • Yang besar yang mungkin muncul dari spesifikasi yang tidak lengkap atau keputusan desain yang buruk sejak awal, atau dua pengembang / tim menciptakan dua solusi berbeda untuk masalah yang sama. Ini umumnya jauh lebih sulit untuk diperbaiki dan membutuhkan upaya bersama untuk memperbaikinya. Akibatnya mereka biasanya ditangguhkan, hingga menjadi gangguan abadi. Masalah-masalah seperti ini membutuhkan waktu khusus untuk memperbaikinya.

Saya biasanya mencoba untuk menyediakan waktu untuk siklus perbaikan / perbaikan bug murni setiap 3 hingga 4 siklus. Saya selalu meminta pengembang saya untuk memberi tahu saya ketika mereka merasa frustrasi dengan basis kode juga. Tidak setiap pengembang harus mengerjakan upaya pembersihan - Anda biasanya dapat (tetapi tidak selalu) sedikit mengejutkan tim, sehingga hanya satu tim yang mengerjakan pembersihan pada waktu tertentu.


1
Saya tidak mengerti peningkatan jumlah dorongan besar sebagai masalah yang gesit.
JeffO

2
@ JeffO Tidak, ini bukan masalah yang lincah. Ini masalah manajemen. Dari apa yang saya lihat, perusahaan yang sangat dipengaruhi oleh penjualan cenderung condong ke siklus rilis agresif dan set fitur besar. Strategi tangkas cenderung menarik bagi perusahaan-perusahaan ini (apakah mereka benar-benar mengikuti strategi atau tidak). Walaupun saya menyukai pengembangan yang gesit, pengalaman saya menunjukkan bahwa ketika sebuah perusahaan menyebut dirinya 'gesit', biasanya itu berarti saya dapat mengharapkan untuk melihat cukup banyak hutang teknis dalam basis kode.
pswg

Saya kira jika mereka tidak memiliki metodologi sama sekali, mereka dapat menyebut diri mereka sendiri apa pun yang mereka inginkan. Karena lincah, adalah kata kunci saat ini, itu yang paling menarik. Sudah beberapa saat sejak saya berada di proyek air terjun; itu merupakan bencana dalam banyak hal lain, sehingga saya tidak pernah menggunakannya sebagai argumen untuk menentang metodologi.
JeffO

Dalam proyek apa pun, gesit atau tidak, refactoring dan pembersihan kode adalah sesuatu yang Anda lakukan saat Anda pergi, untuk terus menjaga utang teknis seminimal mungkin. Jika Anda tidak memperhitungkan itu dalam perkiraan Anda, Anda harus mulai melakukan itu. Anda tidak dapat membiarkan hutang teknis bertambah hingga Anda harus menghentikan semuanya untuk memperbaikinya. Alih-alih ikuti aturan scout: "Selalu biarkan kode lebih bersih daripada yang Anda temukan."
Christoffer Hammarström

Dalam pengalaman saya, tim yang tidak berpengalaman mulai dengan scrum, tanpa memperhatikan prinsip-prinsip pengkodean yang baik (seperti XP), kadang-kadang bisa terlalu terfokus pada fungsionalitas (cerita). Alih-alih, mereka seharusnya mengatakan sebuah cerita tidak dilakukan sampai kodenya cukup 'baik', tetapi tidak semua orang memiliki cukup tulang punggung untuk melakukannya di bawah tenggat waktu yang menjulang. Dan dengan Agile Anda cenderung memiliki tenggat waktu lebih banyak dalam waktu yang lebih singkat, jadi saya menghubungkannya dengan metode Agile juga, sedangkan saya sangat sadar mereka bukan penyebabnya.
markijbema

11

Saya meminta pengembang merapikan kode mereka sebelum checkin (Subversion) atau bergabung dengan cabang pengembangan utama (Git).

Saya minta mereka melakukan hal berikut:

  • Hapus komentar yang tidak relevan
  • Pastikan metode, argumen, dan variabel mereka diberi nama dengan tepat
  • Pastikan ada struktur untuk kelas mereka dan item dienkapsulasi sebagaimana mestinya
  • Refactor untuk meningkatkan keterbacaan dan untuk mengurangi bau kode apa pun

Untuk proyek yang lebih besar, kode ditinjau secara formal sebelum penggabungan dari cabang pengembangan ke cabang utama.

Saya berpikir bahwa "waktu mencurahkan" akan berarti itu adalah sesuatu yang mungkin ditunda, atau ditunda karena jumlah pekerjaan yang terlibat. Dengan meminta pengembang melakukannya pada per-checkin (yang setara dengan permintaan perubahan / masalah di JIRA) itu jauh lebih mudah dikelola.


Hanya ingin tahu: Mengapa Anda menggunakan dua VCS yang berbeda?
Eekhoorn

2
Ada / adalah fase migrasi. Kami telah memigrasi sebagian besar repositori SVN sekarang, saya menyebutkan keduanya untuk beberapa konteks.
Sam

Inilah yang saya lakukan. Bersihkan kode sebelum checkin dan refactor jika saya kembali ke kode untuk meningkatkan fungsionalitas.
Barfieldmv

1
Ini tidak akan mengatasi masalah yang mengganggu yang mengintai di area yang mungkin bukan bagian dari permintaan fitur dari tim produk.
Bill Leeper

9

Tidak menurut saya. Jika Anda membiarkan terlalu banyak waktu antara ketika Anda menemukan utang teknologi dan ketika Anda memperbaikinya, Anda kehilangan konteks tentang apa masalahnya. Butuh waktu lebih lama untuk memperbaikinya, dan itu cenderung diperbaiki lebih buruk. Yang paling penting, orang meninggalkan jendela yang rusak karena itu bukan "membersihkan minggu".

Secara pribadi, saya bernegosiasi untuk pembersihan utang teknis setiap sprint jika saya tahu kami telah membuat beberapa sprint sebelumnya. Itu membuat hutang segar di pikiran orang. Ini membatasi jumlah kode menggunakan kode masalah sehingga refactoring lebih mudah. Ini mencegah utang teknis dari menumpuk. Dan itu membantu mendorong pengembang dari hanya menampar sesuatu bersama, karena saya hanya akan membuat mereka melakukannya dengan sprint berikutnya (jadi sebaiknya lakukan dengan benar di tempat pertama).


Kalimat kedua Anda bertentangan dengan yang pertama. Anda mengatakan tidak, tetapi kemudian mengatakan Anda mengerjakan hal-hal seperti ini di setiap sprint. Dengan cara itulah penjadwalan waktu untuk melakukannya.
Bill Leeper

2
@BillLeeper - tingkatkan. Ketika saya mendengar "waktu reguler" itu berarti ada beberapa interval reguler untuk melakukan pekerjaan pembersihan. IMO, itu salah - sepanjang waktu adalah waktu yang tepat untuk melakukan pekerjaan pembersihan.
Telastyn

1
Poin bagus, saya setuju bahwa waktu reguler tidak bekerja dengan baik. Terlalu sering prioritas menyebabkan pembatalan, dll.
Bill Leeper

4

Saya akan mengatakan ya, dengan syarat: itu harus sering dilakukan, terutama setiap minggu. Saya percaya bahwa tinjauan kode reguler yang dijadwalkan ditambah dengan benar-benar bertindak pada item yang keluar dari tinjauan kode terbayar dengan sangat cepat. Lihat jawaban pswg

1 minggu setiap 2 bulan jelas tidak cukup sering. Ini berbicara kepada sebagian besar jawaban lain yang menjawab dengan 'Tidak' untuk pertanyaan Anda. Inti dari sebagian besar jawaban ini adalah bahwa jika Anda menunggu terlalu lama Anda tidak akan lagi berhubungan dengan kode dan biasanya membutuhkan waktu lebih lama untuk memperbaiki / membersihkan / refactor.


Kami melakukan "Utang Teknis Selasa" untuk ini. Setengah jalannya melemparkan seminggu kerja Israel dan memungkinkan kita mengambil langkah mundur untuk menangani masalah
Zachary K

1

Tidak begitu jelas apakah Anda bermaksud melakukan pembersihan kode tambahan sesekali. Dalam pengertian itu, ya. Apa pun praktik yang kita ikuti, beberapa degradasi selalu terjadi.

Anda tidak boleh menggunakannya sebagai alasan untuk tidak melakukan hal yang benar [Menerapkan prinsip-prinsip SOLID, tes unit yang relevan, inspeksi dll] sejak awal.


1

Saya pikir dua jawaban "Tidak" "Ya" yang populer saat ini adalah dua aspek dari kebenaran yang sama. Ingat OP berbicara tentang grup yang dia kelola, bukan hanya dirinya sendiri sebagai individu. Kami tidak dapat berasumsi bahwa semua pengembang dalam grup cukup disiplin untuk menulis kode yang bersih dan mudah dibaca; dan ada masalah tekanan eksternal dan metodologi gaya gesit. Juga, bahkan dengan upaya terbaik orang, perbedaan gaya mereka akan berarti mereka dapat menulis kode yang akan dianggap bersih ketika terpisah, tetapi tidak bersih ketika dianggap bersama-sama dengan orang lain (belum lagi antarmuka berderit).

Di sisi lain, "memperbaikinya sambil mengerjakannya" menurut saya ideal untuk dicita-citakan. Anda dapat membuat kode Anda lebih "diperbaiki" oleh

  • Rekan CRing hati-hati
  • unit menulis tes bersama dengan kode itu sendiri
  • mengadopsi pedoman pengkodean
  • menggunakan pemformat dan linter otomatis (tapi YMMV)
  • dll.

Sekarang, jika tim OP mengadopsi hal di atas, dan jika ia mendorong bawahannya - misalnya selama tinjauan kode dan selama sesi pembersihan kode berkala - untuk mencoba mengantisipasi jebakan dan menghindari keburukan di muka, lama-kelamaan ia / mereka diharapkan akan membutuhkan lebih sedikit waktu pembersihan. (Dan kemudian mereka dapat mencurahkan waktu itu untuk dokumentasi, refactoring yang lebih dalam, dan berbagi pengetahuan tentang apa yang telah mereka tulis dan konsolidasi.)


1

Saya pikir penjadwalan waktu reguler sangat baik apakah itu tugas dalam proyek gaya air terjun biasa, atau cerita dalam yang lincah. Memiliki waktu yang ditetapkan mungkin tidak sama berharganya dengan hanya mengerjakannya dalam jadwal Anda. Ini memungkinkan Anda menyelesaikannya sebagai bagian dari jadwal vs. membatalkan hari pembersihan karena Anda ketinggalan proyek.

Setelah mengelola sebuah proyek yang memiliki jumlah hutang kode yang luar biasa, mengerjakannya secara teratur adalah kunci agar semuanya berjalan lancar. Beberapa barang kami besar, ada yang kecil.

Setelah beberapa bulan melakukan pekerjaan semacam ini, pimpinan tim operasi kami memberi tahu saya betapa lancar semuanya berjalan.

Setiap item mungkin tidak tampak banyak, tetapi sama seperti semua hutang, iklannya naik.


1

Jawaban yang ideal adalah Tidak, karena Anda mengambil langkah-langkah yang diperlukan untuk menghindari menjadikan ini suatu keharusan (bersihkan seiring berjalannya waktu karena beberapa alasan yang telah dinyatakan).

Ini mungkin tujuan pada akhirnya, tetapi Anda mungkin memiliki tim yang jauh dari mempraktikkannya.

Manajer harus bertanggung jawab. Bukan selalu kesalahan pengembang. Manajer dapat mengatakan satu hal, tetapi mereka mulai mendorong proyek untuk selesai dan membuat saran yang mempromosikan praktik buruk. Mereka mungkin benar-benar berkata, "kita akan membersihkannya nanti" atau jika berhasil, itu cukup baik.

Anda mungkin harus mulai dengan mendedikasikan waktu tertentu untuk menunjukkan ini penting. Setelah Anda tahu tim Anda mampu membersihkan kode mereka (bukan yang diberikan), maka Anda dapat mencoba untuk memasukkannya lebih sering.

Akhirnya, Anda tidak perlu mengatur waktu.

Secara pribadi, saya berjuang dengan memecahkan masalah baru dan membuatnya bekerja sambil mencoba untuk menjaga hal-hal tetap rapi. Saya semakin baik dalam hal itu, tetapi sering mengambil istirahat yang disengaja dan membersihkan hal-hal. Bagi saya ini adalah pola pikir yang berbeda. Akhirnya, praktik yang solid menjadi kebiasaan.


-1

Tidak, Anda harus melakukan ini saat Anda membuat kode. Ini disebut refactoring jika Anda menggunakan TDD. Masalahnya ketika Anda menunggu satu atau dua bulan untuk memperbaiki dan membersihkan kode Anda adalah bahwa Anda dapat mengubah perilaku kode karena Anda tidak ingat setiap bagian dari kode Anda.

Saya menyarankan refactoring yang didasarkan pada pengkodean terlebih dahulu kode yang diperlukan untuk membuat sesuatu bekerja, dan segera setelah berfungsi mendesain ulang, mengoptimalkannya, dan membuatnya cantik.


Ini disebut refactoring apakah Anda menggunakan TDD atau tidak. Pertanyaan ini tidak ada hubungannya dengan TDD ...
Ben Lee
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.