Bagaimana tim saya dapat menghindari kesalahan yang sering terjadi setelah refactoring?


20

Untuk memberi Anda sedikit latar belakang: Saya bekerja untuk sebuah perusahaan dengan sekitar dua belas pengembang Ruby on Rails (+/- interns). Pekerjaan jarak jauh adalah hal biasa. Produk kami terbuat dari dua bagian: inti yang agak gemuk, dan menipis ke proyek pelanggan besar yang dibangun di atasnya. Proyek pelanggan biasanya memperluas inti. Timpa fitur utama tidak terjadi. Saya dapat menambahkan bahwa inti memiliki beberapa bagian yang agak buruk yang membutuhkan refactoring. Ada spesifikasi, tetapi sebagian besar untuk proyek pelanggan. Bagian terburuk dari inti tidak diuji (tidak seperti yang seharusnya ...).

Pengembang dibagi menjadi dua tim, bekerja dengan satu atau dua PO untuk setiap sprint. Biasanya, satu proyek pelanggan secara ketat dikaitkan dengan salah satu tim dan PO.

Sekarang masalah kita: Lebih sering, kita saling menghancurkan barang. Seseorang dari Tim A memperluas atau refaktor fitur inti Y, menyebabkan kesalahan tak terduga untuk salah satu proyek pelanggan Tim B. Sebagian besar, perubahan tidak diumumkan pada tim, sehingga bug yang terjadi hampir selalu tidak terduga. Tim B, termasuk PO, berpikir tentang fitur Y menjadi stabil dan tidak mengujinya sebelum melepaskan, tidak menyadari perubahan.

Bagaimana cara mengatasi masalah tersebut? 'Teknik pengumuman' seperti apa yang bisa Anda rekomendasikan kepada saya?


34
Jawaban yang jelas adalah TDD .
mouviciel

1
Kenapa Anda menyatakan bahwa "Menimpa fitur utama tidak terjadi", dan kemudian masalah Anda adalah bahwa hal itu terjadi? Apakah Anda membedakan dalam tim Anda antara "inti" dan "fitur utama", dan bagaimana Anda melakukannya? Hanya mencoba memahami situasinya ...
logc

4
@ mouvciel Itu dan tidak menggunakan pengetikan dinamis , tapi itu sedikit saran datang agak terlambat dalam kasus ini.
Doval

3
Gunakan bahasa yang sangat diketik seperti OCaml.
Gayus

@logc Mungkin saya tidak jelas, maaf. Kami tidak menimpa fitur inti seperti pustaka filter itu sendiri, tetapi menambahkan filter baru ke kelas yang kami gunakan dalam proyek pelanggan kami. Satu skenario umum dapat berupa, bahwa perubahan dalam pustaka filter menghancurkan filter yang ditambahkan di proyek pelanggan.
SDD64

Jawaban:


24

Saya akan merekomendasikan membaca Bekerja Efektif dengan Legacy Code oleh Michael C. Feathers . Ini menjelaskan bahwa Anda benar-benar membutuhkan pengujian otomatis, bagaimana Anda dapat dengan mudah menambahkannya, jika Anda belum memilikinya, dan "kode apa yang baunya" untuk diperbaiki dengan cara apa.

Selain itu, masalah inti lain dalam situasi Anda tampaknya adalah kurangnya komunikasi antara kedua tim. Seberapa besar tim-tim ini? Apakah mereka mengerjakan backlog yang berbeda?

Hampir selalu merupakan praktik buruk untuk memecah tim berdasarkan arsitektur Anda. Misalnya tim inti dan tim non-inti. Sebaliknya, saya akan membuat tim di domain fungsional, tetapi lintas komponen.


Saya telah membaca di "The Mythical Man-Month" bahwa struktur kode biasanya mengikuti struktur tim / organisasi. Dengan demikian, ini sebenarnya bukan "praktik buruk", tetapi hanya seperti biasanya.
Marcel

Saya pikir dalam " Dinamika pengembangan perangkat lunak ", manajer di belakang Visual C ++ merekomendasikan dengan jelas memiliki tim fitur; Saya belum membaca "The Mythical Man-Month", @Marcel, tetapi AFAIK mencantumkan praktik buruk di industri ...
logc

