Как сообщить товарищам по команде, какие изменения я внес в объект? [закрыто]

Предположим, у меня есть объект 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
  }
}

Теперь, как я могу уведомить моих товарищей по команде, что у моего объекта есть больше атрибутов, которые они могут установить?

Вместо того, чтобы посылать электронное письмо всем в команде разработчиков, как я могу заставить команду знать, что происходит, когда я не хочу, чтобы мои товарищи по команде тратили свое время, чтобы посмотреть, что изменилось на уровне исходного кода?

Это зависит от конкретной ситуации. Давайте предположим, что добавленное вами новое свойство является обязательным, то есть оно должно быть установлено всегда. Затем вы должны выполнить поиск по коду самостоятельно и обновлять его везде, где создается a companyObj, чтобы убедиться, что он построен правильно (включая установку нового свойства). Я предполагаю, что в PHP есть конструкторы, и в этом случае вам нужно всего лишь добавить новый параметр конструктора, и компилятор автоматически пометит каждый вызов конструктора без дополнительного параметра как ошибку компиляции. Это также гарантирует, что товарищи по команде узнают о новой собственности, как только они используют companyObj.

Однако, если новое свойство является необязательным, все становится не так ясно. Вы можете иметь или не иметь подходящее значение по умолчанию для него. В последнем случае я бы по-прежнему предлагал обновить все экземпляры, чтобы при необходимости установить новое свойство. Это делается для того, чтобы код постоянно находился в согласованном состоянии .

Сообщение об изменениях вашим товарищам по команде является еще одним, отдаленным шагом здесь. Agile команды предпочитают общение лицом к лицу , и, ИМХО, для этого есть все основания. Использование документов - очень медленное и неэффективное средство распространения информации в команде. Wiki несколько лучше, но, тем не менее, документирование каждого атрибута класса является ИМХО излишним. Это только станет огромным бременем для команды и быстро обречено стать ненадежным и бесполезным в любом случае, так как мы люди, поэтому мы обязаны иногда забывать об обновлениях, более того, держу пари, что не многие члены команды собираются регулярно проверьте документацию (будь то в любой форме), чтобы получить информацию о последних изменениях кода.

Последнее также верно для автоматически генерируемой документации, например, через Javadoc или Doxygen. Хотя их можно настроить в автоматическую сборку, чтобы постоянно обновлять сгенерированную документацию, я никогда не видел команды разработчиков, члены которой регулярно просматривали бы документацию, чтобы получать информацию о последних изменениях кода. И если вы используете какую-либо систему контроля версий, первое, что вы заметите, это изменения, когда вы все равно обновите свою локальную копию кода - тогда вы можете проверить наличие изменений в знакомых классах и точно увидеть, что и как изменилось (вместе с краткое объяснение и / или ссылка на идентификатор задачи, если ваша команда привыкла добавлять значимые комментарии для проверки - что будет отсутствовать в автоматически создаваемых документах).

Коммуникация - одна из главных причин, почему команды экстремального программирования занимаются парным программированием. Если вы вносите изменения вместе с товарищем по команде, сразу двое из вас знают о каждом изменении, и в следующий раз каждый из вас собирается соединиться с кем-то еще, поэтому полезная информация распространяется довольно быстро. Это не всегда применимо, хотя, по разным причинам. За исключением этого, вы можете просто поговорить со своими соседями об изменении в соответствующий момент (например, во время обеда, если вам случится обедать вместе), или отправить письмо по электронной почте, если это большее, более важное или более сложное изменение.

В последнем случае может быть веская причина для правильного документирования. Проектные документы IMHO являются лучшими, когда они предлагают грубый, подробный обзор системы, а детали реализации находятся в коде (придерживаясь принципа СУХОЙ ).

Рассматривали ли вы просто поговорить с ними ? Запланируйте короткую встречу: «Эй, я внес некоторые изменения в объект X, я хочу показать вам, что изменилось и почему». Или просто поговорите с каждым индивидуально, если встреча кажется слишком формальной или разрушительной.

Если у вас есть команда, у вас, вероятно, также есть проектный документ. Если не. начать на этом. И используйте некоторый инструмент UML, чтобы отобразить ваши проекты.

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

Я думаю, что вы можете назначить пользовательский атрибут в doxygen вашему дополнению, чтобы выделить его как новый.

Если ваши товарищи по команде хороши, они будут проходить новую документацию.

Теперь, как я могу уведомить моих товарищей по команде, что у моего объекта есть больше атрибутов, которые они могут установить?

Ну, вы не должны сообщать своим товарищам по команде о каждой мелочи, которую вы делаете. В противном случае вам придется отправлять много писем. Если это большая вещь, тогда вы можете устроить маленькое собрание и сообщить им, что вы сделали (если вы делаете разборки, вам не нужно назначать отдельное собрание).

Если вы используете IDE, которая поддерживает автозаполнение, ваши товарищи по команде должны заметить ваши изменения. Я просто надеюсь, что вы прокомментируете свой код.