Bagaimana cara memberi tahu rekan setim apa perubahan yang saya buat pada suatu objek? [Tutup]


9

Misalkan saya memiliki objek PHP, katakanlah: companyObj.

class companyObj
{
  private company_name;
  private company_address;

  public function print_contact()
  {
    //logic
  }
}

Ini adalah objek yang saya tulis, dan dibagikan dengan rekan satu tim. Sekarang saya ingin membuatnya lebih kuat, seperti ini:

class companyObj
{
  private company_name;
  private company_address;
  private company_contact_person;

  public function print_contact()
  {
    //logic updated
  }
}

Sekarang, bagaimana saya bisa memberi tahu rekan tim saya bahwa objek saya memiliki lebih banyak atribut yang dapat mereka atur?

Alih-alih mengirim e-mail ke semua orang di tim pengembangan, bagaimana cara membuat tim tahu apa yang terjadi, ketika saya tidak ingin rekan tim saya membuang waktu mereka untuk melihat apa yang diubah pada tingkat kode sumber?


7
svn dapat membantu, karena mereka akan mengetahui bahwa ada sesuatu yang berubah dalam kode..jadi mereka dapat langsung memperbarui perubahan Anda (file tertentu mungkin ada dalam kasus Anda) .. tanpa harus tahu apa yang telah berubah (opsional jika mereka tidak mau to)
PresleyDias

1
ini adalah kelas yang telah Anda tulis bukan objek :) objek ada saat runtime bukan waktu kompilasi
Rune FS

Jawaban:


10

Itu sangat tergantung pada situasi konkret. Anggap saja properti baru yang Anda tambahkan adalah wajib, artinya properti itu harus selalu disetel. Kemudian Anda harus mencari sendiri melalui kode dan memperbaruinya di mana saja a companyObjdibuat, untuk memastikan bahwa itu dibangun dengan benar (termasuk mengatur properti baru). Saya berasumsi PHP memiliki konstruktor, dalam hal ini Anda hanya perlu menambahkan parameter konstruktor baru dan kompiler akan secara otomatis menandai setiap panggilan konstruktor tanpa parameter tambahan sebagai kesalahan kompilasi. Ini juga akan memastikan bahwa rekan tim belajar tentang properti baru segera setelah mereka menggunakan a companyObj.

Namun, jika properti baru itu opsional, semuanya menjadi kurang jelas. Anda mungkin atau mungkin tidak memiliki nilai default yang sesuai untuk itu. Dalam kasus yang terakhir, saya masih menyarankan Anda memperbarui semua kreasi instance untuk mengatur properti baru kapan saja sesuai. Ini untuk memastikan bahwa kode disimpan dalam kondisi yang konsisten setiap saat .

Mengkomunikasikan perubahan kepada rekan setim Anda adalah langkah lain yang jauh di sini. Tim tangkas lebih suka komunikasi tatap muka , dan, IMHO karena alasan yang baik. Mengandalkan dokumen adalah cara yang sangat lambat dan tidak efektif untuk menyebarkan informasi ke seluruh tim. Wiki agak lebih baik, tapi tetap saja, mendokumentasikan setiap atribut kelas tunggal adalah IMHO berlebihan. Itu hanya akan menjadi beban besar bagi tim, dan dengan cepat pasti menjadi tidak dapat diandalkan dan tidak berguna, karena kita adalah manusia sehingga kita terikat untuk melupakan pembaruan kadang-kadang, apalagi saya bertaruh bahwa tidak banyak anggota tim akan secara teratur periksa dokumentasi (baik dalam bentuk apa pun) untuk mendapat informasi tentang perubahan kode terbaru.

Yang terakhir ini juga berlaku untuk dokumentasi yang dibuat secara otomatis melalui misalnya Javadoc atau Doxygen. Meskipun mereka dapat dikonfigurasikan ke dalam bangunan otomatis untuk menjaga agar dokumentasi yang dihasilkan selalu mutakhir, saya belum pernah melihat tim pengembangan dengan anggota yang secara teratur menelusuri dokumentasi untuk mendapatkan informasi tentang perubahan kode terbaru. Dan jika Anda menggunakan sistem kontrol sumber apa pun, tempat pertama yang melihat perubahan adalah ketika Anda memperbarui salinan kode lokal Anda - maka Anda dapat memeriksa perubahan di kelas yang sudah dikenal dan melihat dengan tepat apa dan bagaimana telah berubah (bersama dengan penjelasan singkat dan / atau referensi ke ID tugas, jika tim Anda terbiasa menambahkan komentar check-in yang bermakna - yang akan hilang dari dokumen yang dibuat secara otomatis).