Marcel, memang benar bahwa ini adalah cara yang biasa dilakukan atau dilalui, tetapi semakin banyak tim yang melakukannya berbeda, misalnya tim fitur. Memiliki tim berbasis komponen mengakibatkan kurangnya komunikasi ketika mengerjakan fitur lintas komponen. Selain itu hampir selalu menghasilkan diskusi arsitektur yang tidak didasarkan pada tujuan arsitektur yang baik, tetapi orang-orang berusaha untuk mendorong tanggung jawab ke tim / komponen lain. Karenanya, Anda akan mendapatkan situasi yang dijelaskan oleh penulis pertanyaan ini. Lihat juga mountaingoatsoftware.com/blog/the-benefits-of-feature-teams .
Tohnmeister

Sejauh yang saya mengerti tentang OP, dia menyatakan bahwa tim tidak dibagi menjadi tim inti dan non-inti. Tim dibagi menjadi "per pelanggan", yang pada dasarnya adalah "per domain fungsional". Dan itu bagian dari masalah: karena semua tim diizinkan untuk mengubah inti bersama, perubahan dari satu tim mempengaruhi yang lain.
Doc Brown

@DocBrown Kamu benar. Setiap tim dapat mengubah inti. Tentu saja, perubahan itu seharusnya bermanfaat untuk setiap proyek. Namun, mereka bekerja pada backlog yang berbeda. Kami memiliki satu untuk setiap pelanggan dan satu untuk inti.
SDD64

41

Kami bagian terburuk dari inti tidak teruji (sebagaimana mestinya ...).

Ini masalahnya. Refactoring yang efisien sangat tergantung pada paket pengujian otomatis. Jika Anda tidak memilikinya, masalah yang Anda uraikan mulai muncul. Ini sangat penting jika Anda menggunakan bahasa dinamis seperti Ruby, di mana tidak ada kompiler untuk menangkap kesalahan dasar terkait dengan meneruskan parameter ke metode.


10
Itu dan refactoring dalam langkah-langkah bayi dan melakukan sangat sering.
Stefan Billiet

1
Mungkin ada rim saran yang dapat menambahkan saran di sini, tetapi semuanya akan sampai pada titik ini. Apa pun tentang OP "sebagaimana mestinya" lelucon yang menunjukkan bahwa mereka tahu itu masalah tersendiri, dampak pengujian tertulis pada refactoring sangat besar: Jika sebuah pass menjadi gagal, maka refactoring tidak berfungsi. Jika semua lintasan tetap lolos, maka refactoring mungkin berhasil (pindah gagal melewati jelas akan menjadi nilai tambah, tetapi menjaga semua lintasan sebagai lintasan lebih penting daripada keuntungan netto; perubahan yang memecah satu tes dan perbaikan lima mungkin merupakan perbaikan, tetapi bukan refactoring)
Jon Hanna

Saya memberi Anda "+1", tetapi saya pikir "tes otomatis" bukan satu-satunya pendekatan untuk menyelesaikan ini. Manual yang lebih baik, tetapi QA yang sistematis, mungkin oleh tim QA yang terpisah dapat menyelesaikan masalah kualitas juga (dan mungkin masuk akal untuk melakukan keduanya - tes otomatis dan manual).
Doc Brown

Poin yang baik, tetapi jika inti dan proyek pelanggan adalah modul yang terpisah (dan lebih lanjut dalam bahasa yang dinamis seperti Ruby), maka inti dapat mengubah tes dan implementasi yang terkait , dan memecahkan modul dependen tanpa gagal tes sendiri.
logc

Seperti orang lain berkomentar. TDD. Anda mungkin sudah mengenali bahwa Anda harus memiliki unit test sebanyak mungkin kode. Sementara menulis unit test hanya demi itu adalah pemborosan sumber daya, ketika Anda mulai refactoring komponen apa pun Anda harus mulai dengan penulisan tes yang luas sebelum menyentuh kode inti.
jb510

5

Jawaban sebelumnya yang mengarahkan Anda ke unit test yang lebih baik adalah baik, tetapi saya merasa bahwa mungkin ada masalah yang lebih mendasar untuk ditangani. Anda memerlukan antarmuka yang jelas untuk mengakses kode inti dari kode untuk proyek pelanggan. Dengan cara ini jika Anda memperbaiki kode inti tanpa mengubah perilaku seperti yang diamati melalui antarmuka , kode tim lain tidak akan rusak. Ini akan membuatnya lebih mudah untuk mengetahui apa yang bisa "dengan aman" dire-refored, dan apa yang perlu, mungkin antarmuka, desain ulang.


