«Зачем вообще нужны эти стандарты? Ведь они только ограничивают и сковывают разработчика!»
Это действительно так, пока вы разрабатываете собственную маленькую конфигурацию, к которой больше никогда не вернётесь и никому не покажете. В остальных случаях стандарты более чем оправданы.
О доработке конфигурации 1С
Например, представим такую ситуацию. Над конфигурацией одновременно работают три программиста.
Первый программист (назовём его Пётр) в стандартную процедуру «ПередЗаписью» некоего документа добавил функцию проверки на соответствие документа определённому шаблону. Функция возвращает «Истина» или «Ложь» и соответственно, продолжает или прерывает процедуру «ПередЗаписью». Пётр описал всю логику сверки документа с шаблоном через десяток связанных друг с другом функций, расположенных в общих модулях. Первая функция только вызывает их в определённом порядке и возвращает итоговый результат.
И всё бы ничего, только Пётр назвал эти функции (и общий модуль с ними) без какой-либо привязки к их содержимому или действиям, которые они выполняет. А просто «Функция1», «Функция2», «Функция3», «ОбщийМодуль1» и т.д.
Пётр – программист уникальный, он обладает эйдетической памятью, и поэтому спокоен за свой код, т.к. помнит, что делает каждая функция, написанная им. Ему не нужны какие-то особые осмысленные названия для функций, модулей. Это всего лишь слова. Вся логика у него в голове, мерцает ярким светом чистоты. К нему может обратиться любой программист и он в подробностях опишет что делает функция1, какие из функций она вызывает, в каких модулях они находятся. Уникум.
НО. В разработке участвует ещё один 1c программист (Василий). Он обладает обычной среднестатистической памятью, и не способен весь код держать в голове. Ему ставят задачу дополнить и изменить проверку документа, которую организовал Пётр.
И теперь Василий вынужден тыкаться по всем функциям, пытаясь понять, что каждая из них делает, и где нужно внести изменение чтобы решить задачу. Ну или идти на поклон к Петру, чтобы он ткнул несмышленного в нужную строчку кода.
|
Есть вопросы? Оставьте заявку на консультацию прямо сейчас! Менеджеру по продажам, Евгении, она поможет с выбором услуги: soft@sovetnik1c.ru, или звоните нам: тел.+7 343 383 45 95 |
Однако, мы забыли, что у нас есть третий программист (ну… пусть будет без имени). Он работает на фрилансе, и изредка внедряется в код, написанный Петром или Василием. Делает он это безо всяких комментариев в коде и не сообщая о своих изменениях первым двум. Времени нет, надо деньги зарабатывать (фриланс он порой такой, да), да и главное – работает же, что им ещё нужно.
И вот мы имеем код, который работает совершенно не так как ожидают Пётр или Василий. И поскольку нет никаких комментариев, кто, когда и почему его изменил – Пётр грешит на Василия, а Василий на Петра.
Пётр грешит на Василия, а Василий на Петра...Конфликт нарастает, а в это время фрилансер правит очередные строчки кода…
Пример, конечно, утрированный (хотя что-то подобное я встречал, только не всё сразу), но достаточно яркий, чтобы донести всю пагубность полного отсутствия каких-либо стандартов в разработке 1С.
Как видите, без определенной договоренности между программистами обойтись никак нельзя. И если внутри небольшой группы программисты могут договориться на словах, то в большой компании (а уж тем более в отрасли в целом) нужно внедрять публичный документ со стандартами разработки.
Можно сказать, основная идея, заложенная в стандартах такая: структура должны быть максимально понятной, код должен легко и однозначно читаться другим программистом. Также в стандартах немало указаний, направленных на повышение производительности и эргономичности рабочего места пользователя.
Большинство стандартов очевидны сами по себе, но встречаются и совсем не очевидные, и даже порой противоречащие твоему собственному опыту разработки. Но не стоит принимать их в штыки. Стандарты пишут люди с гораздо большим опытом разработки, и раз уж они написали такие рекомендации – стоит проверить и разобраться, в каких случаях они действительно работают лучше.
Например, широко известен факт, что временные таблицы в запросе к базе данных работают быстрее и лучше, чем вложенные. Я и сам стараюсь вложенные не использовать. Со временными таблицами и читабельность запроса повышается и повторно использовать их можно, и работают они быстрее.
Но оказывается, что со скоростью работы не всё так однозначно. Вложенные запросы работают медленнее, потому что оптимизатор СУБД не может сформировать оптимальный запрос (он не знает количества записей во вложенном запросе). Однако на вложенных запросах с малым количеством записей время обработки запроса будет меньше, чем на создание временной таблицы с этими же записями.
В любом случае, всегда надо мерить производительность, до и после изменений.
Вообще, стандарты разработки – это не строгие правилаВообще, стандарты разработки – это не строгие правила, которые обязательно надо изучить и использовать до начала работы в отрасли. Это скорее рекомендации, выполняя которые ты приближаешься к идеальному коду.
Но рабочий код не обязан быть идеальным. Главное назначение кода – делать то, что он должен. И именно за это мы получаем зарплату.
Однако, если вы хотите развиваться как программист, совершенствовать свои навыки, получать большую зарплату, то изучение и применение стандартов в своей работе – необходимый шаг на этом пути.
Для подробного ознакомления со стандартами можете перейти по этой ссылке. А также в телеграмм есть канал, посвященный стандартам: t.me/v8std.
Стоимость доработки Вы можете уточнить, оформив заявку с сайта. Гарантируем качество оказываемых услуг, логическое завершение проекта, в согласованный срок. Заполняйте заявку на звонок в форме справа.В следующей статье обсудим принципы и инструменты групповой разработки.
