Не знаю, как у вас, в большом мире программирования, а у нас, в 1С, очень распространён подход «что вижу, то и программирую». Есть более удобоваримое название: «программирование от данных». Однако, чаще всего это называют говнокод. Хотя, тут я не согласен – до говнокода ещё надо немного подтянуть.
Обычно, необходимость в программировании от данных возникает под давлением ряда обстоятельств. Например, «надо срочно» или «вотпрямщас» (процентов 90 задач в 1С). Также случается «нечего там смотреть и анализировать, денег только содрать хотите» (те же 90%, пожалуй). Сверху накладывается «да точно ничего не поменяется через 10 лет» (а чего ему меняться, 90%!). Увы и ах, пересекаем три по девяносто, и получаем решающий фактор: 90% программистов 1С по-другому просто не умеют.
Поглядим на несколько примеров и их отложенных последствий.
Копипаст-отчёт
Попросили программиста сварганить пару отчётов для производственного предприятия. Первый показывал выпуск продукции, второй – отгрузку и остатки. Отчёты, к сожалению, были для директора.
Кто не делал отчёты для директоров старой закалки, я поясню: там всё должно быть на своих местах. Гибкие возможности и настройки не то, чтобы не нужны… Строжайше запрещены. Всё аккуратно, по линейке, в заранее обозначенных местах. Поменять местами колонки так же страшно, как переставить полки с хлебом в Ашане.
На тот момент предприятие производило две группы продукции. Программисту так и сказали – сначала первая группа, затем вторая. Данные налицо, от них и код заплясал. На беду, формулы вычисления цифр для групп несколько различались. Не так, чтобы сильно, но в рамках «вотпрямщас» программист не сумел уложить всё в одну функцию. Ну и написал две – по одной на каждую группу продукции.
Директор, хоть и старой закалки (а может – потому, что старой закалки), бизнес развивал. В том числе – линейку производимой продукции. Через несколько месяцев появилась ещё одна группа продукции – плюс функция в отчёте. И ещё. И ещё. И так несколько лет.
Где-то посередине случилось непоправимое. Догадываетесь, что? Самое страшное на свете для таких отчётов. Изменились формулы расчёта и пара источников данных (откуда брался выпуск, продажи, остатки). Те самые формулы и запросы, которые жили своей жизнью в каждой из десятка функций. Естественно, с лёгкими, но совершенно неконтролируемыми изменениями, которые не позволяли хоть на этот раз свести всё воедино.
Потом программист ушёл, его место заняли другие. Каждый новый пытался доказать: нельзя сопровождать такую дичь. Это даже экономически невыгодно. Тысячи строк кода, которые делают одно и то же с небольшими вариациями. Надо посыпать голову пеплом, один раз оплатить рефакторинг, и получить отчёт, который при добавлении новой продукции не потребует программирования.
Увы, увы, увы. К сожалению, полный рефакторинг будет стоить, как 3-4 разовых добавления новой продукции. То есть как год жизни без головной боли от тяжёлого пепла. Поэтому – предприятие платит, программисты развлекаются. Эта задача у них навроде квеста, прятки в темноте. У неподготовленного человека на то, чтобы понять архитектурный принцип отчёта и внести в него изменения, уходит несколько дней.
Бешеный штрихкод
Производственная компания хотела диспетчеризацию производства со штрихкодированием. Перевожу на русский: чувакам в цехе вместе с заготовками выдают бумажки, на которых напечатан штрихкод. Сделал своё дело, свои операции – пикнул штрихкод, в системе отразилось всё, что нужно. И выполненные операции, и выпуск продукции или полуфабриката, и даже зарплата чувака.
Если работали с внутренними штрихкодами, то знаете два принципиальных подхода к их формированию и использованию. Первый – случайно формируем ШК и запоминаем его в привязке к нужным данным. Цифры и буквы ШК при этом ничего не значат (кроме первой и последней, если речь про EAN13). Второй – составляем ШК из каких-то значимых символов, делаем его почти человекочитаемым. Так делают, например, на принтерах ШК весов в Ашане – сам ШК нигде не хранится, но в его цифрах зашит и код товара (PLU), и его вес.
Программисты, которые решали задачу, видимо, тоже в Ашан ходят. К несчастью, это были подрядчики – им хотелось сделать и забыть. Поэтому что увидели, то и запрограммировали. А что они увидели?
Что при сканировании ШК надо узнать номер заказа, номенклатуру, спецификацию (из чего сделано), технологическую карту (как сделано) и номер операции. В 1С однозначно идентифицировать любую из этих сущностей можно только с помощью уникального идентификатора. Но он, собака, длиной 36 букв – в ШК не влезет. Есть относительно стабильное строковое поле «Код» - обычно неизменное, но всяко бывает.
Программисты решили, что всяко не бывает, и составили ШК из кодов сущностей. Длина кодов заложена с запасом – по 11 букв на рыло. На момент программирования (напомню, программирование шло от данных) использовалось 4-5 букв (нетрудно вычислить, что в таблицах было плюс-минус 10 тыс. строк).
Так и порешили – взяли по 5 букв от каждого кода, расставили в строго определённых местах (как биты в древних последовательных форматах обмена), и процедуру разбора ШК ориентировали строго на эту последовательность. Ну типа первые 5 букв – номер заказа, потом 5 букв – код номенклатуры и т.д.
Сделали, презентовали и убежали.
Первые несколько лет мучился заводской программист, которого наняли на поддержку системы. Главным мучителем была нестабильность кодов – как я указал выше, с ними всякое бывает. В том числе – существенные организационные изменения. Предприятие открыло второй цех, в котором производили сильно другую продукцию, с иными подходами к ведению нормативно-справочной информации.
Программист пытался получить карт-бланш на рефакторинг системы ШК, но где уж там… Не трогай то, что работает. А в кодах, тем временем, кроме цифр появились буквы. И не где-то, а в начале кода, перед лидирующими нулями. Не говоря уже о префиксах в номерах заказов.
Говнокод плодился. Одна процедура разбора ШК дополнялась второй, третьей, да с веточками, областями, условиями, подавлением ошибок… Не выдержал программист, уволился.
Пришли новые подрядчики, в этот раз – на сопровождение. Месяц, наверное, вникали в эту дичь. О рефакторинге уже и не помышляли, т.к. система была живая, работающая в режиме 24/7 (производство реально круглосуточное). Попросишь пару недель потерпеть без ШК – пристрелят. Уже тупо не осталось на предприятии людей, которые могут ручками отразить в системе выпуск продукции.
Ну и случилось-таки непоправимое. Вам, может, хи-хи-ха-ха, а на предприятии появилась технологическая карта с кодом 100000. В ШК, по всем правилам, она попала, как 00000. И мир рухнул.
Хорошо хоть программисты давно научились говнокод переговнокодить. Всего полдня производство простояло.
Итого
На самом деле, примеров намного больше. Но я почему-то уверен, что вам они не нужны. Наверняка в вашем окружении, текущем или прошлом, кто-нибудь да исповедует подход «программирование от данных». И вам самим есть, что рассказать на эту тему.
Могу попробовать обсудить какой-нибудь риторический вопрос. Допустимо ли так писать код? Да как им такое в голову могло прийти? Как землю топтать не стыдно после такого?
Но не буду. Есть законы рынка. И спрос на дешёвый говнокод – тоже. И он только растёт. Вслед растёт и предложение.
Если код не касается критичных областей, то и требования к нему не критичны. В обычном же, среднестатистическом, рядовом бизнесе просто нет критичных областей, связанных с программированием и автоматизацией. Самое страшное для них – отчёты в налоговую, но там есть прекрасный входной контроль и итерационность. Не то отправишь – вернут на переделку.
А долгосрочные последствия никого не интересуют. Заводского программиста через 10 лет тут точно не будет. Специалиста подрядчика – тем более, а ответственность юр.лица за неявные ошибки обычно прикрыта по сроку (например, в 1С традиционный срок – полгода). Даже сотрудников заказчика, которые ставили задачу и принимали результат, через 10 лет днём с огнём не сыщешь. Останется только собственник, а для него затраты на автоматизацию интересны только тогда, когда они чот вдруг выросли.
Так что я предлагаю смириться. Кому не лень и оплачивают – пусть пляшут от архитектуры, сценариев использования, стратегии развития, требований к производительности, трендов, триггеров и чего ещё душе угодно.
Остальные, даже если их 90%, пусть что видят, то и программируют.
Комментарии (27)
linchk
22.03.2022 04:31+10Не сталкивался с подобным использованием термина "программирование от данных". В статье описан классический сценарий, неполной постановки задачи, когда решается сиюминутная проблема без анализа последствий принятия конкретных архитектурных решений. Если же, рассматривать реальное программирование от данных, как например это происходит в языках функционального программирования типа Haskell, то описанные в статье ситуации не возникают, так как еще этапе проектирования досконально выясняются все особенности данных с которыми предстоит оперировать. Собственно говоря, только опираясь на глубокий анализ данных с которыми предстоит работать программе можно определить подходящее архитектурное решение.
NTDLL
22.03.2022 07:12+1Не сталкивался с подобным использованием термина "программирование от данных". В статье описан классический сценарий, неполной постановки задачи, когда решается сиюминутная проблема без анализа последствий принятия конкретных архитектурных решений
Это программирование от Бога!
VitB
22.03.2022 08:44Открою секрет. )) Вы описали правильный подход к разработке. В реальности, все хотят "быстро и сейчас" или даже "вчера". И это касаемо не только программирования. Например в электронике для небольших R&D компаний.
unsignedchar
22.03.2022 08:16+4Ничто не стОит так дешево и не обходится так дорого, как говнокод.
leonidy85
22.03.2022 23:22Зависит от задач, бывают ситуации что фирма закрывается быстрее, чем заказ сдашь…
Или пол года пилил црм и в итоге выяснилось что она не нужна
evkochurov
22.03.2022 09:33+7Я больше 20 лет занимаюсь разработкой корпоративных информационных систем, из них почти 10 - в такой суровой отрасли, как медицина. Да, жизнь часто ставит в условия, когда хороший код написать в принципе нельзя, даже если очень хочется. Тут не только ограниченные сроки и бюджет на разработку. Есть внутриорганизационные конфликты интересов, неснимаемые противоречия в требованиях и много чего еще. И если ты стоишь перед выбором, решить задачу хоть как-нибудь или вообще никак (и понимаешь, что тот, кто придет на твое место, встанет перед тем же выбором), то невольно начинаешь искать подходы
Тема сложная, боюсь, какого-то стройного метода выхода из таких ситуаций мне предложить не по силам, однако, кое-что сказать все же можно. Например, если говнокод неизбежен, можно попытаться его локализовать. На первом примере с отчетами из статьи:
Порядок колонок в отчете, по-хорошему, должен настраиваться в справочнике номенклатуры. Если по-хорошему нельзя, все равно пишем отчет так, как будто доступ к сортировке справочника номенклатуры у нас есть: пишем функцию (или выделяем блок кода под это прямо в отчете), которая возвращает отсортированный (и если надо - профильтрованный) список номенклатуры для данного отчета. Внутри этой функции/блока, естественно, говнокод: захардкоденный список. Так мы минимизируем телодвижения при изменении справочника номенклатуры. А если небо будет благосклонно, и настройка в справочнике таки появится, или директор откажется от "особого" порядка колонок, то говнокод можно будет удалить достаточно дешево.
Не удалось формулу расчета уложить в одну функцию, хотя, по-хорошему, она должна быть единой? Все равно пишем одну функцию. Просто внутри будет говнокод: if, который по ИД номенклатуры запускает разные вычисления. Если небо будет благосклонно... Ну вы поняли :) Во всяком случае, вся остальная часть отчета будет написана стройно, а не превратится в говнокод из-за того, что нужно разные функции вызывать, в зависимости от данных.
Возможно, эти предложения и не удалось бы в той ситуации применить прямо в таком виде, они просто служат демонстрацией хода мысли.
larasage
22.03.2022 10:30ну да, если формулы расчетов различаются действительно немного, то if выглядел более предпочтительным изначально, не надо плодить разные функции с дублированием кучи кода...
T968
22.03.2022 10:27"Нет ничего практичней хорошей теории"
Ну или
"Нет ничего полезней хорошей архитектуры"
oracle_schwerpunkte
22.03.2022 11:38+1<sarcasm>Инвестировать в архитектуру ПО на небольшом производстве в России? Может, лучше пару фур сахара купить?</sarcasm>
Если серьёзно, причины почти всегда экономические. Владельцы бизнеса не дураки, если он этот бизнес развили. Куча людей вон на старых машинах ездят и чинят их не переставая, потому что все равно дешевле выходит, чем новая в кредит.
Free0N
22.03.2022 12:37+3Проблема в том, что рано или поздно наступает такой момент, когда исчезает возможность развития такой системы. А вслед за ней (через какое-то время) - возможность поддержки.
Для бизнеса это означает отказаться от системы целиком и полностью.Хорошо, если такой момент пришёл рано - система еще не слишком большая и "спрыгнуть" (по факту - реализовать существующее решение с 0) с нее не слишком дорого. Но если случай запущенный - это фиаско...
В любом случае для компании это выльется в копеечку.
И тут дело в том, что так или иначе эту "копеечку" заплатить придется - выбор лишь в том, в каком виде это "заплатить" будет применено:
1. Платеж растянут во времени - выделяем ресурсы на проработку решений, архитектуру, тестирование, документацию, etc.
2. Единовременный платеж - реализация решения с нуля.Но, как по мне, эти варианты не равнозначны по "сумме" - второй всегда дороже.
Если переводить в аналогию с автомобилем - можно, конечно, какое-то время чинить его, но когда сгнил несущий кузов замена дворников/колодок/ходовой/движка не особо поможет.
mixsture
22.03.2022 12:17+9Все описанное в статье — это скорее о планировании следующих шагов. Мол, давайте угадаем, что будет в Х следующих лет и сразу выберем подходящую архитектуру.
У меня есть теория на этот счет. Горизонт планирования бизнеса в рф находится в промежутке 1-3 года. И тому есть причины: кризисы/дефолты каждые 10 лет, стремительное законотворчество, меняющее налоги, да и общее состояние защищенности прав и частной собственности.
С горизонтом планирования в 1 год описанных в статье проблем не видно — они почти все проявляются намного дальше (какие-то даже к 10 годам). Поэтому так и выбирают.
capitannemo
22.03.2022 15:04+2Вспоминается...
Молодой матрос собирается в первое плавание и спрашивает своего деда, бывалого капитана, что нужно брать с собой в море.— Главное, что нужно в море, — это таблетки от тошноты, ну и, пожалуй, презервативы, ведь ты будешь заходить в порты.Парень сходил в аптеку и купил 10 таблеток и 10 презервативов. На следующий день он рассказал деду, что купил. Но дед сказал, что этого будет маловато. Он сходил в ту же аптеку и опять купил столько же таблеток и презервативов. Но дед сказал, что и этого мало, нужно по крайней мере еще столько же. Когда моряк в третий раз пришел в аптеку, аптекарь спросил:— Это, конечно, не мое дело, но если вас от нее тошнит, почему вы ее трахаете?!
Никто не мешает изучить Кнута
и Пряникаи применять в 1С все алгоритмы программирования, кроме замыканий )Никогда мне наверное не понять людей которые хаят язык на котором программируют и унижают своих коллег.
Вроде крепостное правоеще не ввелидавно отменили.
Решите на питоне выплату з/п и всего делов то, а еще круче на ассемблере.Mike_soft
22.03.2022 15:56+1Да дело не в алгоритмах (хотя и они часто страдают даже у федеральных франчей)…
Дело в подходах бизнеса: лично сталкивался, что «в бюджете данного объекта поступление денег вот от такой группы контрагентов считаем внутренним займом, а в бюджете этого — привлеченными инвестициями» (да, как раз с подобным «директором старой заКАЛки»). Плюс разные не совсем порядочные операции (обнал и оббезнал, вексельные схемы и т.п.) тоже в каждом объекте (и даже в разные периоды времени) по разному. ПесТня!
А вот насчет штрихкода — вопрос спорный. «человекочитаемость» его может быть благом («отразить вручную с помятой-засаленой-надорваной бумажки»), а может, и злом (если просекут и начнут мухлевать — в свое время как раз «человеконепонятность» ШК помогла раскрыть хищение — могла бы и предотвратить, но _до_ этого руководство сказало «не запрещать повторные операции»). Но странно, что рефакторинг оказался такой уж проблемой — если, как Иван писал в телеге, «Один хороший программист, лет 10 назад, создавал систему штрихкодирования в диспетчеризации производства.», то формирование ШК д.б. «в одной процедуре» и разбор ШК должен быть тоже «в одной процедуре». Времени на добавку регистра сведений (или его эмуляции, если это 7.7) — ровно одно технологическое окно. Остальное вполне можно делать не останавливая производства, «на лету» — хоть в клюшках (там при должном навыке и останавливать не надо), хоть динамически в снеговике.
event1
22.03.2022 17:17Предприятие (или начальники) использующее более эффективный подход будет иметь конкурентное преимущество. Если говно-код обеспечивает издержки ниже чем правильная архитектура и гибкий дизайн, то, да здравствует говно-код. Если же нет, то пусть вымрет, как динозавры.
AirLight
23.03.2022 00:40Это ответственность уровня технического лидера. Если компания до такого не доросла, то так оно и будет.
lolipoka
23.03.2022 04:53Компания арендовала склад, и все складские операции оформлялись через распоряжения для склада. Когда сотрудники одного регионального франчайзи 1С реализовывали механизм распоряжений, они решили, что отдельный документ (с надёжным нумератором "из коробки") не нужен, достаточно добавить несколько реквизитов в документы "Поступление товаров и услуг" и "Реализация товаров и услуг".
Потом оказалось, что такие же реквизиты нужно добавить ещё в десяток документов.
При этом для номера распоряжения сделали строковое поле длиной 5 символов ("5 знаков хватит всем" (с)). Про то, как происходила инкрементация строковых номеров в механизме со сквозной нумерацией в нескольких типах документов и без защиты от "грязного чтения", вспоминать не хочется.
Прошло несколько лет, номера распоряжений перевалили за 99000. Другая компания (не в статусе франчайзи фирмы 1С, но стремящаяся) взялась решить проблему надвигающегося конца номеров. Переделывать механизм не стали, длину номера изменять не стали. Просто добавили буквенную часть. А чтобы хватило "на подольше", заложили туда не только кириллицу, но и латиницу.
Нисколько последних не осуждаю, для сохранения обратной совместимости и в условиях, когда заказчик не хочет платить за переделывание чего-то, что "столько лет нормально работало", вряд ли можно было сделать лучше и быстрее. Вряд ли им самим сильно понравилось делать такое. Это просто иллюстрация дальновидности и общего уровня первоначальных исполнителей, и в мире поддержки решений на платформе 1С, к сожалению, такое совсем не редкость.
Насмотришься на такое, и совсем не удивляют заявления типа "перешёл с 1С на Java и ни разу не пожалел".
nikolaiopalov
23.03.2022 04:53-1Наблюдал обратную ситуацию, комманда программистов, во главе архитектом долго тормозила развитие новой версии сайта, пол года думали ,пол года решали, потом посадили пару программистов переписывать потихоньку бэк, думали над веб апи, говорили как важно уйти от пришитого к базе сайта, потом еще года готовились к чему то, потом архитект уволился, года через 2, потом уволились программисты и те кто пытался развить этот проект. Как итог 2года готовились продумывали, просчитывали, ничего не сделали и поувольнялись. Да и у собственника как бы не особо стоит на все эти дела, если не видно никакого прогресса, и мы только оптимизируем и подготавливаем. А сколько я помню подобных внедрений црм, где люди сутками документируют бизнес процессы, пытаются просчитать все варианты, а на выходе не хватает административного ресурса заставить людей в ней работать, так как процесс настолько оброс дополнениями и инструкциями, что сотрудники просто вешаются.. Я за говнокод, быстро написали что бы работало, потом поняли все свои ошибки и оптимизировали.
IvanSTV
23.03.2022 07:25Был у меня опыт. Надо было написать тул для анализа отчета по стокам и выдаче готовых шаблоноа лля прогрузоки обратно в систему с корректировками.
Думаю - не буду привязываться к конкретным полям, пусть сопоставляет по заголовкам - поле отчета и наименование поля шаблона. Сделал, все работает. Проходит 2 месяца- бац, китайцы поменяли наименование поля в шаблонах. А в отчете оставили. Ок, ввожу мягкий поиск и сопоставление. Опять работаем квартал. Опять обновили систему, на этот раз отчет вываливали в старой версии Эксель, она добавляет лишние знаки. Обошел и это. Через год мне надоело бороться с фантазией питомцев Шенжэньского технологического и я написал блок ручных настроек соответствий полей.
Но и тут оказались подводные камни-юзеры оказались слишком... недалеки, так сказать, чтобы вручную что-то настраивать. Недавно уволился, конец квартала, жду, что будут в панике звонить и проситть исправить
asmut
24.03.2022 10:29Автор странный идеалист.
Простой пример:
На 1С программист в одиночку пишет мобильное приложение - за 34 дня. Работающее и хорошо, но естественно внутри всё страшно, да и снаружи желает оставлять лучшего.
-
На условном React тоже самое делает группа из 13 человек и 9 специальностей. Выпускают первый рабочий билд через 4+ месяца. Внутри возможно красиво (рефакторинг, архитектор), снаружи тоже приятно (UI/UX постарались).
Итоги:
Пользователи в восторге. Цена вопроса 280к. Сопровождаемость присутствует.
-
Пользователям неудобно (сделано по первоначальному эскизу, любая доработка через боль и увеличение сроков). Цена вопроса 1кк+. Сопровождаемость присутствует
Это реальный проект.
Автора не осуждаю, просто он сгорел смотреть каждый раз на реально тупые решения. Но дело не в программистах совсем, он решает проблемы, которые создают "опытные" руководители.
vis_inet
А возможно ли было сделать простейшим образом - изменить её код на "100001" ?
ovalsky
А с 99999 что будешь делать? А с 100001 ?
kest007
Как я понял, там 5 разрядов с ведущими нулями. При 100001 (в силу хитрых манипуляций) получилось бы 00001.
Но статья не об этом…
vaiobook
статья про жопо-головых (не семейство афлеков) которым толи руки отрезать толи сразу голову