Spot on. Lebih banyak pengujian otomatis tidak akan menghasilkan apa-apa selain manfaat dan sepenuhnya layak dilakukan, tetapi itu tidak akan menyelesaikan masalah inti di sini yang merupakan kegagalan untuk mengkomunikasikan perubahan inti. Decoupling dengan membungkus antarmuka di sekitar fitur-fitur penting akan menjadi peningkatan besar.
Bob Tway

5

Jawaban lain telah menyoroti poin-poin penting (lebih banyak tes unit, tim fitur, antarmuka yang bersih ke komponen-komponen inti), tetapi ada satu poin yang saya temukan hilang, yaitu versi.

Jika Anda membekukan perilaku inti Anda dengan melakukan rilis 1 dan Anda menempatkan rilis itu ke dalam sistem manajemen artefak pribadi 2 , maka setiap proyek pelanggan dapat menyatakan ketergantungannya pada inti versi X , dan itu tidak akan rusak oleh rilis berikutnya X + 1 .

"Kebijakan pengumuman" kemudian hanya mengurangi memiliki file PERUBAHAN bersama dengan setiap rilis, atau memiliki pertemuan tim untuk mengumumkan semua fitur dari setiap rilis inti baru.

Juga, saya pikir Anda perlu mendefinisikan lebih baik apa itu "inti", dan apa bagian dari itu adalah "kunci". Anda tampaknya (dengan benar) menghindari membuat banyak perubahan pada "komponen utama", tetapi Anda mengizinkan perubahan yang sering ke "inti". Untuk mengandalkan sesuatu, Anda harus tetap stabil; jika ada sesuatu yang tidak stabil, jangan menyebutnya inti. Mungkin saya bisa menyarankan menyebutnya komponen "pembantu"?

EDIT : Jika Anda mengikuti konvensi dalam sistem Semantic Versioning , maka setiap perubahan yang tidak kompatibel dalam API inti harus ditandai oleh perubahan versi utama . Yaitu, ketika Anda mengubah perilaku inti yang sudah ada sebelumnya, atau menghapus sesuatu, bukan hanya menambahkan sesuatu yang baru. Dengan konvensi itu, pengembang tahu bahwa memperbarui dari versi '1.1' ke '1.2' adalah aman, tetapi beralih dari '1.X' ke '2.0' berisiko dan harus ditinjau dengan cermat.

1: Saya pikir ini disebut permata, di dunia Ruby
2: Setara dengan Nexus di Jawa atau PyPI dalam Python


"Versi" memang penting, tetapi ketika seseorang mencoba memecahkan masalah yang dijelaskan dengan membekukan inti sebelum rilis, maka Anda dengan mudah berakhir dengan kebutuhan untuk percabangan & penggabungan yang canggih. Alasannya adalah bahwa selama fase "rilis build" tim A, A mungkin harus mengubah inti (setidaknya untuk perbaikan bug), tetapi tidak akan menerima perubahan inti dari tim lain - sehingga Anda berakhir dengan satu cabang dari inti per tim, untuk digabung "nanti", yang merupakan bentuk utang teknis. Itu kadang baik-baik saja, tetapi sering kali hanya menunda masalah yang dijelaskan di kemudian hari.
Doc Brown

@DocBrown: Saya setuju dengan Anda, tetapi saya menulis dengan asumsi bahwa semua pengembang kooperatif dan dewasa. Ini bukan untuk mengatakan saya belum melihat apa yang Anda gambarkan . Tetapi bagian penting dari membuat sistem dapat diandalkan adalah, yah, berjuang untuk stabilitas. Lebih jauh, jika tim A perlu mengubah X di inti, dan tim B perlu mengubah X di inti, maka mungkin X tidak termasuk dalam inti; Saya pikir itu poin saya yang lain. :)
logc

@DocBrown Ya, kami belajar menggunakan satu cabang inti untuk setiap proyek pelanggan. Ini menyebabkan beberapa masalah lain. Misalnya, kami tidak suka 'menyentuh' sistem pelanggan yang sudah digunakan. Akibatnya, mereka mungkin menghadapi beberapa lompatan versi kecil dari inti yang digunakan setelah setiap penyebaran.
SDD64

@ SDD64: itulah yang saya katakan - tidak mengintegrasikan perubahan langsung ke inti umum ada solusi dalam jangka panjang juga. Yang Anda butuhkan adalah strategi pengujian yang lebih baik untuk inti Anda - dengan tes otomatis dan manual juga.
Doc Brown

