Является ли УС Лэнд самопиской и какие критерии самописок? : КИС Lack & УС Land

AndreyZh · █ 20.04.2018 11:14

"Сделал дело - болтай смело"... Авось кому интересно - моя техника решения задач?

Месячишко назад "прискакала" задача - интеграция по очередному типу документов EDI c учетной системой "УС Land", которую, если честно не понимал, как решать, т.к. здесь, по мимо обычных сложностей нужно было обрабатывать документы по довольно жестким правилам учетки, а такие задачи я делаю "внешними, изолированными обработками".

Вот случилось чудо - планово появилось целых 4 дня, когда смог о ней глубоко подумать. Правда и раньше, при появлении квантов "свободного" времени что-то пытался обдумывать... Сейчас пройдены этапы решения задачи:

1. Понята, в голове, общая концепция её решения;
2. На черновиках в начале описал алгоритмы очень укрупненные блоков программы;
3. Затем на черновиках, каждый из крупных блоков описал в виде алгоритмов, учитывающих возможные нюансы и правила работы программы и УС, возможные косяки операторов или контрагентов... В "голове" программа "заработала"!
4. Сегодня написал мануал для пользователей. Для чего описывать несуществующее?

- сам, для себя "прогнал" все алгоритмы программы;
- данный мануал для меня является ТЗ, согласованный с заказчиком;
- умные пользователи наверняка по данной бумажке заметят нюансы, о которых я не знаю и сделают замечания;

Останется совсем немного, как обычно:

1. Написать тщательно комментируемый код программы, для меня это технологическая инструкция и отладить его по свежим данным;
2. Установить у заказчика и запустить в опытно-промышленную эксплуатацию;
3. Отладить косяки и доработать неучтенные нюансы;
4. Получить денюшку

P.S. Ежели кому интересно прилагаю пример входящего XML от X5 и инструкцию - техническое задание на разработку.

AndreyZh · █ 19.01.2023 15:19

Вчера "встала" новая (?) задача: отделение продаж по акциям от обычных продаж по согласованным индивидуальным прайсам. Вопрос оказался принципиальным, т.к. менеджер одной из огромных торговых сетей, ссылаясь на анализ своих
профессиональных разработчиков утверждал о слабой зависимости объема продаж сети (закупок от производителя) от проводимых акций - скидок в течении пары недель до 30% при отгрузке в регион магазинов сетей. Мотивы менагера понятны - любым способом "утрамбовать" поставщика по ценам.

Ряд наших сотрудников помнил, что в программе были механизмы работы с акциями и анализ продаж в разрезе акций, но утверждали, что это появилось в 2021г... и мне нужно было напомнить, как можно "восстановить" инфу по акциям в операциях 2022г... Когда этой технологией "никогда" не пользовались, да и сам забыл за давностью лет, с "чем её едят"... Конечно "вспомнил", разобрался, рассказал персоналу, оформил список новых задач, в том числе для разрешений заморочек с сеткой. Но как вспомнил? К системе имеется туева хуча мануалов (на каждый месяц), где есть описание технологий... Поиск по ним мало, что дал, т.к. даже примерно непонятно, когда это было сделано и насколько глубоко и зачем прорабатывалась техника... Пока не осознал, что с момента рождения системы для каждой программы, процедуры, модуля ведется история изменений, например по задачке... Все помнили, что что-то делалась на этапе загрузки в систему заказов покупателей. Открыл эту програмку:

Код:

