Куда деваются программисты после 40



    — Вам уже 45? Но у нас коллектив очень молодой. Вы уверены, что хотели бы у нас работать?
    — Да, конечно! Я много наслышан о вашей компании. Это мечта всей моей жизни!
    — Ну ладно. Вот вам простой вопросик. Что означает буква L в аббревиатуре SOLID?
    — Liskov Substitution Principle.
    — Нет. У меня написано, что это Liskov Substitutability Principle.
    — Но…!
    — Никаких «но»! Неверно ответили, ведь видно же, что не готовились к собеседованию, так и скажите, да еще и спорите! Вы вообще конфликтный человек? Ладно, даю вам еще один шанс. Как развернуть односвязный список?
    — Развернуть односвязный список за один проход? Да, пожалуйста. Проходимся по каждой ноде, запоминаем её next, вставляем ей в next указатель на предыдущую, потом идем по запомненному next-у и так далее. Да, в первую ноду в next вставляем, конечно же, nullptr. Нечетко объясняю? Ну давайте я лучше напишу.
    — Хм… Хорошо, достаточно. А рекурсивно можете?
    — Да, рекурсивно тоже могу.
    — А сколько в Москве бензозаправок?
    — O-)????!!! 1127!
    — Откуда вы знаете???
    — А у меня папа работал в Лукойле.
    — Ладно… А знаете наихудший случай quicksort? Есть такой наихудший случай. У меня тут на листочке записано…
    — Да, знаю.
    — Но молодые специалисты это тоже знают. Почему мы должны платить вам на 15% больше?
    — Но у меня семья, дети, ипотека… Да я и английский знаю.
    — Все его знают. Этим сейчас уже никого не удивишь.
    — Но я его очень хорошо знаю и говорить могу тоже хорошо. If you would like to ask me some questions in English, you are welcome.
    — Huh!.. Это для нас не принципиально. Зачем программисту говорить на английском?
    — Но я еще и французский знаю. Si vous voulez parler francais…
    — Хватит!!! Кому в баню в программировании сдался ваш французский???
    — Что же мне тогда делать?
    — Застрелитесь! То есть… что там у меня написано?.. мы вам перезвоним. Если у нас возникнет такая потребность.

    почти выдуманный диалог на собеседовании

    У меня растут года. Будет мне 120.
    Где работать мне тогда? Чем заниматься?

    актуально в свете повышения пенсионного возраста

    Когда я начинал свою трудовую деятельность в далеком 1996 году, то и представить себе не мог, как будет развиваться моя профессиональная карьера на десятилетия вперед и чем я буду заниматься, скажем, в 2017. Уверен был, что это будет связано с компьютерами, а чем конкретно – понятия не имел. Даже не был уверен, кем стану: программистом или сисадмином.

    Вокруг меня все время были молодые специалисты, причем чем старше я, тем моложе они… 2000-й год… молодые специалисты…. 2010-й год… молодые специалисты…. 2017-й год – другие молодые специалисты. Удивительно, но работаешь 20 лет – и вокруг тебя одни молодые специалисты … и специалистки. Да, в последнее время стало много девушек-программисток. Раньше, лет 15 назад, в процентном отношении среди моих коллег их было от 0 до 5%, а теперь все 20%.

    Причем чем больше я работал, тем больше вокруг было молодых специалистов. Как ни удивительно, меньше всего их было на самой первой моей работе, когда сам я был зеленым молодым специалистом, которого никто никуда не хотел брать, только … в компанию к «немолодым специалистам». Я рос, креп, переходил в другие компании, но никак не мог объяснить этот странный феномен. Откуда же берутся все новые и новые молодые специалисты и куда деваются старые? Они же вроде бы должны взрослеть и переставать быть «молодыми»? Но они постоянно присутствуют и появляются все в большем количестве!

    Пришло время, я переходил «от подмастерья к мастеру» и наконец на собственной шкуре узнал, куда деваются программисты после 40! Они … стреляются! Шутка! На самом деле все мои бывшие коллеги, которые были когда-то «молодыми специалистами», осели либо за рубежом, либо растворились в граале отечественных IT-технологий Яндексе (не хочу обижать альтернативные граали – Касперского, Abbyy, Parallels, а также сотни менее крупных по масштабам, но, возможно, более прекрасных по духу граальчиков). Никого не осталось! Вот куда поступает «осадок» молодых специалистов. Почему же никто из них не стал «биг-боссом», менеджером высшего звена или иным руководителем? Ну это ж программисты, они код писать любят и своей профессии не предадут. Так что под конец карьеры такие вот «пожилые» специалисты концентрируются в лучших компаниях (а где еще можно работать?).

    Поймал себя на мысли, что 20-й год тем только и занимаюсь, что перекладываю данные из одного места в другое… Почти как сортировщик апельсинов из известного анекдота. Ну просто никаких алгоритмов, обычное перекладывание туда-сюда, туда-сюда. И так 15 лет. Ну максимум, был у нас merge sort больших файлов лет 10 назад. И всё. Засортировали и будя.

    Вообще, профессия у нас рабочая. Руками мы любим трудиться. Ну мозгом, конечно, тоже надо, не без этого. Не зря же Андрей Аксенов (автор поисковой системы Sphinx) сравнивал программистов, точнее, низкоуровневых программистов-оптимизаторов, с «сантехниками, которые ковыряются в потрохах, рыцарями г… и пара» (доклад на HighLoad 2010 по низкоуровневой оптимизации С/C++).

    Дедушка мой, кстати, был сапожником. И не обычным сапожником, а модельным. Он работал в театре и обувал актеров для спектаклей. Он не был менеджером. Зачем сапожникам менеджеры по сапогам? Так вот и я считаю, что менеджер – это совершенно другая профессия. Сапожник сапоги шьет, как и программист, производит реальный продукт, а менеджер управляет процессом производства сапог. Но в театре нет массового производства сапог, равно как и в небольшом стартапе нет массового производства софта.

    Не все программисты идут в управленцы, так же как не все управленцы – хорошие программисты. Но для управленца, как ни странно, это не самое главное. Главное — иметь под рукой грамотного профессионала, с которым всегда можно посоветоваться.

    Когда лет десять назад подвернулась возможность «продвинуться» в менеджеры, я усомнился в целесообразности этого. Потому что это означало бы деквалификацию. Ведь для любого мастера очень важно ежедневно оттачивать свою технику. Вот для скрипача главное — ежедневная практика. Для спортсмена что главное? Ежедневные тренировки. Если бы я стал полноценным менеджером, то потерял бы возможность главного и самого приятного – программировать. Мне пришлось бы заниматься оргвопросами, принимать участие в совещаниях, ругать и хвалить пресловутых «молодых специалистов», и вообще руко-водить, то есть водить за руку эту зелёную молодежь, вчерашних студентов. Нет! Без меня обойдутся. Займусь-ка лучше тем, где я лучше всего самореализовываюсь.

    Относительно себя с возрастом в профессии ты хуже не становишься. Но есть ли возможность беспредельно развиваться в рамках профессии программиста, не меняя её? Конечно, ты не угонишься за всеми трендами и технологиями в Computer Science.

    Если в 80-е и 90-е годы IT-специалист в принципе мог владеть исчерпывающим объемом знаний, касавшихся Computer Science, то теперь единственный путь IT-специалиста, как мне кажется – в специализацию. Число областей Computer Science растет в геометрической прогрессии, а время на их изучение ограничено, поэтому специализируйтесь и выбирайте вашу специализацию тщательнее!

    Мне как-то пришло сообщение в linkedin от одной рекрутерши или … рекрутрисы (много их теперь стало, а раньше не было совсем. Сам, всё сам… даже через FIDO приходилось искать работу). Она писала:

    «Добрый день:) Для восстановления справедливости во Вселенной Орден Джедаев набирает в свои ряды Великих Воинов джедая С++. Действия происходят на хорошо защищенной и комфортной Планете Yandex в центре Московской Галактики!
    …(описание вакансии опущено)…
    Итак, если Вы — Великий Воин или готовы им стать, жду Тайного манускрипта (резюме). В нашей галактике Вам не страшна звезда уныния и тоски !!»


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

    Я тут же ответил в духе воина-джедая, не подавая виду, что и сам не догадался бы про «манускрипт» без подсказки:

    «Здравствуйте. Большое спасибо за проникнутое юмором послание. Я улыбнулся. Джедаем, Великим Воином, гуру и сенсеем я, безусловно, собираюсь стать. Еще большее спасибо за рекомендацию конкретной вакансии Яндекса. Мне нравится афоризм, в котором говорится, что все программисты делятся на тех, кто уже работает в Яндексе и тех, кто мечтает об этом. Я из последней категории, но мои многие бывшие коллеги уже «там»: они вкусили прелесть работы в лучшей технологической компании страны. Мне же, чтобы дорасти до минимального «проходного» уровня Яндекса (я трезво оцениваю свои знания) необходимо 2-3 года интенсивной подготовки. Необходимо вспомнить институтский курс тервера, порешать задачки на логику и сообразительность, детально изучить то, что «под капотом» у современных библиотек, изучить последние «писки» моды в стандартах С++, алгоритмы на графах и многое, многое другое (список литературы и лекций включает примерно 50 наименований). А ходить «на шару» на интервью в _такую_ компанию (авось пройду) мне совесть не позволит. Отнимать время у Яндексоидов понапрасну не могу. Последний раз был на интервью в «Яндексе» в 2007 году примерно. Получил большое удовольствие (бесплатно обучили :) С тех пор, конечно, уровень свой поднял, но мне еще далеко до необходимого минимума знаний. По рассказам «знающих людей» интервью продолжается более 14 часов. Кандидату дают задачи из разных областей, его собеседуют интервьюеры различных направлений, чтобы составить взвешенное мнение о кандидате. Раньше было проще: не так интенсивно. У меня есть знакомые, которые смотрят на интервью как на своеобразное хобби, позволяющее улучшить свой уровень, пообщаться с коллегами по цеху, приятно провести время наконец. Я отношусь к этому серьезнее, поэтому и подготовкой занимаюсь соответственно. Не буду надолго задерживать ваше внимание. На этом попрощаюсь, но предлагаю поддерживать контакт».

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

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

    Меня потряс как-то «список знаний и умений любого уважающего себя» программиста из miram.livejournal.com/630972.html и sharpc.livejournal.com/67583.html. Не поленюсь привести полную цитату:

    Все, что должен знать программист, чтобы его после 40 лет не выбросили на Помойку, Где Бомжи.
    … В возрасте около 45 лет начинает активно проявляться деградация мозга, приводящая к существенным проблемам в понимании и способности оперировать кодом с обычной цикломатической сложностью. Потеря способности писать код в сочетании с неспособностью из-за отсутствия тренировок к анализу/синтезу — гарантированный путь именно туда. Некоторые люди сохраняют способность оперировать нормальной цикломатической сложностью и в старости, однако лишь за счет превышающих норму показателей в молодости. Проверить, входите ли вы в зону риска, можно на TopCoder.

    Добавление от себя. TopCoder – это реально хорошее место, чтобы держать себя в тонусе. Решаем задачки оттуда и поддерживаем тонус (или даже участвуем в challenges, конкурируем с другими и зарабатываем деньги). Итак, что же нужно знать, чтобы тебя не выбросили на помойку?

    • C++, стандарт, Comeau, 1TBS, Страустрап/D&E/Джосаттис/Вандервуд, Дьюхэрст/Мейерс/Саттер, RAII/copy-and-swap/exception-safety, правило пяти, Александреску/Абрахамс-Гуртовой, type erasure, CRTP, NVI, SFINAE, Koenig lookup, Duff's device, Boost, Сик-Ламсдейн/Карлссон, TR on C++ performance, тест Степанова, forwarding problem/move semantics, SPECS, GotW, Meyer's singleton, cppgm
    • Компиляторы С++, особенности реализации стандарта, ограничения реализации, интринсики, отличия стандартных библиотек (контейнеры, rand), ABI, реализация виртуальных функций, виртуального наследования, исключений, RTTI, switch, указателей на функции и методы; оптимизации, copy elision (RVO, NRVO), sizeof на различных платформах, дефайны компилятора и среды, __declspec, ключи компилятора, empty-base optimization, статическая и динамическая линковка, манглинг, распределенная компиляция, precompiled header, single compilation unit, (strict) aliasing/restrict, inline/_forceinline, volatile, быстрое вычисление математических функций через битхаки, linkers & loaders by Levine
    • Мультитредность, обедающие философы, deadlock/livelock/race condition/starvation, атомарность, lock инструкции процессора, memory model/barrier/ordering, CAS или LL/SC, wait/lock/obstruction-free, ABA problem, написание lock-free контейнеров, spin-lock, TLS/per-thread data, закон Амдала, OpenMP, MPI, map-reduce, critical section/mutex/semaphore/condition variable, WaitForSingleObject/WaitForMultipleObjects, green thread/coroutine, pthreads, future/deferred/promise, модель акторов, parameter server, RDD (as seen in sparks), downpour SGD, wait-free, stackful vs stackless
    • Язык ассемблера, Зубков/Хайд/Дреппер/Касперски/Фог/Абраш, x86, FPU/MMX/SSEn/AVX, AT&T и Intel-синтаксис, masm32, макросы, стек, куча/менеджеры кучи, соглашения вызова, hex-коды, машинное представление данных, IEEE754, little/big endian, SIMD, аппаратные исключения, прерывания, виртуальная память, реверсинг, срыв стека и кучи, return oriented programming, alphanumeric shellcode, L1/L2/RAM/page fault и их тайминг, язык ассемблера ARM
    • Аппаратное обеспечение, Хоровиц-Хилл/Титце-Шенк/От физики к Си от panchul, полупроводниковая электроника/спинтроника/фотоника, транзистор, триггер, схемотехника, микрокод, технология создания процессоров, logic synthesis, static timing analysis, FPGA, Verilog/VHDL/SystemC, SISAL, Arduino, устройства памяти (ROM → EEPROM, RAM, SSD, HDD, DVD), RISC/CISC, Flynn's taxonomy ([SM]I[SM]D), принстонский и гарвардский подход, архитектуры процессоров, архитектуры x86, VID/PID
    • Процессоры, конвейеризация, hyper-threading, алгоритм томасуло, спекулятивное исполнение, static/dynamic branch prediction, префетчинг, множественный ассоциативный кэш, кэш-линия/кэш-промах, такты, кольца защиты, память в мультипроцессорных системах (SMP/NUMA), тайминг памяти, intel optimization manuals, performance counters
    • Дискретная математика, K2, теорема Поста, схемы, конечные автоматы (ДКА и НДКА), автомат Калашникова, клеточные автоматы
    • Вычислимость, машина Тьюринга, нормальные алгоритмы Маркова, машина Поста, диофантовы уравнения Матиясевича, лямбда-функции Черча, частично рекурсивные функции Клини, комбинаторное программирование Шейнфинкеля, Brainfuck, эквивалентность тьюринговых трясин, проблема останова и самоприменимости, счетность множества вычислимых функций, RAM-машина, алгоритм Тарского, SAT/SMT-солверы, теория формальных систем, interactive proofs, теорема Левина-Кука, 3SAT, PSPACE = NPSPACE, #P
    • Языки программирования, грамматики, иерархия Хомского, теорема Майхилла-Нероуда, лемма о накачке и лемма Огдена, алгебра Клини, НДКА → ДКА, алгоритмически неразрешимые задачи в формальных языках, Драгонбук, Фридл, регекспы и их сложность, PCRE, БНФ, Boost.Spirit + Karma + Qi/Ragel, LL, LR/SLR/LALR/GLR, PEG/packrat, yacc/bison/flex/antlr, статический анализ кода, компиляция/декомпиляция/обфускация/деобфускация, Clang/LLVM/XMLVM/Emscripten, GCCXML, OpenC++, построение виртуальных машин, JiT/AoT/GC, DSL/DSEL, on-stack replacement, type checking/type inference алгоритмы, CYK parser, advanced compiler design and implementation by Muchnick
    • Алгоритмы и комбинаторная оптимизация, Кормен/Скиена/Седжвик/Кнут/Ахо-Хопкрофт-Ульман/Пападимитриу/Шрайвер-Голдберг/Препарата-Шеймос/e-maxx.ru, структуры данных, алгоритмы, сложность, символика Ландау, теорема Акра-Баззи, time-space tradeoff, классы сложности, NP-полные задачи, КМП, графы и деревья, потоки в сетях, матрица Кирхгофа, деревья поиска (особенно RB-дерево и B-дерево), occlusion detection, куча, хэш-таблицы и идеальный хэш, сети Петри, алгоритм русского крестьянина, метод Карацубы и матричное умножение Винограда-Штрассена, сортировки, жадные алгоритмы и матроиды, динамическое программирование, линейное программирование, diff-алгоритмы, рандомизированные алгоритмы и алгоритмы нечеткого поиска, псевдослучайные числа, нечеткая логика, gusfield (suffix tree, string alignment), motif search, scanning line, cache oblivious, funnel sorting, VEB-layout, корневая оптимизация, алгоритмы для динамических графов,
    модели вычисления (RAM-machine/pointer machine/decision trees и т.д.), алгоритмы в иерархиях памяти/стриминговые алгоритмы, time forward processing, range & rank, LSM-trees, buffered a-b-trees, toku trees, персистентные структуры, succint-структуры, lossy-струтуры (bloom/bloomier filter, hash-tables with false positives), locality sensitive hashing, space-time tradeoff в хэш-таблицах, scheduling strategies
    • Численные методы, дихотомия/метод Ньютона, интер- и экстраполяция, сплайны, метод Гаусса/Якоби/Зейделя, QR и LU-декомпозиция, SVD, МНК, методы Рунге-Кутты, метод Адамса, формулы Ньютона-Котеса, метод Ритца, метод Бубнова-Галеркина, метод конечных разностей/элементов, FFT/STFT, сходимость и устойчивость, l-bfgs и другие квазиньютоновские методы, adagrad, PARAFAC, cassowary, interior point methods, вариационные методы для байесовского вывода, nesterov, автоматическое дифференцирование, alternating least squares, what every computer scientist should know about floating point arithmetics by Goldberg, Nocedal & Wright/Boyd & Vandenberghe
    • Машинное обучение, Тибширани/Bishop, подходы к моделированию AI, переобучение/кроссвалидация, байесовские сети, нейросети, сети Кохонена, Restricted Boltzmann machine, градиентный спуск/hill climbing, стохастическая оптимизация (метод Монте-Карло, метод отжига, генетические алгоритмы, муравьиные алгоритмы), SVM, gradient boosting, кластерный анализ, метод главных компонент, LSH, обучение с подкреплением, MDP, information retrieval/data mining/natural language processing, машинное зрение, Szeliski, OpenCV, image processing, OCR, фильтры Собеля, каскад Хаара, Viola-Jones framework, SURF, введение в психофизиологию зрения, IPython/pandas/scikit-learn, (ME)HMM, CRF, label bias problem, stacked NN, LeToR, factorization machines, autoencoders, RNN/CNN, вместо NLP лучше отдельные задачи (language modelling, co-reference detection, text chunking, POS-tagging, probabilistic parsing, statistical machine translation, misspell correction, question answering, NER, collocation detection, text summarization, speech recognition, fact extraction, sentiment analysis), эффективное вычисление softmax, feature engineering/selection, quality estimation, Manning/Jurafsky/McCallum/Koehn, latent topics (LDA, chineese restaurant, pLSI), parallel coordinates, vowpal wabbit, NLTK, structured learning, EM-алгоритм, contrastive divergence, optimal brain surgery, belief propagation, semi-supervised learning, inductive vs transductive learning, kernel trick, discriminative/generative pairs (as seen by Ng & Jordan), sequence to sequence learning, bagging, анализ социальных графов, рекомендательные системы/collaborative filtering, multimodal learning
    • Теория информации, сжатие, Хаффман, RLE, BWT, LZ, коды коррекции ошибок, сжатие с потерями (изображения, аудио, видео), информационная энтропия, формула Шеннона, сложность Колмогорова, maximum entropy problem, kullback-leibler divergence, elias/shannon-elias encoding
    • Криптография, Шнайер/Ященко, Принцип Керкгоффса, симметричная (DES, AES), асимметричная (RSA), качество ГПСЧ, алгоритм Диффи-Хеллмана, эллиптические кривые, хэширование (MD5, SHA, CRCn), DHT, криптостойкость, криптоатаки (атака гроссмейстера), WEP/WPA/WPA2 и атаки на них, цифровая подпись и сертификаты, PKI, HTTPS/SSL, доказательство с нулевым разглашением, пороговая схема, murmurhash/cityhash, DKIM
    • Математика, Кнут-Грэхем-Паташник/Зорич/Винберг, Spivak/Dummit-Foote, матан, линал, комплан, функан, диффгем, теория чисел, дифуры/интуры/урчпы/вариационное исчисление/оптимальное управление, производящие функции, ряды, комбинаторика, теорвер/матстат/слупы/теория массового обслуживания, цепи Маркова, интегральные преобразования (Фурье, Лаплас, вейвлет), NZQRCHOS, матпакеты (Mathematica, Maple), теория категорий
    • Физика, правила Кирхгофа, закон Джоуля-Ленца, комплексное сопротивление, скорость и частота света, уравнения Максвелла, лагранжиан и гамильтониан,
    quantum tunnelling/hot electron injection :)
    • Химия, стехиометрия, химия кремния :)
    • Архитектура и стиль кода, Макконнелл/Фаулер/Лебланк/Гамма/Александреску-Саттер/Буч, защитное программирование, паттерны, SOLID/GRASP/KISS DRY SPOT/YAGNI, UML, OOP (Smalltalk), OOD/OOA, метрики кода, uncle Bob
    • Методологии разработки, Waterfall/RUP/Agile/Scrum/Kanban/XP, TDD/BDD, CASE
    • Тестирование, юнит-тесты, функциональное, нагрузочное, интеграционное тестирование, тестирование UI, mocks/stubs/spies, fixture, запахи и паттерны тестов (Osherove/Meszaros)
    • Инструментальные средства разработки, IDE, IntelliSense, отладчики (VS/Olly/WinDbg/kdb/gdb) и трейсеры (strace/ltrace), DWARF debug information format, дизассемблеры и декомпиляторы (IDA/HexRays/Reflector), системы контроля версий (SVN, GIT), merge/branch/trunk, системы именования файлов и бранчей, continuous integration, ant, code coverage, статический анализ (lint, cppcheck), динамический анализ (valgrind, фаззинг), верификация и валидация ПО (Frama-C, RAISE (RSL), Coq), профайлинг, багтрекеры, документирование кода, системы сборки (CMake), пакетные менеджеры (NuGet)
    • Фреймворки, Qt, moc и метаинформация, концепция слот-сигнал, Саммерфилд-Бланшет/Шлее, PoCo, промышленные библиотеки: GMP, i18n, lapack, fftw, pcre
    • Операционные системы, Silberschatz/Рихтер/Соломон-Руссинович/Робачевский/Вахалия/Стивенс/Таненбаум/Love/Linux Kernel Internals, менеджер памяти, менеджер кучи и ее устройство (LAL/LFH/slab), менеджер устройств, менеджер процессов, context switch, реальный и защищенный режим, исполнимые файлы (PE/ELF/Mach), объекты ядра, отладочные механизмы (strace/ptrace/dtrace/pydbg, Debug API) и минидампы, bash, сетевой стек и высокопроизводительные сервера, netgraph, CR0, IPC, оконная подсистема, система безопасности: ACE/ACL и права доступа, технологии виртуализации, RTOS (QNX), программирование драйверов, IRQL, IRP, файловые системы, BigTable, NDIS/miniport/FS drivers/filter driver, Mm-, Io-, Ldr-функции, DKOM и руткиты, GDT/IDT/SDT, ядра Windows/Linux/BSD, POSIX, TRIM
    • Компонентно-ориентированные модели, Роджерсон/Таварес, COM/OLE/ActiveX/COM+/DCOM RPC, ATL, апартменты, моникеры, MIDL, XPCOM, CORBA, TAO, D-Bus
    • Сеть, Стивенс, OSI model/Internet model, Ethernet, TCP/IP, TCP window, алгоритм Нейгла, сокеты, Protocol buffers/Thrift/Avro/ASN.1, AMQP, ICMP, роутинг/BGP/OSPF, ARP, атака Митника, syn flood, HTTP/FTP, P2P/DHT, DHCP, SMB/NBNS, IRC/XMPP, POP3/SMTP/ESMTP/IMAP, DNS, WiFi/WiMax/GSM/CDMA/EDGE/Bluetooth/GPS, ACE, Wireshark
    • Графика и GPGPU, алгоритм Брезенхема, цветовые модели, трассировка лучей vs полигональная графика, OpenGL/GLSL/Open Inventor, DirectX/DirectShow/DirectAudio/HLSL, stencil/depth/alpha-test, графический конвейер в DirectX 11, шейдеры, модели освещения (Фонг), пропускная способность, fillrate, OpenCL/CUDA/AMP, ландшафты, лоды, тени, deferred shading, текстурирование и фильтрация, антиалиасинг, HDR, tone mapping, virtual/augmented reality
    • Форматы, XML/XSLT/XPath/XMLStarlet/DOM/SAX, RTF/ODF, JSON/BSON/bencode, YAML, JPEG/PNG/WebP, AVI/MPEG/RIFF/WAV/MP3/OGG/WebM, SVG, Unicode, кодировки однобайтные/UTF-8/UTF-16/UCS-2/UTF-32, проблемы длины и сравнения Unicode-строк, base64, markdown
    • Базы данных/Распределенные системы, Грубер/Дейт, ANSI SQL, T-SQL, ODBC, MySQL/PostgreSQL/MS SQL/BDB/SQLite/Sphinx, хранимые процедуры, триггеры, алгебра Кодда/А, Tutorial D, нормальные формы, оптимизация и выполнение запросов, структуры данных индексов, транзакции и ACID, CAP-теорема Брюера, graph DB, document store, wide column store, key-value storage, теория распределенных систем, CRDT, net split проблема, протоколы консенсуса, теория шардинга/репликации, ORM (C++ ODB), ERD, OLAP, семантическая сеть, triplestore, RDF/Turtle, SPARQL, OWL, Semanticscience Integrated Ontology, reasoner, DBpedia, big table/hbase vs. dynamodb/cassandra/riak, 2/3PC, chubby/zoo keeper, leader election (paxos/raft), hdfs/gfs/glusterfs, deduplication problem, causality detection (vector clock/stamps), R/W quorum, load balancing, устройство индексов поисковых систем, event sourcing, CRDT, дизайн протоколов и принципы коммуникации, с точки зрения эволюции, расширяемости, надежности, дизайн программных интерфейсов (API)
    • Прикладное программирование, C#/F#, Шилдт/Троелсен/Рихтер, генерики, yield, linq/plinq, рефлексия, AST, WCF, WinForms/WPF/Silverlight, AOP, фреймворки логгирования, .NET assembly, Scala, Хорстманн/Одерски, pattern matching, макросы/квазицитаты
    • Квантовые вычисления, алгоритм Шора, квантовая криптография
    • Функциональное программирование, Haskell/Ocaml/Scheme/Alice или Oz, SICP/TaPL/YAHT/Purely Functional Data Structures/Харрисон-Филд, HOF (map/fold/filter), система типов Хиндли-Милнера, монады, тайпклассы, АТД, dependent types, ленивость/энергичность, логическое программирование (Prolog или Mercury), конкурентное программирование (Erlang или Oz)
    • Веб-программирование и скриптовые языки, Фланаган/Zend PHP5 Certification Course + Study Guide, Apache/nginx, CGI/FastCGI, PHP/Zend Framework/ReactPHP/Zend Engine/Doctrine или Propel/CodeIgniter или Symphony или Yii, Python/Django/Twisted, Ruby/RoR, ASP.NET MV*, JavaScript/jQuery/React/Google Closure/ExtJS/node.js, ООП в JavaScript, HTML5, CSS3/табличная и блочная верстка, RSS, canvas/WebGL, Ajax/WebSockets, вопросы безопасности (XSS, SQL injection, CSRF), highload, C10k problem, SWIG, CDN, shadow DOM, квирки браузеров, real time bidding/trading, anomaly detection, архитектура single page apps, устройство веб-краулеров, web/social graph random walk, asm.js и компиляция в js, v8/spidermonkey internals, PaaS/IaaS, SPDY
    • Проектирование GUI и представление информации, Раскин/Тафти, юзабилити, основы дизайна и типографики, закон Фиттса, основы верстки, LaTeX, алгоритмы визуализации данных (as seen in d3), subpixel rendering

    Немного на 40 лет, правда? Или много, если надо еще и работать? Действительно, когда же это изучать, если надо работать? В свободное время? А я не знаю и половины из этого списка. И четверти не знаю. Метод Карацубы пока не освоил. Химию кремния, наверное, придется, как и уравнения Максвелла, отправить в долгий ящик. Есть более приоритетные темы.

    Но в свете будущего повышения пенсионного возраста мне ведь еще минимум лет 40 работать – как раз узнаю вторую половину в свободное от работы время. И что же, что будет, если я всё это узнаю? Что будет с тем гением, который знает всё по этому списку? Уверен, что его не только не выбросят на помойку, более того, его под конец жизни ожидает священная грааль – Яндекс (и зарплата молодого специалиста + 15%). Там он и найдет упокоение. Аминь.
    Поделиться публикацией
    Реклама помогает поддерживать и развивать наши сервисы

    Подробнее
    Реклама
    Комментарии 1042
    • +59
      Самая большая проблема программистов людей при возрастании пробега — прогрессирующее занудство, исчезающая самоирония и старческая слезливость. В качестве профилактики могу только предложить витамины, полистать луркмуар и послушать группу «Кровосток».

      Колян, 40 лет.
      • –11

        Ну не у всех. Я еще живчик, без всяких там. А ребята типо автора вызывают только жалость. Пить нужно меньше, спортом заниматься, и в 80 мозги будут в порядке.

        • +26
          У автора как раз, вроде, неплохая самоирония, а вот у вас с этим уже слабовато, прям как MzMz написал.
          • 0
            А с чего автора на самоиронию пробило? Скис потому что.
        • +4
          > луркмуар

          Луркмоар
          • +8
            прям как MzMz написал: «прогрессирующее занудство»
          • +4
            Обнаружил, что шутки с луркмоар молодые сотрудники не понимают
            • 0
              Ну так на то и они и молодые) У них шутки про «патимейкер-шейкер-шейкер». Нам с вами не понять.
            • 0

              Луркнуар :)

            • 0
              Зависит от того, доволен ли человек своими результатами в жизни да процессом жизни в целом. С возрастом все основные черты личности проступают и усиливаются. Если был молодым занудой вырастешь той еще брюзгой )
              • 0
                если вы 40+ (а я 50+) могу предложить гантели (они дома, и с пробуждения ставят вопрос ребром сразу — да или нет? ;)) + ежедневный душ самой холодной водой какая доступна…

                … и осознание — только скорость восприятия держит вас в реальности

                это только ваш личный выбор — да, я «википедия», пусть меня читают… или еще нет ;)))
              • +68
                Что-то зачастили с такими статьями на хабре, настолько, что мне аж в 30 уже страшно стало.
                • +13
                  Профессия программистов в массы не так уж давно пошла, особенно в россии.
                  Нытье 40 летнего программиста — 2017-40=1977 года рождения
                  + 18 лет = 1995 год начала работы по профессии — по сути первая массовая волна как раз тех, кто занимался этим «с рождения».
                  2017-1995 ~= 20 лет, аккурат тот срок когда можно начинать ныть о «старых добрых временах» (при дельте в 10-15 лет как-то это еще не так звучит).
                  Чем дальше — тем больше будет таких статей и тем больше будет упоминаемый возраст.
                  В 2037 вангуем статью «Куда деваются программисты после 60».
                  При чем занудство сие постигло не только программистов, достаточно посмотреть аналогичные посты в контактике типа «лайкни если ты помнишь» и дальше какая-нибудь жевачка, которую почти никто не жевал, но вкладыши от которой были местной валютой:)

                  А вообще программист как таковой это типичная профессия со стеклянным потолком. Проблема стеклянного потолка умноженная на устаревание технологий не только в том что рано или поздно некуда больше расти, а еще в и в том, что опыт больше 5 лет по сути не имеет значения в большинстве случаев, поэтому эффект «не успел разогнаться тебя уже догнали» очень силен. А смена профы на менеджера или управленца это именно смена профы.
                  • +6
                    Добавлю к последнему абзацу то, что некие «сакральные» знания, якобы доступные исключительно людям с 20-летним опытом часто не нужны по причине того, что для 95% IT-проектов в России реально достаточно just good enough качество (особенно это касается коротких проектов и мелких бюджетов). То есть нужно просто знать технологию X и молча без зауми херачить проект Y.

                    Смена профессии на менеджера тоже не серебрянная пуля — в связи с более низкой ликвидностью среднего сферического менеджера относительно разработчика такой же геометрии.
                    • +2
                      Зачастую нужны сакральные знания по какому-то продукту, но проблема в том, что этот продукт или уникален или используется в единицах компаний и, уходя из одной такой, нет смысла менять шило на мыло. Как итог — сакральные знания есть, но толку… и чем дольше в этом вариться, тем больше этих знаний и тем больше полезного места они занимают и бОльшим якорем становятся.
                      • +2
                        Есть люди, которым и надо сидеть 20 лет на месте Z, зная только технологию X и молча без зауми пилить проект Y. А кому не надо, идут в ту же сервисную аутсорсинговую компанию и пилят сухие микросервисы на солидной архитектуре через TDD. Мода что-то пошла всех под одну гребенку грести. Программист, пожалуй — одна из самых толерантных к возрасту профессий. Это у токаря-фрезеровщика если единственный в городе завод закрылся, то дороги две — в алкаши да в дворники. А здесь кофе налил, пошел на какой-нибудь Апворк и сиди себе никуда не спеша поддерживай легаси проекты хоть до 80-ти. С нынешним курсом пенсиям даже до индусских рейтов, как до Луны.
                        • +1
                          Достаточно условно толернатная так-то. Если слесарь в 40 будет цениться практически однозначно выше 20летнего, и только из-за возраста проблем у него не будет точно, то про компании, в которых программистов отсеивают из-за того что «слишком старый» я периодически слышу. Это, конечно, не значит что работы сразу нет, но ее однозначно меньше чем 5-10-15 лет раньше.
                          • +2
                            У компаний тоже есть некий психологический возраст. Молодые разработчики всегда находятся чуть ниже этого возраста, поэтому подходят для практически любой фирмы, но чем более компетентен (заметьте, не просто более опытен, а именно более компетентен) становится разработчик, тем больше компаний он «перерастает». От того и складывается впечатление, что рабочих мест становится меньше. В абсолютных значениях — да, но в остальном всё на своих местах. Как в крупную корпорацию не нужен мальчик на должность системного архитектора, так и начинающим сервисникам, клепающим одностраничные визитки на шаблонах с themeforest, не нужны дядьки, рассуждающие про метод подстановки Лисков.
                      • +2
                        + 18 лет = 1995 год начала работы по профессии — по сути первая массовая волна как раз тех, кто занимался этим «с рождения».

                        Гы. И кудаж мне теперь деваться? Я начал программировать в 1975, а деньги зарабатывать в 1978. В это время все студенты у нас к диплому изучали пару языков, если было на то желание, Алгол-60 давали на первом курсе, а Фортран приходилось учить самостоятельно, так как появилась потребность. И это не программисты, а инженеры-механики, между прочим.

                        Это я насчет «массы», если что.

                        А с остальным совершенно согласен — причем опыт больше 5 лет не просто не имеет значения — его еще и практически невозможно подтвердить, и если угодно, монетизировать — потому что управленцы, в большинстве своем, не в состоянии оценить этот самый уровень.
                        • +2
                          Вам надо было аналогичную статью тиснуть 20 лет назад:)

                          А по поводу «массы» все же. Массовой профессией программист стал когда на рынок массово пришли персональные компьютеры, это все же никак не 1975, даже на западе это ближе к 1985 году, а в ссср/россии ближе к 1995. До этих лет профессия программисты была не массовой, скорее областью для энтузиастов любителей и узких специалистов
                          Это все равно как сейчас назвать массовой профессию физика-ядерщика, то что их много — неоспоримо, но массовой профессией это станет не раньше выхода 120 айфона на ядерных батарейках, который будет жить аж 3 дня без дозарядки и на каждом углу будет киоск с починкой оных.
                          • 0
                            Ну, я целом наверное согласен, массовость тоже бывает разная. Просто в 1980-х один чисто инженерный факультет уже выпускал в год примерно 600 человек, каждый их которых знал как минимум Алгол-60. И это только один факультет, прошу заметить, а ведь были и другие, включая тех, у кого программист специальность. Разумеется, далеко не все они реально программировали — но факт обучения никуда не девался.
                      • +1
                        Да у меня после таких статей в 24 уже коленки начинают дрожать))) Соберитесь Мужики!!!
                        • +3
                          мне 52 и я кодирую… не ссцы!
                          • 0
                            спасибо всем кто плусанул )))

                            на самом деле вопрос кодирования и возраста имеет еще измерение — уровень достижений и желание самого процесса

                            вы можете хотеть кодировать — но социальный статус уже требует другого и не оставляет времени
                            вы можете не хотеть кодировать… (социальный статус тогда по фиг в общем то)
                            вы можете хотеть (и быть в состоянии) и социальный статус позволяет! (бинго! ну или может быть ;)… просто я в этой группе )))
                            • 0
                              Клал я на социальный статус (даже не знаю, что это такое), хочу кодировать, но не могу увеличить свою з/п много лет. Вот и все. Вот и причина «депрессии».
                              • 0
                                не сходится однако )))

                                в частности з/п как раз одно из измерений социального статуса ))

                                кратко, примеры с/с — наемный сотрудник, предприниматель, пенсионер, наследник о;;%?;«го состояния (то есть все на халяву), высокопоставленный чиновник (то есть тоже самое почти что)
                                • 0
                                  в частности, я кодирую уже для удовольствия, а не за деньги… ))
                                  • 0
                                    в отношении кодинга, я бы добавил… в моем возрасте это явно уже как секс — главное быть в состоянии ;)))

                                    … а «за деньги» или «по любви» это уже второстепенные детали ;)))))

                                    ps — предупреждая инсинуации — кодирую я не «вместо»! одно другому не мешает" ;)))))))))))))
                                  • 0

                                    Если социальный статус не оставляет времени на то, что хочется, то зачем он тогда нужен?

                                    • –2
                                      глянул профиль… по ходу вам «социальный статус» не что не нужен… он вам не угрожает в принципе ))
                                      • 0

                                        Может, оно и к лучшему?

                                        • 0
                                          что именно? массовое… безграмотность? ))… казалось бы «передового класса»… )))
                                          • 0

                                            Что социальный статус не нужен.

                                            • –1
                                              да не вопрос… дорогу можно переходить не по зебре и не глядя на светофор
                                              • +1

                                                А какое это имеет отношение к социальному статусу?

                                                • –1
                                                  ровно такое же как «у меня нет социального статуса» — асфальт есть — можно идти… нет — все равно можно…
                                                  • +1

                                                    Очень странная аналогия. Социальный статус — ярлык, который на тебя навешивают некоторые окружающие и соответственно ему относятся к тебе. Причём тут ПДД, которые требуют от тебя что-то?

                                                    • 0
                                                      del

                                                      ps… чет я не понял вложенность и отступ?
                                                      • 0
                                                        любое социальное соглашение — условность (ПДД, УК, ГК… какой то там «ярлык»)

                                                        в каких то пределах можно пренебрегать условностями, одними с малым риском, другими с большим…

                                                        и можно даже бравировать этим…
                                                        • 0

                                                          ПДД, УК, ГК — это не условности, это чётко оформленные правила поведения в обществе.


                                                          А социальный статус — это уже негласные правила.

                                                          • 0
                                                            да хоть до хрипоты спорь — это условности усиленные всеобщим согласием

                                                            уголовные понятия — гласные или не гласные правила? они приняты в обществе?

                                                            … однако реальны ситуации смертельной опасности при их нарушении

                                                            и кстати уж точно социальный статус не является «не гласным» правилом
                                                            • 0
                                                              ps — «четко прописанные правила», исторически вообще то с легкостью переписываются ))

                                                              конституции под текущего правителя переписываются сплошь и рядом

                                                              не редко вообще меняют социальное устройство, в том числе как вооруженным путем, так и без применения силы (ну или иногда лишь угрожая таковой…

                                                              социум штука на много более иллюзорная, чем может показаться на первый взгляд
                                                            • 0

                                                              Что значит "пренебрегать социальным статусом"? Вот допустим мой социальный статус "люмпен", как я могу им пренебрегать или не пренебрегать?

                                                            • 0
                                                              в частности ФНС тоже от тебя что то требует… но ты же бравировал тем что пытался их морочить

                                                              так что тут аналогия вполне себе…

                                                              автомобиль может сбить, но и ФНС может однажды «наехать» более чем бумажно… и снова аналогия вполне себе возможна
                                                              • 0
                                                                https://habrahabr.ru/post/324426/#comment_10208992 это я хотел тебе ответить… но что то сегодня у меня не клеится с правильным целеуказанием, прости ))
                                                                • 0
                                                                  ярлык или конституция — по свой сути лишь социальное соглашение…

                                                                  хотя цена нарушения может быть различной, суть от этого не меняется
                                                              • 0
                                                                минимальный пример условности для кодеров — соглашения о форматировании кода

                                                                пока ты «один в поле бы.. воин» — можно спагетить, говнокодить, не каментить и не документировать…

                                                                однако когда захочется влиться в команду, скорее всего придется следовать набору правил (ты прикинь — любые правила всего лишь «соглашения») иначе возможно команде придется сказать тебе «давайдосвидания»
                                                            • 0
                                                              правда некоторые при этом еще и не думают посмотреть — нет ли несущихся на скорости машин…
                                                      • 0
                                                        однако упоминание словосочетания «социальный статус» вызвало довольно комичную ситуацию…

                                                        я даже вспомнил анекдот:

                                                        День рождения Наташи Ростовой. Наташа пригласила на праздник поручика Ржевского и всех гусаров полка.

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

                                                        За столом Наташа пытается завести светскую беседу:
                                                        — Вы знаете, я купила 17 свечек для праздничного торта, а на него влезло только 16. Ума не приложу, куда всунуть еще одну?..

                                                        Из-за стола встает поручик Ржевский и кричит:
                                                        — ГУСАРЫ МОЛЧАТЬ!
                                                        • –1
                                                          по ходу я забыл упомянуть выше, что «бомж» и/или «быдлокодер за еду» — все это тоже социальный статус

                                                          социальный статус — это ярлык, который вам навесят социологи при очередном исследовании/обзоре/переписи… а опера — при описи или в протоколе… и так далее

                                                          а еще это то что вы сами напишите в разного рода анкетах, когда идете на поклон к государству…
                                                          • +1

                                                            Термин "самоирония" вам не знаком?


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

                                                • +45
                                                  42 года. Профессионально в IT 23 года. Самая большая проблема — я вижу на 10 шагов вперёд к чему приведут те, или иные решения, в то время как более молодые коллеги видят, едва ли на 3. Поэтому возникает грусть и некий налёт скуки.
                                                  • НЛО прилетело и опубликовало эту надпись здесь
                                                    • +2
                                                      им не нужно повышать вот так свой уровень.

                                                      Сейчас «развлекаюсь» тем, что у новым задачам линкую писанные мною несколько лет назад, на эту же тему.
                                                    • +1

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

                                                      • +13
                                                        Не примут. Проверено. Проблема в том, что им не хватает не технических знаний (это как раз можно быстро наверстать), а, скорее, знаний о том как ведут себя другие разработчики.

                                                        Плохим разработчикам что-либо рассказывать попросту бесполезно, а хорошие склонны мерить всё по себе.

                                                        Один пример: в одном из компонентов у нас был реализован «белый список» системных вызовов, которые этот компонент имел право совершать. Ну и комментарий типа «если нужно что-то то ещё — пишите, мы список расширим!»).

                                                        Как вы думаете сколько подобных запросов мы получили за пять лет? Предположение «нуль» всё же неверно — один запрос был. От нашей же команды. Зато какие «чудеса героизма» были обнаружены в компонентах, созданных партнёрами, которые были совершены для того, чтобы не писать письмо!

                                                        И вот тут — можно говорить что угодно, но «хотьба по граблям» всё-таки продолжится. Просто потому что даже умным людям, но без опыта, сложно представить насколько по-разному могут быть устроены компьютерные компании. И никакие «конструктивные намерения» вам не помогут, так как вы предлагаете тратить ресурсы на решение проблем, которых, с точки зрения «молодежи» нет и быть не может!
                                                        • +6
                                                          Примеры с «чудесами героизма» можно и в любой другой сфере найти. Это одна из базовых психологических черт людей вообще.

                                                          Вы сделали ограничения?
                                                          image
                                                          • +1

                                                            Chalenge accepted — фигня! NotInventedHere!

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

                                                            А вам лучше такие вещи вынести в конфигурациионный файл.
                                                        • +9
                                                          не дай бог озвучишь, может ещё и по шапке от начальства прилететь за то, что (цитирую) «опять ты со своим брюзжанием, видишь одно только говно». а когда таки говно случается, по шапке прилетает ещё раз, потому что имел смелость озвучить.

                                                          мне 36, в IT я с 18 лет. на собственном опыте отлично знаю, к чему может привести плохо продуманное решение. но попробуй докажи.
                                                          • +1

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


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


                                                            Другое дело:


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

                                                            На текущий момент у нас есть проблемы с архитектурой в %название_модуля%, заключающиеся в том, что %краткое_описание_проблем%. В дальнейшем, если мы продолжим развивать это решение, при разработке задачи Б, имеющейся в плане, нам придётся пойти на внедрение компромиссного решения %костыль%, что, впоследствии, в свою очередь, также увеличит трудозатраты на реализацию задачи В, в силу %список_причин%. Также возможно и %другое_решение% задачи Б, не имеющее этих недостатков, зато имеющее %другие_недостатки%. Кроме того, задача Г может оказаться и вовсе нерешаемой, так как %причины%.

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

                                                            Исходя из вышесказнного, я предлагаю начать решать проблему сейчас, пока мы можем это сделать с меньшими трудозатратами. Хочу предложить %ряд_решений%, которые хороши тем, что %обоснование_решений%, а также дадут нам %дополнительные_возможности% и помогут избежать %ряда_проблем%. Для их реализации потребуется %время%, %человекочасы% и %иные_ресурсы%.

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

                                                            Конечно же, эта пламенная речь должна сопровождаться хотя бы парой слайдов, то есть, представлена в форме презентации. Важно внятно аргументировать свою позицию и пригласить к обсуждению. А главное — быть готовым тому, что ваша точка зрения может оказаться неверна.


                                                            Пробовали так?

                                                            • +5

                                                              А вот эти пламенные речи и презентации когда делать, в рабочее время, вместо основных задач? Или в свободное время, за свой счёт?

                                                              • +5

                                                                Это ваш выбор.


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


                                                                Не можете или опасаетесь наказания за самодеятельность — обратитесь к руководителю и согласуйте с ним.


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


                                                                Но сначала — сформулируйте, для себя в первую очередь, какой цели вы хотите достичь с точки зрения бизнеса. К примеру, «Сейчас мы тратим по два-три дня дорогого разработчика на добавление нового отчёта, так как надо писать SQL-запросы и готовить шаблоны на PHP. Эти задачи у нас регулярны. Если мы потратим две недели на новый модуль отчётов — в дальнейшем будем делать новые отчёты за считанные часы силами дешёвого верстальщика, потому что будет знакомый верстальщику XSLT и простенький генератор запросов. Это реальная экономия денег и времени, плюс мы сможем быстрее реагировать на пожелания пользователей, а разработчики займутся реальными задачами», вместо «Наши отчёты шляпа, легаси и говнокод, давайте сделаем нормально». Редкий вменяемый руководитель наотрез откажет, видя заинтересованность работника в результате. А если и откажет — можно не смириться сразу, а выяснить причины решения, возможно, вы видите не всю картину. В конце концов, если в руководстве реально невменько — что вы делаете на такой работе?

                                                              • +4
                                                                это не работает, и после десятка часов объяснений с разными стратегиями и примерами анологичных ситуаций из прошлого тоже.
                                                                • +9

                                                                  Я повторю вопрос и вам — что вас держит на такой работе?


                                                                  Если у вас есть аргументы, а у начальства нет — смысл такой работы? Быть инструментом автоматизации желаний? Чувствовать себя ничтожным? Просиживать штаны, выполняя тикет буква-в-букву?


                                                                  Или просто не нравятся аргументы руководства? Или даже не пытались узнать?


                                                                  Реально, я персонажей с такими настроениями повидал достаточно за пятнадцать лет в разработке. Всё плохо, руководство тупое, никто не слушает, накажут за инициативу… А чаще всего это означает завышенное самомнение, недостаток знаний и коммуникативных навыков, нерешительность и отсутствие инициативы. И, в конечном счёте — отрыв от реальности.


                                                                  Можно быть гением программиррвария, но в жизни программирование должно приносить прибыль. Самая прекрасная архитектура бесполезна, если решает не те задачи, что требуются бизнесу. Для многих разработчиков профессия выросла из хобби, и удовольствие для них, по привычке, на первом месте. Но нанимают нас вовсе не для того, чтобы мы пускали радостные пузыри, полируя код, а чтобы мы эффективно решали задачи бизнеса в рамках имеющихся ограничений. И, на самом деле, это — реальный интересный вызов, а не игры в 30 строк на JavaScript.


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

                                                                  • +3
                                                                    ээээ, к чему этот вопрос?, тут вроде про другое, ну уйдете вы с такой работы, на ней что-то изменится? ну кроме того что некому, или другой будет указывать на огрехи.
                                                                    • 0

                                                                      Если десятичасовые объяснения не возымели эффекта, нужно выяснять, почему. Как минимум, разузнать (и понять) аргументацию отказа. Убедиться, что вы преследуете совместимые цели. В конце концов, вы либо поймёте, как правильно преподнести своё предложение, либо найдёте альтернативный вариант, всех устраивающий. Либо, в худшем случае — узнаете, что ваши старания напрасны, смысла в трате сил на попытки применить свои профессиональные качества нет, здесь уже не исправить ничего, Господь, жги.
                                                                      С работы, на которой вы не востребованы, уходить вполне нормально, иначе есть риск демотивации и профессиональной стагнации, а то и личностной деградации. Это вас тоже должно волновать, а не судьба компании, которой вы не нужны. Стокгольмский синдром, ей богу.

                                                                  • –1
                                                                    А вы не пробовали с другой стороны посмотреть? Да, можно переписать «правильно». И в долгосрочной перспективе (5-10 лет) это выгодно. А в краткосрочной — это пустая трата времени.

                                                                    Вася и Петя одновременно начали писать один и тот же продукт. Помните?

                                                                    Умение управлять техническим долгом — приходит ещё позже, чем понимание, к чему приводит неудачная архитектура.
                                                                    • +5
                                                                      Но Вася выпустил уже через месяц первую версию программы, пусть и не идеальную, пусть с багами, но рабочую, и ...

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

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

                                                                      Обе истории выдуманные, конец будет такой, как автор захочет, а оправдывать сообственный быдлокод сказками — низко.
                                                                      • –1
                                                                        Да вот в реальности — быдлокод побеждает. Сравните популярность Windows 95 c OS/2 Warp 4.0 или Windows NT 4.0. Из недавно мелькавшего на хабре — Duke Nukem 3D.

                                                                        Для оценки уровня быдлокодовости движка Duke Nukem
                                                                        Код движка находится в одном файле из 8503 строк и с 10 основными функциями (Engine.c) и в двух дополнительных файлах:

                                                                        cache1.c: содержит виртуальную файловую систему (sic!) и процедуры системы кэширования.
                                                                        a.c: реализация на C воссозданного обратной разработкой кода, который был высокооптимизированным x86-ассемблером. Код работает, но читать его — огромная мука!


                                                                        Так что увы, в реальности как в сказке.

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

                                                                        А быдлокод вообще-то называется технический долг. Просто использовать этот долг надо умеючи.
                                                                        • +1
                                                                          Видите ли, бывает и так и так, а вы просто ищите оправдания быдлокода и потому видите только то, что хотите) Вот, например, вы увидели Duke Nukem 3D, но не увидели Doom с хорошим кодом)

                                                                          Да, оно может дать некоторые выгоды в очень короткой перспективе (две недели, максимум месяц, но уже через 3 месяца внесения правок в продукт траты из-за технического долга значительно увеличиваются в сравнении с выиграшем.

                                                                          Запускать технический долг выгодно только в одном случае — вы закончите продукт как его видите и никогда не будете поддерживать. Потому этот подход используют для прототипов, которые идут на выброс.
                                                                          • –1
                                                                            Глянул я тут по наводке в исходный код Doom и обмер…

                                                                            Заранее приготовьте валидол
                                                                            void Error (char *error, ...)
                                                                            {
                                                                            	va_list argptr;
                                                                            
                                                                            #ifndef __NeXT__
                                                                            	if ( *(byte *)0x449 == 0x13)
                                                                            		TextMode ();
                                                                            #endif
                                                                            
                                                                            	va_start (argptr,error);
                                                                            	vprintf (error,argptr);
                                                                            	va_end (argptr);
                                                                            	printf ("\n");
                                                                            	exit (1);
                                                                            }
                                                                            



                                                                            Ну если if ( *(byte *)0x449 == 0x13) для вас хороший код — то вы на 100% правы. Потому что до такого мы даже в прототипах не скатываемся.

                                                                            Потому и живут у нас неоптимальные технические решения лет 5-10. И вполне переносят модификации. Та же Windows при всей её быдлокодовости проживала 25 лет.

                                                                            Так что с вашей оценкой кода — у нас быдлокода вообще нет… :-) А с нашей оценкой — ну скорее всего весь ваш код плох.

                                                                            но уже через 3 месяца внесения правок в продукт

                                                                            Мда… Что это за анализ предметной области, если код нужно править в ближайшие полгода? Что-то мне вспоминается мой бывший коллега, который в своей книжке писал:

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

                                                                            Результат неизменно стабильный…

                                                                            Случайно это не ваш случай? Если ваш — то мне вас жаль.
                                                                            • +1
                                                                              Я не сказал, что через три месяца после начала разработки вносятся правки в продукт.
                                                                              Я сказал про три месяца правок. Они могут начаться и значительно позже.
                                                                              А в геймдеве и вообще активные правки с самого начала — единственный путь для нешаблонной игры. И да, геймдев — мой случай.
                                                                              Кстати, вы про аджайл и итеративную разработку слышали? Или только на водопаде с заранее прописанной документацией работаете?
                                                                              • –1
                                                                                Ну судя по статьям Мосигры — далеко не единственный. Но могу ошибаться. Мы, конечно, не авионику делаем с её двухлетним циклом, но наше АСУТП намного ближе к авионике, чем к игрушкам. По крайней мере сегодняшние правки — как раз для беспилотника.

                                                                                Про аджайл и так далее — почитайте "дефрагментацию мозга". Серега там хорошо и по аджайлу прошелся.

                                                                                Одна из цитат
                                                                                5. Одни из наших конкурентов широко используют agile-методы и TDD[121], но что-то оно им не очень помогает писать безошибочный код. Мы сравнивали количество найденных проблем в течение месяца-двух после major release, у нас показатели лучше в разы, если не на порядок. Частый выпуск версий просто не позволяет им довести код до ума и провоцирует исправление старых и серьёзных проблем методом написания «залепени». (Прим. автора: исправление ошибок, добавляющее новые проблемы.)


                                                                                А у нас что-то среднее. Не аджайл, но и не жесткий водопад. И да, мы обычно на 3-5 лет понимаем, что может потребоваться, а что — нет. Неожиданности бывают, но редко.

                                                                                А претензии к красивому коду у меня как у Жванецкого — "включаешь – не работает.". То есть шик, блеск, красота… но работает только для сферической лошади в вакууме. А на реальных данных — валится, как бык по скользи. Потому что программер думал об архитектуре, декомпозиции, делегировании, концепции… о чем угодно, но не о том, что модуль должен работать. Работать на реальных данных. С выбросами, лакунами и прочим дерьмом отклонением от идеала.

                                                                                И любой работающий быдлокод — в 100 раз лучше неработающей красоты.

                                                                                Особенно, если автор этой «красоты» заявляет, что адаптировать к реальным данным нельзя, ибо «архитектура не позволяет» и «концепция сломается». :-)
                                                                                • +1
                                                                                  Ну судя по статьям Мосигры — далеко не единственный

                                                                                  При чем тут Мосигра? У них коробки делают, а не софт. Там делал-делал пока не закончил, а потом выпустил, что сделал. И имеешь очень мало влияния на проданные продукты.

                                                                                  И да, мы обычно на 3-5 лет понимаем, что может потребоваться, а что — нет

                                                                                  Так это ж просто ляпота, никаких сложностей.

                                                                                  Одни из наших конкурентов широко используют agile-методы и TDD[121], но что-то оно им не очень помогает писать безошибочный код

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

                                                                                  Потому что программер думал об архитектуре, декомпозиции, делегировании, концепции… о чем угодно, но не о том, что модуль должен работать. Работать на реальных данных. С выбросами, лакунами и прочим дерьмом отклонением от идеала.

                                                                                  У вас странные понимания качественного кода. Не удивительно, что вы так агритесь на него. Качественный код — это не когда «много интерфейсов», а когда регулярные правки не вносят множество регрессий, когда новые фичи органично и легко вписываются в архитектуру, когда поддерживаются любые данные, или легко дореализовываются, когда сложность добавления фичей не растет с каждой новой фичей геометически.

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

                                                                                  При живой разработке быдлокод приводит к очень быстрому росту сложности приложения и уже через несколько месяцев пропадает выгода от его использования, а дальше только хуже.
                                                                                  • –1
                                                                                    Понятно. Мы ненастоящие программисты не только потому, что при отладке используем осциллограф. Но и потому, что мы не заменяем отвратительное качество работы аналитики хорошим качеством кода,

                                                                                    Мне помнится, в блоге Мосигры (а может и не в нем) были рассказы про разработку компьютерных игр. Не все игры писались «методом тыка», иногда люди хорошо представляли, что именно они хотят сделать.

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

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

                                                                                    Если угадали — код дописывается легко. Если не угадали — ну или отказываться от заказа — или переписывать код, Но каждый раз, когда мы не угадали — это наша ошибка, как аналитиков.

                                                                                    Вы немного путаете качество кода со способностью кода к модификации.

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

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

                                                                                    P.S. Если не трудно, расскажите что такое редакс. А то «мужики-то и не знают». :-)
                                                                                    • +1
                                                                                      розовый танк с оборками и стразиками — невероятен


                                                                                      Некий российский режиссер с вами не согласен…
                                                                                      Обитаемый остров
                                                                                      image
                                                                                      • 0
                                                                                        Оборочек не вижу. И стразиков. Но +1!
                                                                                    • 0
                                                                                      Чтобы вам было понятней, почему качество и способность к изменениям -разные вещи, простой пример.

                                                                                      Вот есть восьмислойная плата, качественная-перекачественная. Чипы на BGA, рассыпуха 01005 (0,4 × 0,2 мм), дины линий выверены, импедансы рассчитаны и смоделированы, все фронты — ровненькие, хоть на 5 гигагрерц работой. Но вот только срок обновления у неё — 6 месяцев. И ремонтабельность нулевая.

                                                                                      А есть макетка. Быдло-быдло. Чипы — на DIP, рассыпуха — 1210 (3,2 × 2,5 мм), монтаж — проводом МГФТ, фронты завалены, об импедансе и длине линий и разговора нет, дай бог, чтобы на 150 мегагерц завелась. Но срок обновления у такой платы — 3 часа. И ремонт — хоть дома, хоть в офисе.

                                                                                      И что в железе, что в коде — у нас так. Чем выше качество — тем сложнее менять. Чем былокодистей — тем менять проще.

                                                                                      Ну у нас не макетки, но ближе к этому концу. За 3 недели можно новую плату сделать и софт на неё переделать. И даже за две, если печатную плату не заводским методом делать, а ЛУТом.
                                                                                    • 0
                                                                                      И любой работающий быдлокод — в 100 раз лучше неработающей красоты.

                                                                                      А вы действительно не путаете проблемность целевой области и заточку кода под неё (что может включать в себя массу адских хаков на частные случаи исключительно из-за ТЗ) и некачественность самого кода?
                                                                                      Если первое, то это не принято называть быдлокодом (разве что быдлозадачей).
                                                                                      Если второе, то покэпствую
                                                                                      1) красивый неработающий код, скорее всего, легче довести до рабочего состояния;
                                                                                      2) после этого он лучше сопровождаем, в отличие от быдлокода.


                                                                                      Пример с Doom и куском для NeXT, кстати, тут очень хорош дидактически :) С одной стороны, там очевидные странности в виде магических констант, которые по обычным нормативам надо описать в виде #define. Но я бы тут вместо этого поставил комментарий с описанием смысла конкретного числа.
                                                                                      С другой стороны, стиль, рекомендуемый во многих местах, потребовал бы сделать тут безусловно вызванное макро, которое было бы определено в непустое действие только для NeXT. А вот это уже хуже потерей локальности — надо идти неизвестно куда только для того, чтобы узнать, что для 99.999% случаев макро просто пустое.

                                                                                      • 0
                                                                                        Давайте разделим:

                                                                                        1. Быдлокод — это простой, некрасивый код, написанный в лоб. Часто большие размеры процедур, связь через глобальные переменные и так далее.
                                                                                        2. Хакерский код — эффективный, но очень сложный в понимании код с множеством трюков.
                                                                                        3. «красивый» код — эффективный код, написанный по всем правилам (классы, методы на все случаи жизни).

                                                                                        И вот вам пример, чем быдлокод лучше. Известная "Задача о восьми ферзях": Простой вариант с 8 циклами — легко обеспечивает переход к доскам непрямоугольной формы. А вот быстрый алгоритм Дейкстры…

                                                                                        1) красивый неработающий код, скорее всего, легче довести до рабочего состояния;
                                                                                        2) после этого он лучше сопровождаем, в отличие от быдлокода.

                                                                                        Увы и ах. Если в «красивом, эффективном коде» неверно понято ТЗ — заставить его работать можно лишь путем хакережа. И сопровождаемость после этого падает в ноль.

                                                                                        Неужели непонятно, что красота и эффективность идет за счет специализации кода (по условиям ТЗ)? Что вся декомпозиция — хороша лишь, пока программист верно понимает ТЗ и спектр его изменений? А если программер построил "мост вдоль реки", то его разворот обойдется дороже, чем написать его заново.
                                                                                        • +1
                                                                                          Неужели непонятно, что красота и эффективность идет за счет специализации кода (по условиям ТЗ)?

                                                                                          EPARSE, простите. Красота и эффективность — следствие специализации кода, или они страдают (ухудшаются) из-за специализации кода?


                                                                                          Что вся декомпозиция — хороша лишь, пока программист верно понимает ТЗ и спектр его изменений?

                                                                                          Нет, непонятно. На практике можно считать, например, что через год изменятся 10% требований, а за десятилетний цикл развития — чуть менее, чем все. (Реальные цифры с одной из моих прошлых работ.) Но каким образом из этого следует рекомендация писать всё так, что не заботиться о его сопровождении? Ведь даже если 20% изменилось, остальные 80% те же, а сопровождать надо каждый день.


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

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


                                                                                          И вот вам пример, чем быдлокод лучше. Известная "Задача о восьми ферзях": Простой вариант с 8 циклами — легко обеспечивает переход к доскам непрямоугольной формы. А вот быстрый алгоритм Дейкстры…

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


                                                                                          Давайте разделим:
                                                                                          Быдлокод — это простой, некрасивый код, написанный в лоб.

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

                                                                                          • –2
                                                                                            На практике можно считать, например, что через год изменятся 10% требований, а за десятилетний цикл развития — чуть менее, чем все.

                                                                                            МДА. Ну или у вас аналитики действуют методом памяти покойного академика тыка, или вы путаете изменения ТЗ с дополнениями, из у вас какое-то "настоящее" программирование типа поддержи сайта.

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

                                                                                            С другой стороны газонокосилка вполне может начать отстреливаться очередями, стан для оцинковки — делать алюминирование, а атомный ледокол — перейти экватор. Это маловероятно — но возможно.

                                                                                            Точно так же я понимаю, что на компе может не быть часов, а в байте неожиданно может оказать 32 бита,

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

                                                                                            Дописывания отличаются от переписываний тем, что при нормальной структуре почти не меняют существующий код. А при плохой структуре — вызывают рефакторинг кода. В обоих случаях — речь об усталости кода идет редко.

                                                                                            Красота и эффективность — следствие специализации кода, или они страдают (ухудшаются) из-за специализации кода?

                                                                                            Ни то ни то. Делая код эффективным — мы теряем в его универсальности. Делая код красивым — опять теряем в универсальности.

                                                                                            Чтобы было понятней — вспомните дискуссию про goto сороколетней давности. Код с goto -очень гибкий. Но и некрасивый.

                                                                                            очень вероятно, что те же решения (быки-опоры, пролёты, методы их сцепления, покрытие для дороги) годятся для моста что вдоль, что поперёк

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

                                                                                            A вот сами быки и пролеты — выкидываются. Ибо после демонтажа быка половина остается под руслом. Там же сваи, они глубоко забиваются.

                                                                                            Так что в сухом остатке — всего лишь опыт и образец документации.

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

                                                                                            Соглашусь, лоб у всех разный, естественный код — тоже.

                                                                                            В моей юности процедуры на 5 страниц считались отличным (и понятным кодом). Именно в этом стиле и писали в журналах и книгах по программированию. Ну и блок глобальных данных — был вообще единственным способом эффективной связи по данным.
                                                                                            • +1
                                                                                              Так что если я решил, что какого-то изменения не будет, а оно произошло — это моя ошибка. Дописываний бывает много и очень разных, а вот непредсказанные изменения — это редкость. Ну, разумеется, если понимаешь предметную область.

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

                                                                                              • 0
                                                                                                Уточню — моя ошибка как аналитика предметной области. Или другого аналитика.

                                                                                                Кроме того, изменения вообще редки. Ограничение размера пени — это дополнение, а не изменение ТЗ. Ну разумеется, если ваша архитектура позволяет формировать проверки и корректировки финансовых операций как дополнения.

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

                                                                                                Новый режим стирки — дополнение. Изменение параметров режима стирки — тоже дополнение, пишем новый режим, а старый просто не вызывается.

                                                                                                Замена датчика — опять дополнение. Пишем чтение с нового датчика и не вызываем код для старого датчика.

                                                                                                ДА, исходники разбухают. Но одним кодом + таблица конфигурации мы поддерживаем всю линейку стиральных машин от царя гороха до наших дней.
                                                                                                • +1
                                                                                                  В качестве примера, придумайте изменения ТЗ для программы, работающей в стиральной машине.

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

                                                                                                  Посмотрите на историю развития World of Tanks, к примеру. Или Hearthstone. Или RimWorld. Или Minecraft.

                                                                                                  Я прекрасно понимаю, что вотерфол значительно снисходительнее к плохому коду — представляешь конечную цель, знаешь, что у тебя не будет ничего сверхординарного и продюсер не скажет «можно атомный ледокол полетит над Москвой (ну хотя бы низенько-низенько можно?)». Если пришло что-то неординарное или ошибся немного — костыль подставил, благо такое крайне редко бывает.

                                                                                                  Да, на таких проектах в среднесрочной перспективе говнокод может вполне себе работать. Именно потому я в самом начале ветки написал следующее:
                                                                                                  Запускать технический долг выгодно только в одном случае — вы закончите продукт как его видите и никогда не будете поддерживать

                                                                                                  И ваш пример со стиральной машинкой — отличный. Вы сделали, как сделали, небольшая группа потестила, всё, что криво — записали в руководство «дважды кнопку не нажимать» и отдали пользователям — пускай себе трахаются. А вот если стиральную машинку отдаете пользователям, а потом понимаете, что барабан должен быть на 60% больше и вам это нужно сделать не в новой машинке, а за три недели. А потом понимаете, что механические кнопки слева не подходят и надо поставить рычажки справа и у вас на это три недели. А потом понимаете, что рычажки справа не подходят, а сверху надо поставить тач-скрин. А после этого понимаете, что слив в том месте у 20% вызывает разлив воды потому что они его неправильно подключают и вы переделываете слив. И так три года.

                                                                                                  Если вы в таком режиме будете быдлокодить — поймете, о чем я говорю.
                                                                                                  • –2
                                                                                                    Вы раз за разом приводите в пример вотерфол-подобные методологии.

                                                                                                    Отнюдь. Вполне можно и по скраму.

                                                                                                    У вас есть 200 сейчас продающихся моделей стиральных машин, 100 — уже не продающихся, но поддерживаемых и 50 в новой разработке. Реально это выливается в поддержку 7 вариантов процессорной платы, 30 вариантов пультов и по 3-5 вариантов каждого датчика и исполнительного устройства + не на всех моделях есть все датчики и все агрегаты.

                                                                                                    И вот всю эту армаду в 350 моделей вы и делаете по скраму. По модели (или группе моделей на спринт).

                                                                                                    Единственное упрощение — вы не поддерживаете старый код ядра. Нашлась ошибка в старой модели — вы берете самое последнее ядро, берете коды датчиков и исполнительных механизмов для старой модели и допиливаете их для нового ядра (если они ещё не допилены).

                                                                                                    А вот если стиральную машинку отдаете пользователям, а потом понимаете, что барабан должен быть на 60% больше и вам это нужно сделать не в новой машинке, а за три недели.

                                                                                                    Это не за три недели, в нормальном коде это делается за день, если не за час. Изменили константу в конфигурации, потестили и отдали в production.

                                                                                                    Если вы в таком режиме будете быдлокодить — поймете, о чем я говорю.

                                                                                                    я в таком режиме уже почти 10 лет работаю. 6 операционок (Linux, Windows, FreeRTOS, FreeBSD, MS-DOS, QNX, МСВС считаем за linux), 6 компиляторов (gcc, clang, lcc, borland C++, С Builder, MS VC++) 3 разных архитектуры (x86, ARM, SPARC) и куча конкретных продуктов. Ну не 350, но к двум десяткам. И всё это — на единой кодовой базе и с приличным техническим долгом.

                                                                                                    Ниша у нас такая — полузаказные продукты делать. И поддержка пожизненная. То есть лет на 10-20.

                                                                                                    Да, такой подход есть и он накладывает повышенную ответственность на аналитика и снимает эту ответственность с программиста.

                                                                                                    Последние лет 15-20 лет я занимаюсь и тем и тем. То есть для меня это перекладывание ответственности с одного плеча на другое.

                                                                                                    есть поверхностное понимание, что будет в задачах в ближайшие два месяца

                                                                                                    Это называется разработка методом тыка. Или вы настолько мелкая сошка, что аналитики не считают нужным ставить вас в известность.

                                                                                                    А основное отличие в другом. Мы делаем для реального мира. Наши приборы и решения реально нужны. За них платят потому, что без них — обходится дороже.

                                                                                                    А вы — делаете для выдуманного, цифрового мира. Если не будет игрушек — никто денег не потеряет. Никто не придет к вам и не скажет — сделайте мне систему, это мне сэкономит полмиллиона долларов в месяц. Сделали. Сэкономили в итого больше сотни миллионов в год на отдельных режимах.

                                                                                                    Вы можете позволить себе сидеть без заказов и действовать методом тыка. Мы — не можем. Методом тыка мы можем только по миру пойти.

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

                                                                                                    Мы не можем сказать «а давайте попробуем вот такой вариант, вдруг он кому-то нужен». Прежде чем что-то делать, мы должны понимать, кому мы продадим, по какой цене, каким тиражом.

                                                                                                    А что касается гавнокода, то я уже описывал вам, чем гавнокод лучше. И что именно из-за гавнокода мы имеем короткий цикл модификации. Увы, вы на это ничего не ответили.
                                                                                                    • +1
                                                                                                      Это не за три недели, в нормальном коде это делается за день, если не за час. Изменили константу в конфигурации, потестили и отдали в production.

                                                                                                      Эй, не выходите за пределы сообственной аналогии! У вас новый барабан не вмещается в старый корпус, даже если не учитывать, что управляющие конструкции вы сделали быдлокодом и они впритык упираются в барабан существующего размера.

                                                                                                      У вас есть 200 сейчас продающихся моделей стиральных машин...

                                                                                                      Вы теоретизуруете. А я говорю о реальных проектах.

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

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

                                                                                                      А вы — делаете для выдуманного, цифрового мира

                                                                                                      Да, я знаю, что вы обижены на game-developer'ов и web-developer'ов, но эти факты не делают вас лучше. Вот я какое-то время писал медицинский софт, то не говорю ведь вам теперь: «вот, вы просто за бездушные деньги работаете, а я жизни людей спасал». Странно звучит, правда. А вы так постоянно говорите.

                                                                                                      Это называется разработка методом тыка. Или вы настолько мелкая сошка, что аналитики не считают нужным ставить вас в известность.

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

                                                                                                      Это называется разработка методом тыка.

                                                                                                      Я стараюсь не судить о том, в чем не разбираюсь. А зачем вы поступаете иначе?

                                                                                                      Или вы настолько мелкая сошка, что аналитики не считают нужным ставить вас в известность.

                                                                                                      Оскорбления. Прекрасный ход. Сразу видно силу и аргументированность вашей позиции.
                                                                                                      • 0
                                                                                                        Да, я знаю, что вы обижены на game-developer'ов и web-developer'ов

                                                                                                        Отнюдь. Это отсылка к делению на хабр и гиктаймс. «Программирование» на HTML+CSS было признано настоящим, а всякое автовождение и прочий embeded — ненастоящим.

                                                                                                        Логика тут есть. Настоящее — это то, что делается цифрового мира. А то, что делается для реального мира — ненастоящее. Цифровой мир — намного гибче и допускает работу методом тыка. И масштабы гигантские. 10 тысяч пользователей цифрового мира — это ерунда, 10 тысяч пользователей реального устройства — это очень много.

                                                                                                        Я в разработке железа не разбираюсь и мне это не очень интересно.

                                                                                                        Хорошо, вот вам аналогия из вашей работы. Насколько проще бы бы вам работать, если бы вместо реалистичного 3D использовалась анимация спрайтами или ASCII-Art? Чувствуете? Там, где вы месяцы будете отрисовывать красивую 3D-картинку, ASCII-art меняется за день. Вот так быдлотехнологии и ведут к быстрому циклу изменений.

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

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

                                                                                                        Собственно вы помладше моей старшей дочки, так что вряд ли являетесь ведущим программистом тех же танков. Но вполне допущу, что вы кое-что умышленно скрываете, чтобы юзеры просьбами не доставали. Сотня миллионов игроков WoT — достаточный повод, чтобы скрываться.

                                                                                                        Вы теоретизуруете. А я говорю о реальных проектах.

                                                                                                        Реально — к паре десятков.

                                                                                                        Эй, не выходите за пределы сообственной аналогии! У вас новый барабан не вмещается в старый корпус, даже если не учитывать, что управляющие конструкции вы сделали быдлокодом и они впритык упираются в барабан существующего размера.

                                                                                                        Аналогия — код для 350 разных стиральных машин. А то, о чем вы говорите — это даже не электроника, а механика.

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

                                                                                                        Это специфика вашей отрасли. Огромное количество фирм сейчас живет по другим принципам.

                                                                                                        Скорее должности, чем отрасли.

                                                                                                        А итоговые тезисы такие:

                                                                                                        1. Применяя технологии вчерашнего и позавчерашнего дня (быдлокод) в современной обработке — мы уменьшаем цикл разработки (и легкость переделок) за счет скорости, эффективности, красоты кода и прочего. И наоборот — чем качественней код, тем сложнее он изменяется, оставаясь качественным.
                                                                                                        2. ООП — очень гибкая вещь, но только если угадали со структурой. В случае ошибки в выборе структуры — изменения становятся настолько тяжелыми, что проще все переписать заново.
                                                                                                        3. Технический долг — абсолютно нормальная штука, если им грамотно управлять. Но это уровень менеджеров, аналитиков и темлидов, а не рядовых программистов.
                                                                                                        • 0
                                                                                                          Хорошо, вот вам аналогия из вашей работы. Насколько проще бы бы вам работать, если бы вместо реалистичного 3D использовалась анимация спрайтами или ASCII-Art? Чувствуете? Там, где вы месяцы будете отрисовывать красивую 3D-картинку, ASCII-art меняется за день. Вот так быдлотехнологии и ведут к быстрому циклу изменений.

                                                                                                          Какая-то аналогия левая. Это ведь просто разные жанры или стили. При чем тут быдлотехнологии? Или если делаешь 2д-игру вместо 3д-игры, то уже быдлятник? Если хорошо написан код, то легче работать и с 3д и с 2д.

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

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

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

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

                                                                                                          И как вывод — скорее всего, где-то в душе вы понимаете, что быдлокод вам мешает, но, может, вы просто не знаете, как написать хороший код, чтобы он при этом легко поддерживался и изменялся. А такая агрессия — это просто защитная реакция.
                                                                                                          • 0
                                                                                                            И как вывод — скорее всего, где-то в душе вы понимаете, что быдлокод вам мешает, но, может, вы просто не знаете, как написать хороший код, чтобы он при этом легко поддерживался и изменялся

                                                                                                            Кстати да, напомнили вы мне своим комментарием о вопросе, который меня сильно мучает: как писать в рамках TDD (про BDD молчу — там я сам принцип не понимаю)… Сам принцип я понимаю, но вот как перейти к нему?..

                                                                                                            • 0
                                                                                                              как писать в рамках TDD

                                                                                                              Я переходил волевым решением. Не знаю, насколько оптимально, но, в целом, доволен реультатом. Проще всего в новых проектах это делать (даже в рамках того же продукта).
                                                                                                              • 0

                                                                                                                Потихоньку. Пришел багрепорт — воспроизвели его тестом (падающим), а не руками. Добились, чтобы тест прошёл любым костылём — баг исправлен. Если костылём, то отрефакторили и убедились, что тест всё ещё проходит. Так же и с фичереквестами.


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

                                                                                                                • 0
                                                                                                                  Мда… у нас в ответствественных местах баг закрывается трижды
                                                                                                                  1) Работа системы с деградацией функциональности при наличии бага
                                                                                                                  2) Адекватная диагностика поближе к точке возникновения бага
                                                                                                                  3) Правка самого бага.
                                                                                                                  • 0

                                                                                                                    Речь про ваш пункт 3, может 2 частично.

                                                                                                                    • 0
                                                                                                                      Угу. я о том, что 1 намного важнее, чем 3. Ну в смысле для надежных систем.
                                                                                                                      3, как правило, закрывает только конкретный баг. 1 дает возможность работать при целом классе багов.
                                                                                                                • 0
                                                                                                                  Да точно так же, просто вначале пишите тесты, а уж потом код.
                                                                                                                  • 0

                                                                                                                    Было бы точно так же — уже давно больше половины разработчиков перешла бы на TDD… А я вот до сих пор вижу кучу проектов с покрытием юнит-тестами ниже 30%!


                                                                                                                    PS Да и на своём примере я чётко вижу, что это не так просто…


                                                                                                                    Угу. я о том, что 1 намного важнее, чем 3. Ну в смысле для надежных систем.
                                                                                                                    3, как правило, закрывает только конкретный баг. 1 дает возможность работать при целом классе багов.

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

                                                                                                                    • 0
                                                                                                                      Немного дольше писать на TDD, но на выходе имеем покрытие 90%, а не 30. Если сначала писать код, а потом тесты, то заленитесь покрывать 100% и бросите после 30.
                                                                                                                      Для багфиксов это суперудобно: сначала фейлящийся тест, а потом багфикс, который его вылечивает (как вам тут уже написал VolCh). Очень удобно и логично. И покрытие не страдает.
                                                                                                                      Для фич пишем h-ники, потом заглушки тестов (покрытие 90%) по максимуму, потом функционал, потом тесты до конца, потом их отлаживаем.
                                                                                                                      • +1
                                                                                                                        Для багфиксов тест действительно пишется до правки. Только это не TDD.
                                                                                                                        • –1

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

                                                                                                                          • 0

                                                                                                                            Это просто элемент TDD, потому что TDD придуман не для этого.
                                                                                                                            Смысл TDD — это методология написания программ, а не исправления ошибок.

                                                                                                                            • –1
                                                                                                                              Давайте не путать исправление ошибок с доделками, а сопровождение с тестированием. А то вы потом божий дар с яичницей спутаете.
                                                                                                                              • 0

                                                                                                                                Что исправление ошибок, что доделки, что переделки с точки зрения TDD одно — нет нужной функциональности в системе, пишем (в случае переделки переписываем) тест, проверяющий её наличие, убеждаемся, что он падает и изменяем код так, чтобы перестал падать.

                                                                                                                                • –1
                                                                                                                                  Откуда ж у вас ошибки, если теоретически TDD страхует от них? :-)
                                                                                                                                  • +2

                                                                                                                                    TDD, как и любое (ну, почти) тестирование не страхует от ошибок, это заблуждение. Тесты лишь фиксируют поведение системы для конкретных частных случаев входных данных и ничего не говорят о поведении даже при минимально отличающемся наборе. Из того, что проходит тест assert(4, add(2,2) нельзя делать логический вывод без анализа кода хотя бы функции add, что пройдёт тест assert(3, add(1,2)). Интуитивно, предполагая разумность и внимательность разработчика должен пройти, но это не логически выведенное утверждение, а лишь предположение, рабочая гипотеза, которая может быть опровергнута даже при промышленной эксплуатации.

                                                                                                                                    • 0
                                                                                                                                      Пр этом альтернативные технологии контролируют поведение программы в production, то есть на всех реальных наборах данных,

                                                                                                                                      Кстати, мой коллега в одной из ЭВМ обнаружил, что 2.0 равно 16.0, то есть сравнивались лишь мантисы, без ординат. Завод-изготовитель потом долго извинялся. :-) Машина была с серийным номером три.
                                                                                                                                      • 0

                                                                                                                                        TDD не является альтернативой какой-то технологии, она дополняет имеющиеся.

                                                                                                                                        • 0
                                                                                                                                          Это при бесконечном бюджете. А при конечном? TDD дает ложную уверенность в оттестированности кода без Q&A,
                                                                                                                                          • 0

                                                                                                                                            Почему ложную? Я вот уверен, что метод, который я написал последним, оттестирован для двух кейсов и если в будущем метод будет меняться, то сразу будет заметно, если поведение метода для одного из них или для обоих изменится. Но при этом я понимаю и то, что оттестирован код исключительно для двух кейсов, один из которых граничный случай, а второй — общий. Я не строю никаких предположений о том, как он поведёт себя в каких-то других граничных случаях. Придёт баг-репорт, что поведение не соответствует ожидаемому в каком-то случае — будет третий кейс. Не исключено, что его нормальное исправление будет осуществляться вообще не в нашей кодовой базе, а в трансляторе языка или его стандартной библиотеке.

                                                                                                                                            • 0
                                                                                                                                              Потому что одновременно с введением TDD руководство снижает затраты на Q&A. Накладные расходы у TDD не нулевые. Если мы тратим бюджет на TDD — значит урезаем его в другом месте.
                                                                                                                                              • 0

                                                                                                                                                В первый раз о такой практике слышу. Внедрение и использование TDD входит в бюджет непосредственно разработки, кодирования, к Q&A оно никакого отношения не имеет, это как внедрение нового фреймворка.

                                                                                                                                                • 0
                                                                                                                                                  А вы про экстремальное программирование почитайте. Там «представитель заказчика» заменят QA и вводится прямо в бригаду.
                                                                                                                        • –1
                                                                                                                          TDD — это один из вариантов Hype Driven Development. Некая модная тенденция, полезная в отдельных случаях и вредная во всех остальных.

                                                                                                                          TDD нарушает одну из основных заповедей тестирования — никогда не тестировать свой собственный код. Грубо говоря, при неверном прочтении ТЗ ошибка попадает и в тесты и в код, поэтому тестирование бесполезно.

                                                                                                                          Как говорит мой коллега, если программеры работают по TDD, то работает только то, что попало в тесты. Шаг влево, шаг вправо — не работает. При этом коллеги обычно не правится по 5 лет с момента написания, ибо багов просто нет.

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

                                                                                                                          А что удивляться? Тому, что кто-то до сих пор умеет писать программы, которые не падают после первой ошибки? Это нормально! У самолетов кроме постоянной забагованности, как ещё и цикл правки багов по 2-3 года.

                                                                                                                          Мы у себя в одном проекте решили, что баги есть, были и будут, в итоге работает 15 лет 365 на 24.
                                                                                                                          • 0

                                                                                                                            А потом и тесты, и код пуллреквестят специально обученные люди. Да и до написания и тестов, и кода обычно советуются с людьми, разбирающимися в бизнесе. Вероятность "неправильно понять" стремится к 0.

                                                                                                                            • –2
                                                                                                                              Равно как и выигрыш от TDD. Точнее он становится отрицательным. TDD — нишевая штука, все остальное — мода.
                                                                                                                            • +2

                                                                                                                              Основное назначение тестов в виде используемом в TDD — не обнаружение несоответствий поведения программы ТЗ, а фиксация понимания ТЗ и регулярная проверка соответствия поведения этому пониманию. Тесты в TDD — часть процесса кодирования, а не тестирования, чистый development, а не Q&A.

                                                                                                                              • –3
                                                                                                                                TDD — отличный инструмент, если вы рассчитываете довести код до состояния, когда почти любая правка багов вызывает новые баги. :-)

                                                                                                                                В остальных случаях — где-то он полезен, а где-то просто мода или религия.

                                                                                                                                Если вы думаете, что подсчитанная вручную пара матриц понятнее ТЗ — вы сильно ошибаетесь. :-)

                                                                                                                                • +2
                                                                                                                                  Я надеюсь, что Вы пошутили. Иначе не вижу никакого резона для таких утверждений.
                                                                                                                                  TDD — отличный инструмент, если вы рассчитываете довести код до состояния, когда почти любая правка багов вызывает новые баги. :-)
                                                                                                                                  • –1
                                                                                                                                    Здрасти, приехали. Чего у TDD не отнять — это создания огромной базы для регрессионного тестирования. А полезнее всего эта база при усталости кода, когда каждая правка бага вызывает новые баги.

                                                                                                                                    Если уж вы довели код до такой ситуации, то будете сильно рады, что работали по TDD.
                                                                                                                                    • 0
                                                                                                                                      А, тогда да, согласен.
                                                                                                                                    • +1
                                                                                                                                      При обсуждении TDD надо отделить мухи от котлет и принципы, лежащие в его основе, от их конкретной комбинации. У меня лично претензии именно к конкретной комбинации (ну и, естественно, к доведению её до статуса религии).

                                                                                                                                      Первое: тут уже упоминалось, но повторю: формально TDD никак не требует собственно писать по ТЗ, оно требует только удовлетворения теста. Поэтому, если мы напишем умножение в виде

                                                                                                                                      multiply(0, 0) -> 0;
                                                                                                                                      multiply(2, 0) -> 0;
                                                                                                                                      multiply(2, 2) -> 4.

                                                                                                                                      и никто не проверит, что работа вообще не делается, будет полное формальное соответствие, которое никому не нужно.

                                                                                                                                      Для объяснения этого вообще нужно вернуться к тому, зачем же тест нужен. Тут лучшая формулировка, что я слышал, дана коллегой landerhigh с RSDN: «Тесты — не для поиска багов, а для написания верифицируемого в контролируемых условиях кода.» Под верификацией имеется в виду любая верификация, начиная с банального просмотра глазами. Код должен обеспечивать своим содержимым выполнение ТЗ так, чтобы это могли проверить средства верификации (сам автор, коллеги-ревьюеры, автоматические средства...), а тест — чтобы ловить то, что верификация не ловит: человек не заметил опечатку или крайний случай; вместо символа ';' шутник подставил ';' (U+037E); не выловлен какой-то крайний случай; и тому подобное.

                                                                                                                                      Далее, в классическом TDD объявляется, что
                                                                                                                                      1) пишутся тесты до кода («test first»);
                                                                                                                                      2) тесты должны быть проверены на то, что они не проходят (тупо — запустили, увидели отказ и только после этого имеем право двигаться дальше);
                                                                                                                                      3) пишется код для их удовлетворения.

                                                                                                                                      Каждое из первого и второго не допускает возможности его применения для уже существующего кода, что неизбежно в случае, когда происходит изменение спецификации к уже написанному, или при заимствовании готовой чужой разработки с адаптацией под себя. А это неизбежная ситуация как во многих случаях начальной разработки, так и тем более при поддержке.

                                                                                                                                      Чтобы допустить в принципе ситуацию, когда код меняется, надо допустить, если использовать правило «test first», что новые тесты соответствуют TDD, но старые — нет, часть тестов может работать и до новой разработки, и после. А это значит, что они уже нарушают этот принцип — их нельзя проверить на корректность той проверкой, что «тест до написания упал => он, вроде, правильный».

                                                                                                                                      Поэтому, или вы доверяете корректности уже существующих тестов согласно их коду, но тогда правило «сначала тест должен упасть» вообще теряет смысл, или вы вводите другие методы контроля корректности тестов (в моём случае это инверсии тестов, когда проверяется нарушение выходных данных при заведомых отклонениях входных данных). А в этом случае уже пофиг, были написаны тесты до или после: это вопрос административного контроля качества покрытия тестами, но не собственно их выполнения.

                                                                                                                                      Также с этим напрямую связано, что TDD никак не решает вопрос качества самого тестового окружения. Например, что будет, если в результате сбоя в одном файле assertEqual() станет проверять не равенство результата ожидаемому, а просто наличия результата?

                                                                                                                                      Пригодный к длительному сопровождению (а не к одиночному «хренак, отдали заказчику и забыли») тестовый комплект должен быть таким, чтобы корректность самого тестирования можно было проверить автоматизированно в любой момент без ручного вмешательства. Например, мы вводили инверсии тестов — аналог «мутационного тестирования» именно для кода тестов, в явно продуманных местах. Общая идея: пусть тест ожидает, что если на входе A, на выходе B. Модифицируем код посылки на вход так, чтобы посылалось C, но так, что верхний уровень контроля теста ничего про это не знает. Тест должен упасть (а вокруг него строится другой, который проверяет факт падения вложенного теста). Ошибка инверсного теста у нас срабатывала очень редко, но каждый такой случай означал серьёзные скрытые проблемы в коде.

                                                                                                                                      И с такими средствами исходный принцип TDD про «сначала тест должен упасть» теряет свой методический смысл: что прямой тест работает, а инверсный падает — проверяется в любой момент независимо от того, был ли написан тест раньше кода, или нет.

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

                                                                                                                                      Вы вначале решите, что должен пройти тест для (1,2) и (2,1). OK, сравнили два элемента, прошли. Теперь добавляем третий… четвёртый… двадцатый… во что превратилась функция? В лучшем случае вы получите сортировку вставками (если кодер очень умён), а скорее всего это будет «пузырёк». При совсем тупом кодере это вообще не будет читаемо даже после ста грамм. И Вы никак не получите ни метод Хоара, ни тем более метод Бэтчера. Потому что для них надо сначала реализовать алгоритм, хотя бы в уме, со всеми циклами, ветвлениями и тому подобным, а уже затем тестировать.
                                                                                                                                      Можно сказать тут, конечно, что алгоритм в уме и алгоритм в коде — разные. Но когда вы заранее знаете, какое именно ветвление вы напишете и почему — вы уже действуете не под тест, а под алгоритм. Идея предварительного разделения на два подмассива, как у Хоара, а тем более математически подобранная сортировка подпоследовательностей, как у Бэтчера — тестом не решится.

                                                                                                                                      В вычислительной математике таких случаев ещё больше. Тестирование решения СЛАУ через построение треугольной матрицы — очень хреново ложится на TDD, а тонкие эффекты на долях эпсилона в принципе не могут быть заранее просчитаны.

                                                                                                                                      Следующее — проблема уже состоявшихся требований. Пусть есть изменение ТЗ — добавилось новое требование. Но что будет, если оно уже реализуется кодом? Например, требование — чтобы сортировка была устойчивой — но она уже такая в реализации. Такая ситуация в принципе не покрыта TDD. Решение я уже описал выше — отказ от заложения на важность теста его изначальной неработой.

                                                                                                                                      В каком же случае TDD может идеально работать, и даже быть полезным, в его каноническом виде? Это
                                                                                                                                      1) написание только нового кода, или расширение на безусловно новые требования;
                                                                                                                                      2) полное отсутствие необходимости R&D, весь проект ясен с самого начала (сюда входит и вариант изменения ТЗ на ходу — просто таких начал становится несколько);
                                                                                                                                      3) большое количество низкоквалифицированных сотрудников и аналогичного управления ими, которое способно сэкономить на тестах, но для которого угроза административного наказания за нарушение инструкций важнее проблемы собственно качества выходного кода.

                                                                                                                                      То есть это идеальная технология для классической оффшорной галеры. Антиполюс — то, где TDD способно только навредить — разработка собственного наукоёмкого продукта. (Как раз случай коллеги Jef239, поэтому я не удивляюсь его отношению. И мой случай для всех прошлых и нынешних работ.)

                                                                                                                                      Резюмирую: я никак не против отдельных функциональных тестов всех уровней (от юнит- и до интеграционных верхнего уровня). Они должны быть. Более того, они должны быть и для нормального заказчика (который обязан не верить, пока не покажут работающее), и для собственного контроля. И разработчик должен сам писать тесты на все подозрительные и крайние случаи, и контроль должен это поощрять и требовать. Но требование 100% покрытия и «test first» — это то, что превращает разумный подход в религию.

                                                                                                                                      И ещё один PS — речь не про тесты для прямой проверки ТЗ (я их отношу к BDD, а не TDD).

                                                                                                                                      Чуть сумбурно получилось, но, надеюсь, понятно.
                                                                                                                                      • +2
                                                                                                                                        Каждое из первого и второго не допускает возможности его применения для уже существующего кода

                                                                                                                                        TDD про написание нового кода или изменение существующего. Если принято решение перевести развитие существующего проекта на TDD, то есть два глобальных варианта:


                                                                                                                                        • забиваем на существующую кодовую базу, тесты пишем только под задачи на развитие (новая или изменяющаяся функциональность), рефакторя существующий код без автоматизированного юнит-тестирования регрессий
                                                                                                                                        • перед переходом на TDD покрываем существующую кодовую базу тестами с применением практик из Q&A и прочих "tests last"
                                                                                                                                          Допустимы, конечно, комбинации, компромиссы между этими вариантами, но суть в том, что покрытие тестами существующего кода — процесс ортогональный TDD.

                                                                                                                                        Представим себе написание метода сортировки по принципу TDD тем, кто не знает этих алгоритмов.

                                                                                                                                        Вы при описании TDD забыли ещё один этап при разработке — рефакторинг. Замена пузырька или вставок на Бэтчера — это как раз и он есть: видимое поведение не изменяется, а код оптимизируется по какой-то метрике. Обычно по читаемости, улучшению поддерживаемости, но это не догма.

                                                                                                                                        • 0
                                                                                                                                          > перед переходом на TDD покрываем существующую кодовую базу тестами

                                                                                                                                          Это никак не относится к тому, что я говорил — о проблемах работы с существующим кодом, уже покрытом тестами, согласно TDD.

                                                                                                                                          > Вы при описании TDD забыли ещё один этап при разработке — рефакторинг. Замена пузырька или вставок на Бэтчера — это как раз и он есть: видимое поведение не изменяется, а код оптимизируется по какой-то метрике.

                                                                                                                                          Это не к тому, что я описывал. Во-первых, Вы почему-то предположили, что какая-то сортировка уже была. Ну ладно, примем. Тогда, при буквальном следовании TDD данный вид рефакторинга просто невозможен — его не допустит догма.
                                                                                                                                    • 0

                                                                                                                                      TDD — отличный инструмент для создания легкотестируемой архитектуры с покрытием тестами близким к 100%.

                                                                                                                                      • 0
                                                                                                                                        Угу, как хопер-инвест в рекламе 1993 года. Вот только ленчей даром не бывает.

                                                                                                                                        Если вы меняете архитектуру ради TDD, то вы проигрываете в другом. Как минимум приходится выбирать кристалл с большей памятью данных и кода.

                                                                                                                                        Не спорю, что в 20% проектов TDD дает выигрыш. Речь не о них. А о том, что для остальных 80% — это религия или маркетинговый код.

                                                                                                                                        По вашим же словам:



                                                                                                                                        Так что однозначная выгода от TDD — лишь в ситуации, когда тест дошел до состояния, когда почти любая правка вызывает вторичные ошибки. Вот тогда массив накопленных регрессионных тестов будет сильно полезен.

                                                                                                                                        Все остальное — зависит от проекта. Я, например, больше люблю «assert driven development», то есть агрессивное расставление ассертов с сохранением их в production. В сочетании со структурными исключениями и перезапуском подсистем по возникновению исключений получаем неубиваемое приложение.

                                                                                                                                        Главное — это то, что технологию надо выбирать исходя их технических свойств, а не по шуму хайпа вокруг неё.
                                                                                                                                        • +1

                                                                                                                                          Я не знаком с исследованиями насколько TDD увеличивает потребности в памяти в продакшене. Вы знакомы?


                                                                                                                                          Ну, я выбираю TDD по субъективной оценке технических и не очень свойств:


                                                                                                                                          • не влияет на рантайм (кроме архитектурных решений)
                                                                                                                                          • при разумном применении уменьшает связанность кода (те самые архитектурные решения)
                                                                                                                                          • несёт документирующую нагрузку
                                                                                                                                          • обеспечивает покрытие тестами меньшей ценой чем тесты после кода
                                                                                                                                          • обеспечивает страховку (неполную, конечно) от нежелательных изменений
                                                                                                                                          • –2
                                                                                                                                            Возьмите hello world, замерьте размеры. А потом сравните с рабочей программой в 300 байт кода и 8 бит рабочей памяти (и 20 бит GPIO). Ну и подумайте, насколько больший кристалл вам будет нужен для TDD по сравнению ну скажем с PIC16F57 c двумя килобайтами ПЗУ и 72 байтами ОЗУ.

                                                                                                                                            А выполнять тесты на одном кристалле, а боевую программу на втором — это профанация.

                                                                                                                                            Ну что там верно именно для вашего кода — я не знаю, потому и не спорю. Но…

                                                                                                                                            обеспечивает покрытие тестами меньшей ценой чем тесты после кода

                                                                                                                                            Тесты (что железа, что софта) бывают двух видов. Одни — чтобы доказать, что ошибок нет. Другие — чтобы найти ошибки. TDD дает лишь тесты первого рода.

                                                                                                                                            Пример (чуть утрированный) из моей бытности руководителем группы тестирования на похожем на ваш проекте. Один человек регулярно делает ошибку типа ±1. Ну то есть вообще считает, что «не меньше» — это «больше» (на самом деле — больше либо равно). Программер вполне нормальный, багов не больше, чем у других, просто часты ошибки вот такого типа.

                                                                                                                                            Что у него будет в TDD? Да ровно то же, что и в коде. В тестах он тоже решит, что «не меньше — это больше». И так у каждого, хороший тестер — это психолог, он ещё до тестирования понимает, куда стоит «потыкать палочкой»

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

                                                                                                                                            Но, если, вы хотите качества продукта, то есть несколько «золотых» правил":

                                                                                                                                            • Никогда не тестировать свой собственный код.
                                                                                                                                            • Оценка работы тестеров идет по найденным багам, оценка работы программеров — по тому, чтобы багов было меньше и самой малой значимости.


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

                                                                                                                                            При этом я не отрицаю полезности TDD в отдельных нишах. И сам использовал его больше 25 лет назад (лет за 10 до того, как TDD получил своё имя), при написании электронных таблиц для УКНЦ. Там основную сложность представлял компилятор формул, а придуманный мной язык формул — хорошо ложился на схему TDD.

                                                                                                                                            Но массовое использование TDD, где надо и где не надо — это карго-культ.
                                                                                                                                            • +1
                                                                                                                                              TDD дает лишь тесты первого рода.

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


                                                                                                                                              Никогда не тестировать свой собственный код.

                                                                                                                                              Собственно отличие подхода tests first от других именно в том, что программер не тестирует свой собственній код по сути. Тест написан, а кода ещё нет, есть только декларация намерений написать код, который в таких-то случаях будет вести себя так-то, практически окончательная постановка задачи самому себе в формализованном и, главное, автоматически верифицируемом by design виде. Естественно, что если такая постановка изначально неверная, не соответствует ТЗ или иным ожиданиям заказчика, то реализация тоже будет неверной с точки зрения заказчика, как и в случае если он сам налажал и не смог поставить задачу корректно, не смог описать свои ожидания.

                                                                                                                                              • –1
                                                                                                                                                Это ошибка. Сначала идет программирование (в уме), потом написание тестов, потом кодирование. Пока вы не запрограммировали (в голове) хотя бы интерфейсы, вы не можете написать тесты.
                                                                                                                                                • 0

                                                                                                                                                  Зачем уж так маньячить и слепо следовать "концепции TDD"? Берите оттуда то, что вам нужно. Интерфейсы конечно пишите до тестов, если так лучше.