1
Sebagai catatan, saya tidak menganjurkan inti yang terpisah untuk setiap tim, atau menyangkal bahwa tes diperlukan - tetapi tes inti dan implementasinya dapat berubah pada saat yang sama, seperti yang saya komentari sebelumnya . Hanya inti beku, yang ditandai oleh string rilis atau tag komit, yang dapat diandalkan oleh proyek yang dibangun di atasnya (tidak termasuk perbaikan bug dan asalkan kebijakan versi suara).
logc

3

Seperti yang dikatakan orang lain, serangkaian uji unit yang baik tidak akan menyelesaikan masalah Anda: Anda akan mengalami masalah saat menggabungkan perubahan, meskipun setiap suite uji tim lulus.

Sama untuk TDD. Saya tidak melihat bagaimana itu bisa menyelesaikan ini.

Solusi Anda bersifat non teknis. Anda perlu mendefinisikan dengan jelas batas "inti" dan menetapkan peran "anjing penjaga" untuk seseorang, baik itu pemimpin dev atau arsitek. Setiap perubahan pada inti harus melewati pengawas ini. Dia bertanggung jawab untuk memastikan setiap output dari semua tim akan bergabung tanpa terlalu banyak kerusakan jaminan.


Kami memiliki "anjing penjaga", karena ia menulis sebagian besar intinya. Sayangnya, dia juga bertanggung jawab untuk sebagian besar bagian yang belum diuji. Dia adalah YAGNI berkedok dan telah diganti setengah tahun yang lalu oleh dua orang lainnya. Kami masih berjuang untuk refactore 'bagian gelap' itu.
SDD64

2
Idenya adalah untuk memiliki unit uji unit untuk inti , yang merupakan bagian dari inti , dengan kontribusi dari semua tim, bukan suite tes terpisah untuk setiap tim.
Doc Brown

2
@ SDD64: Anda sepertinya bingung "Kamu belum akan membutuhkannya (belum)" (yang merupakan hal yang sangat baik) dengan "Kamu belum perlu membersihkan kode Anda (belum)" - yang merupakan kebiasaan buruk yang ekstrem , dan IMHO justru sebaliknya.
Doc Brown

Solusi pengawas benar-benar, sangat suboptimal, IMHO. Ini seperti membangun satu titik kegagalan ke dalam sistem Anda, dan yang paling lambat, karena melibatkan seseorang dan politik. Kalau tidak, TDD tentu saja dapat membantu dengan masalah ini: setiap tes inti adalah contoh untuk proyek pelanggan bagaimana inti saat ini seharusnya digunakan. Tapi saya pikir Anda memberikan jawaban dengan itikad baik ...
logc

@DocBrown: Oke, mungkin pemahaman kita berbeda. Fitur inti, yang ditulis olehnya, terlalu rumit untuk memuaskan bahkan kemungkinan yang paling aneh sekalipun. Kebanyakan dari mereka, kami tidak pernah temui. Kompleksitas memperlambat kita untuk memperbaiki mereka, di sisi lain.
SDD64

2

Sebagai perbaikan jangka panjang, Anda juga membutuhkan komunikasi yang lebih baik dan lebih tepat waktu antar tim. Setiap tim yang akan memanfaatkan, misalnya, fitur inti Y, perlu dilibatkan dalam membangun testcases yang direncanakan untuk fitur tersebut. Perencanaan ini, dengan sendirinya, akan menyoroti berbagai kasus penggunaan yang melekat dalam fitur Y antara kedua tim. Setelah bagaimana fitur harus bekerja dipakukan, dan testcases diimplementasikan dan disepakati, ada perubahan tambahan dalam skema implementasi Anda yang diperlukan. Tim yang melepaskan fitur diperlukan untuk menjalankan testcase, bukan tim yang akan menggunakannya. Tugas, jika ada, yang harus menyebabkan tabrakan, adalah penambahan testcase baru dari salah satu tim. Ketika seorang anggota tim memikirkan aspek baru dari fitur yang tidak diuji, mereka harus bebas menambahkan testcase yang telah mereka verifikasi lewat di kotak pasir mereka sendiri. Dengan cara ini, satu-satunya tabrakan yang akan terjadi akan berada pada tingkat niat, dan harus dipaku sebelum fitur refactored dilepaskan ke alam liar.


2

Sementara setiap sistem membutuhkan rangkaian pengujian yang efektif (yang berarti, antara lain, otomatisasi), dan sementara pengujian ini, jika digunakan secara efektif, akan menangkap konflik ini lebih cepat daripada yang ada sekarang, ini tidak mengatasi masalah yang mendasarinya.

