Индустрия зазнаек

[vit_r]

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

Кто-то утверждает, что писание программ - инженерная дисциплина. Многие ещё любят про архитекторов добавлять.

Фиг.

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

Та же вкусовщина. Та же бездоказательность. Та же любовь выровнять всё по себе.

Главный аргумент: мне нравится - значит это правильно.

Книги "протухают" в течении пяти лет. Они писали на Фортране, значит ничего полезного не могли знать. Что мог понимать в программировании человек, если памяти в компьютере у него было меньше мегабайта. Тогда дизайна не было, ведь UML 2 ещё не изобрели.

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

Короче, маркетинг в худшем своём проявлении. Особенно статистика, за методы добычи которой станет стыдно даже экономисту.

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

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

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

Вариант 1

function()
    ...
        return A =>
    ...
        return B =>
    ...
    return C =>

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

Вариант 1

function()
    variable $to_return = NULL
    ...
        $to_return = A
    ...
        $to_return = B
    ...
        $to_return = C
    ...
    return $to_return =>


Дорога от Варианта 1 до Варианта 2 выложена седыми скальпами менеджеров и орошена слезами (а кое где и кровью) пользователей.

Но раз за разом приходят юные дарования различного возраста и заявляют Вариант 2 - это старьё, мы придумали Вариант 1. И утверждают, что он красивее, компактнее, читабильнее, понятнее...

И так и идут по жизни, гордо подняв новое старьё на флаг. Менеджеры - ничего не смыслят, клиенты вообще где-то в иной реальности. Все программисты гениальны, если б не сидели днями развалившись в кресле, на спине выросли б крылышки. Если б не склоняли голову над клавиатурой, над головой появилось бы свечение. А так неудобно: нимб за монитор задевать будет. Есть, конечно, тупые. Но это проблема начальства, если таких наняли.

Ну и последнее. Там, где результат чего-то значит,
Программа может не выполнить действие, но должна вернуть код ошибки.
Программа может вернуть код ошибки, но не может вернуть данные ошибочные.
Программа может вернуть ошибочные данные, но не может вернуть бред.

Потому как не выполненное действие - это только не выполненное действие.
Ошибка можно предусмотреть.
Ошибочные данные отловить при тестировании.
А вот против бреда лекарства не придуманы.

Comments

[george-grey.livejournal.com]

Хехе. А ведь скажи такому современному оператору ЭВМ, считающему себя программистом, что по вычметодам еще в 60х написаны целые тома, и там дофига полезного и поныне...

[yajohn.livejournal.com]

Я думаю это просто талант. У одних он есть, у других нет. Как к музыке. Есть люди которые не понимают рекурсию. Т.е. понимают, но добровольно использовать ее не будут. Тоже, кстати, кодингом на хлеб зарабатывают и даже востребованы.
Просто отрасль уж очень молодая. Все еще моложе одного поколения. Вот и хватаются все за это дело, потому как чего-ж в этом сложного - пиши исходники, да компилируй. И до какого-то момента это работает. А потом перестает работать. И тогда приходит проект-манагер и начинает перестановки.
Но вы, друзья, как ни садитесь...

[gorba.livejournal.com]

Бежать. Сломя голову.

[juan-gandhi.livejournal.com]

Я на этот конкретный вопрос (в смысле, на эту конкретную тему) отвечу в своём журнале. Будучи современным оператором ЭВМ, заставшим в 60-е пятидорожечные перфоленты и машину М3М, у которой было 1024 ячейки памяти, помнящим, что такое 1041 и 0042 и 0165 на машинах типа М20, и как М.Р.Ш.-Б. умело совмещал в одном слове команду и константу.

[bon-voyage.livejournal.com]

Я согласен на 95% с вышенаписанным. Всё это конечно правильно, но есть 3 аспекта, которые необходимо учитывать.

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

private String s2i ( String s, out int Result)
И только в том случае, если код строки возврата соответствует коду успешного завершения можно смотреть содержимое Result.
Возникающие при этом проблемы
- все программисты работающие в проекте должны быть проинформированы о том, что мы возвращаем код ошибок
- основные группы ошибок должны быть выделены и классифицированы и модуль их обработки должен быть написан или хотя бы продуман ДО того, как будут написаны другие модули.
Проблемы: Количество кодов возврата нельзя всегда предугадать зарание. При достаточно сложных ошибках требуется их специальная обработка и сложность модуля обработки ошибок возрастает.

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

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

2. Интерграция legacy систем, third-party продуктов, EAI проекты - очень часто написать нормальную обработку ошибок тут бывает трудно, так как какая-та внешняя dll не предоставляет необходимой информации, а "умирает молча". И даже если чудесным образом найдены исходники, то затраты на обработку и отладку чужого кода могут быть очень велики.

3. Иногда сроки важнее качества или кто отвечает за ошибки.

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

Если мы посмотрим на ситуацию с Тойотой и зададимся вопросом, кто пострадал, то увидим:

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

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

[sergeeva777.livejournal.com]

любой софтописатель, изучая код предыдущего софтописателя, непременно произнесёт: я бы сделал лучше)))