Komunikasi adalah salah satu alasan utama mengapa tim Extreme Programing melakukan pemrograman berpasangan. Jika Anda melakukan perubahan bersama dengan rekan satu tim, ada dua dari Anda segera yang tahu tentang setiap perubahan, dan lain kali Anda masing-masing akan berpasangan dengan orang lain, sehingga informasi yang berguna menyebar dengan cepat. Namun tidak selalu berlaku, karena berbagai alasan. Kecuali itu, Anda mungkin hanya berbicara dengan tetangga Anda tentang perubahan di saat yang tepat (misalnya saat makan siang, jika Anda makan siang bersama), atau mengirim email jika perubahan itu lebih besar, lebih penting atau lebih rumit.

Dalam kasus terakhir, mungkin ada alasan bagus untuk mendokumentasikannya dengan benar. Dokumen desain IMHO adalah yang terbaik ketika mereka menawarkan gambaran kasar tingkat tinggi dari sistem, sementara rincian implementasi ada dalam kode (mengikuti prinsip KERING ).


2
+1 Saya pikir semua orang di tim perlu dididik untuk tidak "membabi buta" memperbarui ke versi terbaru dari kode tetapi secara singkat memeriksa apa yang telah dilakukan dan di mana sebelum melakukannya. Dan seperti yang Anda katakan, komentar pendek tapi tepat itu bagus.
Jalayn

10

Sudahkah Anda mempertimbangkan untuk berbicara dengan mereka ? Jadwalkan pertemuan singkat: "Hei, saya membuat beberapa perubahan pada objek X, saya ingin menunjukkan kepada Anda apa yang berubah dan mengapa". Atau, berbicaralah dengan masing-masing orang secara individu jika rapat tampaknya terlalu formal atau mengganggu.


+1, entah bagaimana jawaban yang paling jelas tidak dipikirkan terlebih dahulu!
NoChance

2

Jika Anda memiliki tim, Anda mungkin juga memiliki dokumen desain. Jika tidak. memulai itu. Dan gunakan beberapa alat UML untuk memetakan desain Anda.


7
Ini kedengarannya bagus pada prinsipnya, bagaimanapun: 1. dokumen desain yang berisi setiap atribut kelas tunggal akan menjadi sakit di pantat untuk mempertahankan dan tetap sinkron dengan kode. 2. diagram UML terbalik direkayasa dari kode terikat menjadi praktis tidak berguna dalam proyek nontrivial segera, sekali lagi karena banyaknya detail di dalamnya.
Péter Török

Anda tidak perlu mendokumentasikan setiap kelas jika Anda memiliki terlalu banyak. Hanya orang-orang yang membuat antarmuka publik. Setuju bahwa untuk proyek besar itu akan menjadi rumit, tetapi lebih baik daripada tidak memiliki dokumen yang menentukan bagaimana berbagai bagian aplikasi berbicara satu sama lain.
DPD

1
Saya setuju tentang pentingnya dokumen arsitektur / desain tingkat tinggi (sebagaimana disebutkan dalam jawaban saya). Namun, itu level tinggi tepatnya sehingga tidak perlu terus diperbarui dengan perubahan sangat kecil.
Péter Török

1

Anda bisa menggunakan alat seperti doxygen di dalam kode Anda. Sekarang buat skrip yang akan menghasilkan dokumentasi doxygen dan menjalankannya secara teratur, mungkin sebagai bagian dari bangunan malam Anda (Anda membangun malam hari, bukan?).

Saya pikir Anda dapat menetapkan atribut khusus di doxygen sebagai tambahan untuk menyorotnya sebagai yang baru.

Jika rekan satu tim Anda bagus, mereka akan pergi melalui dokumentasi baru.


Mungkin saya belum pernah bekerja dengan rekan tim yang baik, karena saya belum pernah melihat pekerjaan ini dalam praktik :-(
Péter Török

@ PéterTörök Saya harus mengakui bahwa mereka jauh dan sedikit di antaranya, termasuk saya.
tehnyit

0

Sekarang, bagaimana saya bisa memberi tahu rekan tim saya bahwa objek saya memiliki lebih banyak atribut yang dapat mereka atur?

Nah, Anda seharusnya tidak memberi tahu rekan tim Anda tentang setiap hal kecil yang Anda buat. Kalau tidak, Anda harus mengirim banyak email. Jika ini adalah hal besar, maka Anda dapat melakukan pertemuan kecil, dan biarkan mereka tahu apa yang Anda lakukan (Jika Anda melakukan scrum, maka tidak perlu mengatur pertemuan terpisah).

Jika Anda menggunakan IDE yang mendukung penyelesaian otomatis, maka rekan kerja Anda akan melihat perubahan Anda. Saya hanya berharap Anda berkomentar kode Anda.

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.