Pertanyaan itu mengungkapkan setidaknya dua masalah mendasar: praktik memodifikasi 'inti' untuk memenuhi persyaratan bagi pelanggan individu, dan kegagalan tim untuk berkomunikasi dan mengoordinasikan niat mereka untuk melakukan perubahan. Tidak satu pun dari ini adalah akar penyebab, dan Anda harus memahami mengapa ini dilakukan sebelum Anda bisa memperbaikinya.

Salah satu hal pertama yang harus ditentukan adalah apakah pengembang dan manajer menyadari ada masalah di sini. Jika setidaknya ada yang melakukannya, maka Anda perlu mencari tahu mengapa mereka berpikir mereka tidak bisa berbuat apa-apa, atau memilih untuk tidak melakukannya. Bagi mereka yang tidak, Anda dapat mencoba meningkatkan kemampuan mereka untuk mengantisipasi bagaimana tindakan mereka saat ini dapat menciptakan masalah di masa depan, atau menggantinya dengan orang-orang yang bisa. Sampai Anda memiliki tenaga kerja yang menyadari bagaimana segala sesuatunya salah, Anda tidak mungkin dapat memperbaiki masalah (dan mungkin bahkan tidak, setidaknya dalam jangka pendek.)

Mungkin sulit untuk menganalisis masalah secara abstrak, setidaknya pada awalnya, jadi fokuslah pada insiden tertentu yang mengakibatkan masalah, dan cobalah untuk menentukan bagaimana itu terjadi. Karena orang-orang yang terlibat kemungkinan akan bersikap defensif, Anda harus waspada terhadap justifikasi yang melayani diri sendiri dan pasca-hoc untuk mengetahui apa yang sebenarnya terjadi.

Ada satu kemungkinan yang saya ragu untuk disebutkan karena sangat tidak mungkin: persyaratan pelanggan sangat berbeda sehingga tidak ada cukup kesamaan untuk membenarkan kode inti bersama. Jika demikian, maka Anda sebenarnya memiliki beberapa produk terpisah, dan Anda harus mengelolanya seperti itu, dan tidak membuat kopling buatan di antara mereka.


Sebelum kami memigrasikan produk kami dari Jawa ke RoR, kami benar-benar menyukai yang Anda sarankan. Kami memiliki satu inti Java untuk semua pelanggan, tetapi persyaratan mereka 'mematahkannya' suatu hari dan kami harus membaginya. Selama situasi itu, kami menghadapi masalah seperti: 'Bung, pelanggan Y memang memiliki fitur inti yang bagus. Sayang sekali kami tidak dapat mem-port-nya ke pelanggan Z, karena intinya tidak kompatibel '. Dengan Rails, kami sangat ingin menerapkan kebijakan 'satu inti untuk semua'. Jika memang harus demikian, kami masih menawarkan perubahan drastis, tetapi itu melepaskan pelanggan dari pembaruan lebih lanjut.
SDD64

Hanya menelepon TDD sepertinya tidak cukup bagi saya. Jadi, selain pemisahan saran inti, saya paling suka jawaban Anda. Sayangnya, intinya tidak diuji dengan sempurna, tetapi itu tidak akan menyelesaikan semua masalah kita. Menambahkan fitur inti baru untuk satu pelanggan mungkin tampak sangat bagus dan bahkan memberikan bangunan hijau, bagi mereka, karena hanya spesifikasi inti yang dibagikan di antara para pelanggan. Orang tidak memperhatikan, apa yang terjadi pada setiap pelanggan yang mungkin. Jadi, saya suka saran Anda untuk mencari tahu masalahnya dan membicarakan apa yang menyebabkannya.
SDD64

1

Kita semua tahu bahwa tes unit adalah cara yang harus dilakukan. Tetapi kita juga tahu bahwa secara retro-pas ini untuk suatu inti adalah sulit.

Teknik khusus yang mungkin berguna bagi Anda ketika memperluas fungsionalitas adalah mencoba untuk sementara dan memverifikasi lokal bahwa fungsi yang ada belum diubah. Ini bisa dilakukan seperti ini:

Kode semu asli:

def someFunction
   do original stuff
   return result
end

Kode uji sementara di tempat:

def someFunctionNew
   new do stuff
   return result
end

def someFunctionOld
   do original stuff
   return result
end

def someFunction
   oldResult = someFunctionOld
   newResult = someFunctionNew
   check oldResult = newResult
   return newResult
