|
23.07.2009, 22:31 | #1 |
Administrator
|
Цитата:
Поэтому тут - палка о двух концах. На одной чаше весов - разовое удобство переноса модификации для себя, на другой многократные попытки исследования кода для других. Поэтому - как разработчик - могу посоветовать НЕ комментировать свои модификации, стирать старый код и писать свой поверх. Единственный комментарий, который можно оставить - это у класса/формы/отчета в ClassDeclaration. Остальное - вполне можно видеть путем сравнения слоев (в крайнем случае сравнения со старым слоем). Не надо забывать, что за комментариями в коде надо "ухаживать", чтобы они не устаревали и оставались актуальными. В идеале я для себя вижу следующий вариант - если "врезка" нового кода "условно-мала" (условно-мала - это сколько?) по отношению к остальному коду в методе, то ее нужно снабдить комментариями. В противном случае - все надо стереть и оставить только одну свою метку. Все это нужно хранить ДО переноса модификации. После переноса - жестко стирать и удалять. Посмотрим на наш любимый Микрософт. Сравните кол-во комментариев в коде в 3-шке и в 4-ке - В 4-ке много потерли комментариев.
__________________
Возможно сделать все. Вопрос времени |
|
24.07.2009, 08:21 | #2 |
Участник
|
в таких случаях можно переименовать метод в old_name(), и создать новый метод name(), куда перенести только код, а в коментариях к нему перечислить все модификации, например.
Последний раз редактировалось ice; 24.07.2009 в 08:24. |
|
24.07.2009, 09:13 | #3 |
Участник
|
Цитата:
Сообщение от sukhanchik
А когда таких "модификаций" будет пару-тройку раз в одном месте кода - то у Вас комментариев будет больше чем кода и разобраться в нем совершенно новому человеку будет уже нереально. Первое желание, которое возникнет - стереть все комментарии .
Поэтому тут - палка о двух концах. На одной чаше весов - разовое удобство переноса модификации для себя, на другой многократные попытки исследования кода для других. Поэтому - как разработчик - могу посоветовать НЕ комментировать свои модификации, стирать старый код и писать свой поверх. Единственный комментарий, который можно оставить - это у класса/формы/отчета в ClassDeclaration. Остальное - вполне можно видеть путем сравнения слоев (в крайнем случае сравнения со старым слоем). Не надо забывать, что за комментариями в коде надо "ухаживать", чтобы они не устаревали и оставались актуальными. В идеале я для себя вижу следующий вариант - если "врезка" нового кода "условно-мала" (условно-мала - это сколько?) по отношению к остальному коду в методе, то ее нужно снабдить комментариями. В противном случае - все надо стереть и оставить только одну свою метку. Все это нужно хранить ДО переноса модификации. После переноса - жестко стирать и удалять. Посмотрим на наш любимый Микрософт. Сравните кол-во комментариев в коде в 3-шке и в 4-ке - В 4-ке много потерли комментариев. Вам никогда не приходилось откатывать назад модификации? Совместно с ведением архитектурного дизайна проекта, в котором учитываются изменения во всех затронутых объектах АОТ это получается действительно самое оптимальное решение. И поверьте, чужому человеку гораздо легче будет взглянуть на номер модифа в комменте и почитать ФД (ТЗ), чтобы понять, чего тут написано до него. А также, очень часто бывают случаи, когда по прошествии пользовательского тестирования нужно переносить в боевую базу объекты, в которых есть код из других модифов, что-то нужно переносить, что-то нет. Тут я задам скромный вопрос: Вы точно запомните, что нужно переносить?
__________________
// no comments |
|
24.07.2009, 09:28 | #4 |
Administrator
|
Цитата:
Сообщение от dech
Позвольте не согласиться
Вам никогда не приходилось откатывать назад модификации? Совместно с ведением архитектурного дизайна проекта, в котором учитываются изменения во всех затронутых объектах АОТ это получается действительно самое оптимальное решение. И поверьте, чужому человеку гораздо легче будет взглянуть на номер модифа в комменте и почитать ФД (ТЗ), чтобы понять, чего тут написано до него. А также, очень часто бывают случаи, когда по прошествии пользовательского тестирования нужно переносить в боевую базу объекты, в которых есть код из других модифов, что-то нужно переносить, что-то нет. Тут я задам скромный вопрос: Вы точно запомните, что нужно переносить? Откатывать модификации не так сложно, если: а) делать пул модификаций на верхнем слое, а затем оптом их переносить на нижний. б) есть бекап слоя до модификации. в) (человеческий фактор) есть чел, который в курсе, что надо изменить И наконец, да, я с Вами согласен .. если изменений немного и они касаются только конкретной модифы, которую нужно откатить. А когда модифа на модифе - тут уже ничего не спасает. А если в рамках модифы были методы удалены (например, убрано перекрытие в наследнике) - тут увы - никаких комментариев точно не останется. А вот в боевую базу надо не объекты переносить - а накатывать целиком приложение, предварительно откомпилированное, вылизанное и оттестированное.
__________________
Возможно сделать все. Вопрос времени |
|