Версификация кода

[Dimont]

Очень хочется внедрить версификацию кода . Поделитесь у кого есть какие идеи или наработки.

[Галина]

А что это такое?

[Dimont]

Это когда храняться версии изменений кода.
Т.е. кто что поменял сохранили в хронилище версий
Дальше другой сотрудник что-то поменял сохранили в хронилище версии

В любой момент мы можем поднять нужную нам версию и посмотреть кто и и что изменял.

[romeo]

У нас достаточными считаются комменты в коде с указанием номера задачи, даты и исполнителя + фобы хранят те, кто заливает объекты ... Бэкапы баз периодически, чтобы уж совсем непоправимое восстановить ...

[Yoil]

На mibuso.ru как-то постили на этому тему
http://www.mibuso.ru/forum/index.php?showtopic=3034

[Kirvisniemi]

Navision это не среда для одновременной разработки большим количеством сотрудников сложного функционала, поэтому такие вещи как средства для хранения кода во внешних файлах, возможность прикручивания другой IDE, а тем более возможность бренчинга и поддержки версионности (хотя бы на уровне Check In и Check Out) разработчиками просто не были предумотрены.

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

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

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

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

Есть конечно разработки вроде того же NCT, только вот сильно сомневаюсь, что ей практически кто-то пользуется - слишком уж примитивно

[Dimont]

Все это замечательно работает на конечных процессах внедрения функционала (читай проектная работа) с количеством разработчиков по одному функционалй в колличестве 1-2 чел. При этом со схемой выявления ошибок - я сам себе злобный тестер.

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

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

Использовать или не использовать средства версификации необходимо решаться должно административными ресурсами.

[Yoil]

Dimont, ну в Вашем "бональном" случае достаточно сотрудникам сохранять после каждого изменения отдельную версию объекта на диск (что-нибудь типа Form50_151105.fob)
На крайний случай можно поднять cvs и складывать фобы туда.

[Dimont]

Это понятно. Можно так же в текстовый формат экспортировать и выложить в VSS

[Галина]

А что в Development ?

[romeo]

А вообще код нужно комментировать, а не стирать.

[Dimont]

изучается

[Likefire]

Цитата:

Сообщение от romeo

А вообще код нужно комментировать, а не стирать.

<{POST_SNAPBACK}>

Видал я баяны коментированного-перекомментированного кода и могу сказать, что если команда разработчиков достаточно часто меняла свой состав, то в таких комментах разобраться подчас можно только при наличии поллитры. Давным-давно признано, что комментить код можно только в случае небольших локальных изменений, внесение которых сомнительно и может повлиять отрицательно на конечном качестве. А если внимательно читать методологию даже самого Нави,- там без труда можно найти положения о том, что каждый девелопер, совместно с консультантом должен детально документировать все изменения в документе под названием Desighn Specification. Если кто-нибудь сомневается в правильности моих слов, загляните на страницу 4-30 Navision Attain Solution Development.

[romeo]

2Likefire: Согласен. Но мы говорим в контексте темы "версификатора" ... Считаю, что для навижена нафиг надо. Образно выражаясь ...

[Шрэк]

Цитата:

Сообщение от Likefire

Цитата:

Сообщение от romeo

А вообще код нужно комментировать, а не стирать.

<{POST_SNAPBACK}>

А если внимательно читать методологию даже самого Нави,- там без труда можно найти положения о том, что каждый девелопер, совместно с консультантом должен детально документировать все изменения в документе под названием Desighn Specification. Если кто-нибудь сомневается в правильности моих слов, загляните на страницу 4-30 Navision Attain Solution Development.

<{POST_SNAPBACK}>

При чем тут Desighn Specification?
Для того, что вы понаваяли в процессе внедрения в целом описывается в документе Project Log и Change Log.
Документ Desighn Specification служит несколько иным целям. Это скорее руководство к действию для программистов, основанное на концептуальном дизайне, а также оценки времени и стоимости той или иной кастомизации, которая должна быть указана в конц. дизайне.

[DA_NEAL]

Сделал недавно несколько объектов как раз для совместной разработки. Принцип такой. При модификации объекта он блокируется (в ручную), т.е. записывается запись в определнную табличку. В этой табличке есть поле BLOB куда сливается текущий объект, а также ряд полей по коду задачи, пользователе, времени и признаке блокировки. В триггер таблички Object вставлен код который проверяет наличие в этой таблице модификаций записи с признаком открытой блокировки. Если Запись есть и пользователь в ней не совпадает с пользователем который модифицирует ему выдается предупреждение. После окончания модификации инициатор освобождает объект (в ручную). То есть запись в журнале модификаций помечается как закрытая.

P.S. Ест простенькое описание в атачменте

[DA_NEAL]

забыл приатачить

[Dimont]

Цитата:

Сообщение от romeo

А вообще код нужно комментировать, а не стирать.

<{POST_SNAPBACK}>

Итого: разаботка\доработка кода ведется достаточно давно и функционал достаточно прилично дописывается\переписывается, то можно накопить комментариев ЗНАЧИТЕЛЬНО больше, чем сам код. И нафиг это нужно.

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

В общем версификация нужна. Вопрос в необходимости и грамотности ее применения. В общем случае при кол-ве разработчиков > 2 она нужна. Та же она нужна как инструмент для хранения измениний на случай МАЛЕНЬКОЙ ТРАГЕДИИ со случайным сохранением

[Галина]

Цитата:

Сообщение от Роман

При чем тут Desighn Specification?
Для того, что вы понаваяли в процессе внедрения в целом описывается в документе Project Log и Change Log.
Документ Desighn Specification служит несколько иным целям. Это скорее руководство к действию для программистов, основанное на концептуальном дизайне, а также оценки времени и стоимости той или иной кастомизации, которая должна быть указана в конц. дизайне.

<{POST_SNAPBACK}>

Роман-ну объясните как описывать в них? вручную или с толкита выгружать?

[Шрэк]

Цитата:

Сообщение от Галина

Роман-ну объясните как описывать в них? вручную или с толкита выгружать?

<{POST_SNAPBACK}>

В документации по девелопменту описывается, что Change Log можно вести вручную или автоматически (DevTool).