Предположим, у меня есть объект 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, которая поддерживает автозаполнение, ваши товарищи по команде должны заметить ваши изменения. Я просто надеюсь, что вы прокомментируете свой код.
источник