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

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 16.11.2005, 14:04   #1  
Dimont is offline
Dimont
Участник
 
15 / 10 (1) +
Регистрация: 05.10.2005
Очень хочется внедрить версификацию кода . Поделитесь у кого есть какие идеи или наработки.
Старый 16.11.2005, 14:14   #2  
Галина is offline
Галина
Участник
 
1,132 / 28 (3) +++
Регистрация: 01.07.2003
А что это такое?
Старый 16.11.2005, 14:42   #3  
Dimont is offline
Dimont
Участник
 
15 / 10 (1) +
Регистрация: 05.10.2005
->
Это когда храняться версии изменений кода.
Т.е. кто что поменял сохранили в хронилище версий
Дальше другой сотрудник что-то поменял сохранили в хронилище версии

В любой момент мы можем поднять нужную нам версию и посмотреть кто и и что изменял.
Старый 16.11.2005, 14:44   #4  
romeo is offline
romeo
Участник
Аватар для romeo
 
564 / 10 (2) +
Регистрация: 31.03.2004
У нас достаточными считаются комменты в коде с указанием номера задачи, даты и исполнителя + фобы хранят те, кто заливает объекты ... Бэкапы баз периодически, чтобы уж совсем непоправимое восстановить ...
Старый 16.11.2005, 15:00   #5  
Yoil is offline
Yoil
NavAx
NavAx Club
Лучший по профессии 2017
Лучший по профессии 2009
 
1,574 / 70 (6) ++++
Регистрация: 20.11.2002
Адрес: Msk
На mibuso.ru как-то постили на этому тему
http://www.mibuso.ru/forum/index.php?showtopic=3034
__________________
"Моей лошадке ядрышком полмордочки снесло..."
А.В.Суворов, письма к дочери
Старый 16.11.2005, 15:37   #6  
Kirvisniemi is offline
Kirvisniemi
Moderator
 
342 / 13 (1) ++
Регистрация: 21.12.2004
Navision это не среда для одновременной разработки большим количеством сотрудников сложного функционала, поэтому такие вещи как средства для хранения кода во внешних файлах, возможность прикручивания другой IDE, а тем более возможность бренчинга и поддержки версионности (хотя бы на уровне Check In и Check Out) разработчиками просто не были предумотрены.

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

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

Именно поэтому, Navision изначально не имеет средств, позволяющих его сопрягать с системами контроля версий типа Source Safe, у него даже внутренняя архитектура другая - код хранится не в виде файлов, а в откомпилированном виде в системной таблице.

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

Есть конечно разработки вроде того же NCT, только вот сильно сомневаюсь, что ей практически кто-то пользуется - слишком уж примитивно
Старый 16.11.2005, 16:04   #7  
Dimont is offline
Dimont
Участник
 
15 / 10 (1) +
Регистрация: 05.10.2005
Все это замечательно работает на конечных процессах внедрения функционала (читай проектная работа) с количеством разработчиков по одному функционалй в колличестве 1-2 чел. При этом со схемой выявления ошибок - я сам себе злобный тестер.

Рассмотрим бональную схему - сотрудники последовательно выполняют задачи по доработке одного и того же объекта, но один из N сотрудников накосячил (к примеру стер нужный функционал) и чего нам в этом случае бэкап БД восстанавливать (хорошо если мы базируеся на SQL Server и у нас налажена система бэкапов)

По поводу лицензирования- данная функциональность нужна только девелоперу и может открываться его лицензией.
Разговор о бональном удобстве и безопасности разработки.

Использовать или не использовать средства версификации необходимо решаться должно административными ресурсами.
Старый 16.11.2005, 16:12   #8  
Yoil is offline
Yoil
NavAx
NavAx Club
Лучший по профессии 2017
Лучший по профессии 2009
 
1,574 / 70 (6) ++++
Регистрация: 20.11.2002
Адрес: Msk
Dimont, ну в Вашем "бональном" случае достаточно сотрудникам сохранять после каждого изменения отдельную версию объекта на диск (что-нибудь типа Form50_151105.fob)
На крайний случай можно поднять cvs и складывать фобы туда.
__________________
"Моей лошадке ядрышком полмордочки снесло..."
А.В.Суворов, письма к дочери
Старый 16.11.2005, 16:20   #9  
Dimont is offline
Dimont
Участник
 
15 / 10 (1) +
Регистрация: 05.10.2005
Это понятно. Можно так же в текстовый формат экспортировать и выложить в VSS
Старый 16.11.2005, 16:22   #10  
Галина is offline
Галина
Участник
 
1,132 / 28 (3) +++
Регистрация: 01.07.2003
А что в Development ?
Старый 16.11.2005, 16:33   #11  
romeo is offline
romeo
Участник
Аватар для romeo
 
564 / 10 (2) +
Регистрация: 31.03.2004
А вообще код нужно комментировать, а не стирать.
Старый 16.11.2005, 16:33   #12  
Dimont is offline
Dimont
Участник
 
15 / 10 (1) +
Регистрация: 05.10.2005
изучается
Старый 16.11.2005, 16:49   #13  
Likefire is offline
Likefire
Заноза в заднице
Аватар для Likefire
MCBMSS
Лучший по профессии 2009
 
