Анти-критерии для софта и апи

[metaclass]

В процессе срачей с айседом пришел к выводу, что искать идеальные софты/либы/платформы бесполезно, практически все, что хоть как-то используется - достаточно пригодно для использования. Лучше выделить критерии для того, что использовать нежелательно:

С точки зрения пользователя:
1) Отличие от общепринятых UI гайдлайнов. Например, розовый фон, красные кнопки, шрифт Comic Sans и выход из программы по кнопке F1.
2) Неадекватное поведение по отношению к другим программам и ОС. Например, встраивание хуков на системные действия или расширений в Explorer.
3) Издевательства над обычными средствами пользовательской интеграции - например, невозможность без вуду скопировать текст из программы в клипбоард, стандартным сочетанием кнопок или меню.
4) Наличие тупиков в Workflow, т.е. возможность обычными действиями зайти в программе туда, откуда обычными действиями уже не выйдешь (только снимать программу из диспетчера задач, kill и прочая)
5) Отсутствие прогресс-баров и прочей индикации выполнения при длительных операциях, отсутствие возможности их корректно прервать.

С точки зрения админства-деплоймента:
1) Неумение работать в многопользовательской среде/на терминальном сервере.
2) Неумение переживать xcopy-деплоймент и запускаться на чистой машине. В крайнем случае - должно быть документировано, что из окружения требуется (.net, жаба, переменные окружения)
3) Хардкодед пути в бинарниках - убивать нещадно.
4) Размещение своих либ/данных в общих папках, типа system32. Под линуксом - не считается, там за это пакетный менеджер, в идеале, отвечает и там принято всему софту гадить единообразно.

С точки зрения программизма:
0) ad-hoc программирование, без проектирования. Практически сразу заметно по структуре api.
1) Хардкодед значения, не являющиеся математическими константами. Пытать на дыбе авторов. Сюда же - хардкодед пути типа C:/Program Files или C:/openssl/etc (портированный софт
2) Тот же контекст, но в пределах ВСЕЙ ОС, а не только запущенного бинарника (Dragon Naturally Speaking и его апи - сука, ненавижу).
3) Не реентерабельные функции.
4) Отсутствие в АПИ для работы с внешними ресурсами явных пар типа Open/Close, Enter/Exit.
5) Невидимый/недокументированный/мутабельный глобальный контекст. Сюда же - использование такого контекста для работы с внешними ресурсами. Т.е. Open не возвращает "хендл для работы с ресурсом", а просто открывает где-то внутри его и все последующие функции его используют, неявно. Например, коннект к БД - один на всю программу. Или транзакция - одна на весь коннект к БД.
6) Отсутствие для значений getter там где присутствует setter. Забивать гвозди в голову за такое. Т.е. мы можем установить некий параметр, но не можем узнать его значение.
7) Случайное поведение API, не объяснимое переданными параметрами и документированным окружением. Обычно - следствие пункта 5 и общего рукожопия.
8) Использование GUI в явно не-гуишных либах. Последний пример - библиотека для работы с одной железякой, кидающая диалоговое окно при ошибке драйвера. Если ее использовать в фоновом сервисе - капец от входа.
9) Отсутствие в API возможности показать прогресс и прервать длительно выполняющиеся операции.
10) Отсутствие обработки ошибок вообще. УБИВАТЬ! УБИВАТЬ! УБИВАТЬ!
11) Обработка ошибок нормального workflow исключениями. Т.е. "попытка подключится к отсутствующему серверу" кидает исключение, хотя должна быть операция TryConnect
Хуже этого - только парсинг строк в простые значения без функции TryParse
12) Отсутствие логгинга. Сажать на кол, конечно же.
13) Отсутствие исходников - когда вышеописанное вылезет в полной мере, а автор окажется живущим половой жизнью с ежихой в ашраме Гуру Бхактиведанты Свами Прабхувады Ребе Короля Мошиаха - вам придется чинить либу самому.
За вас никто ничего чинить не будет - инфа 100%, еще ни одной либы не видел, где автор бы починил самоочевидную ошибку ранее чем через месяц после баг-репорта.

Т.е., если вы проектируете API - лучше сразу думайте, как его можно однозначно завернуть в красивый класс на c# или сделать обертку для него на хаскеле функциональном языке - резко становится очевидно, что можно делать и чего нельзя.

