Alur kerja, mengedit hal-hal yang tidak ada dalam tugas Anda saat ini


12

Biasanya ketika saya memprogram, saya memiliki tugas yang jelas di depan saya, tetapi menemukan hal-hal yang mengganggu saya ingin membersihkan saat saya melanjutkan.

Di sini saya melihat tiga opsi:

  • Lakukan nanti (mungkin lupa / harus menghabiskan waktu menambahkan tiket)
  • Lakukan sekarang dan lakukan bersama dengan pekerjaan saya saat ini (tidak jelas)
  • Lakukan sekarang dan komit secara terpisah (harus menemukannya, mungkin membuat kesalahan dan memilih opsi # 2 secara tidak sengaja)

Ini mungkin cukup mendasar, tetapi apa saja cara untuk menghindari ini menggunakan svn / git / lainnya?



Saya biasanya pergi dengan opsi ke-2. Tetapi jika saya telah melakukan banyak refactoring saya melakukan dua komitmen terpisah. 1 untuk tugas spesifik saya dan yang lainnya hanya diberi label "Refactoring" yang saya rebaseganti merge.
Alternatex

Jawaban:


7

Secara pribadi, saya pikir itu tergantung :-).

  • Untuk perbaikan kecil , opsi tiga (sekarang, dalam komit terpisah) adalah yang terbaik, karena overhead melakukannya nanti tidak sepadan. Dalam hal ini, Anda cukup membuat komit terpisah. Cara melakukannya tergantung pada VCS yang Anda gunakan, dan merupakan pertanyaan terpisah :-).

  • Jika ini adalah perbaikan yang lebih besar , Anda membuat tiket. Kalau tidak, Anda berisiko terus-menerus tergelincir dari tugas utama Anda ("Oh, lihat, kesempatan lain untuk refactoring, oh, ada yang lain, dan di sana, dan di sana ...").


Untuk peluru pertama Anda, perbaikan kecil, melakukan pengeditan segera sepertinya pilihan terbaik. Saya tidak tahu mengapa saya tidak memikirkan itu, saya kira kebiasaan buruk. Saya cenderung mendapatkan sedikit ke bagian pengkodean pemrograman, sebagai lawan dari bagian manajemen kode :)
Nattfrosten

@Nattfrosten: Ya, itu wajar, dan tidak buruk - lagipula, fokusnya biasanya pada pengkodean. Manajemen kode hanya untuk membuat pengkodean lebih mudah.
sleske

5

Pertimbangkan ini. Ketika Anda "menemukan hal-hal yang mengganggu (...) untuk dibersihkan" dan Anda membuat keputusan eksekutif untuk melakukannya, Anda memotong sisa tim Anda dari diskusi prioritas dan keputusan. Anda membiarkan Anda truf orang agenda lain karena hubungan istimewa dengan kode. Saya pikir itu tidak baik. Dari pengalaman, itu juga mengarah pada kebencian tim / pemegang saham.

Sebaliknya, buat masalah / tugas untuk pembersihan / refactoring. Sementara itu segar di pikiran Anda, buatlah daftar alasannya penting: perkiraan peningkatan stabilitas, kemudahan perawatan, hal-hal semacam itu. Mungkin termasuk estimasi usaha tergantung pada bagaimana tim Anda bekerja. Kemudian dalam rapat pemilihan / penugasan / prioritas tugas Anda berikutnya, sampaikan tugas refactoring Anda dan posisikan itu terhadap tugas-tugas lain. Sebagai tim, putuskan kapan harus diselesaikan.

Tolong jangan berpikir aku menyuruhmu membuang akal sehat atas nama prinsip. Gunakan kepalamu. Jika ada sesuatu yang jelek dalam fungsi yang Anda edit, itu bukan tugas refactoring baru. Perbaiki dan periksa semuanya. Jika mengganti nama properti yang Anda kerjakan menjadi sesuatu yang lebih masuk akal memengaruhi beberapa file sumber tambahan, itu bukan tugas refactoring baru. Perbaiki dan periksa semuanya. Jika, di sisi lain, Anda tidak suka cara pengembang lain (Mitch, saya benci pria itu) melakukan sesuatu dalam fungsi yang tidak Anda edit dan mengatakan fungsi tampaknya berfungsi dengan baik, biarkan saja untuk saat ini. Buat tugas refactoring dan sajikan kasing Anda ke tim Anda.

Jika refactoring selalu dipilih oleh tim Anda demi fitur baru, mulailah mencari pekerjaan lain. Lebih mudah untuk menemukan pekerjaan ketika Anda sudah memilikinya.


1
Terima kasih banyak untuk balasan ini, sejauh ini saya sebagian besar terlibat dalam proyek solo, jadi dari situlah perspektif saya berasal. Saya harus mengubah banyak kebiasaan agar lebih cocok dengan tim nanti, dan hal seperti inilah yang saya butuhkan.
Nattfrosten

Kesimpulan yang sama, tetapi sering kali para bos memutuskan untuk menggunakan fitur baru dan tidak melakukan refactoring: - |
Mark Hurd
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.