AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX: Программирование
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 23.07.2009, 22:31   #1  
sukhanchik is offline
sukhanchik
Administrator
Аватар для sukhanchik
MCBMSS
Злыдни
Лучший по профессии 2015
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,286 / 3494 (123) ++++++++++
Регистрация: 13.06.2004
Адрес: Москва
Цитата:
Сообщение от dech Посмотреть сообщение
Наиболее оптимальный и действенный вариант - комментирование своих модификаций таким кодом
...
Вы всегда будете знать, что, кто и когда писал. А также неоценимую помощь вы почувствуете при переносе модификаций.
А когда таких "модификаций" будет пару-тройку раз в одном месте кода - то у Вас комментариев будет больше чем кода и разобраться в нем совершенно новому человеку будет уже нереально. Первое желание, которое возникнет - стереть все комментарии .

Поэтому тут - палка о двух концах. На одной чаше весов - разовое удобство переноса модификации для себя, на другой многократные попытки исследования кода для других.
Поэтому - как разработчик - могу посоветовать НЕ комментировать свои модификации, стирать старый код и писать свой поверх. Единственный комментарий, который можно оставить - это у класса/формы/отчета в ClassDeclaration. Остальное - вполне можно видеть путем сравнения слоев (в крайнем случае сравнения со старым слоем). Не надо забывать, что за комментариями в коде надо "ухаживать", чтобы они не устаревали и оставались актуальными.

В идеале я для себя вижу следующий вариант - если "врезка" нового кода "условно-мала" (условно-мала - это сколько?) по отношению к остальному коду в методе, то ее нужно снабдить комментариями. В противном случае - все надо стереть и оставить только одну свою метку.
Все это нужно хранить ДО переноса модификации. После переноса - жестко стирать и удалять.

Посмотрим на наш любимый Микрософт. Сравните кол-во комментариев в коде в 3-шке и в 4-ке - В 4-ке много потерли комментариев.
__________________
Возможно сделать все. Вопрос времени
Старый 24.07.2009, 08:21   #2  
ice is offline
ice
Участник
Аватар для ice
Лучший по профессии 2014
 
1,700 / 405 (17) +++++++
Регистрация: 23.03.2006
Цитата:
Сообщение от sukhanchik Посмотреть сообщение
А когда таких "модификаций" будет пару-тройку раз в одном месте кода - то у Вас комментариев будет больше чем кода и разобраться в нем совершенно новому человеку будет уже нереально. Первое желание, которое возникнет - стереть все комментарии .
в таких случаях можно переименовать метод в old_name(), и создать новый метод name(), куда перенести только код, а в коментариях к нему перечислить все модификации, например.

Последний раз редактировалось ice; 24.07.2009 в 08:24.
Старый 24.07.2009, 09:13   #3  
dech is offline
dech
Участник
Аватар для dech
Самостоятельные клиенты AX
 
643 / 347 (13) ++++++
Регистрация: 25.06.2009
Адрес: Омск
Записей в блоге: 3
Цитата:
Сообщение от sukhanchik Посмотреть сообщение
А когда таких "модификаций" будет пару-тройку раз в одном месте кода - то у Вас комментариев будет больше чем кода и разобраться в нем совершенно новому человеку будет уже нереально. Первое желание, которое возникнет - стереть все комментарии .

Поэтому тут - палка о двух концах. На одной чаше весов - разовое удобство переноса модификации для себя, на другой многократные попытки исследования кода для других.
Поэтому - как разработчик - могу посоветовать НЕ комментировать свои модификации, стирать старый код и писать свой поверх. Единственный комментарий, который можно оставить - это у класса/формы/отчета в ClassDeclaration. Остальное - вполне можно видеть путем сравнения слоев (в крайнем случае сравнения со старым слоем). Не надо забывать, что за комментариями в коде надо "ухаживать", чтобы они не устаревали и оставались актуальными.

В идеале я для себя вижу следующий вариант - если "врезка" нового кода "условно-мала" (условно-мала - это сколько?) по отношению к остальному коду в методе, то ее нужно снабдить комментариями. В противном случае - все надо стереть и оставить только одну свою метку.
Все это нужно хранить ДО переноса модификации. После переноса - жестко стирать и удалять.

Посмотрим на наш любимый Микрософт. Сравните кол-во комментариев в коде в 3-шке и в 4-ке - В 4-ке много потерли комментариев.
Позвольте не согласиться
Вам никогда не приходилось откатывать назад модификации? Совместно с ведением архитектурного дизайна проекта, в котором учитываются изменения во всех затронутых объектах АОТ это получается действительно самое оптимальное решение. И поверьте, чужому человеку гораздо легче будет взглянуть на номер модифа в комменте и почитать ФД (ТЗ), чтобы понять, чего тут написано до него. А также, очень часто бывают случаи, когда по прошествии пользовательского тестирования нужно переносить в боевую базу объекты, в которых есть код из других модифов, что-то нужно переносить, что-то нет. Тут я задам скромный вопрос: Вы точно запомните, что нужно переносить?
__________________
// no comments
Старый 24.07.2009, 09:28   #4  
sukhanchik is offline
sukhanchik
Administrator
Аватар для sukhanchik
MCBMSS
Злыдни
Лучший по профессии 2015
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,286 / 3494 (123) ++++++++++
Регистрация: 13.06.2004
Адрес: Москва
Цитата:
Сообщение от dech Посмотреть сообщение
Позвольте не согласиться
Вам никогда не приходилось откатывать назад модификации? Совместно с ведением архитектурного дизайна проекта, в котором учитываются изменения во всех затронутых объектах АОТ это получается действительно самое оптимальное решение. И поверьте, чужому человеку гораздо легче будет взглянуть на номер модифа в комменте и почитать ФД (ТЗ), чтобы понять, чего тут написано до него. А также, очень часто бывают случаи, когда по прошествии пользовательского тестирования нужно переносить в боевую базу объекты, в которых есть код из других модифов, что-то нужно переносить, что-то нет. Тут я задам скромный вопрос: Вы точно запомните, что нужно переносить?
Ну я ж говорю - что это палка о двух концах - забота о себе любимом (откат модификаций и проч) и забота о будущих ковырятелях кода (когда что-то не работает)

Откатывать модификации не так сложно, если:
а) делать пул модификаций на верхнем слое, а затем оптом их переносить на нижний.
б) есть бекап слоя до модификации.
в) (человеческий фактор) есть чел, который в курсе, что надо изменить

И наконец, да, я с Вами согласен .. если изменений немного и они касаются только конкретной модифы, которую нужно откатить. А когда модифа на модифе - тут уже ничего не спасает. А если в рамках модифы были методы удалены (например, убрано перекрытие в наследнике) - тут увы - никаких комментариев точно не останется.

А вот в боевую базу надо не объекты переносить - а накатывать целиком приложение, предварительно откомпилированное, вылизанное и оттестированное.
__________________
Возможно сделать все. Вопрос времени
Теги
программирование

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
Проблема с передачей контролов из формы в класс matew DAX: Программирование 0 28.04.2008 17:37
запретить вносить изменения в AOT kitty DAX: Администрирование 2 27.06.2006 07:52
траблы при выделении черным цветом и указанием слоя изменения кода... NetBus DAX: Программирование 8 14.07.2005 18:31
Сводное планирование - изменения&изменения мин. Alexm DAX: Прочие вопросы 1 05.04.2005 10:43
Русская локализация Axapta 3 ? SlavaK DAX: Администрирование 59 01.07.2003 22:38

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 08:53.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.