vit_r

Случайно на мангафоксе наткнулся на четвёртую главу Shin Sekai yori и проникся огромным уважением к сценаристам аниме-сериала этой франшизы. Им почти удалось сделать из этого низкопробного порноромана более-менее вменяемую детскую фантастику. Теперь понятно, почему в действии такие нестыковки и чего там было на месте швов.

Ещё от нечего делать почитал газету. Еле подавил желание поставить в журнал пост, начинающийся словами «Всё плохо. А именно...» Особенно жалостливые статьи были про турков, у которых рождаемость падает, а курды понаехали в Анкару и плодятся, и про тётю с двумя образованиями, которая получила отлуп от платной биржи знакомств «Элите-Партнер» с формулировкой, что она слишком крутая, чтобы какой-то представитель противоположного пола обратил на неё внимание. Но, нафиг политику. Лучше вернёмся к нашим баранам.

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

Про технодрочеров

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

Определить технодрочеров просто. Даю три безошибочных признака.

1. В их коде нет комментариев. А те, что есть, лучше бы их не было.
   
   Тексты программ пишут для людей. И как хорошая книга, проверить можно, прочитав вслух. Да, прямо код. Со всеми комментариями, операторами и переменными.
   
   Пару раз я встречал образцы, где код можно было не просто прочитать, но и понять на слух. Комментарии были к месту и на самом деле поясняли то, чего не было в коде, а код говорил сам за себя.
   
   Большая часть хорошего промышленного кода до таких высот не дотягивает, но хотя бы в сложных местах люди пытаются выразить свою мысль и немного думают о тех, кто это может прочитать.
   
   Следует отметить, что с запахами и рефакторингом это ничего общего не имеет. Текст или будет звучать, или нет. Да, и комментарии адепты рефакторинга не учитывают. Потому как технодрочеры.
   
   Ещё технодрочеры любят делать выступления на своих конференциях, постить в блоги и писать книги. Там они рассказывают, как они круты. В своих собственных глазах, естественно, а не по абсолютной шкале. Как и комментарии, это всё не предназначено для употребления другими лицами. Не умея выражать свои мысли человеческим языком, они запихивают в свои произведения дикие количества кода, диаграмм и прочего мусора. Результаты по большей части ужасны и опасны для употребления, а заголовки выступлений на конференциях при честном переводе на человеческий должны бы выглядеть как-нибудь вот так: «Гениальный опыт создания велосипеда с квадратными колёсами, и как он будет крут, когда начнёт ездить.»
   
   (На днях выяснил, что на двойной скорость воспроизведения делает употребимыми почти все записи выступлений. Сейчас ищу программу, которая плавно позволит регулировать скорость для mp4. При возбуждённом обсуждении животрепещущих проблем оптимальная кратность где-то 1.6 - 1.8.)
   
   У меня, кстати, код не читаемый, а графичный. В большинстве случаев мне пофиг, если кто-то будет иметь сложности с пониманием. А вот я, зато, должен с первого взгляда определять что, как, почему и куда дальше, даже открыв код мелкого проекта пятилетней давности. И очень часто, когда лезу чего-то доделывать, нахожу в нужном месте комментарийй «Если нужно то-то и то-то, добавить здесь, а это сделать так.»
   
   В коде технодрочеров единственные полезные заметки по этому поводу выглядят как «!!!» или «Fuck!» (в зависимости от того, практикуют ли в конторе ревью кода или нет.)
   
   
2. Они ужасно озабочены буквой «O».
   
   Практика показывает что разница между алгоритмами O(N), O(N²) и O(log N) только в том, как быстро программа выдаст ошибку.
   
   Да, есть задачи, где это важно. Но в большинстве случаев двадцать миллисекунд равны двумстам миллисекундам, если на экран результат выводится полторы секунды без всяких «милли». Ещё простые алгоритмы проще отлаживать. И ошибок в них меньше.
   
   Опять же практика показывает, что увеличить эффективность в сто и тысячу раз можно, уточнив постановку задачи, упростив структуры данных, добавив обработку ошибок или ограничив обработку теми случаями, которые встречаются в реале, а не всеми теоретически возможными, если вдруг из паровоза начнут делать подводную лодку. Здесь, естественно, имеется ввиду общая эффективность от нажатия пользователем на кнопку, до получения им правильного результата. Но технодрочерам плевать на такие тонкости. Их путь освещает буква «O».
   
   Да, простой алгоритм может быть быстрым. Но вот оптимизировать простой алгоритм в сложный имеет смысл, только когда все другие резервы исчерпаны. И когда это всё на круг с получением не просто работающей, а работающей без ошибок версии стоит приемлемые деньги в человекочасах. И даже при этих условиях выигрыш должен иметь ненулевую экономическую ценность. Если программа запускается раз в квартал, то абсолютно пофиг, работает она десять минут или два часа.
   
   Клиентам, конечно, пофиг, но не технодрочерам. Начав улучшать, они положат на алтарь буквы «O» уйму времени и на продолжительный период переведут систему в неработоспособное состояние типа «почти готово». Кстати, опять можно вспомнить рефакторинг.
   
   Особо мило бывает, когда технодрочеры рассказывают, как замечательно, быстро и красиво код бы работал, если бы они его дописали. Или если бы во входных данных не было бы исключений, которые они, увлёкшись круглой буквой, не учли. Что, собственно, тоже квалифицирует код как не готовый к релизу.
   
   
