Comments 30
появилась технологическая карта с кодом 100000
А возможно ли было сделать простейшим образом - изменить её код на "100001" ?
А с 99999 что будешь делать? А с 100001 ?
Как я понял, там 5 разрядов с ведущими нулями. При 100001 (в силу хитрых манипуляций) получилось бы 00001.
Но статья не об этом…
Технологическая карта с номером 100001 и 000001 и даже 200001 имели бы одинаковый "00001" код в разряде "номер документа". Как по такому ШК найти нужный документ?
Не сталкивался с подобным использованием термина "программирование от данных". В статье описан классический сценарий, неполной постановки задачи, когда решается сиюминутная проблема без анализа последствий принятия конкретных архитектурных решений. Если же, рассматривать реальное программирование от данных, как например это происходит в языках функционального программирования типа Haskell, то описанные в статье ситуации не возникают, так как еще этапе проектирования досконально выясняются все особенности данных с которыми предстоит оперировать. Собственно говоря, только опираясь на глубокий анализ данных с которыми предстоит работать программе можно определить подходящее архитектурное решение.
наверное от данного
Не сталкивался с подобным использованием термина "программирование от данных". В статье описан классический сценарий, неполной постановки задачи, когда решается сиюминутная проблема без анализа последствий принятия конкретных архитектурных решений
Это программирование от Бога!
Открою секрет. )) Вы описали правильный подход к разработке. В реальности, все хотят "быстро и сейчас" или даже "вчера". И это касаемо не только программирования. Например в электронике для небольших R&D компаний.
одна эсс
Ничто не стОит так дешево и не обходится так дорого, как говнокод.
Печальная правда
Я больше 20 лет занимаюсь разработкой корпоративных информационных систем, из них почти 10 - в такой суровой отрасли, как медицина. Да, жизнь часто ставит в условия, когда хороший код написать в принципе нельзя, даже если очень хочется. Тут не только ограниченные сроки и бюджет на разработку. Есть внутриорганизационные конфликты интересов, неснимаемые противоречия в требованиях и много чего еще. И если ты стоишь перед выбором, решить задачу хоть как-нибудь или вообще никак (и понимаешь, что тот, кто придет на твое место, встанет перед тем же выбором), то невольно начинаешь искать подходы
Тема сложная, боюсь, какого-то стройного метода выхода из таких ситуаций мне предложить не по силам, однако, кое-что сказать все же можно. Например, если говнокод неизбежен, можно попытаться его локализовать. На первом примере с отчетами из статьи:
Порядок колонок в отчете, по-хорошему, должен настраиваться в справочнике номенклатуры. Если по-хорошему нельзя, все равно пишем отчет так, как будто доступ к сортировке справочника номенклатуры у нас есть: пишем функцию (или выделяем блок кода под это прямо в отчете), которая возвращает отсортированный (и если надо - профильтрованный) список номенклатуры для данного отчета. Внутри этой функции/блока, естественно, говнокод: захардкоденный список. Так мы минимизируем телодвижения при изменении справочника номенклатуры. А если небо будет благосклонно, и настройка в справочнике таки появится, или директор откажется от "особого" порядка колонок, то говнокод можно будет удалить достаточно дешево.
Не удалось формулу расчета уложить в одну функцию, хотя, по-хорошему, она должна быть единой? Все равно пишем одну функцию. Просто внутри будет говнокод: if, который по ИД номенклатуры запускает разные вычисления. Если небо будет благосклонно... Ну вы поняли :) Во всяком случае, вся остальная часть отчета будет написана стройно, а не превратится в говнокод из-за того, что нужно разные функции вызывать, в зависимости от данных.
Возможно, эти предложения и не удалось бы в той ситуации применить прямо в таком виде, они просто служат демонстрацией хода мысли.
"Нет ничего практичней хорошей теории"
Ну или
"Нет ничего полезней хорошей архитектуры"
<sarcasm>Инвестировать в архитектуру ПО на небольшом производстве в России? Может, лучше пару фур сахара купить?</sarcasm>
Если серьёзно, причины почти всегда экономические. Владельцы бизнеса не дураки, если он этот бизнес развили. Куча людей вон на старых машинах ездят и чинят их не переставая, потому что все равно дешевле выходит, чем новая в кредит.
Проблема в том, что рано или поздно наступает такой момент, когда исчезает возможность развития такой системы. А вслед за ней (через какое-то время) - возможность поддержки.
Для бизнеса это означает отказаться от системы целиком и полностью.
Хорошо, если такой момент пришёл рано - система еще не слишком большая и "спрыгнуть" (по факту - реализовать существующее решение с 0) с нее не слишком дорого. Но если случай запущенный - это фиаско...
В любом случае для компании это выльется в копеечку.
И тут дело в том, что так или иначе эту "копеечку" заплатить придется - выбор лишь в том, в каком виде это "заплатить" будет применено:
1. Платеж растянут во времени - выделяем ресурсы на проработку решений, архитектуру, тестирование, документацию, etc.
2. Единовременный платеж - реализация решения с нуля.
Но, как по мне, эти варианты не равнозначны по "сумме" - второй всегда дороже.
Если переводить в аналогию с автомобилем - можно, конечно, какое-то время чинить его, но когда сгнил несущий кузов замена дворников/колодок/ходовой/движка не особо поможет.
У меня есть теория на этот счет. Горизонт планирования бизнеса в рф находится в промежутке 1-3 года. И тому есть причины: кризисы/дефолты каждые 10 лет, стремительное законотворчество, меняющее налоги, да и общее состояние защищенности прав и частной собственности.
С горизонтом планирования в 1 год описанных в статье проблем не видно — они почти все проявляются намного дальше (какие-то даже к 10 годам). Поэтому так и выбирают.
Вспоминается...
Молодой матрос собирается в первое плавание и спрашивает своего деда, бывалого капитана, что нужно брать с собой в море.— Главное, что нужно в море, — это таблетки от тошноты, ну и, пожалуй, презервативы, ведь ты будешь заходить в порты.Парень сходил в аптеку и купил 10 таблеток и 10 презервативов. На следующий день он рассказал деду, что купил. Но дед сказал, что этого будет маловато. Он сходил в ту же аптеку и опять купил столько же таблеток и презервативов. Но дед сказал, что и этого мало, нужно по крайней мере еще столько же. Когда моряк в третий раз пришел в аптеку, аптекарь спросил:— Это, конечно, не мое дело, но если вас от нее тошнит, почему вы ее трахаете?!
Никто не мешает изучить Кнута и Пряника и применять в 1С все алгоритмы программирования, кроме замыканий )
Никогда мне наверное не понять людей которые хаят язык на котором программируют и унижают своих коллег.
Вроде крепостное право еще не ввели давно отменили.
Решите на питоне выплату з/п и всего делов то, а еще круче на ассемблере.
Дело в подходах бизнеса: лично сталкивался, что «в бюджете данного объекта поступление денег вот от такой группы контрагентов считаем внутренним займом, а в бюджете этого — привлеченными инвестициями» (да, как раз с подобным «директором старой заКАЛки»). Плюс разные не совсем порядочные операции (обнал и оббезнал, вексельные схемы и т.п.) тоже в каждом объекте (и даже в разные периоды времени) по разному. ПесТня!
А вот насчет штрихкода — вопрос спорный. «человекочитаемость» его может быть благом («отразить вручную с помятой-засаленой-надорваной бумажки»), а может, и злом (если просекут и начнут мухлевать — в свое время как раз «человеконепонятность» ШК помогла раскрыть хищение — могла бы и предотвратить, но _до_ этого руководство сказало «не запрещать повторные операции»). Но странно, что рефакторинг оказался такой уж проблемой — если, как Иван писал в телеге, «Один хороший программист, лет 10 назад, создавал систему штрихкодирования в диспетчеризации производства.», то формирование ШК д.б. «в одной процедуре» и разбор ШК должен быть тоже «в одной процедуре». Времени на добавку регистра сведений (или его эмуляции, если это 7.7) — ровно одно технологическое окно. Остальное вполне можно делать не останавливая производства, «на лету» — хоть в клюшках (там при должном навыке и останавливать не надо), хоть динамически в снеговике.
Предприятие (или начальники) использующее более эффективный подход будет иметь конкурентное преимущество. Если говно-код обеспечивает издержки ниже чем правильная архитектура и гибкий дизайн, то, да здравствует говно-код. Если же нет, то пусть вымрет, как динозавры.
Это ответственность уровня технического лидера. Если компания до такого не доросла, то так оно и будет.
Компания арендовала склад, и все складские операции оформлялись через распоряжения для склада. Когда сотрудники одного регионального франчайзи 1С реализовывали механизм распоряжений, они решили, что отдельный документ (с надёжным нумератором "из коробки") не нужен, достаточно добавить несколько реквизитов в документы "Поступление товаров и услуг" и "Реализация товаров и услуг".
Потом оказалось, что такие же реквизиты нужно добавить ещё в десяток документов.
При этом для номера распоряжения сделали строковое поле длиной 5 символов ("5 знаков хватит всем" (с)). Про то, как происходила инкрементация строковых номеров в механизме со сквозной нумерацией в нескольких типах документов и без защиты от "грязного чтения", вспоминать не хочется.
Прошло несколько лет, номера распоряжений перевалили за 99000. Другая компания (не в статусе франчайзи фирмы 1С, но стремящаяся) взялась решить проблему надвигающегося конца номеров. Переделывать механизм не стали, длину номера изменять не стали. Просто добавили буквенную часть. А чтобы хватило "на подольше", заложили туда не только кириллицу, но и латиницу.
Нисколько последних не осуждаю, для сохранения обратной совместимости и в условиях, когда заказчик не хочет платить за переделывание чего-то, что "столько лет нормально работало", вряд ли можно было сделать лучше и быстрее. Вряд ли им самим сильно понравилось делать такое. Это просто иллюстрация дальновидности и общего уровня первоначальных исполнителей, и в мире поддержки решений на платформе 1С, к сожалению, такое совсем не редкость.
Насмотришься на такое, и совсем не удивляют заявления типа "перешёл с 1С на Java и ни разу не пожалел".
Наблюдал обратную ситуацию, комманда программистов, во главе архитектом долго тормозила развитие новой версии сайта, пол года думали ,пол года решали, потом посадили пару программистов переписывать потихоньку бэк, думали над веб апи, говорили как важно уйти от пришитого к базе сайта, потом еще года готовились к чему то, потом архитект уволился, года через 2, потом уволились программисты и те кто пытался развить этот проект. Как итог 2года готовились продумывали, просчитывали, ничего не сделали и поувольнялись. Да и у собственника как бы не особо стоит на все эти дела, если не видно никакого прогресса, и мы только оптимизируем и подготавливаем. А сколько я помню подобных внедрений црм, где люди сутками документируют бизнес процессы, пытаются просчитать все варианты, а на выходе не хватает административного ресурса заставить людей в ней работать, так как процесс настолько оброс дополнениями и инструкциями, что сотрудники просто вешаются.. Я за говнокод, быстро написали что бы работало, потом поняли все свои ошибки и оптимизировали.
Был у меня опыт. Надо было написать тул для анализа отчета по стокам и выдаче готовых шаблоноа лля прогрузоки обратно в систему с корректировками.
Думаю - не буду привязываться к конкретным полям, пусть сопоставляет по заголовкам - поле отчета и наименование поля шаблона. Сделал, все работает. Проходит 2 месяца- бац, китайцы поменяли наименование поля в шаблонах. А в отчете оставили. Ок, ввожу мягкий поиск и сопоставление. Опять работаем квартал. Опять обновили систему, на этот раз отчет вываливали в старой версии Эксель, она добавляет лишние знаки. Обошел и это. Через год мне надоело бороться с фантазией питомцев Шенжэньского технологического и я написал блок ручных настроек соответствий полей.
Но и тут оказались подводные камни-юзеры оказались слишком... недалеки, так сказать, чтобы вручную что-то настраивать. Недавно уволился, конец квартала, жду, что будут в панике звонить и проситть исправить
Автор странный идеалист.
Простой пример:
На 1С программист в одиночку пишет мобильное приложение - за 34 дня. Работающее и хорошо, но естественно внутри всё страшно, да и снаружи желает оставлять лучшего.
На условном React тоже самое делает группа из 13 человек и 9 специальностей. Выпускают первый рабочий билд через 4+ месяца. Внутри возможно красиво (рефакторинг, архитектор), снаружи тоже приятно (UI/UX постарались).
Итоги:
Пользователи в восторге. Цена вопроса 280к. Сопровождаемость присутствует.
Пользователям неудобно (сделано по первоначальному эскизу, любая доработка через боль и увеличение сроков). Цена вопроса 1кк+. Сопровождаемость присутствует
Это реальный проект.
Автора не осуждаю, просто он сгорел смотреть каждый раз на реально тупые решения. Но дело не в программистах совсем, он решает проблемы, которые создают "опытные" руководители.
всё правильно сделал программист :-)
1. Задание (ТЗ) от директора - надо делать по ТЗ
2. Цифры в штрихкоде должны означать что-то. Очень много бывает штрихкодов выцветших, неработающих.
Даже в любом магазине продавцы часто вводят штрихкод вручную цифрами.
Что вижу, то и программирую