Добрый день, коллеги.

Сидим вдвоём, кода много, следов минцувших кодеров немало, хочется читаемости и понятности. Что посоветуете?

(О конфе. Собственная конфа оперативного, бухгалтерского и МСФОшного учёта. 8.2, толстый клиент).

(0) Стандарты 1С на ИТС читал?

Пройти 1С Совместимо

(1) Чур меня. Мне б что-нибудь простое, практичное и разумное, что люди используют. А этих теоретиков я не очень высоко ценю.

+(2) скорее попытаться пройти...

(2) Сразу после того, как их конфы пройдут эту совместимость.

Конфа своя, не тиражная ни разу. Цель - удобство разработки и уменьшение ошибок.

Как минимум проанализировать что именно не нравится в конфе и подумать, как этого избежать...

Почитать "Система стандартов и методик разработки конфигураций для платформы 1С:Предприятие"

Почитать умные книги и статьи по разработке и программированию

(4) совместимо проходится легко... а вот вроде еще есть совместно - там ж...

Стандарты 1С на ИТС -- калька со стандартов разработки на С

(8) мы полгода пытались пройти ее как то, причем сам по себе функционал не менялся

(8) Это совсем другая история...

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

http://www.ozon.ru/context/detail/id/5011068/

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

На 1С Совместимо такие шедевры проходят... Читабельность (и т.д.) тут мало при чем.

По своему многолетнему опыту управления котами (программистами) - единственным реально работающим средством является жесткий контроль выполнения всех задач одним человеком.

Берете софтину для планирования работ и постановки задач.
1. Старший ставит задачу
2. Программист пишет
3. При приемке старший проверяет качество кода/проектирования. Сначала каждую строчку - через полгода контроль можно будет ослабить.

например, можете использовать http://vikit.ru/products/soratnik

(15) Эт чо, реклама?

(16)
1. это работающая у нас методика.
2. а вот применимость пиндоских методик из (13) в российских условиях большой вопрос.

(15) Спасибо, свой трекер вовсю используется, и даже пользователи в него заносят и обсуждают задания.

Сейчас я ищу простую (больше 2 страниц не хочу) инструкцию вида "Назови локальную переменную Счётчика Сч, и да продлится жизненный цикл твоего кода".

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

(19) все по той же ссылке ты можешь в демке посмотреть качество кода и понятность. Сделано исключительно по такой методике. Число программистов, работавших одновременно над проектом в разное время - от 1-го до 4-ех. И ничего - код получился понятным и читаемым. А все потому что без моей тщательной инспекции не одна строчка кода в релиз не попадала.

(20) сколько времени уходит на аудит в процентном соотношении и были ли другие задания у тебя, то есть вырывал ли из контекста аудит?

В какой момент происходит приемка задачи? на конфе исполнителя, получается через хранилище или еще как?

Есть ли какие нить фокусы с быстрым получением списка изменений, например посмотреть сравнение/объединение предыдущей версии хранилища с текущей...

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

Тестирование не автоматизировано, массово переписывать иимеющийся код разного качества не планируем, пользовательскую документацию ведём.

(20) и наиух кому-то нужны кодеры, которым в таком масштабе надо сопли подтирать и штанцы подтягивать? Затраты на контроль в твоей модели превышают затраты на создание полезного кода.
(21) как это у тебя так ловко в одном предложении ужилось "быстрое получение списка изменений" и "сравнение/объединение предыдущей версии хранилища"? :)

такой контроль, доверху набитый фашизмом пополам с обедненным ураном, - признак того, что чо-то не с кадровой политикой, ИМХО.

(24) ну у меня 3-4 конфы открыто обычно, в одной запустил сравнение, ушел в другую... всяко лучше, чем ручками лазить по доработкам в УПП например

