Apa yang harus dilakukan sebagai pemimpin tim baru pada proyek dengan masalah rawatan?


19

Saya baru saja ditugaskan proyek kode dengan masalah rawatan. Apa yang bisa saya lakukan untuk mendapatkan proyek dengan stabil?

Saya menemukan diri saya di tempat di mana kami bekerja dengan sistem .NET multi-tier yang sangat besar yang kehilangan banyak hal penting seperti tes unit, IOC, MEF, terlalu banyak kelas statis, dataset murni dll. Saya hanya 24 tapi saya sudah di sini selama hampir tiga tahun (aplikasi ini telah dalam pengembangan selama 5) dan sebagian besar karena kendala waktu kami baru saja menambahkan lebih banyak omong kosong agar sesuai dengan omong kosong lainnya. Setelah melakukan sejumlah proyek di waktu luang, saya mulai memahami betapa pentingnya semua konsep itu. Juga karena perpindahan karyawan, saya mendapati diri saya sekarang menjadi pemimpin tim pada proyek ini dan saya benar-benar ingin membuat beberapa cara cerdas untuk meningkatkan aplikasi ini. Cara di mana nilai tersebut dapat dijelaskan kepada manajemen. Saya punya ide tentang apa yang ingin saya lakukan tetapi mereka semua tampak sangat luar biasa tanpa banyak keuntungan di muka. Setiap kisah tentang bagaimana orang akan atau akan berurusan dengan ini akan menjadi bacaan yang sangat menarik. Terima kasih.


Saya akan menyarankan investasi besar-besaran dalam alat cakupan kode seperti Re # dan StyleCop (gratis), dll. Jauh lebih murah untuk memiliki perangkat lunak mendeteksi masalah dalam kode sumber, setidaknya untuk pass pertama.
Pekerjaan

Jawaban:


14

Waktu anggaran untuk menyerang utang teknis. Kamu harus melakukannya. Bagian mana yang Anda serang pertama-tama tergantung pada tempat yang paling banyak menghabiskan waktu pengembang Anda saat ini, tetapi yang lebih penting adalah Anda memulai daripada memulai hal-hal yang ideal. Jika Anda menggunakan Scrum, letakkan potongan-potongan tertentu pekerjaan utang teknis pada jaminan Anda dan perlakukan mereka seperti fitur sampai Anda bisa mengatasinya.

Bekerja secara Efektif dengan Legacy Code sangat dianjurkan, dan mungkin akan bermanfaat. Saya belum membacanya, tetapi tampaknya memiliki banyak informasi tentang cara mendapatkan tes unit ke dalam kode warisan sehingga Anda dapat memodifikasinya dan membawanya terbaru dengan aman.

Gunakan analogi kartu kredit dengan manajemen - Anda "membayar bunga" untuk semua yang Anda lakukan karena sangat sulit untuk mencapai apa pun. Jika Anda membayar utang teknis Anda, Anda akan membebaskan sumber daya itu dan dapat mengembangkan fungsionalitas baru dengan lebih cepat di masa depan. Jika tidak, "pembayaran bunga" Anda (dibayar dalam waktu pengembangan) akan terus menumpuk dan tim Anda akan menghasilkan fungsionalitas baru yang lebih lambat.

Mungkin mulai memperkirakan jumlah waktu yang Anda habiskan setiap siklus berjuang melawan utang teknis untuk memberi mereka gambaran tentang berapa banyak yang telah terakumulasi. Jelaskan seperti apa perbaikan atau perubahan fitur dalam sistem yang dapat dipertahankan, seperti apa di sistem yang sebenarnya, dan perubahan apa yang perlu dilakukan atau bisa menjadi langkah pertama yang baik untuk sampai ke sana.


1
Saya telah membaca WEWLC, dan ini sangat bagus. Mungkin hal yang paling berharga yang disediakan buku ini adalah pengetahuan bahwa ADA cara-cara berurusan dengan hal-hal buruk yang Anda temui dalam proyek-proyek lama dan Anda BISA membalikkan proses pembusukan perangkat lunak.
Jason Swett

4

Gulung hutang teknis ke dalam perbaikan bug dan fitur tambahan.

Saya telah menemukan pendekatan berulang untuk perbaikan menghasilkan hasil terbaik. Mantra di tempat kerja saya adalah meningkatkan kualitas kode kapan pun Anda menyentuhnya. Setiap bagian dari pekerjaan apakah itu perbaikan bug atau fitur dimulai dengan analisis tentang apa yang dapat diperbaiki / direstorasi / dibersihkan. Kami mencoba membuat refactor setara (dalam skala) untuk pekerjaan yang harus kami selesaikan.

Buat daftar masalah yang terurut dalam basis kode. Pastikan semua orang mengetahui daftar dan urutan prioritas. Setiap kali mereka mendapatkan pekerjaan mereka harus mencari masalah dari daftar yang terkait dengan kode yang akan Anda kerjakan.

Ini tidak akan memperbaiki semuanya. Ada beberapa refaktor atau perbaikan yang membutuhkan banyak waktu dan sumber daya. Saya biasanya mencoba mengikatnya dengan karya besar lainnya yang akan bermanfaat.


1

Saya mungkin hanya menyatakan yang sudah jelas, tapi hei.

Tulis tes unit kecil yang melatih sejumlah kode yang memiliki masalah, lalu refactor kata chunk, memastikan bahwa tes masih berlalu. Pindah ke sepotong kode lain, kode yang dapat Anda jangkau paling mudah dari bagian kecil dari tanah padat yang baru saja Anda buat. Busa, bilas, ulangi.

