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

[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х написаны целые тома, и там дофига полезного и поныне...

[vit-r.livejournal.com]

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

[raydac.livejournal.com]

они правильно к процессу организации производства подходят, ты просто не учитываешь что в их процессах не нужен выходной продукт (не ну на словах то он нужен конечно) и наверное ты там выглядишь аки Генрих Мария Заузе в "Геркулесе" а именно как :) "склочник"

[vit-r.livejournal.com]

Я слишком циничен, чтоб верить в добро и смысл.
Но всё равно грустно.

[yajohn.livejournal.com]

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

[vit-r.livejournal.com]

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

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

[yajohn.livejournal.com]

Но область действительно молодая. А реальные живые инженеры сегодня работают иначе нежели 40 лет назад. Про архитекторов не знаю.

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

Кстати, что до приведенного примера, ИМХО рубикон проходит не между теми кто использует 1. и теми кто 2., и даже не между теми кто открыл 1. заново и теми кто знал о нем, а между теми кто до хрипоты доказывает преимущества одного и использует только его, и теми кто использует более подходящий в конкретном случае.

[vit-r.livejournal.com]

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

Инженеры чертят совершенно по-другому. И моделлируют тоже. А в остальном мало что изменилось.

Тех же инженеров-электронщиков сто лет назад практически не было.

талантливый программист как раз и пишет код устойчивый к изменениям.


Может - да. Хочет - а вот это не всегда.

Кто и как доказал, в каком случае что лучше подходит? Вот, если копнуть эксперементальные данные.

[yajohn.livejournal.com]

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

> Может - да. Хочет - а вот это не всегда.
Полагаешь есть шанс заставить?

> Кто и как доказал, в каком случае что лучше подходит?
Нет нужды доказывать, проще назвать субъективным :) В приведенном тобой примере: я предпочитаю использовать подход номер два. Но если надо вывалится из вложенных циклов (типично при линейном поиске, например), то по всем параметрам удобнее окажется вариант номер раз.

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

Это как с форматированием исходного кода. Я, например, всегда стараюсь писать код как можно более компактно (во всяком случае по вертикали). Типичный IF (возьмем паскаль) выглядит у меня так:
if ...
then ....
else;
итого - три строчк. другия предпочитаю "классический" стиль
if ... then
begin
....
end
else
begin
...
end
итого - восемь строк текста.

Какой стиль лучше спорить можно до хрипоты, но. Единственный раз когда я наблюдал действительно крупный скандал по поводу кода - это когда один деятель переформатировал пару сотен килобайт чужого кода. Изменив т.о. 80% строк и сохранил результат в SVN.

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

[vit-r.livejournal.com]

Мне кажется все же что и общие подходы меняются.

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

Полагаешь есть шанс заставить?

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

Нет нужды доказывать, проще назвать субъективным :)

Когда-то время программистов было ценно и проводились реальные эксперименты с реальными высокооплачиваемыми спецами. Сейчас (по причине указанной выше) обходятся частным мнением или статистикой на пяти студентах.

В приведенном тобой примере: я предпочитаю использовать подход номер два. Но если надо вывалится из вложенных циклов (типично при линейном поиске, например), то по всем параметрам удобнее окажется вариант номер раз.

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

Все же считаю что хороший (читай талантливый) программист в каждом конкретном случае найдет наиболее элегантное решение.

Ещё ни одного программиста не видел, кто б считал себя тупым и бесталанным. В результате такого бреда наизобретают...

[gorba.livejournal.com]

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

[vit-r.livejournal.com]

Спасибо. Подумываю о том, чтоб переквалифицироваться в управдомы.

[gorba.livejournal.com]

Я в какой-то момент был готов пойти в монастырь нахер

[juan-gandhi.livejournal.com]

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

[vit-r.livejournal.com]

Нет тут вопроса. Так, воспоминания о том, как люди меняют тип возращающемого значения, подавляя вопли компилятора, а потом всё чудесным образом вылетает.

А дырочками на перфолентах тут много кто любовался.

[vit-r.livejournal.com]

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

[bon-voyage.livejournal.com]

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

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

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

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

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

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

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

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

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

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

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

[vit-r.livejournal.com]

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

Есть такая штука - называется документация.

На самом деле в критичных приложениях пишут аналог exceptions, который просто при ошибке кладёт всю систему.

Обработка ошибок вполне может развиваться параллельно с проектом. В частности по этой причине происходит бардак со сменой возвращаемых значений.

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

репутация Тойоты пострадала мало.

Результаты опросов показывают обратное.

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

[sergeeva777.livejournal.com]

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

[vit-r.livejournal.com]

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