(21)
Да, кроме аудита я занимаюсь текущей деятельностью.
С помощью того же софта посчитано, что на прием/постановку уходит до 30% общего рабочего времени. Зависит от стадии. В стадии разработки - 10% рабочего времени (1 раз в день проверить задачи поисполнителю); в стадии исправления ошибок и тщательного тестирования - получается что отправляешь на доработки одному исполнителю задачи, а второй уже в очереди стоит и так целый день они бегают. Может целый день уйти на вылавливание багов и мелочей.

Процесс следующий:
План вносим в "Соратник"
На основании плана раздаем "Задачи"
Исполнители выполняют задачи в хранилище и помещают все в хранилище. При этом отмечают в выполненных дела в "Соратнике" внесенные изменения (укрупненно: например "доработано заполнение обработки ХХХ. Исправлен запрос.")
Отмечают задачу как выполненую - он приходит мне на контроль.
Я сначала смотрю общую работоспособность того что сделано. Потом проверяю отмеченные в "Соратнике" изменения. Уже глаз набит - мне достаточно знать, куда программист руку приложил и я примерно знаю где искать г.но.

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

(28) согласен только с тем, что за "каждый динамически ставит то, что ему вздумается" надо рукти отрывать по самые ногти.

Меня пугает то, что кодер в твоей модели может быть пустоголовым рукодолбом, ни какой ответственности не несущим. Хотя, наверное, по результатам контроля можно раздавать слонов и пряников, чтобы этого не происходило... Надо подумать

(29)
ты путаешь постановку задачи и контроль выполнения.
в выборе средств программист должен быть свободен - иначе это быдлокодер. Но понимать, что если понапроектирует через анус - то получит звезды и будет переделывать.

Я имею ввиду нормальную командную работу с передачей работы другим членам команды и последующей проверкой этой работы. Кстати, на своем опыте убедился, что один хороший программист + 2 обычных программиста, которым он ставит задачи и контролирует сделают больше и качественнее чем 2 хороших программиста. По деньгам примерно одинаково, а результат выше =)

(30)>один хороший программист + 2 обычных программиста, которым он ставит задачи и контролирует сделают больше и качественнее чем 2 хороших программиста.

это так не только в кодинге

юзай ДлинныеМнемоническиеИменаПеременных

http://infostart.ru/public/79901/

100 лет назад, ну, не 100, а скажем, 40, появилась книга
Брукса "Мифический человекомесяц". И там подробно рассказано, как организуется труд бригады программистов.
Ну, например, в бригаде - только один программирует, никому ничего не раздает, а сам все пишет.

(0) 1с твой 1ый язык?

(27) К сожалению коллективная разработка намного сложнее простого плана с фактом. Как, например, оценивать соотношение запланированного времени к фактическому? Как определить, что задача является неделимой и её можно отдавать в работу? И т.д. и т.п. там ну просто гора нюансов, которые, как правило, решают методом тыка. Из всего этого и формируется то, что автора сподвигнуло на такой вопрос

А вообще, стандарты от 1С очень даже не плохие. Их надо только немного допилить под себя и все. Почти все пункты приобрели статус "по возможности" и все. При чем пока читал внимательно, в голове отложилось многое. Особенно с чем не согласен, это с тем, что строки надо группировать при помощи ТАБ после равно и локальные переменные надо бы обязательно объявлять локально

озвучу вопрос в этой ветке:


у 1С есть стандарты "внесения изменений" в типовые..
один из которых требует наличия префиксов у добавляемых объектов.


вопрос: скрещиваю ужа с ежом (типовую бп 2.0 и БСП) - чтобы ненарушить стандарты нужно ли делать префиксы у переносимых из БСП модулей, объектов и тд? :)

БСП это что? Я что-то не в теме.
А вообще, 1С явно сказала "внесения изменений", а не скрещивание 2-х огромных конф

пилять... дурень... БСП = библиотека стандартных подсистем, сам же всем так пишу :(

(39) ну дык я и вношу изменения..

беру подсистему например версионирование.. и вношу ее как изменение типовой БП :)