547 / 50 (3) ++++
Регистрация: 22.10.2007
Адрес: Москва
Записей в блоге: 1
Цитата:
Сообщение от romeo
А вообще код нужно комментировать, а не стирать.
Видал я баяны коментированного-перекомментированного кода и могу сказать, что если команда разработчиков достаточно часто меняла свой состав, то в таких комментах разобраться подчас можно только при наличии поллитры. Давным-давно признано, что комментить код можно только в случае небольших локальных изменений, внесение которых сомнительно и может повлиять отрицательно на конечном качестве. А если внимательно читать методологию даже самого Нави,- там без труда можно найти положения о том, что каждый девелопер, совместно с консультантом должен детально документировать все изменения в документе под названием Desighn Specification. Если кто-нибудь сомневается в правильности моих слов, загляните на страницу 4-30 Navision Attain Solution Development.
__________________
Лень мудрого человека - это необходимое средство нейтрализации кипучей активности руководящих им дураков!
Старый 16.11.2005, 17:02   #14  
romeo is offline
romeo
Участник
Аватар для romeo
 
564 / 10 (2) +
Регистрация: 31.03.2004
2Likefire: Согласен. Но мы говорим в контексте темы "версификатора" ... Считаю, что для навижена нафиг надо. Образно выражаясь ...
Старый 16.11.2005, 17:17   #15  
Шрэк is offline
Шрэк
Участник
Аватар для Шрэк
 
645 / 24 (2) +++
Регистрация: 09.02.2004
Адрес: Москва
Цитата:
Сообщение от Likefire
Цитата:
Сообщение от romeo
А вообще код нужно комментировать, а не стирать.
А если внимательно читать методологию даже самого Нави,- там без труда можно найти положения о том, что каждый девелопер, совместно с консультантом должен детально документировать все изменения в документе под названием Desighn Specification. Если кто-нибудь сомневается в правильности моих слов, загляните на страницу 4-30 Navision Attain Solution Development.
При чем тут Desighn Specification?
Для того, что вы понаваяли в процессе внедрения в целом описывается в документе Project Log и Change Log.
Документ Desighn Specification служит несколько иным целям. Это скорее руководство к действию для программистов, основанное на концептуальном дизайне, а также оценки времени и стоимости той или иной кастомизации, которая должна быть указана в конц. дизайне.
__________________
MBS Certified Master in Navision Developer
Старый 16.11.2005, 17:40   #16  
DA_NEAL is offline
DA_NEAL
Участник
Аватар для DA_NEAL
Лучший по профессии 2017
Лучший по профессии 2009
 
788 / 54 (3) ++++
Регистрация: 05.08.2002
Адрес: Королев
Сделал недавно несколько объектов как раз для совместной разработки. Принцип такой. При модификации объекта он блокируется (в ручную), т.е. записывается запись в определнную табличку. В этой табличке есть поле BLOB куда сливается текущий объект, а также ряд полей по коду задачи, пользователе, времени и признаке блокировки. В триггер таблички Object вставлен код который проверяет наличие в этой таблице модификаций записи с признаком открытой блокировки. Если Запись есть и пользователь в ней не совпадает с пользователем который модифицирует ему выдается предупреждение. После окончания модификации инициатор освобождает объект (в ручную). То есть запись в журнале модификаций помечается как закрытая.

P.S. Ест простенькое описание в атачменте
__________________
Want to believe...
Старый 16.11.2005, 17:47   #17  
DA_NEAL is offline
DA_NEAL
Участник
Аватар для DA_NEAL
Лучший по профессии 2017
Лучший по профессии 2009
 
788 / 54 (3) ++++
Регистрация: 05.08.2002
Адрес: Королев
забыл приатачить
__________________
Want to believe...
Старый 16.11.2005, 17:47   #18  
Dimont is offline
Dimont
Участник
 
15 / 10 (1) +
Регистрация: 05.10.2005
Цитата:
Сообщение от romeo
А вообще код нужно комментировать, а не стирать.
Итого: разаботка\доработка кода ведется достаточно давно и функционал достаточно прилично дописывается\переписывается, то можно накопить комментариев ЗНАЧИТЕЛЬНО больше, чем сам код. И нафиг это нужно.

С другой стороны комментировать конечно нужно простые изменения, но всегда найдется ДУРАК или не очень, который СЛУЧАЙНО сотрет код.

В общем версификация нужна. Вопрос в необходимости и грамотности ее применения. В общем случае при кол-ве разработчиков > 2 она нужна. Та же она нужна как инструмент для хранения измениний на случай МАЛЕНЬКОЙ ТРАГЕДИИ со случайным сохранением
Старый 16.11.2005, 17:59   #19  
Галина is offline
Галина
Участник
 
1,132 / 28 (3) +++
Регистрация: 01.07.2003
Цитата:
Сообщение от Роман
При чем тут Desighn Specification?
Для того, что вы понаваяли в процессе внедрения в целом описывается в документе Project Log и Change Log.
Документ Desighn Specification служит несколько иным целям. Это скорее руководство к действию для программистов, основанное на концептуальном дизайне, а также оценки времени и стоимости той или иной кастомизации, которая должна быть указана в конц. дизайне.
Роман-ну объясните как описывать в них? вручную или с толкита выгружать?
Старый 16.11.2005, 18:33   #20  
Шрэк is offline
Шрэк
Участник
Аватар для Шрэк
 
645 / 24 (2) +++
Регистрация: 09.02.2004
Адрес: Москва
Цитата:
Сообщение от Галина
Роман-ну объясните как описывать в них? вручную или с толкита выгружать?
В документации по девелопменту описывается, что Change Log можно вести вручную или автоматически (DevTool).
__________________
MBS Certified Master in Navision Developer
 

Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

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

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

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