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

[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

[falcrum.livejournal.com]

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

[vp.livejournal.com]

Это вообще у тебя получился всеобъемлющий пост, универсальный на все случаи жизни :) Хоть ты его в рамку вставляй.

[theiced.livejournal.com]

>1) Отличие от общепринятых UI гайдлайнов. Например, розовый фон, красные кнопки, шрифт Comic Sans и выход из программы по кнопке F1.

зачем ви так ненавидите каснерика?

[juan-gandhi.livejournal.com]

Отлично изложено. Призывы к еасилию с адрес социвльной глруппы тупых программистов.

[serbod.livejournal.com]

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

[ex0_planet]

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

[ex0_planet]

Пункт 4 (admin) под линуксом еще как считается. В /usr/lib положено складывать либы "общего пользования", для приватных нормальные люди делают /usr/lib/программа/запчасти.so.

[guamoka.livejournal.com]

0) ad-hoc программирование, без проектирования. Практически сразу заметно по структуре api.

Ога. Имплементировать надо решение, а не проблему. А то и выходит бабушка с бородой и хвостом жучки, которую внезапно надо расширить и впихнуть куда-то репку. Правда, стоит заметить, те люди, которые так на голубом глазу поступают, если вдруг открывают для себя проектирование (сперва в лице дизайн паттерном, прости господи), то лучше от этого никак не становится:-)

[guamoka.livejournal.com]

5) Невидимый/недокументированный/мутабельный глобальный контекст.

О, я вам расскажу еще за интерсепторы. Значит, прилетает в наше ОПИ некий идентификатор, согласно сигнатуре типа #уй, но интерсептор, который надо ручками прописывать в виде аннотации (и не дай бог забудешь) к каждому нужному методу, кроме прочих шаманских ритуалов, берет этот идентификатор, превращает его в палец и сует в ту же переменную, называющуюся #уй, и в результате в теле метода мы имеем в переменной #уй уже палец:-) Экая архитектурная сила мысли!

[denisioru.livejournal.com]

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

[vp.livejournal.com]

Добавлю:

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

[j-sheridan.livejournal.com]

Ребе, я взял на себя смелость и перепостил это туда (http://www.rsdn.ru/forum/flame.comp/4762758.1.aspx)
Срач возможен знатный ))

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

[livejournal.livejournal.com]

User molnij referenced to your post from Анти-критерии для софта и апи (http://molnij.livejournal.com/315520.html) saying: [...] Оригинал взят у в Анти-критерии для софта и апи [...]

[justy-tylor.livejournal.com]

- Наличие в одной директории исходников с одинаковыми именами, различающимися лишь по регистру
- Использование символов с кодами больше 127 в именах файлов внутри неюникодных контейнеров (.zip, ...)
- Библиотеки локального назначения, шарящие по глобальным ресурсам машины (дырявая libxml и иже с ней)

[nonameshadow.livejournal.com]

Про UNC-пути люто плюсую, особливо, кода софтина многопользовальская!!!

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

[d4s.livejournal.com]

ребе, а вот я не помню спрашивал я у вас или нет: а читали ли вы "Искусство программирования в UNIX" Реймонда?
а то ваш пост мне почему-то коррелирует с этой книжкой ;-) Впрочем, как и часть комментов по существу.

[sbinq.livejournal.com]

> 11) Обработка ошибок нормального workflow исключениями. Т.е. "попытка подключится к отсутствующему серверу" кидает исключение, хотя должна быть операция TryConnect ...

А можете пояснить, чем вам не нравится просто метод Connect(..) бросающий Exception вида CannotConnectToMyCoolServer? Совсем не вижу что в этом плохого.

[n0way.livejournal.com]

"2) Неадекватное поведение по отношению к другим программам и ОС. Например, встраивание хуков на системные действия"

подразумевается что всегда есть альтернатива? это не так.

[levgem.livejournal.com]

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

No title

[livejournal.livejournal.com]

User arbinada referenced to your post from No title (http://arbinada.livejournal.com/466024.html) saying: [...] О софтопроектировании http://metaclass.livejournal.com/695560.html?thread=12443656#t12443656 [...]

[(Anonymous)]

> использование нестандартных диалогов открытия и сохранения файлов

Несколько спорный пункт. Виндовые диалоги - это если не маразм, то дебилизм - точно. Пример на винде-7: КАЖДЫЙ раз, когда нужно что-то сохранить, эта тварь мне суёт Desktop/Libraries/Documents - дура штоле?! У меня ДВА места для сохранения - C: и D:! Которые конечно видны в дереве слева, но они... СПРЯТАНЫ! И "колесо прокрутки" там не пашет без фокуса! Там же сидит "сидиром", на который в здравом уме никто писать не будет, но тем не менее он стоит.
Короче, мудак, проектировавший эти диалоги заслуживает всех вышеперечисленных наказаний.

[ko-bx.livejournal.com]

Интересно, почему ни слова про тесты.

[mar-shim.livejournal.com]

"невозможность запустить софтину под уровнем пользователя , отличного от админа" - а вот как раз бывает на вполне пользовательских программах, якобы защита от пиратства (WTF?)