(41) Вот смотри, ты вносишь изменения, добавляешь объекты, пишешь модули и всему присваиваешь префикс мой_. Все аккуратно и красиво. Теперь в твоем случае ты одну стандартную цепляешь к другой. Да тут даже не понятно куда префиксы то добавлять: в БП или БСП! Типа делить по размеру? А правильно это? Почему не по значимости?
И т.д. и т.п. В общем я бы не стал такого делать ни под каким предлогом. А если вариантов нет, тогда ни каких префиксов не добавлять и обновлять все как по нормальному

(12). Для того чтобы понять чего у метода внутрях существует такое понятие как спецификация (в упрощенном виде комментарий). Использовать общепринятые сокращения в наименованиях тоже нормальная практика. А то методы типа ФункцияПолученияОстаткаПоУказанномуВПервомПараметреСчетуПланасчетовБухгалтерскогоУчетаСУсловиемПоВторомуПараметруСубконто1() - это уже маразм.

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

(44) Я же говорю, что префиксы только к своим доработкам, которые ты сам поддерживаешь. Префиксы удобны глазами выделить зону анализа. В случае с БСП все не так, её не надо менять, она стандартная и дорабатывается в параллельном мире. В общем не надо ни чего менять, совсем не надо

(43) Можно не доводить до маразматических наклонностей. Кстати, точное определение названия модуля производится на усмотрение обычных людей.
-----------
Вот другая крайность от мегаразработчиков
с = Запрос.Выборка
...
в = Менеджер.Выборка
...
в.параметр = с.другойпараметр

(46). Я, кстати, не зря такой пример привел. Разработчики типовых 1С считают, что это нормально давать такие длинные имена методам. Я стандарты разработки от 1С не читал, но если то что делают разработчики типовых этим стандартам соответствует, но я никогда в жизни такими стандартами пользоваться не буду.

(47) Они слабо придерживаются своих стандартов, только мы то не собираемся же быть во всем похожими на 1С? Ведь так?
Фича в том, что разработка конф в 1С, это далеко не прибыльное направление, поэтому там часто негры работают в паре с обезьянками. Соответственно и требования и качество такое

вот меня тоже очень интересует тема данного топика!
Где можно прочитать про префиксы, правила наименования?
Ато на сайте 1С не шибко-то про это написано...

(49) есис нужен, там все есть

(50) А там где?

Ещё хочется в условиях множественных правок использовать теги.
Думаю зарезервировать и не использовать эти слова в коде и  комментах без надобности.

soon - место будущих правок.
bug - известная или потенциальная ошибка
не придумал слово для текущих правок. current и now - уже есть в коде. А то пришёл с утра, конфигуратор закрыт (терминальную сессию на ночь закрываю), над какими фрагментами работал - сразу не вспомнить. А тут - поиск по тегу, щёлкнул, открыл - рабочая среда восстановлена или перенесена.

Да - интересно, а кто-нить использует CVS для работы с 1С - по идее - самое оно в данном случае.

...упоминания были.

(13)Не плохая книга.
Читаю http://www.ozon.ru/context/detail/id/5508646/

(54) книга действительно хороша, читал когда-то

(51) используйте Хранилище. Там можно распечатывать историю изменений, причем по объектам.

(54) книга из разряда мастрид для любого, кто считает себя программистом... планирую перечитать ее в ближайшее время

(52) хранилище?

(51) я на листочке помечаю что нужно делать, если приходится прерываться и стараюсь не оставлять незаконченные задания... да и в багтрекере всегда видно список активных задач.

использовали у нас некоторые свои теги, типа "доделать", "тут ошибка, нужно править", "это нужно оптимизировать" итд. До сих пор в коде валяется и никто к ним не приступает, ибо в багтрекере не зафиксированы... ну а если и использовать, то просто юзай какие нить спец символы, типа #bug