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

[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]

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

Я работаю над проектом, где модель поведения описывается конфигом в виде скрипта perl, который парсится на отдельные наборы параметров для модулей. При этом сам конфиг генерируется скриптом на питоне из шаблона и набора глобальных параметров. А скрипт генерации вызывается из шелловского скрипта, в котором подготавливается набор переменных окружения, библиотек и путей. =)

Кроме того, в проекте используется Thrift, который тоже чего-то генерирует..

[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 из объектов, чем объекты из схемы.

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

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

[vit-r.livejournal.com]

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


Благородный дон хоть издали слышал слова Bridge Point, xtUML, Shlaer-Mellor?

Новые поколения с удивительным упорством изобретают велосипед на квадратных колёсах...

[serbod.livejournal.com]

Подумать только, сколько систем построил а слов таких волшебных не слышал.

И вообще, все технологии придумал еще ДаВинчи, а сейчас только придумали для них красивые названия.

Кстати, мне когда нужен новый класс (вид объекта) или метод (функция объекта), то я просто создаю его, задаю поведение и делаю для него визуальную форму. И совершенно не парюсь, как он будет в БД храниться, какие у него взаимосвязи с другими объектами. А вы предлагаете рисовать схему взаимосвязей, прописывать логику, а добавление к ней реализации поведения считаете великим достижением? Представляю вашу радость, когда в UML добавят возможность описывать формы GUI и макеты отчетов.

[vit-r.livejournal.com]

Не надо хвастаться своей серостью.

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

Зато, все писатели, а не читатели.

А вы предлагаете

Не поняв даже элементарной информации, начинать спорить с померещившимся бредом - это, конечно, круто и создаёт чувство правоты в любой ситуации.

[serbod.livejournal.com]

Да мне, вообще-то, пофиг на информацию, если она ничем не подтверждена. Покажите ваши работы, поделитесь опытом, расскажите, как оно на практике себя показало. Если оно достойно подражания - я постараюсь ваши технологии опробовать. А красивые слова оставьте для гуманитариев.

[vit-r.livejournal.com]

Не мечите бисер...

Я удаляюсь. С теми, кто книжку сам прочитать не может, мне не по пути.

[serbod.livejournal.com]

Гуманитарий обиделсо. =)

ИТ - гуманитарная дисциплина

[vit-r.livejournal.com]

А у меня два красных диплома. И оба по техническим специальностям.

Re: ИТ - гуманитарная дисциплина

[serbod.livejournal.com]

Докажи, что ты их не купил. Покажи свои работы.

Re: ИТ - гуманитарная дисциплина

[vit-r.livejournal.com]

Не мечите бисер...

Меня как-то с английского на русский перевели. Просто текстик. Но писателям это не интересно.

Re: ИТ - гуманитарная дисциплина

[serbod.livejournal.com]

Show it, please. Don't worry, I can read.