Не знаю, как у вас, в большом мире программирования, а у нас, в 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%, пусть что видят, то и программируют.
habr.com
Обычно, необходимость в программировании от данных возникает под давлением ряда обстоятельств. Например, «надо срочно» или «вотпрямщас» (процентов 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%, пусть что видят, то и программируют.
Что вижу, то и программирую
Не знаю, как у вас, в большом мире программирования, а у нас, в 1С, очень распространён подход «что вижу, то и программирую». Есть более удобоваримое название: «программирование от данных». Однако,...
habr.com