PS от denisioru:
- невозможность запустить несколько инстансов софтины одновременно. Да, год 2012й. Лом в жопу.
- изобретение собственных IP-протоколов. Прикладной софт должен работать по UDP или TCP. В редких очевидных случаях - RTMP и иже с ними. Люто, бешено лоботомировать.
- использоать API ОС для ресолвинга имён. За формирование руками DNS запросов и отправку их в неизвестном направлении - насылать нещадный кровавый понос.
- использование нестандартных диалогов открытия и сохранения файлов. Как наказание - выдать блок питания к ноуту юзера, несовместимый с розетками в офисе и дома.
- глюки на мультимониторных конфигурациях. За появление главного окна софтины, напополам распиленное между десктопами - выкалывать глаза.
- создание и использование временных файлов ВНЕ системного каталога TEMP - отправлять сортировать мусорные баки.

PS от belnetmon:
- невозможность запустить софтину под уровнем пользователя , отличного от админа
- невозможность работы с UNC путями
- гадить во временную папку, которую пидор создал в корне системного диска (NVidia, Intel - привет)

Comments

[serbod.livejournal.com]

У нас модель может на ходу, в runtime меняться. А вам слабо?

[serbod.livejournal.com]

Приведите пример. =)

[serbod.livejournal.com]

Коллега, вам ужасно не повезло. Вы бросили меня в терновый куст. Я 10 лет занимался ERP вообще и 1С в частности, поэтому ваша опердень меня совершенно не впечатляет.

Приведите конкретный пример работы "статическая модель генерирует приложеие и ядро его динамичской модели" на реальной задаче.

А я пока вкраце опишу наш проект. Это "лего-конструктор" для постройки систем захвата, кодирования, обработки и распространения видео в реальном времени. Примерно как DirectShow или GStreamer, только на порядок проще и эффективней. Работает как распределенная система на сотнях машин, управляется файлами- конфигами, настраивается в реальном времени. Мы ведь не можем в случае проблем во время трансляции футбольного матча повесить табличку "under construction".

[serbod.livejournal.com]

Судить по нескольким записям в моем журнале было большой ошибкой. =) Я разработал с нуля как минимум 3 разные CRM на базе 1С и написал сотни (а может и тысячи - не считал) разных обработок, документов, отчетов для типовых конфигураций 1С 5.0, 6.0, 7.х и 8.х. А еще всякие внешние компоненты для разных железок. К сожалению (а может и к счастью) я инженер, а не предприниматель, поэтому все эти наработки не лежат в онлайновых магазинах софта.

Вы же свою CRM гордо называете ERP-системой и пытаетесь ее сравнивать с 1С 8.1. А резервировать товар ваша опердень умеет? А вести учет по договорам? Ребе erp_shik вас на тряпки порвет, почитайте его журнал и его статьи.

[serbod.livejournal.com]

Да не вопрос - serbod.com

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

Сдается мне, что у вас там банальный GUI к базе данных и вся логика на хранимых процедурах.

[theiced.livejournal.com]

он просто дурак. не важно что там у него.

[serbod.livejournal.com]

Я бы не стал называть дураком человека, спроектировавшего и реализовавшего классическую опердень. Даже если она не особо удачна и перспективна.

[serbod.livejournal.com]

Почитал.
Зря вы недооцениваете ORM, для учетно-бухгалтерских оперденей оно гораздо удобнее и продуктивнее, чем генерация классов по UML. В оперденях обычно работают с относительно простыми объектами из реального мира - документ, карточка товара, карточка клиента. Отчеты в основном сводятся к фильтрации и компоновке данных. А при просмотре больших списков используются курсоры и постраничный fetch. То есть, нет сложных select'ов, и проще генерировать SQL из объектов, чем объекты из схемы.

Зато в оперденях много логики (как круто звучит, а?) и она все время меняется. Для таких малых квантов данных очень дохрена логики. А логику проще, лучше и удобнее реализовывать на клиентской части, чем в хранимых процедурах. В идеале, использовать какой-нибудь скриптовый язык, чтобы можно было логику опердени писать и отлаживать прямо на коленке, не пересобирая весь проект. И не заморачиваться деталями работы хранилища - не те объемы.

Ваш подход эффективен только для специфичных систем, где очень много данных и мало логики - биллинг, например. А бухгалтерская опердень на хранимых процедурах - дикий оверкилл.