Ini juga akan membantu Anda sedikit lebih terbiasa dengan basis kode.

Setelah Anda melakukan itu sebentar, Anda akan menemukan waktu untuk melakukan refactoring yang lebih panjang. Mencari tahu kode duplikat, pelanggaran prinsip KERING ... Anda tahu, hal-hal yang biasa. Pada saat itu Anda akan memiliki cakupan kode yang layak, yang akan memungkinkan Anda untuk mengacak metode, mengekstrak antarmuka dan semua fasilitas itu.

Selalu tinggalkan basis kode sedikit lebih baik daripada sebelum Anda mulai meretasnya. Saya cukup yakin ini adalah investasi kecil yang akan memberikan hasil, bahkan dalam jangka waktu yang tidak terlalu lama.


1

Anda dapat mencoba menjelaskan utang teknis yang dimiliki proyek ini untuk satu ide tentang mulai dari mana. Anda juga dapat mencoba untuk menawar bahwa karena perpindahan karyawan harus ada waktu yang dihabiskan untuk mempercepat kode dan ini berarti melakukan beberapa tes untuk membantu memastikan pengembangan masa depan yang lebih baik karena tes dapat membantu mencegah bug dan membuat segalanya lebih mudah untuk orang-orang baru untuk mengerjakan proyek mungkin.


1

Dalam kasus seperti itu, saya ingin mencoba merampingkan proyek sebanyak mungkin. Cari tahu fitur mana yang benar-benar diperlukan untuk membuatnya bergerak maju. Setiap sistem yang sudah ada sejak lama mungkin memiliki backlog yang sangat panjang. Banyak dari barang-barang ini akan menjadi kritis dan banyak hanya akan menjadi "lonceng dan peluit".

Sejauh pengujian, pengujian unit pasti akan membantu, tetapi Anda mungkin ingin meminta beberapa staf non-teknologi untuk berpartisipasi dalam pengujian dan mengirimkan bug ke anggota tim Anda.

Semoga berhasil.


1

Salah satu opsi adalah membersihkan resume Anda dan mulai mencari pekerjaan.

Pertanyaan yang bagus untuk ditanyakan kepada diri sendiri adalah apakah proyek yang berjalan buruk ini menandakan bagaimana seluruh perusahaan dijalankan. Jika jawabannya adalah ya, tanyakan apakah Anda dibayar cukup untuk tetap berada di perusahaan yang dijalankan dengan buruk.


Ya, beberapa pertanyaan untuk diajukan: Apakah manajemen menyerahkan Anda sebuah kapal yang ditinggalkan? Apa yang terjadi pada orang-orang lain yang dulu bekerja di basis kode? Apakah mereka pindah setelah melemparkan handuk di atas ring? Mungkin proyek itu sudah harus dihapus tanpa dikomunikasikan kepada Anda seperti itu? Apakah ada lebih banyak untuk diperbaiki maka ada untuk diselamatkan?
Joppe

0

Sering kali Anda dapat mendorong refactoring oleh manajemen tingkat atas jika Anda dapat memberi tahu mereka bahwa itu akan merupakan peningkatan kinerja atau perbaikan beberapa bug yang ada. Jangan faktor ulang hanya untuk mengubah sesuatu dengan apa yang akan Anda lakukan, terutama jika itu berhasil. Waktu perbaikan bug juga bisa menjadi cara yang baik untuk menyesuaikan dengan beberapa refactoring karena Anda sudah ada di sana. Bersikaplah asertif dan jangan melihatnya sebagai Anda lebih muda dari sesama coders Anda. Mulailah dengan sesuatu yang kecil seperti masuk ke beberapa unit pengujian dan bekerja dari sana, Anda mungkin mengekspos beberapa bug yang dapat membuat manajemen memberi Anda siklus untuk hal-hal lain.


0

Saat ini saya sedang membaca Pengembangan Aplikasi Brownfield di. NET yang, pada dasarnya, adalah tentang bagaimana menangani masalah yang Anda miliki saat ini. Sejauh ini saya suka sebagian besar dari apa yang dikatakannya (tidak semuanya - tetapi ini adalah jenis buku yang membantu Anda memikirkan jalan Anda sendiri melalui masalah, bukan buku yang dimaksudkan untuk sepenuhnya bersifat preskriptif). Ini dapat membantu dalam beberapa cara - ini menunjukkan Anda tidak sendirian; mudah-mudahan ini akan memberi Anda petunjuk tentang cara mengatasi beberapa masalah.

Pada dasarnya saya setuju dengan sebagian besar pendekatan - Anda tidak dapat memperbaiki semuanya dalam semalam, tetapi Anda dapat memperbaikinya secara bertahap dalam langkah-langkah yang sangat kecil. Dan ya - Hutang Teknis adalah metafora yang perlu Anda gunakan.


0

Pada akhirnya tergantung pada seberapa baik orang-orang Anda pada proyek. Jika kru yang sama yang menciptakan kekacauan, maka Anda memiliki sedikit peluang untuk membuatnya lebih baik dengan grup yang sama. Analisis staf Anda, cari tahu anggota terlemah Anda dan gantikan mereka (jika Anda memiliki kemampuan untuk melakukannya).

"Kamu tidak bisa membuat dompet sutra dari telinga babi".

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.