Код по цене пачки пельменей и сорок бочек скрама
Разработка - Рефакторинг и качество кода
Достаточно часто на ресурсе выходят статьи представителей франчайзи. Иногда - интересные и нужные. Иногда - не очень интересные. А еще регулярно статьи, чтение которых способно ввести в депрессию.
И то - скромные авторы пишут о стандартах разработки, о том, как надо писать код, о том, как надо внедрять, как работать с заказчиками, как персонал мотивировать, как проекты вести и “как сделать за пять минут то, на что у других уйдет год труда”. Статьи обильно приправляются сентециями типа “В нашей компании мы всегда работаем по самым высоким стандартам и тому-же молодых сотрудников учим”, “у нас есть в компании правила разработки, правила групповой работы, а еще мы внедрили скрам и стали на 99% процентов эффективнее”. Читаешь и чувствуешь, что сам-то ты отстал от сверх-высоких стандартов, что надо догонять, что все вокруг программируют на недостижимом уровне, и ты - никому не нужный мастодонт, реликт и музейный экспонат.
Для тех из коллег, у кого подобные мысли возникают, я и решил тоже несколько живых кейсов привести. Только не из неких заоблачных стандартов - а из самых что ни на есть актуальных продуктов. Продуктов, которые отдельные “партнеры” вполне себе продают клиентам. Ну и раз уж я Agile упомянул - скажу пару слов и о живых примерах групповой работы во франчайзи - из того, что лично видел.
Итак - как накодить за 20 секунд то, на что другие целый день убьют? Нужно придерживаться золотого правила минимализма. Например - зачем вот нужны регистры сведений? Дураку понятно, что это все от лукавого. Вместо регистров сведений вполне можно обойтись реквизитами справочников! И вот живой пример - продукт от “партнера 1С”, который вполне себе клиентам продается.
Справочник “Номенклатура” - смотрим и ценим (часть реквизитов я стер на скриншоте, чтоб решение не сразу угадали). Люди вводят реквизит - цена1, и не нужно никаких там разных регистров сведений и документов установки цен тем более. Просто, быстро, красиво. Правда вдруг может понадобиться еще один вид цен - ну не беда, добавим еще один реквизит. И еще один. На моем скрине 12 видов цен - 12 реквизитов. Ну и цена закупки отдельно. Пока, видимо, не нужно было больше.
Точно так же можно (и нужно) упрощать все остальное. Вот, например, - нужно добавить информации в справочник. Фирма 1С придумывает для этого не-пойми чего. Какие-то регистры сведений, планы видов характеристик, табличные части с доп реквизитами. А потом, чтоб эту информацию извлечь, хитрые запросы к данным строят. Для “эффективного” кодера все это лишне. Добавил два-три реквизита прямо в справочник или документ - и проблема решена. А как же быть, если заранее неизвестно, какая информация нужна будет? А очень просто - заранее добавить реквизитов и назвать их просто и красиво.
Как на скриншоте - “Свойство1”, “Свойство2”. Просто и красиво, прямо как в 1С 7.7 было. Этот продукт люди пользователям продают. И разумеется - с контрагентами все точно так же. “Категория1”, “Категория2”.
Все прочее - тоже реквизитами. ABC категория, должностное лицо-руководитель, должностное лицо - главный бухгалтер - все строго реквизитами. Зачем придумали регистры сведений? Не нужно это, и без того продукт можно “впарить” клиенту. И доработать быстро - нанял студента за пачку пельменей, он и добавит еще реквизит (или два реквизита, или сто - все одно не дороже пачки пельменей выйдет).
Что на сайте самой компании, которая такие чудо-продукты производит, сказано? “один из крупнейших российских системных интеграторов и независимых разработчиков типовых программных решений на базе "1С" для автоматизации… Основная сфера деятельности группы компаний полный комплекс услуг по автоматизации бухгалтерского и управленческого учета предприятий и организаций любых отраслей бизнеса, от индивидуальных предпринимателей до холдингов. Группа компаний ...основана в 1993 году. С 1997 года ... является партнером фирмы "1С". За время сотрудничества накоплен обширный опыт внедрений в различных сферах бизнеса и в области государственного управления. Это подтверждают сертификаты и статусы, полученные ... а также статистика работы”.
Является партнером 1С с 1997 года.
Является партнером 1С с 1997 года!
Является партнером 1С с 1997 года!!
Но - я отвлекся. Я обещал показать, как можно программировать легко и просто, а сам на первом же кейсе завис (в офигении). Так вот, урок второй - регистры накоплений на самом деле тоже совершенно не нужны. И то, каждому разумному человеку ясно, что все нужные цифры уже есть в документах, для чего повторно информацию в регистры пихать? Не нужно этого делать! И вот вам еще один живой пример.
Тут мы видим, как легко и просто можно обойтись без всяких дурацких регистров. Нужно узнать, сколько нам клиент оплатил? Считаем строки документа прихода денег, и сумму узнаем. Просто? Просто! Быстро? Быстро! Смешно? А коллега мой за голову держался, у него из-за такого чудо-кода клиенту без оплаты отгрузили чрезвычайно дорогостоящий товар (потому что помимо приходников там у клиента в истории и расходник фигурировал, и сумма оплаты из-за этого получалась сильно ниже).
Этот программный продукт продают клиентам!
Этот программный продукт продают клиентам за деньги!!
Этот программный продукт продают клиентам за деньги прямо сейчас и в нашей стране!!!
И раз уж начали - по методологии работы. Отдельные шибко умные люди непонятно зачем любят умножать сущности. Вот например - партионный учет. Зачем-то документы партий в регистрах используют, аналитики всякие, разные ФИФО и по-средней, давят умняка, короче. Тру-специалисты не заморачиваются такой фигней, и поэтому их партионный учет прост и создается за пять минут.
И снова живой пример. Делаем справочник партий.
Партию указываем прямо в документе прихода - причем человек может партию выбирать или же программа автоматом создаст.
ФИФО и всякое скользящее - это от лукавого. Ставим просто - списывать самую старую.
Регистр партий делаем простой - номенклатура, склад, партия как элемент справочника. И при таком грамотном проектировании наши запросы будут невелики и создавать их можно будет секунд за 30. Примерно так это будет выглядеть - код на списание по регистру партий.
Как видим - все очень просто, никаких километров кода, как разные несознательные личности делают - не нужно. Все предприятие с таким подходом легко за пару рабочих дней автоматизировать, причем код с нуля написав и под требования заказчика. Понятно, что потом клиенты будут плакать, и за голову хвататься - ну да вы в этот светлый момент уже будете автоматизировать кого-то другого.
Ну и раз уж мы заговорили о франчайзи - нельзя несколько слов не сказать и о методах работы отдельных из них. Как говорится - не скрамом единым.
Помнится, в свое время меня потряс список требований одного франчайзи к удаленным разработчикам. Документ был большой, детальный, расписывалось, куда и как ставить точки, какие отступы в коде делать, требования к комментариям. Отдельно и очень много - что надо делать все, что в техзадании расписано. А если в техзадании вдруг что-то не указано - то надо догадаться, что это подразумевается, и тоже сделать. И на сладкое - приводили пример реального диалога с разработчиком, которого совестили и стыдили. Я начал этот диалог читать, и понять ничего не могу. Вернулся к началу - ну да. “Читайте этот диалог снизу вверх”.
Читайте этот диалог снизу вверх!
Читайте этот диалог снизу вверх!!!
Может это и был самый мудрый в мире франчайзи - но меня охватило глубочайшее отвращение. Писать километры требований к чужому коду - и не взять за труд себе даже эти требования хотя бы читаемо оформить.
Еще, помнится, очень понравился ролик одного франчайзи, чье название что называется - “на слуху”. Лукавый человек с хитрым взглядом в ролике долго рассказывает, какая у них замечательная фирма. И какие стандарты высокие - и в разработке, и во взаимодействии. И что они бы могли еще сильнее развиться, но не хватает разработчиков. И в конце просто шедевральную фразу выдает: “У нас нужно в проекты вписываться. У нас вот недавно устроился разработчик, он сидел, ждал пока ему работу дадут - ну и уволился через месяц, не дождался”. Человек на голубом глазу подает, что вот, какой не шустрый разработчик оказался, не стал сам бегать и искать, чё кого. Про то, что у человека по идее должен был менеджер быть, который хотя бы какие-то правила игры мог бы и объяснить (ну или HR на худой конец, который должен был провести мероприятия адаптации) - про это ни пол-слова. То есть у вас в компании такая “замечательная” культура, что новым людям не оказывается никакой поддержки - это ладно. Но зачем тогда говорить, что вам разработчиков не хватает? Может быть, с себя стоит начать, подумать, отчего люди приходят, сидят в недоумении и уходят? Ну это ведь не так интересно, как рассказывать басни про скрам и выигранные тендеры.
Чтоб не голословно было - вот несколько цитат с сайта компании (про скрам и agile - тоже есть). “в приоритете индивидуальный подход к каждому сотруднику”, “Этому же учим сотрудников, повышая их мотивацию на собраниях и тренингах, есть коуч-тренером в отделе, мы изучили множество тематических вебинаров по программам 1С, и адаптировали их под специфику работы своего отдела.. совместное обсуждение в коллективе позволяет сотрудникам глубже изучить материал, досконально освоить используемое в работе программное обеспечение. ”, “руководитель отдела всегда готова ответить и помочь коллегам, у которых в работе случается всякое: опускаются руки, снижается мотивация, энтузиазм. Тогда ищет нужные слова и стимулы, которые помогут раскрыть потенциал человека, вдохновить, подбодрить, показать перспективу. С каждым детально разбирает ситуации, которые привели к сложностям, ищут варианты решений”
Месяц человек просидел за столом и уволился!
Месяц человек просидел за столом, никто к нему не подошел и он уволился!!
Месяц человек просидел за столом, ему не дали работы и его зарплата по итогам месяца была никакой и он уволился!!!
Индивидуальный подход к каждому сотруднику!!!!!
“Тема обсуждения: почему IT отдает предпочтение именно Scrum” (с)
“Если есть необходимость быстро получить рабочее ПО то смело выбирайте технологию Agile” (с)
.
Еще случай из практики франчайзинга (другая фирма). Менеджер берет заказы у клиентов в обход руководства. И программистам также в обход руководства кидает. В итоге несколько команд в одном коллективе - одни вроде б и заняты, но заказы у них “тощие”, и работа ведется кое-как. А другие вроде б и не заняты почти, и выработка минимальна - но жирные заказы уходят к ним слева, и времени у них по факту нет - а уж на групповые стандарты и командные методы им просто фиолетово - люди по факту в другом месте работают. В итоге может быть несколько десятков разработчиков - а поставить на проект и некого.
И нельзя ни сказать о замечательной и чудесной практике под названием “Кому отдать проект? Тому, кто поставит меньше часов”. Как это выглядит? Примерно так же, как написано. Поступило ТЗ от заказчика. Большое такое, основательное ТЗ. Страниц на 50, к примеру. Кому отдать такой заказ, если у вас под началом 50 голов разработчиков? Разумеется, тому, кто меньше денег попросит - то есть тому, кто выставит за работу как можно меньше часов. Выглядит это примерно так. На корпоративном портале появляется новость - “Есть ТЗ, кто возьмется?”. Разработчик Вася со стажем в 15 лет разработки в серьезных проектах только заканчивает читать 30-ю страницу ТЗ, думая при этом, что 90% описанного уже есть в продукте “1С-Совместимо”, с которым он раньше работал, а вот оставшиеся 10% - с ними нужно месяц возится, потому что сложно. А студент Петя, который вчера сдал на “Профа” по платформе, уже пишет - “Возьмусь за проект, 80 часов”. Как мы видели по приведенным выше примерам архитектуры - любое задание действительно можно сделать за 80 часов - отказ от регистров, от методологии, и на выходе получается проект из разряда - “Наверное, это все же лучше, чем в экселе посчитать.. или не лучше?”. В итоге проект уходит студенту Пете. Ну а опытный разработчик Вася, несколько подивившись такому пиру жизни, через какое-то время уходит на фикси, куда его давно звали.
И чтобы уж совсем закрыть тему, еще два слова о наболевшем. Пришлось не обновленную адаптировать УТ 11.3 к переходу на 20% НДС. Мне казалось, что задача не будет сложной. Добавить новое значение в перечисление “Ставки НДС”, потом проверить, и всех дел. Я оказался сильно не прав. Отчего-то в типовом решении 1С этого было недостаточно. Потому что были буквально сотни строк кода, типа
И для новой ставки НДС нужно было добавить еще кода. Сотни таких мест, увы. Что мешало вообще сделать “Ставки НДС” не перечислением, а справочником, что мешало сделать одну обработку значения ставок в функции и вызывать эту функцию везде? Вы знаете ответ на этот вопрос. Так что - когда вы читаете очередной рассказ о скраме, Agile и прочих зарубежных словах, не спешите впадать в депрессию и считать себя безнадежно отставшим. Вполне возможно, что у рассказчика дела с высокими стандартами обстоят еще хуже, чем у вас, увы.
Alexander Chernykh
Вступайте в нашу телеграмм-группу Инфостарт
Вы можете заказать платную адаптацию этой статьи под ваши задачи на «Бирже заказов».
- 0% комиссии — оплата напрямую исполнителю;
- Исполнители любого масштаба — от отдельных специалистов до команд под проект;
- Прямой обмен контактами между заказчиком и исполнителем;
- Безопасная сделка — при необходимости;
- Рейтинги, кейсы и прозрачная система откликов.
См. также
Нейросети Рефакторинг и качество кода Запросы Разработчик 1С 8.3 Абонемент ($m)
Нейросеть написала запрос или процедуру для вашей базы 1С, и непонятно, все ли имена в нём настоящие. Обработка компилирует текст без выполнения, сверяет его с метаданными этой базы и к каждой ошибке пишет настоящее имя, например ВНаличииОстаток вместо выдуманного КоличествоОстаток. Список ошибок с подсказками одной кнопкой копируется обратно в чат с моделью.
10 стартмани
02.11.2026 375 2 nedomolkov.ivan 3
Рефакторинг и качество кода Разработчик 1С:Предприятие 8 Россия Бесплатно (free)
Одна проверка в обработчике кнопки может выглядеть достаточной, пока ту же операцию не вызовут из другого места. На примере управляемой формы разберём, почему так происходит, как разместить проверку в общей серверной функции и чем отличается удобная проверка ввода от обязательного условия выполнения операции.
29.10.2026 385 YA_777378709 0
Рефакторинг и качество кода Разработчик Бесплатно (free)
Рассказываем, почему качественный код – это не техническая прихоть, а актив, который помогает бизнесу быстрее адаптироваться к изменениям и запускать новые фичи без бесконечного преодоления техдолга. Показываем, как объяснить бизнесу ценность рефакторинга через понятные признаки: замедление разработки, неточные оценки, страх перед legacy и хрупкость системы. Разбираем, почему неправильный рефакторинг может быть дороже его отсутствия, какие анти-паттерны ломают процесс и как не превратить улучшения в бесконечную переделку ради переделки. Объясняем, как сделать рефакторинг частью культуры команды: договориться с бизнесом, научить разработчиков видеть проблемные места, закрепить правила и поддерживать улучшения на уровне тимлидов, архитекторов и всей команды.
28.10.2026 501 Pavel791 0
Рефакторинг и качество кода HighLoad оптимизация Системный администратор Разработчик Стажер 1С 8.3 Абонемент ($m)
Если к HTTP-сервису 1С обращаются сразу несколько программ, сколько запросов в секунду он успеет обработать? Я опубликовала простой HTTP-сервис на нашей "подопытной" конфигурации «Нано-УТ» (файловая база, Apache, без прав администратора) и нагрузила его скриптом на Python. Ответ: около 15-16 запросов в секунду, сколько бы клиентов ни обращалось одновременно. Запросы ждут своей очереди, и при 32 клиентах ответ приходит через 2 секунды вместо 64 мс. Заодно разобрала скрипт из первого варианта статьи: он «проверял» сервер, который отвечал по одному, и считал ошибки вместе с успешными ответами. В архиве исправленный скрипт, учебный сервер, HTTP-сервис для 1С и инструкция по запуску.
1 стартмани
23.10.2026 533 Ninel_S 3
Рефакторинг и качество кода Разработчик 1С 8.3 Абонемент ($m)
Запустили Analyzer 1C 2.7.65 на промышленной конфигурации (596 модулей, 13 669 функций) и исследовали перегруженные функции (до 1887 строк), циклические зависимости и экран «Циклы» (кольцо из 64 модулей). Разобрали, почему популярные метрики (McCabe, связность) не представлены в продукте вендора, и составили пошаговый план разделения модуля. Привели проверенный платформой 8.3.27 пример до и после рефакторинга и выявили скрытую ловушку загрузки модулей с точкой в имени.
9 стартмани
19.10.2026 469 Ninel_S 2
Рефакторинг и качество кода EDT СКД Разработчик 1С 8.3 1С 8.5 1С:Бухгалтерия 3.0 Бесплатно (free)
Одиннадцать граблей схем компоновки, которые не видно в конструкторе и не ловит EDT, на реальных отчетах БП КОРП. Формат числа задается в двух местах, и условное оформление варианта перебивает формат поля. Ресурс складывает штуки с часами, и помогает выражение «только когда единица одна». Ресурс пуст в детальных записях, параметр не появляется в шапке без userSettingID, valueListAllowed ломает границы периода, Остатки и СрезПоследних с параметром периода падают с «Несоответствием типов», title без xsi:type дает «Исключение XDTO» при загрузке. В конце код проверки схемы из файла до обновления базы, сводная таблица и чеклист.
16.10.2026 550 Konstmax13 2
Инструментарий разработчика Нейросети Рефакторинг и качество кода EDT Разработчик 1С 8.3 1С 8.5 1С:Бухгалтерия 3.0 Бесплатно (free)
Как ИИ-агент (Claude Code) работает в живом EDT-проекте 1С:Бухгалтерии КОРП 3.0: из чего собрать стенд с MCP-сервером для EDT, как ставить задачи агенту, где он ломает проект и какие проверки это ловят. Реальные случаи: рукописные метаданные, ронявшие конфигуратор; четыре дня зависшего обновления из-за порядка блоков в Rights.rights; ошибки, которые EDT пропускает, а платформа нет; сплошная сверка вместо «вроде работает». В приложении шаблон CLAUDE.md, шаблон правила, чеклист перед обновлением базы и скрипты проверки ролей и схем СКД.
15.10.2026 3517 Konstmax13 11
Рефакторинг и качество кода Тестирование QA Разработчик 1С 8.3 Абонемент ($m)
Инженерный анализ влияния (Impact Analysis) при изменении общего метода в 1С:Предприятии: почему штатный поиск ссылок скрывает 99% зависимостей и как обратный обход графа вызовов выявляет 370 скрытых потребителей на глубине 3 уровней. В статье — верификация сквозной цепочки обмена с маркетплейсом; в архиве-компаньоне — автономный BFS-анализатор на Python, слепки графа и план регрессионного тестирования.
1 стартмани
12.10.2026 335 Ninel_S 0
Не обращайте внимание - это подражание западу, где (в отличии от ..) чтут традиции, дорожат репутацией и следят за качеством.
Тоже самое можно встретить на продуктах питания.
быстро - дешево - качественно (выберите два из трех критериев)
В России, кажется, большинство выбирает - быстро и дешево.
"Клуб Енох — ассоциация владельцев частных компаний, существующих не менее 200 лет."
Старейшая организация среди участников ассоциации — семейная фирма «Хоси» из Японии, занимающаяся гостиничным бизнесом с 717 года. (!!! ФИРМЕ 1304 ЛЕТ)
Самая крупная из участников клуба — оружейная корпорация «Beretta» из Италии была основана в 1526 году
Мне эта линейка понравилась, и еще понравилась дружелюбная поддержка.
С Далионом Трактир вообще не работал, с магазином и трендом знакомство поверхностное. Один раз столкнулся с ситуацией, когда известная в регионе фирма франчайзи поставила клиенту купившему лицензионный тренд или магазин ломаную копию, чтобы никто из чужих за поддержку не брался.
Что понравилось в Далионе Авто - весь код функционала был открыт, что не понравилось в магазине и тренде - часть функционального кода закрыта.
Условно открыт.
Перем DalionAuto Экспорт; // Внешняя компонента, все защищенные функции вызываются через эту функции
.....
Файл=Новый Файл(ПутьDLL);
Если Не Файл.Существует() Тогда
Попытка
ПолучитьОбщийМакет("DalionAuto").Записать(ПутьDLL);
Исключение
Предупреждение("Не удалось установить компоненту защиты """+ПутьDLL+"""
|Попробуйте запустить программу от имени администратора", 30);
Возврат Ложь;
КонецПопытки;
КонецЕсли;
Попытка
ЗагрузитьВнешнююКомпоненту(ПутьDLL);
DalionAuto = Новый("AddIn.DalionAuto2");
Исключение
Предупреждение("Не удалось загрузить компоненту защиты """+ПутьDLL+"""
|Попробуйте запустить программу от имени администратора", 30);
Возврат Ложь;
КонецПопытки;
ПоказатьИ дальше килограммы вызовов этой ВК во всех ключевых документах.
DalionAuto.ПересчитатьСуммуНалогиСтрокиДокумента(СтрокаДокумента,ДокументОбъект,ИмяТабЧасти,"Всего");
DalionAuto.ТабЧастьНоменклатураПриИзменении(СтрокаДокумента,ДокументОбъект,"Товары");Всем понятно, что внутри этих закрытых процедур ничего сверхестественного нет.
Мне эта линейка понравилась, и еще понравилась дружелюбная поддержка.
я очень много лет работал с 7.7. Мне очень нравилось это решение... пока не появилось версия 8. Когда верссия 8 уже десятилетия на рынке, как-то стыдно писать код в стиле 7.7
да, просто и быстро, а регистры их сначала создай, потом еще запросы к ним... напридумали
статья все же о разных франчайзи, не об одном
продукты - одного
подход к работе - второго и третьего
приведен конкретный пример
считают оплату по приходникам - раз приходник и два
у клиента был еще расходник (вернули деньги или что-то в таком духе)
в логике оплат по приходникам - все гуд
клиент получает дорогостоящий товар и счастливо уходит
а так то да - функционал прекрасный
Добрый день.
Посмотрели у себя. Правильно ли я понял, что это код, который вызывается при печати Справки-расчета из Расходной накладной и только в случае если расчеты по договору ведутся в у.е.?
Непонятно тогда в принципе зачем контролировать оплаты через эту форму. Мы обычно оплаты смотрим через отчет по взаиморасчетам. Этот отчет строится на базе регистра накопления по взаиморасчетам. Можно также настроить запрет отгрузок без оплат.
В принципе аналог таблицы "Расшифровка платежа" есть и в других конфигурациях. В Бухалтерии например есть таблица, в которой можно разбить платеж по нужным договорам/счетам. Но тут уже человеческий фактор влияет.
вот так и никакой интриги
смотреть философски - хорошо
а выплеснуть возмущение и после этого смотреть философски - еще лучше
- да. Это печально, потому и надо писать чтоб люди стыдились
ассоциировал ни со скрамом, ни с чем другим похожим...
автор все же пишет не о скраме, а о тех, кто семинары по скраму проводит
Совсем недавно была сформулирована в одной из статей идея, что "незаменимые сотрудники" - это цена, которую не хочет платить компания за организацию процессов. Скрам и Аджайл - это методологическая база для организации процессов, за которую платится определенная цена, а сами процессы в результате оплаты этой цены становятся ценностью компании, фактически увеличивают ее стоимость на рынке. Но т.к. у нас такой локальный экстремум управленческой функции двигает массы воздуха человеческих ресурсов, что в нем принято декларировать, а не обеспечивать процесс. Обеспечение функционала процесса как минимум трудоемко, написать это все на бумаге - тоже, но написать можно всего один раз, а двигать приходится постоянно. И ленивые управленцы выбирают "декларировать", а не "двигать". А неленивых управленцев мало, т.к. в управленцы идет тот, кому лениво (один мой друг постоянно говорит, что ему лениво программировтаь, в итоге он пошел работать Scram-мастером в СберТех, где часть руководителей проектов откровенно саботировали данный подход. После этого он пошел в Альфа-Банк - там все подобные проблемы решаются мгновенно и ничья голова не удержится на месте больше 15 минут при попытке подобного саботажа, сейчас он там руководитель чего-то большого и красивого).
потому, что слова эти уже употребляют к месту и не к месту. Еще через какое-то время уже ругательствами будут (примерно так со ловом - "демократия" произошло в прошлом веке)
вам самому не смешно, когда какой-нибудь болтливый директор сберкассы , любящий переодеваться и кассиров пугать, начинает рассуждать про аджайл и о методологиях разработки? При том, что методологии в компании этого человека - слишком хорошо известны
НО! Как мне показалось враг тут не Аджил. Автор не поленись и прочитай книжку по SCRUM красного цвета, там описана покер методика и собственно про разработку в группе.
Это не торги кто меньше скажет того и тапки. Есть проект, он бьется на куски и каждый кусок оценивается всеми, если оценки сильно разнятся, все обосновывают почему дали такую оценку и еще раз оценивают. Задачи выполняет группа, а не студент сказавший меньше всех.
П.С. Сам я по скраму не работал еще, но почему бы и нет, очень даже интересно попробовать.
-- само собой враг не Agile а люди, которые берутся проводить семинары по нему, понимая при этом несколько меньше, чем средний обыватель
собственно статья о людях, а не о agile
Вместо размеров одежды в качестве характеристики вносит расфасовку готовой продукции (10 по 0,5 вместо зеленое 36 размера или 12 по 0,2 вместо желтое 50 размера).
Тоже очень интересно получается.
И для новой ставки НДС нужно было добавить еще кода. Сотни таких мест, увы. Что мешало вообще сделать “Ставки НДС” не перечислением, а справочником, что мешало сделать одну обработку значения ставок в функции и вызывать эту функцию везде?
Только что делал эту же операцию в старой ERP, там этого кода в несколко раз больше. Мысли были те же самыми.
прошу прощения. Я добавил скрин
Пара слов о перечислениях в 1С. Когда я только начал изучать синтаксис 1С и сравнивать его с C++, то пришел в замешательство. Как так - перечисление есть, а значения перечисления - нету? В C++ ведь как:
Либо так
enum color { RED, GREEN, BLUE };
Тут ясно, что значение RED = 0, GREEN = 1 и т.д.
Либо так:
enum Suit { Diamonds = 5, Hearts, Clubs = 4, Spades };
Тут ясно, что Diamonds = 5, Hearts = 6, Spades = 5.
А в 1С кроме имен нет ничего. И какой толк тогда от перечисления, если это не более чем ссылка на строку? Почему это не аналог фиксированного соответствия хотя бы? С таким же успехом можно было бы в качестве типа поля НДС поставить просто список с элементами типа Число и рассчитывать налево и направо без всяких проверок.
Тут ясно, что Diamonds = 5, Hearts = 6, Spades = 5.
А в 1С кроме имен нет ничего. И какой толк тогда от перечисления, если это не более чем ссылка на строку? Почему это не аналог фиксированного соответствия хотя бы? С таким же успехом можно было бы в качестве типа поля НДС поставить просто список с элементами типа Число и рассчитывать нале
Забавный пример, а если и Diamonds и spades =5, как с таким перечислением работать?
Закаким хреном 1С-ники сделали ставку НДС с помощью перечисления? Тут сложно гадать. Может быть они думали, что это такая константа околовечная, что не стоит из-за нее целый справочник городить, ибо кроме самой сущности ставки ничего другого к ней привязать невозможно (т.е. это не расширяемое понятие, для которого справочник нужен). Может быть следовало бы сделать что-то типа перечня ставок налога, а в каком-то регистре привязывать к этой ставке имя и саму ставку, но это было бы пложением сущностей без необходимости, от которой еще дедушка Оккам предостерегал всех правоверных католиков еще в XI-м веке.
Я тогда совершил ошибку - ввёл общий справочник налогов со ставками (не на 1С) и задолбался потом его править....
Вообще, тема НДС - бессмысленная и беспощадная. Бухгалтера боятся санкций налоговой, т.к. она может ни с того ни с сего взять и не признать принимаемым к зачету часть НДС, по которым счета-фактуры оформлены с нарушением. Но суд в данном случае налоговую может поддержать только тогда, когда представитель организации вообще ничего не понимает в деле. Алгоритм расчета суммы НДС для суда не является существенным, особенно если налоговая сама его не прописала в законодательных актах.
PS Помню одна букашка настолько мне нервы измотала, что я написал официальное письмо от имени руководства её конторы в налоговую с требованием дать официальные же разъяснения по поводу. Письмо было отправлено. Ответа не было год минимум, дальнейшую судьбу этой истории не отслеживал.
но когда это правишь, то становится крайне вот обидно за потраченное время, да
Если а = Перечисление.КакоеТо.Значение1 Тогда
б=1;
ИначеЕсли а = Перечисление.КакоеТо.Значение2 Тогда
б=2;
ИначеЕсли а = Перечисление.КакоеТо.Значение3 Тогда
б=4;
КонецЕсли;
то это следствие неправильной архитектуры, а не ограничения языка.
1. Отвязал бы их от БД - т.е. сделал бы чисто метадантными, не хранящимися в БД (ну и, условно, не требующим реструктуризации
2. Сделал возможным связывать элементы перечислений со значением (заданного у перечисления типа - как у планов видов характеристик) в конфигураторе (только примитивные типы (включая UUID, Тип, которые сейчас 1С8 примитивными типами считать не хочет) и значения ссылок на предопределённые элементы).
3. Сделать возможным задавать у реквизитов тип - такого перечисления как сейчас - в БД будет сохраняться само значение, но в объектной модели будет автоподставляться значение перечисления (если есть несколько одинаковых значений - выбирается первое - ну или запретить такие случаи)
4. Сделать возможным вводить такие перечисления не только глобально (я бы перенёс их в раздел "Общие"), но и локально - т.е., например в обработках (в т.ч. внешних) или в справочниках, и даже в формах (но типообразующиими для сохранения в БД будут только введённые в Общих или у владельца, сохраняющегося в БД; введённые у формы или обработки могут быть использованы только в контексте своего владельца, и не могут использоваться в реквизитах, сохраняющихся в БД как тип перечисления - но по значению - конечно могут).
5. Наверное, ещё бы сделал событие - получения значения перечисления - чтобы там можно было свой алгоритм написать - и сделать значение динамическим.
А то, что в конфигурациях Ставка НДС - это перечисление - да, можно было бы считать архитектурным просчётом, тянущимся десятилетиями - справочник кажется очевидным - но.... вот не задача - будет значение ставки значением реквизита - то для его получения пришлось бы обращаться к нему через точку - в тонком клиенте это уже сразу было бы не возможно, в остальных случаях - это приводил бы к обращению к СУБД (хотя кеширование тут поможет избежать падения производительности), но это уже не "красивый" код - его нужно избегать. Вот идея перечислений-метаданных-со связанными значениями - это было бы красивое решение!
В ректальном вроде другие вопросы разбираются.
Лично мне интересны статьи на подобные темы от разных авторов.
Во первых, это разные точки зрения
Во вторых, регулярное появление таких публикаций - это хоть какая-то борьба со злом
да, читал в свое время, но у человека сборник говнокода - а у меня про продукты от франчей, которые даже за живые деньги продаются
(ну и вообще моя статья лучше по моему субъективному мнению)
Статья жизненная, мне понравилась.
По поводу бардака в отраслевых конфигурациях:
Это так. Наверное просто нет времени переделать всё качественно, ведь основная разработка ведется по ТЗ и там "вроде как" всё продумано и даже есть системный подход, отсутствие избыточности в хранении данных. Но вот потом... Обкатывают продукт на каком - то предприятии - там уже пошло - поехало - тут не так, здесь вообще не так. В общем - пошли костыли Цена1, Цена2...ЦенаN. Я за другое переживаю - как такое проходит сертификацию "1С: Совместимо"?
По поводу партионного учета:
На самом деле попытки написать его заново, либо несколько упростить имеют под собой основания. Есть проблема, которая с каждым годом никак не решается - это оперативность получения информации по себестоимости, которая напрямую зависит от регламентной операции расчет себестоимости выпуска / товаров . Особенно это важно в рознице, где цена напрямую зависит от цен партий. Вот представь, что у тебя сеть из тысячи точек, на которые идут закупки как централизовано, так и непосредственно на местах. Десятки тысяч накладных в день. И наценка у тебя 2 - 5 %, котрая меняется каждый день. Цена ошибки очень велика. При этом есть передачи товара напрямую между точками. РАУЗ хорош, но нет возможности сказать всем СТОП, сейчас мы быстро посчитаем себестоимость и можете дальше работать)) Есть варианты считать характеристики партиями и использовать РАУЗ по средней - тогда оно хотя бы не уходит в многодневный анабиоз. Поэтому иногда и такие вещи простительны, так как решают проблемы бизнеса, хоть и далеко не изящны.
По поводу ставки НДС:
Полностью согласен. Ощущение, что уровень кода в типовых решениях упал за последние годы. Ранее неоднократно дорабатывал на проектах УПП / ЗУП и другие - одно удовольствие. Сейчас же без мата не обходится. Некоторые считают, что уровень вхождения программиста стал выше для разработки, например в той же "УТ 11". Соглашусь. Но не по причине того, что код там стал уж так хорош, а по причине того, что местами там хаос и нужно иметь крепкие нервы и более высокий уровень, чтобы разобрать его логику на составляющие. Это конечно не ко всем блокам относится, но уж к половине подсистем точно.
Понимаю. Локально -да. Я это называю "заколхозить" ))
Но автор пишет про коробочный вариант поставки. Там такое недопустимо (имхо).
вы про код списания по партиям?
я привел скрином прямо в статье, посмотрите
автор отвечает, просто не сразу - и проекты крупные внедряются у автора с нового года, и 20% ндс - все навалилось
Всё равно колонки в книгах продаж/покупок жестко фиксированы и без проверки ставок в коде не обойдешься.
Для тех инженеров, что имеют непосредственный контакт с кассами он-лайн.
Не надо в таблице налогов в кассе тупо менять ставку НДС с 18 на 20%!
Да, вы решите проблему с тем, что не зависимо от того, какую ставку налога передала уч. система в драйвер, сама касса рассчитает по ставке 20%
Приведу пример на Штрих-М.
таблица налогов должна иметь вид:
НДС 10% = 1000
НДС 18% = 1800
НДС 20% = 2000
Следовать они должны строго в этом порядке.
Соот-но уч. система должна начать пользовать 3-ю строку ставки налога , которая =20%.
Многие инженера изменяют значение 2 строки с 18% на 20%.
Получается примерно так:
НДС 10% = 1000
НДС 20% = 2000
НДС 20% = 2000
Сама касса корректно рассчитает ставку налога и в чеке выдаст 20%. Все верно. НО!
Если смотреть этот чек в ОФД, то там будет 18%.
Не попадитесь на этом.
Всем добра!
Возможно я некорректно выразился.
Дело не в том, как напечатать чек с различными ставками НДС в одном документе. Понятно, что у Вас тут скилл вкачан!
При отправке в ОФД, ставки налогов в таблице должны идти в порядке увеличения и никак иначе.
Сама касса передает тут ставку , которая находится в её таблице на тек. момент. Ей все равно.
Зашить их можно так:
1. 18%
2. 10%
3. 20%
На чеке ККМ все будет нормально. В ОФД по суммам налогов будет тоже корректно.
Но если посмотреть в Л.К. ОФД значение ставок будет так:
1. Всего 118 р. в том числе НДС 10% =18 р.
2. Всего 110 р. в том числе НДС 18% =10 р.
3. Всего 120 р. в том чисте НДС 20% =20 р.
Т.е. сумма НДС верная, а ставка отразится кривая.
Понятно, что это всего лишь отображение ставки в личном кабинете. Но тем не менее.
Уже пошли. На моей прошлой работе так и косякнули. Соб-но, чего и пишу. Звонили в ОФД. они умывают руки.
Типа "ничего не знаем , от нас пуля ушла" ) В общем то они правы. Им что прислали, то они и перекинули в ИФНС.
И никто не знает, что делать дальше ) Сидят и ждут, вдруг пронесет :-D
Типа "ничего не знаем , от нас пуля ушла" ) В общем то они правы. Им что прислали, то они и перекинули в ИФНС.
И никто не знает, что делать дальше ) Сидят и ждут, вдруг пронесет :-D
Если читать 54-ФЗ, то вроде как при выявлении некорректных сведений нужно делать коррекцию, но это ИМХО, на самом деле даже в самой налоговой еще до конца не определились. Зато были проверки, при которых проверяли что на кассе стоит именно тот продавец что и указан в чеке. Одна из небольших торговых сетей, с которой я работаю, добыла фотографии проверяющих, и повесила в своих торговых точках перед кассирами.
Многие инженера изменяют значение 2 строки с 18% на 20%.
Такое возможно когда пытаются сэкономить на перепрошивке кассового аппарата, сейчас все производители устроили аттракцион жадности и выпускают индивидуальные прошивки с 20 процентами НДС под конкретный аппарат привязывая его к серийному номеру. Естественно за дополнительную денюжку.... И желающие сэкономить на прошивке (примерно 2000 за саму прошивку плюс стоимость работы ЦТО) могут и "сколхозить" подобным образом.
Жиза жизненная
компанию, работодателяя, коллег и совершенно незнакомых ему людей. Да ещё и выложил в общий доступ куски конфигурации, которые вероятно защищены авторским правом (какими бы они не были).
компанию, работодателяя, коллег и совершенно незнакомых ему людей. Да ещё и выложил в общий доступ куски конфигурации, которые вероятно защищены авторским правом (какими бы они не были).
автор не трудился в компании, где данный программный продукт пользовали
автора друг, который с данным продуктом работает, как эксперта привлек - чтоб автор ужаснулся
если называть черное - черным, а белое - белым, это говорить гадости - то да, статья полна гадостей
выложенные куски конфигурации имеют отрицательную ценность
Я хотел скачать гениальные изобретения, которые вы выложили в своих публикациях, но почему-то стало жалко даже 100 рублей на них. Поэтому просто задам пару вопросов: как вы отнеслись бы если бы ваши разработки так описали? Ваши решения можно считать эталоном разработки на 1С?
Если называть чёрное черным и тд, то статья полна гадостей. Но мир многообразен и не делится исключительно на чёрное и белое. Если бы вы умели хотя бы специалисту объяснить, почему описанные решения неверные, а конфигурация не имеет ценности, то претензий не было бы. А так вы просто ругаете чужой труд ни за что. Представил себе ситуацию в суде. Вам говорят, что программа столько-то стоит, продано n лицензий, приносит стабильный доход, даёт работу штату целой компании. А вы что? Бу- у бу бу так не делают, это отстой. Не смешно разве?
все верно
когда я вижу, что в 2019 году люди цену ставят как реквизит справочника - мне как-то не хочется смотреть дальше
есть довольно простое и не нами придуманное правило - если что-то выглядит как утка, ходит как утка и крякает как утка - то скорее всего это и есть утка
если кто-то ставит цену реквизитом справочника номенклатура
при этом ставя ответственных лиц реквизитом справочника контрагенты
а сумму оплат получает суммируя строчки в документах оплат
то возможно, конечно, что это непризнанный гений
но используя бритву Оккама я предположу все же что это некомпетентный лодырь и халтурщик
Без контекста не понятно, что за архитектурное решение было применено, какова система? Например есть типовой подход к универсальным аналитикам, их просто обозначают Аналитика1, Аналитика N и это сознательное архитектурное решение. Или вот, например, запрос в цикле - это плохо, а системе нужно обработать большой массив информации и не поделив его на части система не справится. Или тот же пример из статьи про НДС, тут тоже не все однозначно (см в (49)). С одной стороны у нас неизменяемая структура, с другой - справочник с условно-постоянной информацией. В справочнике НДС тоже недостаточно хранить только ставку как число, нужно и алгоритмы подвязывать, т.к. ставка Без НДС и Ставка НДС или 18 и 18/118 имеют одинаковое значение.
А по поводу стандартов, так это тоже распространенная практика и ее цель - привидение к единообразию. Это такой элемент борьбы с энтропией. Но здесь наверное противопоставлялось наличие стандартов и плохая культура разработки (хотя стандарт тоже представлен с претензией вроде как), то это, как было сказано выше (см. в (42)), выбор менеджеров, когда легче задекларировать, чем поддерживать. И да, конечно, отсутсвие культуры порождает плохие архитектуры вероятнее всего.
На практике любое архитектурное решение - это выбор между ограничениями: скорость и стоимость разработки, стоимость сопровождения, производительность, определенность требований (возможно требования сильно не стабильны), время жизни решения, наличие готовых решений и т.д.
В статье не хватает мотивации критики и, конечно, контекста. И если уж критиковать профессионализм других, то нужно это делать тоже профессионально, а это тоже сложно. Особенно сложно, когда в представленных примерах нет явного "говнокода", т.е. нечитаемого, перегруженного и т.д.
А теперь вопросы к вам, как к архитектору:
- сколько вариантов решения можно предложить?
- какие преимущества и недостатки таких решений?
- перечислите факторы, которые могут влиять на ваш выбор?
Вопросы без подвоха, просто хочется понять ход ваших рассуждений.
Обращаюсь к тем, кто в танке. Пишу на языке обывателя, если им статья автора непонятна с первого раза.
Компания занимается автобизнесом! Что бы было понятна специфика работы: продажа авто, запчастей,оказание услуг по ТО , trade-in и пр.
Так вот: с НГ массово меняются цены. Други мои НА ЗАПЧАСТИ И РАБОТЫ! На все! Каталог сейчас содержит около 5 млн. записей.
Только одного Mersedes самолично загрузил 986 тыс. наименований.
И ещё есть несколько известных брендов.
Цены должны быть изменены с 01.01.2019 г.
Представьте себе, ещё неделя до НГ и уже есть новые цены. А загрузить, сцУко, не можем только потому, что тупой программист впихнул их не в периодический регистр сведений, а МляДь, в реквизит (ему должно сейчас икаться)!!
Все, что мне остается - это под бой курантов запускать обработку по смене цен. Ес-но справочник заблокирован транзакцией.
А 02.01.2019 авосервис начинает работать. А работать не могут, потому что цены еще не обновились. Не успел сервер за сутки обработать такую махину.
И для тех, кто не слышал про периодический регистр сведений:
Те заказ-наряды, которые были открыты в 2018 году , должны остаться с теми ценами, по которым была договорённость с заказчиком.
Сами теперь понимаете, что стоит только "перещелкнуть" ном-уру или добавить новую, то событие ПриИзменении() пересчитает её на цену 2019 г. Если пользователь потом руками не вернет старую цену, то будет скандал с заказчиком. А это репутация.
P.S.
Тот, кто тупо вхерачил цены в справочник: удали 1С ; выключи комп и больше не занимайся этим.
Вообще не сложно взять и полить нечистотами чужую работу. Критиковать все умеют. Очень сложно в таком случае найти слова, которые поймет только что вышедший из универа молодой разраб. И не думаю, что вы эти слова найдете. Вряд ли вы можете назвать хоть одну причину делать цену или ответственных в регистре кроме той, что так сделано в типовых конфигурациях. Что касается суммы оплат, то я по приведенному примеру не возьмусь ничего конкретного сказать.
Помню спорят как-то 2 программиста. Один другого критикует, что у того код плохой, переменные названы непонятно, много копи-паста и т.п., ну как обычно. А тот отвечает: "Моя программа такая-то работает в такой-то компании, такая в другой. А где твои программы работают?"
Поэтому хорошая программа это та, которая надежно работает. Быстро, стабильно и предсказуемо.
И еще как-то встречал в стандартах разработки Майкрософт, что если программа может работать в течении часа (!) и не выдает ошибок, то она готова к коммерческому использованию.
PS: но я ни в коем случае не против красивого кода))
Такое лучше всё-таки приводить со ссылками на первоисточники. Поискал подтверждающую информацию - не нашёл.
Поэтому хорошая программа это та, которая надежно работает. Быстро, стабильно и предсказуемо.
Это неверное рассуждение, логическая нестыковка.
Первое предложение относится к проданной программе и способности продажников убедить клиента её купить.
Второе утверждение логически никак не следует из первого и всего ранее написанного, хотя и преподносится как следствие.
Нельзя говорить "проданная программа с недочетами лучше, чем не проданная и хорошая, поэтому хорошая программа - та что работает быстро и стабильно".
Также не ясен контекст. Довольны ли клиенты проданной программой с недочетами? Не собираются ли они отказываться от неё? Готовы ли рекомендовать другим компаниям? Был ли у них выбор?
Извините за занудство.
Интересно, Windows по этому стандарту релизят?
в общем-то в статье приводится живой пример - почему указанный код не работает, и чем чревато, когда итоги считают по документам
Иными словами, производителя спасает низкая конкуренция (вспоминаю ранние релизы УСО 1.3 и документы закрытия объекта строительства, часть из которых корректно работала только при РАУЗ, а часть только при партионном учете, а по отдельности эти документы смысла не имели).
Всем добра!
Запрос по амортизации ОС вызывается 38000 раз. В закрытом модуле. Но мы то умеем посмотреть что там.
Тут смайлики: убьюсь-об-стену и рукалицо.
Документ НачислениеЗП. В нем есть кнопка отчета для отдельной строки "Карточка начислений" (или что-то вроде того). Работал с ЗУП только в части производительности, поэтому в формулировках синонимов неточности.
Так вот, чтобы построить данный отчет: открывается транзакция, проводится документ, строится СКД отчет, откатывается транзакция. Если документ на 10к строк, то вообще весело.
Да, решение - разбивать док на более мелкие части. Но в целом подход интересен.
Локализованная БП: Полные соединения соединяются с полными, кучи соединений со срезами и т.д. Постгресс вообще отказывается работать без полной переписки ряда алгоритмов.
Как повторял за кем-то Шахиджанян: "Лучшее - враг хорошего!" Совсем плохой код, который будет работать неэффективно, плодить, конечно, не стоит, а вот пытаться сделать код идеальным - большее зло, чем работающий "плохой" код. Ведь работающая программа лучше сферической в вакууме неработающей программы, да?
Как повторял за кем-то Шахиджанян: "Лучшее - враг хорошего!" Совсем плохой код, который будет работать неэффективно, плодить, конечно, не стоит, а вот пытаться сделать код идеальным - большее зло, чем работающий "плохой" код. Ведь работающая программа лучше сферической в вакууме неработающей программы, да?
А в том то все и дело - заявленный функционал коробки не работает.
Поправить возможности нет - закрытый модуль.
Один из примеров - ориентировочно 1,5 года назад - РАРУС МФО. Заявлено: полное формирование отчетности ЦБ.
По факту - Таб док в который цифры надо вбивать руками полностью.
Через какое то количество обновлений аж целых 2 поля сами начали заполняться (из нескольких сотен.)
Заявлено обмен с БКИ - по факту - допиливался по нашим письмам в момент внедрения из коробки не работал.
И таких примеров не один десяток.
Да я там уже не работаю.
Как происходит разработка "для людей"? Разрабатываемое решение не всегда имеет какую-то модель, оно не то чтобы не типовое... Вообще часто неповторяемая автоматизация. Иногда нужно сделать что-то непонятное, не известно как дальше используемое.
В таких случаях речь об универсальности решения вообще не может быть. Как правило, все что делается, еще несколько раз переделывается. И это не потому, что не смогли описать бизнес-процессы и составить модель. А потому, что у заказчика случается крайне низкая квалификация и все описание, которое он вам дал под протокол и роспись оказывается в статусе "я не это имел ввиду".
Но заказчики разные. Это частные случаи.
Разработка типовых, локализуемых или других тиражных решений позволяет вести разработку по нужным продуманным методологиям, которые относительно устойчивы. Вот тут подобным вольностям (ай, все равно потом все переделывать) не место.
Поэтому все зависит от контекста разработки.
Нужно в один единственный документ добавить подпись - добавьте этот чертов реквизит и не городите сложную подсистему. Наберется таких документов и подписей критическое количество - все переделайте.
Переделывать - это нормальный и хороший подход. К этому времени уже складывается понимание, что нужно и как будет.
Реализовывать без понимания будущего какую-то перспективу - утопия, потерянное время.
Вести разработку с техническим долгом, но с гарантированным возвратом к устранению этого долга - труднореализуемый в организационном плане, но наиболее эффективный по затратам метод.
Возвращаясь к первой строке своего поста: в целом со статьей согласен, но все очень неоднозначно.
В том, что на рынке присутствуют программные решения с "кривым" кодом, есть и наша вина.
Когда вы приходим а автосалон и хотим купить новую иномарку, то смотрим на внешний вид, цвет, салон, обвес и прочую канитель.
Но не заглядываем в моторный отсек. Почему? Потому, что покупает машину человек , который в этом ничего не смыслит (согласитесь с тем, что когда вы устраиваетесь на работу, то работодатель Вам сразу обозначает решение, на котором работает компания. Когда его покупали, то вас не спрашивали). Да и какой в том смысл? Ведь это же автосалон. Он же не продаст новую машину с Б/У движком?
Полюбовались , купили, приехали домой и начались проблемы.
Гнать её в тот же автосалон , где и брали резона нет. У них драконский ценик на ТО. К тому же в штате есть собственный механик.
Обращаетесь к нему и понеслась [смейлик:рука-лицо]...
Пишу все это к тому, что хорошо бы перед покупкой софта и на код взглянуть. Даже не на сам код, а на архитектуру метаданных.
Я ,например, бы не купил решение, которое описывает автор, видя цены реквизитами справочника и справочник партий.
И не важно, насколько круто решает проблему автоматизации данное ПО с точки зрения пользователя.
p.s.
Не помню фильма, где слышал эту фразу. Но сама она в голове засела.
"Главное, что бы пипл хавал. А пипл хавает!"
Сейчас так все происходит за не имением конкуренции.
Аффтар прям Америгу отрыл ))
Про код
Ни для кого не секрет что наиболее успешная компания та, что получает больше прибыли с меньшими затратами. Поэтому ну ничего удивительного в приведенных примерах совершенно нет.
Классическая фраза: х-к,х-к и в продакшн! И это относится далеко не только к 1С. Периодически встречаю это и в совершенно в других продуктах. Возьмите например WebDev или мобильную разработку. Ситуация точно такая же, уверяю вас.
Ну в самом деле, в чем профит компании, потратить год на разработку и 100500 денег на идеальный код, что бы при начале продаж понять что это не отобьется вообще? Клиентам чаще всего глубоко фиолетово, какие у вас "классные процедуры и как все соответствует стандартам", если это будет стоить в 10 раз дороже чем у конкурента с хоть как то работающим говнокодом. И тем более если "надо здесь и сейчас".
В целом я разделяю ваши взгляды на это безобразие, но не могу не признать что ситуация вряд ли изменится в лучшую сторону. В ближайшие годы уж точно. Идеальный код (или почти)) могут себе позволить либо крупные компании со своим штатом программистов (фикси) либо любители своего дела, выполняющие разработку чаще всего "просто по фану".
Про методологии
Как то вы все смешали в одну кучу. Наверное да, это все для красного словца и привлечения внимания? По сути от того что используется при работе (скрам ли, агиле или водопадная модель) в целом в коде ничего не изменится. Задача у всего этого одна - получить результат за минимальные сроки с минимальным использованием ресурсов. А это и приводит к такому результату, как бы нос от этого ни воротили.
Про компании
Вообще не секрет что во франчайзи "или около того" достаточно большая текучка. И да, те сотрудники что будут "сидеть на попе ровно" и ждать у моря погоды - надолго не задержатся. Указанный пример достаточно показателен, но не могу его расценить как жирный минус компании.
Представьте: вы пришли работать в компании, у вас испытательный срок. НИКТО не знает в чем у вас сильные стороны, что вы реально можете а чего нет. К вам присматриваются. А вы сели за стол, сложили ручки и ждете что вам все принесут на блюдечке. И вот ВНЕЗАПНО, через месяц, остаетесь без зарплаты.
Спорить не буду, ситуации бывают разные. Иногда пашешь весь месяц а на выходе пшик. Такое тоже бывает. Но по сути это и есть естественный отбор.
PS. К чему все это написано?
Забейте и наслаждайтесь жизнью )
Причины в первом приближении я разобрал. Не нужно расстраиваться из-за этого. Если можете реально поменять что то в такой ситации - меняйте. Нет - нечего и париться.
Удачи в новом году!
Это станет понятно по первым двум неделям работы. Не стоит месяц ждать.
Было такое, что я работал во франчах по 2-3 недели вообще без трудустройства. Носил, как дурак, все документы по приему. Меня динамили. Может это и хорошо. Нет лишних записей в трудовой об этих "компашках".
Все они сейчас мягко стелят, да жестко спать.
Читаешь вакансии: ну прям работа мечты. А на поверку ,,,, ну вы сами знаете.
(115)
Эх! Хорошо бы забивать на подобное. Но каждый день приходится снова и снова окунаться в подобный код.
Вот у автора и вырвалось)))
С точки зрения заказчика имеет смысл лишь соответствие его требованиям. Не важно что там написано - работает.
Результат нужен прямо сейчас и здесь. И заказчику непонятно зачем нужно платить 20 часов что бы добавить новую цену/колонку/посчитать итог. И ему непонятно когда к ним приходили франчи и настраивали за час. А тут ты с них хочешь 4 часа.
Мне нечего ему возразить. Все проблемы настройки других лиц он не видит в текущем времени. Они возникнут потом. И будут новой проблемой. Не связанной с старой и не являющиеся следствием предыдущего.
Для заказчика не важно что разукрасить в все цвета радуги список реализаций в УПП с кучей подзапросов (дата последней оплаты, первая поставка, общий долг и т.д.) это неправильно. Ему не важно что это нужно проектировать заранее. Что если разукрасить быстро - разукраситься всем. И тормозить будет у всех. Все это будет потом. потом будем решать проблему тормозов и проблему другого человека, которому не нравятся эти цвета радуги. Это будет следующая задача в итиль.
А пока приходиться красить. Если я его пошлю - он пойдет к начальству. И уже финансовый директор будет говорить что надо покрасить.
И именно поэтому я буду писать говнокод и плодить реквизиты. Мне семью надо кормить.
зы: У нас с этого года новая концепция. Все затраты должны быть экономический и финансово оправданы. Вот даже не знаю как туалетную бумагу оправдывать будут. )
Вы можете заказать платную консультацию или разработку у автора. Будет создан приватный заказ на «Бирже заказов» для автора.
№ 975296
Создание 10.01.19 15:12
Обновление 10.01.19 15:12
Просмотры 17053
Загрузки 0
Рейтинг
88
Комментарии 144
Код открыт Да
Рубрики Рефакторинг и качество кода
Кому Разработчик
Тип файла Нет файла
Платформа 1С:Предприятие 8
Конфигурация Универсальные
Операционная система Не имеет значения
Страна Не имеет значения
Отрасль Не имеет значения
Налоги Не имеет значения
Вид учета Не имеет значения
Доступ к файлу Бесплатно (free)