end

Jalankan versi ini melalui tes level sistem apa pun yang ada. Jika semuanya baik-baik saja, Anda tahu Anda tidak merusak barang-barang dan kemudian dapat melanjutkan untuk menghapus kode lama. Perhatikan bahwa ketika Anda memeriksa kecocokan hasil lama dan baru, Anda mungkin juga menambahkan kode untuk menganalisis perbedaan untuk menangkap kasus yang Anda tahu harus berbeda karena perubahan yang dimaksudkan seperti perbaikan bug.


1

"Sebagian besar, perubahan tidak diumumkan pada tim, jadi bug yang menyerang hampir selalu tidak terduga"

Masalah komunikasi, siapa pun? Bagaimana dengan (selain apa yang orang lain telah tunjukkan, bahwa Anda harus melakukan pengujian yang ketat) memastikan bahwa ada komunikasi yang tepat? Bahwa orang-orang dibuat sadar bahwa antarmuka yang mereka tulis akan berubah dalam rilis berikutnya dan apa perubahan itu nantinya?
Dan memberi mereka akses ke setidaknya dummy interace (dengan implementasi kosong) sesegera mungkin selama pengembangan sehingga mereka dapat mulai menulis kode mereka sendiri.

Tanpa semua itu, unit test tidak akan berbuat banyak kecuali menunjukkan selama tahap akhir bahwa ada sesuatu yang tidak beres antara bagian-bagian dari sistem. Anda ingin mengetahuinya, tetapi Anda ingin mengetahuinya sejak dini, sangat dini, dan meminta tim berbicara satu sama lain, mengoordinasikan upaya, dan benar-benar memiliki akses yang sering ke pekerjaan yang dilakukan tim lain (jadi komit reguler, tidak satu pun masif komit setelah beberapa minggu atau bulan, 1-2 hari sebelum pengiriman).
Bug Anda BUKAN dalam kode, tentu saja tidak dalam kode tim lain yang tidak tahu Anda bermain-main dengan antarmuka yang mereka tulis. Bug Anda dalam proses pengembangan Anda, kurangnya komunikasi dan kolaborasi antara orang-orang. Hanya karena Anda duduk di ruangan yang berbeda tidak berarti Anda harus mengisolasi diri dari orang lain.


1

Terutama, Anda memiliki masalah komunikasi (mungkin juga terkait dengan masalah pembangunan tim ), jadi saya pikir solusi untuk kasus Anda harus difokuskan pada ... well, komunikasi, daripada teknik pengembangan.

Saya menerima begitu saja bahwa tidak mungkin untuk membekukan atau garpu modul inti ketika memulai proyek pelanggan (jika tidak maka Anda hanya perlu mengintegrasikan dalam jadwal perusahaan Anda beberapa proyek yang tidak berhubungan dengan pelanggan yang bertujuan memperbarui modul inti).

Jadi kita pergi dengan masalah mencoba meningkatkan komunikasi antara tim. Ini dapat diatasi dengan dua cara:

  • dengan manusia. Ini berarti bahwa perusahaan Anda menunjuk seseorang sebagai arsitek modul inti (atau istilah apa pun yang baik untuk manajemen puncak) yang akan bertanggung jawab atas kualitas dan ketersediaan kode. Orang ini akan menjelma inti. Dengan demikian, ia akan dibagikan oleh semua tim dan memastikan sinkronisasi yang tepat di antara mereka. Selain itu, ia juga harus bertindak sebagai peninjau kode yang berkomitmen pada modul inti untuk mempertahankan koherensinya;
  • dengan alat dan alur kerja. Dengan menerapkan Integrasi Berkelanjutan pada inti, Anda akan menjadikan kode inti itu sendiri sebagai media komunikasi. Ini akan membutuhkan beberapa upaya terlebih dahulu (dengan menambahkan suite tes otomatis di atasnya) tetapi kemudian laporan CI malam akan menjadi pembaruan status kotor dari modul inti.

Anda dapat menemukan lebih banyak tentang CI sebagai proses komunikasi di sini .

Akhirnya, Anda masih memiliki masalah dengan kurangnya kerja tim di tingkat perusahaan. Saya bukan penggemar acara membangun tim, tapi sepertinya ini berguna. Apakah Anda melakukan pertemuan di seluruh pengembang secara teratur? Bisakah Anda mengundang orang-orang dari tim lain ke retrospektif proyek Anda? Atau kadang minum bir Jumat malam?

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.