[serbod.livejournal.com]

С фиксацией торговой первички (с проверкой остатков, резервов и взаиморасчетов) 1С 7.7 прекрасно справлялась в 2004 году на изрядно устаревшем (на то время) желдезе, на объемах порядка сотни документов в час, до 50 строк в документе. База строительных товаров, 4 розничные кассы + 2 оператора для оптовиков. Отчеты по продажам, остаткам и взаиморасчетам - без особых проблем. База MSSQL, без терминала. То есть, далеко не оптимальный вариант по производительности.

Сложности при обработке таких объемов (перепроведение, книга продаж). Пробовали разные именитые системы - они даже не смогли данные за месяц загрузить и обработать.

Что касается проверки остатка через ORM в реальном времени - получаем таблицу остатков с фильтром по перечню товаров и складов. Примерно так:

СписокТоваров=Накладная.ДанныеКолонки("Товар");
Фильтр = СоздатьОбъект("Фильтр");
Фильтр.Установить("Товар", СписокТоваров);
Фильтр.Установить("Склад", Накладная.Склад);
Остатки = ТаблицаОстатков.Выбрать(Фильтр);

Можно было по-английски написать, для солидности. Но смысл от этого не изменится. Последняя строка сгенерирует:

SELECT * FROM ТаблицаОстатков WHERE "Товар" IN СписокТоваров AND "Склад" = Накладная.Склад;

А еще она заполнит, проверит и санизирует параметры, выполнит запрос, возьмет результат, переведет его в форму объекта. Или обработает ошибку, если она возникнет. Вполне возможно, что часть этих операций будет выполняться в хранимой процедуре, которую создала ORM. И все это в одной строке, а не в в 2-3 тысячи строк.

Про кеширование сальдо с изоляцией - нифига не понял, нужен конкретный пример.

[serbod.livejournal.com]

ТаблицаОстатков - это просто для примера. Физически это может быть view из какой-нибудь огроменной таблицы движений (операций).

В 1С используется комбинация таблицы движений и "кэширующей" таблицы остатков по периодам (обычно по месяцам). Можно запросить остаток за любой момент, сначала выбирается остаток на начало периода, и добавляются движения до конкретного момента. Дешево и сердито. При изменениях задним числом соответствующие последующие остатки пересчитываются. Причем, все это происходит автоматом и не требует ни малейших усилий со стороны программиста. Изменения задним числом в 1С настолько тривиальны, что многие бухи считают это нормой.

[serbod.livejournal.com]

Как прикладной программист я вас не понимаю. Какие какие еще кеширующие таблицы, что это за цифры, зачем они? Есть объект "ТаблицаОстатков", из которого можно получить остатки других объектов на любой момент. Это же так просто!

Как системный программист я написал класс "ТаблицаОстатков", который производит массу операций по подготовке и выполнению SQL-запроса, извлечению данных. Те самые 2-3 тысячи строк, которые оперируют полями, ключами, идентификаторами и прочей низкоуровневой хренью, в которой даже специалист с двумя высшими образованиями и 5 годами опыта работы будет 2 дня разбираться. Кстати, serialize в таблице остатков нафиг не нужен, мы же свойства объектов храним, а не методы.

[serbod.livejournal.com]

Меня можно считать кем угодно - не ошибетесь. =) А вот вы дальше опердени под глупого, но богатого буратину не продвинитесь, потому что без разделения разработки на прикладную и системную часть сложность доработок и обслуживания растет в геометрической прогрессии, и кроме пары-тройки стареющих спецов это никто не потянет. В прикладной части вы явно не сильны, не видите разницы между управленческим и бухгалтерским учетом. У ваших клиентов, видимо, директор никогда в программу не заглядывает, ему все данные главбух в папочке приносит.

[serbod.livejournal.com]

Остатки - это вторичные данные, которые пересчитываются на основании первичных данных. Хранить их историю крайне глупо, и даже чревато.

Это все равно, что хранить историю колонки "итого", чтобы при удалении какой-то строки вернуть прежнее значение.

Если откатывать не отдельную операцию, а на конкретный момент - то это делается средствами SQL-сервера, по журналу транзакций.

[metaclass.livejournal.com]

Я как раз сейчас работаю над темой нормального кэширования расчетов сальдо в произвольных разрезах.