3. Клиенты и пользователи им должны.
   
   Технодрочеры считают себя высшими существами. Ниже по лестнице эволюции стоят созданные ими программы. Глубоко внизу, задрав голову вверх и завороженно смотря на сияющие небеса компьютеризации стоят пользователи, с трепетом и благоговением принимающие дары небожителей, и клиенты, с радостью и задором расстающиеся с деньгами.
   
   Одно из самых ярких проявлений такой картины мира является слово «должны» по отношению к людям.
   
   Клиенты должны поставить задачу. Должны поставить её правильно. И должны отвечать за все ошибки в постановке. И, конечно, должны платить деньги и не должны выпендриваться и говорить, что им нужно было совсем другое.
   
   Пользователи должны выполнять указания. И должны догадываться о тех действиях, которые не описаны в документации, потому что об этом может догадаться всякий дурак. Они должны использовать программу, и не отлынивать, говоря что в Экселе сделали бы всё за пять минут. Они должны понимать, что это именно их действия приводят к ошибке, должны знать, что они делают не правильно, и не должны звонить в службу поддержки, увидев на экране сообщение «Нуль Пойнтер Эксепшен». Пусть сами откроют лог и убедятся, что ввели не те данные, или не так нажали на кнопочку. Ведь именно для этого благосклонные технодрочеры выводят им все сообщения стека.
   
   И конечно же и те и другие должны понимать птичий язык технодрочеров.
   
   Если на встрече с клиентами сидит инженер, он не будет сыпать терминами, а просто и чётко объяснит возможные варианты решения, их плюсы, минусы и возможную стоимость. Если за столом сидит дизайнер, он по ходу разговора делает в своём альбоме пометки и на вопрос о том, что он думает, сразу выдаст две-три возможных концепции, пусть и не окончательных, но просто и ясно показывающих направление движения. Если финансовый аналитик объясняет алгоритм и область его применения, поймут даже ученики старшей школы. Хотя, в специальной книжке для финансовых аналитиков они вряд ли продвинутся дальше десятой страницы.
   
   Технодрочеры играют роль глухонемого гения. По возможности они утыкаются в принесённые для экономии времени ноутуки. Если ситуация не позволяет, они просто думают, изредка скользя по лицам присутствующих отсутствующе-презрительным взглядом. За разговором они не следят. Во-первых, решение им известно уже до того, как они переступают порог комнаты. Во-вторых, всё равно ничего умного люди, не написавшие строчки кода на Яве, сказать не смогут. Когда их спрашивают о возможностях и перспективах, они на птичьем языке классов и протоколов пытаются объяснить, что это невозможно. Их объяснения того, что возможно, не предназначены для понимания кого-то кроме таких же технодрочеров, и чаще всего слабо относятся к делу. В результате клиенты просто решают посмотреть, что сделает мастер, а потом сравнить с тем, что им было надо.
   
   Часто работая между заказчиками и технодрочерами вижу, какое удивление появляется в глазах клиента, когда будущий софт предстаёт в знакомых терминах и вполне понятых картинках вместо птичьего языка, приправленного винегретоподобными диаграммами. Это существенно упрощает работу и ускоряет получение результата. Хотя, при денежном клиенте эта тактика не самая выгодная и надёжная.

Конечно, перечисленными тремя качествами сущность технодрочеров не ограничивается. Но я заканчиваю на этом, потому что мне просто надоело про них писать.

Copyright

(CC BY-NC-ND 3.0) vit_r, 2012

This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License.
Перевод на английский запрещён, потому как нефиг портить хорошую вещь.