Комментарии 82
То что писалось с трудом, должно и читаться с трудом
Особенно если по-другому писать не умеешь (это я про себя)
Это вы ещё пороху не нюхали!
А я этот порох в десны втирала!
https://yandex.ru/video/touch/preview/9752723673882598851
На 3й минуте
На днях узнал шокирующую практику среди сеньоров: намеренно пишут запутанный код без комментариев, чтобы стать незаменимыми. Один коллега за 3 года получил 4 повышения и +210% к зарплате. «Только он понимает эти системы». Два разработчика, пытавшиеся разобраться в его коде, уволились.
Те, кто сегодня на острие прогресса в AI, тоже сделали за 3 года +ХХХ%, а их код тоже малочитаемый, если математику не знать.
Не очень понимаю саму проблему - в каждой большой системе где десятки микросервисов код был не документирован и кроме системной аналитики не было никаких пояснений к информационным потокам и никаких комментариев. И всегда от новых разработчиков требовалось погрузиться и разобраться, то что чёрт его пойми как оно вообще может работать никого никогда не интересовало. И никаких преференций обладателям знания не было - менеджмент не интересует чистота кода, больше рынка тебе за его знание предлагать не будут.
Я вообще думал что в каждой компании такая же ситуация и считал это нормой) Сидящих по 5 лет "уникальных специалистов" не встречал.
Если речь про условно обфускацию кода без наличия таких требований, за такие фокусы уважающий себя СТО такого уникума выкинет, а не будет ему преференции давать)) Но конечно если руководство не смотрит код и не занимается контролем аналитики - ССЗБ, в таких местах впрочем и делать нечего
просто юные энтузиасты смотрят на свою работу как на возможность сделать мир лучше, а прожжёные профи - как на способ обеспечить себе достойный уровень жизни с минимальными трудозатратами. и тут стОит внимательно посмотреть, что написано в трудовом договоре, и не лучше ли часть рвения пустить в собственные проекты, в обучение, итд.
и не лучше ли часть рвения пустить в собственные проекты, в обучение, итд.
компания не оценит усилий по чистоте, красоте, понятности и поддерживаемости кода. Ни разу. И не думает, что будет, если сотрудник уйдет. У меня правда, своя специфика.
Но как-то раз я переписал проект с нуля с оптимизацией архитектуры, а задокументировать, и даже откомментировать по-человечески не успел, код читался плоховато. Просто отложил на потом, когда времени будет побольше. Но так вышло, что вскоре после этого в компании произошли некоторые кадровые изменения, к начальнику предъявили новые требования, эти требования были делегированы на меня, и отношения с начальником резко ухудшились. Прям настолько, что премию срезали задним числом, поменяв рейтинги за предыдущий год, с вычетом из зарплаты ранее выплаченного. Ну, я написал по собственному, даже не спросил, кому передать дела и кто и как будет поддерживать тулзы, молча перекинул начальнику, эффективной сове. То, что тот, кто на мое место придет, не справится, я понял уже в первую неделю, когда стали звонить девочки-операторы и просили помочь. Я, конечно, проконсультировал мужичка, куда смотреть, но без фанатизма и попросил больше не звонить в рабочее время, так как уже на новой работе. Но с другой стороны - я больше года своими костылями закрывал операционные дырки, которые появились у фирмы в связи с уходом многих программ с рынка из-за санкций, но спасибо не сказали, сказали, что я деньги получал за красивые глазки и авансом. Я знал, что чувак, который после меня придет, намучается, чувака было жалко. Но ничего личного - какой монетой платите, такой и вам отплатится. Вы лишили меня месячного заработка, я, не озаботившись нормальным хэндовером, перевел как минимум на две недели работу ваших операторов в ручной режим и замедлил отгрузку. по 5 складам
Да нет. Это йуный энтузиаст не очень понимает, что сложный код написать проще, а простой — сложнее. «Ребёнко открывает мир», но пока ещё только начинает.
Поэтому если фигачить погонными метрами, то hello-world-enterprise-style вырастает сам собой. Более того, корпоративный cookie-cutter — шаблонизатор новых проектов, скорее всего, генерирует что-то подобное по-умолчанию. Зато собирается, встраивается в корпоративную систему сбора ошибок и тд. :-)
хз, мне писали благодарности бывшие сотрудники, уехавшие, например, в Австралию, говорили, "ты учил нас, святой человек, а тут если кто-то из бородатых мужиков что-то умеет, то он это пишет на голом c без комментариев и никому не отдаёт", правда область - анализ данных, не совсем разработка, но я о таком именно феномене писал выше.
иногда от коллег помладше код бывает более запутанный. А если писал сеньор, то другой сеньор разберется. а если не может разобраться, то скорее всего просто не сеньор. по своему опыту в своей области не встречал кода, который бы не мог понять / разобраться. Поддерживать его - это другой вопрос, бывает проще переписать кусок, это да :)
по своему опыту в своей области не встречал кода, который бы не мог понять / разобраться
Есть инструментально-зависимый код. Хорошо, если код императивный. Сиди, и ковыряй с отладчиком. Но код может быть написан под некий сдохший фреймворк с утраченной документацией. И вот тут могут быть сюрпризы. Ковыряешь код, а он БАЦ, и диспетчеризирует сообщение. А вот дальше уже разбираешься не в коде, а с фреймворком, чтобы понять, где же ответная часть, которая это сообщение отрабатывает.
если не может разобраться, то скорее всего просто не сеньор
Вот я и думаю: откуда вокруг меня столько ненастоящих сеньоров?
если не может разобраться, то скорее всего просто не сеньор
Кто из этих двоих — кто написал, или кто пытался прочесть? :р
Встречалось и не раз. Но всегда тут идет речь о незаменимости. Есть просто люди такие...
Я работал с такими людьми пару лет назад, они даже не скрывали этого. Дело было в «студии» а-ля Sweatshop, которая выполняла задачки для разных заказчиков. Один из заказчиков эту студию полностью и выкупил. Разработчики писали код как можно сложнее и запутаннее, чтобы заказчик не мог уйти от них, как видно сработало.
Я старый (47 лет) сеньор SQL/BI/Python. Моя суперсила - разгребать легаси код. Это г...о точно не специально так писалось. А если юный сеньор хочет всё выбросить и написать лучше, то флаги и барабаны у меня давно кончились.
Поделитесь суперсилой
Стратегия разгребания легаси в чём?
зачем разгребать легаси если можно лутать деньги + всегда ссылаться на "да там легаси" и завышать сроки, круто же) а ещё есть так делать на несколько работ одновременно то вообще кайф
Два разработчика, пытавшиеся разобраться в его коде, уволились
В конечном счёте можно разобраться в чём угодно. Сам имею опыт копания в недокументированном легаси со спагетти-кодом, в процедурном стиле и прочими неудачными плюшками. Разбираюсь после того, как всё-таки незаменимого программиста подвинули. Часто ловлю себя на мысли: можно было бы переписать, возможно быстрее, чем разбираться, что оно делает. Но тут никто не знает, что оно делает.
А так процесс очень похож на складывание пазла. Вначале стойкое ощущение, что в этом невозможно разобраться, но потом приходит насмотренность, и понимание, как эти кусочки вместе складывать.
Я обычно просто расставляю развесистые комментарии.
Тут еще от ситуации зависит, если начальство на все это смотрит с пониманием, можно спокойно сидеть, ковырять, потихоньку "распутывать узелок".
А если типовая ситуация когда надо все сделать вчера иначе минус премиальные или еще что, то нафиг оно надо.
Часто это бывает и без злого умысла.
Понятно, что такое подход - не есть хорошо, но знаю нескольких таких людей. Они потом сами год спустя не понимает как это все работает...
Реальность скучнее и страшнее.
Нет никаких суперзлодейских разработчиков, которые держат на коленях белого кота, с хитрым прищуром потирают ладошки и смеются: «MWAHAHAHA!!! Сегодня я запутал код на 146%!». Точнее сказать, они есть, но в виде исключения. Я, кстати, такого встречал. Человек делал отступы в три пробела (и жалел, что нельзя делать три с половиной), и заменял все условия на тернарные операторы. Ему, правда, это не помогло, и его всё равно уволили.
А вот, что происходит в реальности.
Сеньоры говорят: нам не надо использовать DSL'и, мы всё будем писать гомогенно, на C++. А то наймут нам обезьяну, которая будет писать некоторые части на JS, зачем это. Если же всё писать на C++, то и нанимать будут только тех, кто владеет C++. А человек, владеющий C++, глупым быть не может, и так мы обеспечим высокий профессиональный уровень команды. Более того, так мы сохраним контроль над хайрингом.
Это всё говорится не шёпотом в туалете, на ухо, при включённой сушилке для рук, а в открытую, на совещаниях. Директора слушают и кивают: да-да, профессиональный уровень команды, очень православно.
Другой пример. Приходит новичок на проект, смотрит в код и говорит: ребят, но это же СВИНАРНИК. Всё запутанно, и без комментариев. Давайте я хоть прокомментирую, всё равно же буду разбираться. Ему говорят: нет. Ты плохо понимаешь проект, твои комментарии будут говном. Подожди годик.
Проходит год, человек говорит: я разобрался, и всё ещё хочу написать комментарии. А ему говорят: теперь ты один из нас, и понимаешь всё без комментариев. Зачем тебе это? Иди лучше полезное что-нибудь сделай! А то мы все делаем что-то полезное, а ты, получается, не хочешь, да?!
Как-то так. И много как ещё. Причём, чем громче в коллективе высмеивают вслух тех, кто путает код, тем сильнее проявления того, о чём написано выше. Какая-то закономерность прямо.
MWAHAHAHA!!!
теперь ты один из нас!
Человек делал отступы в три пробела (и жалел, что нельзя делать три с половиной), и заменял все условия на тернарные операторы. Ему, правда, это не помогло, и его всё равно уволили.
Какой эпичный идиот.
ты один из нас, и понимаешь всё без комментариев. Зачем тебе это? Иди лучше полезное что-нибудь сделай!
Как это знакомо... Очень зависит от начальства - понимает ли оно важность рефакторинга. Что "технический долг" лучше платить побыстрее, а не копить, пока он не привёл к банкротству проекта. Некоторые понимают. Но не все.
Многие компании просто не понимают, что код для людей, а не для машин, легко читаемый, с документированными неявными зависимостями - это инвестиция. Она окупается через пару лет, когда меняется команда. Два месяца в начале экономят несколько месяцев на разгребании тех долга в конце. Но тайм ту маркет для многих берет верх над разумом. Думают, что потом найдут сеньоров за 5x и перепишут. Но это может и не быть так.
Я всё-таки дам ссылку на свою статью
В каждой статье про рефакторинг и сопровождение должна быть эта картинка
Скорее как в поговорке.
"Миром правит не тайная ложа, а явная лажа".
К сожалению сложный и запутанный код получается сам собой, из-за процесса, эволюции и сложности задач.
Иногда это просто история компромиссов.
Да, но регулярный рефакторинг мог бы с этим бороться. Разработчики со временем растут, лучше понимают как своё ремесло, так и предметную область. Могут переделывать код в более лучший, если им дать на это ресурсы.
"Съесть-то он съест, да кто ж ему даст?"
Рефакторинг с точки зрения руководства выглядит так: "Мистер Начальник, дайте нам время и сто тысяч долларов, и мы сделаем так, что система будет работать так же, как и сейчас".
Я обычно объясняю необходимость документации, рефакторинга и т.п. таким образом - если мы это не делаем, то стоимость внесения изменений (багофиксы, новые фичи и т.п.) начинает работать по экспоненциальному закону вплоть до запуска процесса бегства разработчиков с корабля.
Даже те, кто изначально писал подобный проект с отвратительной архитектурой, и как бы все в нем знают - все равно в итоге в это упираются, что сами начинают бороться со снежным комом, который уже больше их самих. Видел такое не раз, приходилось потом за ними исправлять..
Но если этого не сделать то завтра код нельзя будет поддерживать и наращивать.
Хотя, у менеджеров горизонт планирования до годовой премии в лучшем случае.
Мы с коллегами обычно объясняли начальству, что в это "говно мамонта" впиливать новые фичи просто невозможно без риска, что всё вообще сломается в любой момент. После рефакторинга будет легче пилить новые фичи, фиксить баги и в целом поддерживать проект. Начальство вполне этим проникалось.
Рефакторинг только снимает заусенцы, чтобы не очень кровь шла.
Самолёт из танка напильником не сделать. Хотя анекдоты такие есть.
Тут кстати помогает ротация - когда новые люди заходят на проект и оценивают все свежим взглядом.
Они разумеется будут рассказывать какое г понаписали синьоры предыдущего поколения. Но это чаще конструктивная критика, ради которой, собственно, все и затевалось. Важно дать им довести свой рефакторинг до конца, а потом можно тоже менять.
Через несколько итераций вы получаете код, который сможет поддерживать кто угодно. Ну либо абсолютно неподдерживаемый венигрет, если вам не хватило управленческих скиллов и процесс отбора решений был пущен на самотёк.
Это понятно.
Самое важное в рефакторинге то, что с ним ты можешь оперировать послезнанием - делать точки расширения, переиспользовать что-то или декомпозировать когда нужно, а не когда хочется (или кажется, что хочется).
Но кто же на это времени даст. Так и остается по чуть там, по чуть тут, и коллекционировать шаблоны, которые вызывают поменьше проблем для следующих проектов.
Сложный код имхо пишется в трех очевидных случаях:
Сложный случай, который по-другому не сделаешь. Зачастую такой код получается за несколько итераций, когда находятся баги и приходится добавлять доп. условия и обработку в код. И он из красивого начинает превращаться в мешанину
Хочется понтануться и показать себя крутым кулхацкером, который умеет в монады и теорию категорий. Когда изучил новомодную игрушку и хочешь ее повсюду пихать.
Ты шизик и у тебя такая картина мира, которую простые смертные не смогут никогда понять - а если поймут, то привет санитары :)
Сам вот был таким плохишом пару раз неспециально. Первый после укуса Александреску - наметапрограммировал на C++ так, что напарник сдался, а потом и я сам через полгодика. Пришлось код на один экран переписать и получить в 4 раза больший, но понятный.
А второй случай был, когда мой обычный C++ код перепаковывающий бинарные данные переписали на более высокоуровневом языке с ООП, поскольку подозреваю что просто не знали С++. Ну в результате пару секунд работы программы превратилось в четверть часа - и так сойдёт :(
В нашей команде меня называют сеньором, тимлидом и т.д. Именно с меня спрашивает руководство по работе команды. Всё что написано в статье - всё правда.
1. Я дроблю свои таски на субтаски, потому что я предпочитаю потратить час-два на анализ задачи и "на бумаге" её решить. Иногда я это делаю для кого то, но стараюсь не делать. Ведь анализ задачи это часть работы программиста.
2. На встречах чужие задачи у меня часто получают комментарии "Да это очень просто ". Собственно потому что моя задача чтоб все работали, потому беру сложные таски себе. Очень часто это задачи архитектурные, которые часами решаются на бумаге. Я руководствуюсь желанием решить задачу, а не закрыть таск - время исполнения может различаться в разы.
3. Я пишу запутанный код без комментариев. Потому что если разработчику нужна документация к интерфейсу *Стратегия, то ему не стоит делать в этой части правки.
4. Руководство всегда интересуется моим мнением, потому что в прошлом новые разрабы уже проталкивали свои идеи. A я не говорил "я ж говорил" и возвращал проект в стабильность. Потому что на соседнем проекте уже в 4ый что то переделывают (React->Angular, Mongo->SQL, Java->Typescript...). Поиск серебряной пули - знаем, переболели.
5. Я пушу срочно в продакшн. Собственно у меня кнопка, которая запускает билд в прод. Мне доверили прод, я знаю цену ошибки и цену "простоя". Я принимаю решение и если что то срочно ушло в прод без ревью - значит такое было моё решение. Код, кстати в гите.
6. У меня "нет времени" искать способы объяснения которые бы понял именно ты. Я ценю своё время, охотно делюсь опытом. Но это мой опыт, а могу им лишь поделиться, я не могу тебя научить или заставить взять то с чем я делюсь. Мне кажется что вот эта статья хорошо описывает вопрос. Да, вдумчивого чтения на пару часов. Нет, у меня нет видео. Рассказать в двух словах? Так вот же бумага и схема - при тебе рисовал.
7. "Давайте добавим в проект либу А" - скорее всего я отвечу "не надо". Я знаю что эта за либа, я знаю какие аргументы сейчас будут озвучены, я знаю что мои контраргументы будут проигнорированы. Но билд станет больше и дольше, поддержка сложнее, риск поиметь несовместимость и всё это ради экономии 20 строк? Не надо.
Очень много "зашедших в айти", которым BigO уже сложно - они будут жаловаться что я пишу плохой код. Много людей, которые еще до собеседования знали что идут сюда ненадолго - копят техдолг и сваливают в закат. Не мало айтишников, гуру фреймворка ХХХ, который я не знаю, но спотыкаются об очевидный race condition. Я могу быть не прав, но в айти выбор между А и Б чаще всего это как выбор между Windows и Linux и поэтому решать должен опыт, а он у меня есть.
Запутанный код без комментариев неявных зависимостей может выстрелить, когда тебе самому в нем надо разобраться через год, или делать передачу знаний следующей команде.
Вы абсолютно правы, однако вы ответили на мой комментарий и я предполагаю на пункт 3. В общем то весь мой комментарий это легкий сарказм. Основной посыл в том, начинающие программисты не понимают работу сеньора и делают выводы. Например, не зная, что такое стратегия кажется очевидным что код запутан, в него намеренно добавлено 10+ классов по <10 строк и всё это легко можно удалить и использовать 10+ switch/case там где надо.
Джуниоров легко научить пользе DI, если попросить их писать юнит тесты, и показать, что хорошее именование переменных, DI и некоторые паттерны сильно облегчают работу с абстракциями и взаимодействием частей. Тут самое главное не переусложнять там, где это не нужно (это очень любят делать новоиспеченные сеньоры). У меня чаще всего получалось, по крайней мере. Но лучше всего писать такой код, чтобы джуны могли делать по аналогии, и вся сложность была скрыта внутри. А им оставалось только накидывать лямбды да по шаблону добавлять логику. Не всегда это возможно, но когда возможно всю сложную работу (в том числе параллельный процессинг, всякие тонкости работы с базой и прочим) перенести внутрь - это идеальный вариант. Получается deep interface vs shallow interface, если следовать терминологии книги "A philosophy of software development".
Например, не зная, что такое стратегия кажется очевидным что код запутан.
в него намеренно добавлено 10+ классов по <10 строк и всё это легко можно удалить и использовать 10+ switch/case там где надо.
И, возможно, совершенно верно считают. Потому что сам это паттерн - оно в значительной мере костыль против ограниченности языка. Которую, поди, уже давно починили и во многих случаях оно легко заменяется на вызов по указателю на функцию (ну или эквиваленты в виде лямбд и прочей функциональщины). После чего все эти 10 классов успешно пропадают и остается просто коллекция методов/функций в какой-нибудь контейнере.
Тут есть два варианта:
1. Условный "он" не знает что такое стратегия, точно также он скорее всего не знает эквивалент в виде лямбд и прочей функциональщины.
2. "Он" знает и хочет поменять А на Б. И я знаю чем это закончится. В проекте долгое время будет местами А, местами Б, плюс двойной набор зависимостей, большой техдолг, потому что поменять на Б оказалось местами сложно и "проще переписать с нуля", времени будет потрачено много, а другого не дают. Я, конечно, могу оказаться не прав, но я столько раз оказывался прав да и самую малость умею в риски.
А какая тут дискуссия?
Всегда так делаю - зп подняли уже в 40 раз!
Даст бог, скоро домик сладим, да вторую яхту прикупим!
Я вам больше скажу. ООП специально придумали чтобы все усложнить. Сроки разработки увеличить, и лупить в разы больше денег с заказчиков.
Дерновенно дерзну высказать моё частное мнение.
Имхо, важен вопрос: "почему люди пишут непонятный код или текст?"
Мой ответ: по трём причинам.
1) Человек пишет непонятный код/текст, потому что пребывание в корпоративной среде небезопасно, любого могут в любой момент вышвырнуть за дверь, оштрафовать или понизить. Поэтому даже на подсознательном уровне у разработчика (аналитика, тестировщика, техписа и т.д.) возникает желание создать область недосказанности настолько большую, чтобы увольнение этого сотрудника автоматически бы нанесло фирме существенный ущерб без каких-либо дополнительных мстительных усилий со стороны увольняемого сотрудника.
Следовательно, в этом случае появление сказочного и магического кода/теста/текста/знания - это ответственность руководства и менеджеров, именно они не создали безопасную для работы среду, каждый ходит под страхом увольнения, ибо жизнь в таком колективе непредсказуема и жестока.
Такие преднамеренно созданные области недосказанности (в коде, в тестах, в постановочной и технической документации) имеют свою неявную цену для компании: время на вхождение в тему нового разработчика, техписа, аналитика, тестировщика.
Я для себя это формулирую так: работодатель платит за свою спесь, за своё право вышвырнуть человека в любой момент, - платит управляемостью бизнеса и деньгами.
2) Человек пишет непонятный код/текст, потому что хочет власти и роста в иерархии, хочет, чтобы от его эксклюзивных знаний зависели другие и ходили бы к нему на поклон.
Опять-таки, это зона ответственности управленцев: выстроить понятную и безопасную как для компании, так и для сотрудников, ясно описанную карьерную траекторию.
Если нету ясных общих правил роста, как в должности так и по зарплате, то неизбежно будут возникать князья, владеющие своими кодовыми вотчинами эксклюзивно и требующие за это власти в разных её выражениях.
3) Человек пишет непонятный код/текст силу сиюминутных обстоятельств, срочности, неполноты постановки задачи, а потом вступает в свои права корпоративная культура "работает - не трожь, рефакторинг - блажь". Здесь играют роль сжатые сроки, отсутствие код-ревью и прочие факторы, которые в целом можно описать как "невыстроенные процессы". Невыстроенные процессы управления качеством позволяют писать такой код.
То, что процессы управления качеством разработки/тестирования/документирования не выстроены, - это зона ответственности техдиректора, начальников отделов и тимлидов, предполагаю.
Как правило, руководство давит только на 3-й пункт, считая возможность играть людьми и глумиться над ними, держать их в страхе, стравливать друг с другом и через это управлять, - считая это своим священным правом.
Пункт 2 в лучшем случае спихивают на отдел HR, давая на задачу микробюджет и никаких полномочий. "Обеспечьте нам ясный карьерный трек".
Пунктом первым руководство, как правило, не занимается, потому что какие-то гарантии для сотрудников влекут за собой обязятельства (хотя бы на словах) и самоограничение для руководства. Именно руководство т.н. корпоративный дух. Бывают компании, в которых царит дух уважения и дружелюбия. Бывают компании, где душно, где руководство устраивает крысиные бега для сотрудников.
Каждый способ управления имеет свою цену, плюсы и минусы.
Мой поинт в том, что, если человек пишет магический код/тест/текст, то всегда имеет смысл поинтересоваться - в каком людском окружении исполнитель находится и как им управляют.
Стараюсь писать код, что бы не было стыдно, если кто его увидит.
Лично писал такой код)) Но проблема была не в моих способностях или намерениях, а в том, что за этим апи скрывались железки с достаточно мутной документацией, в том числе с ответами по e-mail, и я в некоторых случаях даже не представлял, к чему приведёт несколько вызовов апи. И какие комментарии или документация тут помогла бы разобраться в том, как это работает?) Код причём на верхнем уровне был несложный, а вот внутри такое разнообразие поведений возникало.. Да и желающих не было туда соваться)
Ещё у нас был функционал, в котором эээ.. собиралась группа отнаследованных объектов каждый со своей наследованной стейт машиной, которая обрабатывала и трансформировала евенты. И ещё схема для группировки такая же. Те, кто это писал, точно это делали не для какой то джоб секьюрити или графоманства, задокументированы были тольао принципы, комментировать бесполезно, просто сложная функциональность, а её имплементация свою сложность впоследствие оправдала.
В общем со статьёй согласен только в плане того, что сложный и запутанный код бывает что пишут)
Очередная история, как бизнес в попытках сэкономить создал в команде нездоровый басфактор. Сеньор на проекте должен быть не один, между ними должна быть здоровая конкуренция, а в процессах должно быть обязательное ревью кода и активности по обмену знаниями.
Из жизни:
Сеньор, выдыхая:
- Комментарии в коде - это круто!
Мимо проходящий начальник:
- Это ты к чему?
С: Да вот багу ищу, она где-то в этой либе, которую я и писал.
Н: И что, прочитал комментарии и понял, где может быть бага?
С: Да в том то и проблема, что тут никаких комментариев нет. Комментарии - это круто!
1) Рефакторинг.
2) Взаимный код ревью.
3) Выполнение всех рекомендаций IDE (IDEA/GigaIDE сейчас формируют многие конструкции).
Стараюсь следовать всем трем принципам.
Вообще непонятная проблема конечно, главное чтобы деньги платили и как можно больше и при такой схеме можно и нескольких работах работать, а "сложный код" лишь поможет
Да ну ни к чему строить теории заговоров. Во многих случаях сам бизнес не даёт времени на документирование кода. Вот с этим я сталкивался неоднократно. Впрочем пару раз я сталкивался со "специалистами", работающими по принципу "это йожег, и он тут живёт".
Дискуссия: сеньоры в некоторых случаях специально пишут запутанный код, чтобы стать незаменимыми в компании