Як дозволити товаришам по команді знати, які зміни я внесла до об'єкта? [зачинено]

Припустимо, у мене є об'єкт PHP, скажімо: companyObj.

class companyObj
{
  private company_name;
  private company_address;

  public function print_contact()
  {
    //logic
  }
}

Це об’єкт, про який я написав і яким поділився з товаришами по команді. Тепер я хотів би зробити його більш потужним, наприклад:

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

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

Тепер, як я можу повідомити своїх товаришів по команді, що мій об’єкт має більше атрибутів, які вони можуть встановити?

Замість того, щоб надсилати електронні листи всім, хто працює в команді розробників, як я можу змусити команду знати, що відбувається, коли я не хочу, щоб мої товариші по команді витрачали час на перегляд того, що зміниться на рівні вихідного коду?

Багато що залежить від конкретної ситуації. Припустимо, додане вами нове властивість є обов'язковим, тобто його потрібно встановлювати завжди. Потім потрібно самостійно шукати код і оновлювати його скрізь, де companyObjстворюється, щоб переконатися, що він правильно побудований (включаючи встановлення нового властивості). Я припускаю, що у PHP є конструктори, і в цьому випадку вам потрібно лише додати новий параметр конструктора, і компілятор автоматично позначатиме кожен виклик конструктора без додаткового параметра як помилку компіляції. Це також забезпечить, що товариші по команді дізнаються про нове майно, як тільки вони користуються companyObj.

Якщо нова властивість не є обов'язковою, все є менш зрозумілим. Ви можете мати або не мати відповідного значення за замовчуванням для нього. В останньому випадку я все ж пропоную вам оновити всі створення екземплярів, щоб встановити нову властивість, коли це можливо. Це потрібно для того, щоб код постійно знаходився в постійному стані .

Повідомлення про зміну своїм товаришам по команді - це ще один, далекий крок тут. Спритні команди віддають перевагу спілкуванню віч-на-віч , і, ІМХО з поважної причини. Посилання на документи - це дуже повільний і неефективний засіб поширення інформації навколо команди. Вікі дещо краще, але все-таки документування кожного атрибуту кожного класу є надмірним вбивством IMHO. Це стане лише величезним тягарем для команди, і це швидше стане ненадійним і марним у будь-якому разі, оскільки ми люди, тому ми неодмінно забудемо оновлення іноді, більше того, я думаю, що не багато членів команди збираються регулярно перегляньте документацію (будь то в будь-якій формі), щоб отримати інформацію про останні зміни коду.

Останнє також стосується автоматично створеної документації, наприклад, через Javadoc або Doxygen. Хоча вони можуть бути налаштовані в автоматичну збірку, щоб постійно оновлювати згенеровану документацію, я жодного разу не бачив команди розробників із членами, які регулярно переглядають документацію, щоб отримати інформацію про останні зміни коду. І якщо ви використовуєте будь-яку систему управління джерелом, перше місце помітити зміни, коли ви все одно оновите свою локальну копію коду - тоді ви можете перевірити зміни в знайомих класах і точно побачити, що і як змінилося (разом із коротке пояснення та / або посилання на ідентифікатор завдання, якщо ваша команда звикла додавати змістовні коментарі до реєстрації, - чого не буде виставлено в автоматично створених документах).

Комунікація - одна з головних причин, чому команди Extreme Programing займаються парним програмуванням. Якщо ви внесете зміни разом з товаришем по команді, відразу двоє з вас знають про кожну зміну, і наступного разу кожен з вас збирається з'єднатися з кимось іншим, тому корисна інформація поширюється досить швидко. Однак це не завжди можливо з різних причин. Заперечуючи це, ви можете просто поговорити зі своїми сусідами про зміну у відповідний момент (наприклад, під час обіду, якщо трапляєтесь обідати разом), або надіслати пошту, якщо це більша, важливіша чи складніша зміна.

В останньому випадку може бути вагомий привід правильно її документувати. Документи проектування IMHO найкраще, коли вони пропонують грубозернистий огляд системи високого рівня, тоді як деталі щодо впровадження містяться в коді (дотримуючись принципу DRY ).

Ви думали просто говорити з ними ? Заплануйте коротку зустріч: "Ей, я змінив об'єкт X, я хочу показати вам, що змінилося і чому". Або просто поговоріть з кожною людиною окремо, якщо зустріч здається занадто формальною чи руйнівною.

Якщо у вас є команда, ви, ймовірно, також маєте проектний документ. Якщо ні. починайте з цього. І скористайтеся деяким інструментом UML для складання проектів.

Ви можете використовувати такий інструмент, як doxygen, в коді. Тепер створіть сценарій, який би генерував доксигенну документацію, і запускайте її регулярно, можливо, як частину вашої нічної збірки (ви робите нічну збірку, правда?).

Я думаю, ви можете призначити власному атрибуту в doxygen своєму додатку, щоб виділити його як новий.

Якщо ваші товариші по команді добрі, вони переглянуть нову документацію.

Тепер, як я можу повідомити своїх товаришів по команді, що мій об’єкт має більше атрибутів, які вони можуть встановити?

Ну, ви не повинні інформувати своїх колег про кожну дрібницю, яку ви робите. В іншому випадку вам доведеться надсилати багато електронних листів. Якщо це велика річ, то ви можете зробити невелику зустріч, і дайте їм знати, що ви зробили (Якщо ви робите сутичку, то не потрібно встановлювати окрему зустріч).

Якщо ви використовуєте IDE, який підтримує автоматичне завершення, ваші товариші по команді повинні помітити вашу зміну. Я просто сподіваюся, що ви коментуєте свій код.