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

[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

[theiced.livejournal.com]

дотнетовцам аннулировать?

[serbod.livejournal.com]

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

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

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

[serbod.livejournal.com]

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

[serbod.livejournal.com]

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

[serbod.livejournal.com]

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

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

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

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

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

[sergiej.livejournal.com]

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

[sergiej.livejournal.com]

Хуже того, если идею можно довести до абсурда, она будет доведена до абсурда :)
В итоге как ни прыгай, любой кусок софта, если в нём хорошенько покопаться, имеет тонны абсурда.

[sergiej.livejournal.com]

Само собой. Просто идеала не бывает.

[v-l-a-d.livejournal.com]

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

[metaclass.livejournal.com]

Я бы предпочел генерить UML из декларативного описания, очень уж он неприятен в качестве первичного источника информации.

[v-l-a-d.livejournal.com]

ну я вообще предпочитаю рисовать UML ручками на бумаге или фломастерами на доске