*   Загрузки заказов из LeraData в предзаказы УС Лэнд. Интеграция с EDI LeraData             ZLO.PRG
*   Разработка:   Жуков Андрей Николаевич                                           Автор: Жуков А.Н.
*   Система разработки:    XHARBOUR 
*  
*   Старт: 05 марта 2016
*   Назначение - работа в фоновом режиме с заданными при запуске параметрами и чтение XML файлов
*   заказов из текущего каталога программы и запись их в таблицы предварительных заказов УС Land
*   согласно параметрам, определенным в таблицах системы учета
*
*   11.07.2016  Ряд покупателей присылают заказы на непроизводимые товары, коды GTIN этих товаров
*   записаны в файле BrakGTIN.cfg, перекачиваемый в массив памяти. Для товаров из данного списка
*   никаких работ и анализа не произвожу... Файлы *.TXT все удаляю в плане чистки времянок
*
*   24.11.2016  Появилась схема изменения маршрута вывоза в отдельной таблице в зависимости от
*   номера дня недели, т.е. может быть заменяющий маршрут
*
*   11.05.2019  Для Тандер ГМ GTIN отличается от кодов других клиентов. Сделал технику закачки
*   таких расхождений из текст.файла PreoGTIN.cfg и преобразование неверного GTIN к коду, который
*   используется для всех клиентов - БД LeraData        
*
*   29.06.2019  Введен новый параметр запуска, который можно менять нажатием кнопки в интерфейсе,
*   по которому переключаются, как брать цены для заказов. Раньше автоматом бралось из спецификации,
*   а сейчас можно из заказов. Гемор, что цены в заказе могут определяться с НДС, без НДС или 
*   их вообще может не быть... Если не могу их взять с заказа, то беру из спецификации
*
*   08.07.2019  Исправлил косяк, сделанный в 29.06.2019, когда убрал анализ исключаемых GTIN из заказов
*   
*   18.10.2019  Дата предзаказа по настройке (-1)-дата заказа, (-2)-дата поставки, (>=0)-добавляем указанное число дней
*   
*   08.11.2019  Проставляю признак "А" в детализации предзаказа, если цены заказа отличаются от цен,
*       заданных в спецификации покупаля. В поле DETALPRE.stat
*
*   28.11.2019  Из-за Ленты, на перспективу проставляю интервал времени поставки, если он есть в заказе покупателя
*   20.02.2020  Адаптация схемы преобразования входящих GTIN для Вдохновения ООО Лента: 4607124662150 меняю на 4607124662228
*   05.05.2020  Постоянные заморочки с ООО Лента. GLN=4606068999995 На этот раз от них приходит заказ на
*       Вдохновение=4607124662228, который не преобразуется через схему 
*                на=4607124662228... или может быть, но обратное преобразование в Lera_edi всё равно не работает
*****       Вишенка=4607124662181, который не преобразуется через схему 
*                на=4607124662020
*   07.12.2020  В Э-КОМ поступают заказы не имеющие тэга по НДС - тупо при этом прописываю 20%
*   15.09.2021  Схема преобразования GTIN РЦ в липовые GTIN базу УС - альтернативная технология
*   21.10.2021  Исключаю из анализа выведенных из производства GTIN изделия из схемы преобразования РЦ
*   22.03.2022  При приеме заказа в программе zLeraOrd заменяю имя файла order* на order_z* при переносе
*       в каталог программы zLeraOrd, где по этому признаку пишу признак в системную УС, т.к. много
*       замечаний, что исходящие доки не отправляются, когда кидают заказы непосредственно в каталог
*       zLeraOrd и при этом наезды на качество работы программы
*	14.12.2022	Создание фиктивных предзаказов по паллетам или добавление паллет к существующим заказам,
*		что регулируется настройкой plus_pal.cfg. Описание настроек дано в данном файле
*
*   Main        Процедура стартовой для программы
* ==================================================================================================

То есть сразу узнал, что это сделано было в ноябре 2019, следовательно доработки проводились в ноябре-декабре 2019г., а дальше посмотрел инструкции и так далее. Ведение логов изменений версий - это просто блаж, культура написания кода или признак, что программу нельзя считать самопиской?

OlegON · █ 19.01.2023 15:32

культура кода
точнее - структура проекта
без этого все плохо, учитывая ограниченность памяти человека

FinSoft · █ 19.01.2023 17:56

Обсуждалось, мнение неоднозначное. Некоторые считают, что надо. Даже специальные инструменты делают для автоматической вставки в код. В том числе, оставляя закомментированными старый код. Другие, наоборот, стараются держать код без наслоения лишнего. Я лично в комментариях пишу только пояснения, чтобы потом легче было вспомнить ход мыслей. Код без комментариев это зло. А историю изменений держу в отдельном файлике. Если изменение достаточно принципиальное, то сохраняю старый расчет целиком, чтобы удалить после отладки нового, хотя удаляю не всегда. У меня расчеты обычно в отдельных рутинках (подпрограммах). Если рутинка называется calc_r, копирую ее, например, в calcOld_r и изменяю исходную. А в старой могу подписать что-то для памяти. Рутинки редактируются раздельно, в тексте нет ничего лишнего, а предыдущую версию всегда можно посмотреть и сравнить. Аналогично иногда делается и для целых оконных процедур.

AndreyZh · █ 19.01.2023 18:40

Цитата:

FinSoft ➤ Обсуждалось, мнение неоднозначное. Некоторые считают, что надо. Даже специальные инструменты делают для автоматической вставки в код. В том числе, оставляя закомментированными старый код. Другие, наоборот, стараются держать код без наслоения лишнего. Я лично в комментариях пишу только пояснения, чтобы потом легче было вспомнить ход мыслей. Код без комментариев это зло. А историю изменений держу в отдельном файлике. Если изменение достаточно принципиальное, то сохраняю старый расчет целиком, чтобы удалить после отладки нового, хотя удаляю не всегда. У меня расчеты обычно в отдельных рутинках (подпрограммах). Если рутинка называется calc_r, копирую ее, например, в calcOld_r и изменяю исходную. А в старой могу подписать что-то для памяти. Рутинки редактируются раздельно, в тексте нет ничего лишнего, а предыдущую версию всегда можно посмотреть и сравнить. Аналогично иногда делается и для целых оконных процедур.

Комментарии лишь на скриптовых языках или интепритаторах могут вносить замедления, но на компиляторах они удаляются в процессе сборок, т.е. для работы приложения не нужны... Упоминал, что пытался найти когда? Как пример - собрание добавок к основным инструкциям... Сам редко там, что-то по нюансам ХХХ годичной давности нахожу... и даже поиском, т.к. и лексика мануалов стареет вместе с разработчиком

FinSoft · █ 19.01.2023 19:11

На скриптовых языках тоже практически не замедляет. У всех сейчас трансляция в байт код. Это не машинный код, а некий промежуточный для движка, чтобы каждый раз не делать синтаксический разбор текста. В java, c#, pyton, php, 1C и т.п.