Андрей Аксенов делится трудностями в подготовке слайдов для доклада. Это — расшифровка выступления Highload++ ^[1].

Если видите этот слайд – я не очень успел картинки. Пришел Бунин, убедился, что у него докладчик не пропал и задал подлый вопрос. Мы заранее готовим конференцию, 1 сентября приём докладов. Я тоже хотел заранее подготовиться. Вчера в 6 вечера начал рисовать слайды для другого доклада, а для этого в 11, поэтому вот так.

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

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

Возможно это федеральное преступление и меня ФСБ заметёт сразу после того как я со сцены выйду. Рискнем, заодно познакомлюсь, поехали.

Про что доклад?

Он с одной стороны про плохой код и про плохую архитектуру. Потому что навеяла мысль сделать доклад про плохой код и плохую архитектуру, в момент, когда я прочитал пост на форуме с вопросом: «а как у вас в компании организован аудит качества и review кода?».

Хороший вопрос.

Мы не знаем хороший у нас код, плохой у нас код. Архитектура эта еще непонятна, тем более. В момент, когда мы никак это не проверяем. Кто-нибудь код проверяет? Хоть кто-нибудь в код смотрит? Или чисто write only? Или я попал в ад, и почти все тут пишут на Perl, кроме вот этих двух. Они old-school и пишут sendmail.cf, причем руками. Все остальные исключительно write only языки, на read only языках никто не пишет. Или кто-то всё-таки review’ит?

Довольно большой процент покрытия. Остальные либо не review’ят, либо не палятся. Возможно я попал на сильно депрессивный форум, на котором исключительно русский человек, который если счастлив, то бухает и ничего не напишет. А если несчастлив, то поделится своей болью со всеми. Поэтому все отзывы вот такие. Review вообще не видел за карьеру, в лучшем случае CI есть, тесты есть. Зачем review код смотреть? Его в собственной команде то никто не смотрит, да и дорого и времени нет. А если компания большая, то чтобы кто-то из другой команды посмотрел код другой команды, так это вообще невозможно.

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

Всё есть вроде, а счастья нет. Все равно сплошной говнокод. Одно из двух, либо счастья нет нигде, либо счастливые на форуме не пишут. Есть счастливые-то? Типа да, вы внедрили code review, у нас идеальный код и идеальный архитектура. Один счастливый человек. Остальным то ли похвалится нечем, то ли стыдно если выбрана такая минорная тональность. Не может такого быть. Я не верю.

Я верю в то что где-то в природе все-таки есть мегапроекты с хорошим кодом, можем быть не безупречным, но хорошим и безупречной архитектурой.

Надо же ставить высокую планку. Кто-нибудь знает хорошие проекты с идеальным кодом и безупречной архитектурой?

Давайте топ 3. Мы все знаем определенный топ 3. Любимые покемоны, плохая тема, я никого не знаю. Пикачу покемон? Знает кто? И про покемонов никто. Строим внутренний список.
Nginx, еще? Какие-нибудь ещё гипотезы?

С этим можно работать, но нужна определённая коррекция: четвёртая версия сфинкса. Третью я начал писать, она публично не доступна, но она реально существует, я могу достать ноутбук и показать, она там есть.

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

Я сумел вспомнить несколько проектов, понятное дело не из тех, над которыми работал, это было бы слишком хорошо, при взгляде на которые чувствуется «Вах! Кабаны писали». Я вспомнил, честно говоря, один и более того на всякий случай, плюс потому опять же ленивый и в последнюю секунду готовился не стал пересматривать этот код сегодня, и чтобы не очернять такие воспоминания детства, двадцатилетней давности, когда я читал исходники Doom’a, Quake’a и так далее. Единственное приближение к списку под названием «где-то ж в природе есть, наверное, клевый код, безупречная архитектура, ля-ля три рубля». В качестве приближения, наверное, исходники старого ID Software могу привести, такая вот личная профессиональная акцентуация или грех молодости, как назвать, но как бы их даже не чувствую за собой технической возможности в мега список внести.

Правда, возникла гипотеза про nginx.

Есть ли Сысоев в зале? Не палится.

А есть ли nginx’ы в зале? Опять не палятся.

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

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

Но опять-таки, мне кажется, что мы в среднем мы знаем вот такие три проекта.

И конечно же IDTech, но это было 20 лет назад. Помните все те времена, когда 286 компьютер, шлем VR1 и разрешение 320х200 и исходники Doom и ты их как бы читаешь и не знаешь с какой руки изучать чей код: с левой руки изучаешь кармака, с другой абраша и молишься на этих двух богов. Больше таких откровений от кода в жизни не происходило. Более того, если призадуматься над сложным вопросом под названием «где же мы видели идеальный код и хорошую архитектуру?». И вспомнить про свои собственные ped проекты, хрен с ними с рабочими, ты там как бы не виноват, ты там, наверное, один.

Программисты кстати интересные люди, и я том числе будь оно проклято. Нормальный человек имеет хобби: работает охранником, а хобби водку пить, ну норм в принципе, это мой план на пенсию. А программиста у него есть проект на работе, а хобби он дома приходит и тоже что-то пилит. Причем иногда случается так в gamedev’e было повсеместно, что чувак на работе пишет движок, но на работе он пишет говно, это знает он, это знает вся команда, и даже продюсер, который все это финансирует со стороны издателя о чем-то немножечко догадывается, но поворачивать назад уже нет никакой малейшей возможности. Но его как ломает совершено и от того что он говно пишет, он приходит домой и пишет, что? Правильно — движок для игры, но в лучшем случае для другой. Не шучу, в gamedev’e почему-то такая фишечка под названием «чего-то мне не хватает на работе, пишу на технологии А днём, а прихожу домой пишу на технологии Б». Она была решительно не распространена.

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

Как же так получается? Случается, так понятно откуда. Неизбежный жизненный путь, который обусловлен тем, что человек рождается совершенно без мозгов, потом у него постепенно объём мозга ^[2] увеличивается и совершенно без знаний в этих мозгах, и соответственно должен проходить несколько стадий заполнения этих мозгов.

Для того что бы что-то получалось с конкретной штукой, будь это язык программирования, новая клёвая технология или хотя бы умение красить кисточкой заборы. Неизбежно ты проходишь 3 стандартные стадии: не умею «копать», научился «копать» и чувствуешь внутренний душевный подъем от того что «да-да овладел новой мегатехнологией, теперь я могу «копать», я лучший копальщик мира, все фонари на меня». И в тот момент, когда ты все это изучил ты можешь этой лопатой сделать все: картину нарисовать, собор построить, что угодно.

После изучения второй технологии, третьей и даже десятой становится ясно, что еще можно не «копать». Это важный момент я хотел бы заострить на нем внимание. Бывает так, слава богу не поголовно, что люди фиксируются в развитии на стадии, умею «копать». Натурально умею писать на С без крестов, так чтоб никого не обидеть сильно, и все. На С писать умею, на С++ писать не умею, а на другие языки я смотреть не хочу, везде буду писать на как на С. Даже если партия заставит, и компиляторы С умрут все поголовно, им придётся идти какую-нибудь ненавистную компанию где все на java пишут, буду на ней писать, как на С, рукой разрушать объекты. Я ж привык, мне нравится.

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

Второй важный обуславливающий момент то, что ты на подъеме, ты о-го-го, тебе лопату в руки дали, теперь мы из этой лопаты ух заживем теперь. В момент, когда у тебя такая лопата, тебе даже когда новая какая-то появилась как-то не с руки думать о том, как же надо. Первого шага под названием «блин, посидеть бы подумать, что возможно не лопатой здесь яму копать, нам все-таки столб просили сделать». Если мы яму 100х100 выкопали, мы такой могильник соответственно 100х100 возведём это не совсем по ТЗ. Мыслей об этом не возникает, нам только что дали лопату, не дай бог такому человеку экскаватор в руки дать. Еще реже это воплощается в жизнь мысли, даже если она внезапно и промелькнёт в тупой башке. И понятное дело, даже если она вдруг промелькнула и дошла до стадии «не мы все-таки попробуем в жизнь воплотить», до конца не доходит никогда. Отмазки совершенно стандартные — это всегда долго, всегда дорого и зачем этим вообще заниматься, тяп-ляп и так сойдёт. И как бы вот эта известная книга, здесь должна была быть картинка про «херак, херак и в production».

Ну ладно, мотивационный спикер, второй день, уже послеобеденная зона, понятное дело я не могу про C++ рассказывать в данный момент. Я только мотивационным спикером могу работать.

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

Представим на минутку, есть святая Библия. Лично боженька дал десять заповедей: не убий, не укради, и конечно же не пользуйся singleton’ами. Человек пользуется singleton’ами, православный или мусульманин? Не пора ли его на костер? Сразу крестовые войны, костры и всё хорошо. Внутри каждой конкретной группы. Слева православные, справа мусульмане, сверху буддисты взирают меланхолично и косточками от вишен плюются. Внутри каждой социальной группы которая внешним образом успешно задана клевые заповеди, типа святой библии. В принципе всё хорошо, иногда конечно война с другой социальной группой. Так то все нормально. Но к несчастью и этого нет. Или если есть, то оно очень сильно фрагментировано. Слишком много групп, а каждая группа маленькая.

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

Как это добиться? Что такое хорошо? Я не знаю, что такое хорошо, реально не знаю.

Что могу сделать? Это попытаться это определить.

Вот смешная цитата в тему от project-менеджера.

Есть еще вот такое дзенское определение. Что хорошо, это когда не плохо. То есть когда плохо, это еще не хорошо.

Меня не жарят на костре, с одной стороны это уже не плохо, но не обязательно от этого хорошо.

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

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

Для особо въедливых читателей, которые заранее готовились к конференции, ведь есть такие, хоть один. Которые читали абстракт, в котором было написано про идеальный код, который прост, элегантен, самодокументирован. Теоретически, в неживой природе существует, наверное, в книгах Кнута и написан на малоизвестном языке mix, literal programming. Там всё изначально придумано ради того, чтобы самодокументировалось. Безошибочен понятное дело. Найдите ошибку Кнута, он лет 40 их ищет. Одна с ним проблема, что это код не существует в принципе вообще никогда, за исключением книга Кнута. Там написано ровно одна production программа написана.

В любом случае это не конструктивное определение, мол пиши просто, элегантно, самодокументировано и т.д. Посоветовал, спасибо капитан.

Идеальную архитектуру конструктивно определить тоже сложно. То есть мысль останавливается примерно на классической метрике wtf/min. Далее это одна мечта чтобы тебе к этому wtf/min натурально не поставили микрофон вокруг qbicle и не привязали твой бонус годовой к wtf/min.
Тут сразу начинаются интересные политические игры, можно бегать, подбегать к чужой двери и орешь wtf много раз и врагу срезали годовой бонус. Было бы интересно, с точки зрения team building, но не то.

Что такое идеальный код? Знает ли кто-нибудь?

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

А идеальная архитектура? Тут хотелось написать много слов, на предмет того что она бывает очень разной. На счет сразу ясен, у меня сразу возникли сомнения. Архитектура, которая сразу ясна средневзятому человеку, который может удерживать в голове примерно 7 вещей, а восьмая теряется. Как известно из анекдота, три шарика, второго сразу не было. Требовать при этом от архитектуры чтобы она была сразу вся ясна для минимально большого проекта, хотя бы длиннее 200 строк, как-то довольно странно.

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

Какой-то ужас. Почему так? Почему именно такие странные выводы, под названием «сразу ясен и не мешает»?

Потому что средний рабочий день программиста без совещаний, устроен вот так:

С совещаниями, синее заменяется на совещания.

Не надо думать, что менеджерам живётся лучше. Дело в том, что рабочий день менеджера устроен так: все залито синим, легенда — это совещания, а хочу я писать код. Это менеджер, который вышел из программиста вышел. Понятное дело, что зада любого нормально программиста в данной сложной ситуации это быстрее, эффективнее, клевее ковырять говнокод и перекидывать за стену 10-20-30 тонн угла. Потом в конце ты умираешь и улицу Стаханова называют в твою честь. Нет.

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

Какие операции мы обычно выполняем при ковырянии говнокода?

Сидишь и думаешь, что бы сделать. Примерно 90-99% уходит не на то чтобы написать новый клёвый код, от которого начнёт исходить сияние, и компания заработает первый триллион. 90-99% времени уходит на то чтобы разобраться в этом коде. А его много, найти ошибку или найти место где необходимо внести изменения или ещё что-нибудь в это репозитории и сделать необходимые изменения. К несчастью, анекдот старый добрый про удар молотком один рубль знание куда 99 рублей. Он до изобретения программистов был вполне актуален, с изобретением программистов так и вообще. Удары молотком бывают очень смешные. Я помню клёвые ачивки под называнием «я две недели что-то доблестно исследовал, ловил баг проводил эксперименты, писал километровые логи», выхлоп одна строчка в минус. После этого чудобаг исчезает.

Чтобы ускорить эти увлекательные археологические взыскания, хотелось бы делать две штуки. Во-первых, тупо быстрее читать локально. Есть какая-то простыня определённая, в зависимости от того, у кого какая скорость чтения, размер монитора и прочая атрибутика, разный контекст. Тот кусок кода, с которым ты сейчас работаешь, его хочется уметь быстро читать и более-менее понимать.

Но это к несчастью не всегда влияет архитектура общего глобально приложения, у нас 300 мегабайт кода, которые завернут в микросервисы. У нас часть гоняется под виндой, потому что именно там определенный проприетарный софт, вокруг него какой-то wrapper на .net’e, и он отдает данные по http, json, миллион ключевых слов. Emc это малая часть стэка, еще у нас клёвые production сервера, на solaris’e. Почему на нем? Потому что админам очень нравится профайлить, а программисты не могут продавать чтобы мы убили этот solaris. Стэк может быть большой, общий стэк, общего проекта и т.д. Локальный контекст всегда достаточно маленький, иначе он просто в голову не поместиться. Контекст не хочется держать в башке, я не могу помнить ни 20 мегабайт кода проекта, ни 2 гигабайта кода проекта, ни даже 200 килобайт кода текущего модуля, я помнить не хочу, я хочу уметь занырнуть в них, мгновенно всё понять и вынырнуть.

На это влияет нехитрый список из 4 штук:

1. Оформление этого всего дела, чтобы скобочки и переводы строк не мешали читать
2. Толковый naming
3. Компактность кода, там, где нужна одна строчка, не должно быть написано 30
4. Наличие либо отсутствие комментариев, не всегда они нужно, но местами нужно так, что хочется задушить того, кто их не написал.

Чтобы тупо быстрее понимать, как оно глобально устроено и каково места этого куска кода в глобальном большом проекте на 20-300-5000 мегабайт исходников, внезапно нас кусает в попу архитектура. У нас появляется совершенно другой набор требований.

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

Момент опять холиварный. У кого-то в этот момент возникать эмоции, погодите не может быть, идеальный код, безупречная архитектура. Что он несет? Оформление, naming, компактность и комментарии. Это же детский сад. Это примитив. Не может быть, это слишком просто. Набор примитивных требований ошибочно распространен и на код, на микроуровне и на архитектуру всего подряд, на макроуровне.

Звучит совершенно немодно, мы молчим что набор необходимых слов, extreme programming, правильная архитектура. Нет модных архитектурных нововведений, какие-то базовые штуки. Совершенно недопустимо для 2016 года, нет машинного обучения, глубокого машинного обучения, нет нейросетей. Непонятно зачем купить новую NVIDIA машину за 130 тысяч долларов, чтобы нейросети быстро обучались. Не может быть, слишком просто всё. Хрен с ним с вашим кодом, код это нечто такое приземленное, неинтересное.

Давайте поговорим об архитектуре. Не может быть, чтобы с архитектурой всё было так просто. Обязательно как минимум нужно design patterns, обязательно нужно следовать SOLID принципам, GRASP принципам, без TDD, CI не CI. Agile в чистом виде внутри достаточно сложно, поэтому внедряют тот или иной набор agile практик, здесь кусок Канбана, тут кусок другого процесса и т.д.

Это мы молчим про всякие эзотерические принципы, про которые некоторые слышали, а некоторые даже пытаются применять. Никак нельзя называть класс, который er или or. Такой принцип иногда работает. С этим я даже частично согласен, называть класс helper нехорошо, там образуется помойка, есть дополнение к принципу с одной стороны, и формальный чит-код, с другой стороны. Называешь класс helper, тебя мгновенно ловят на этом, находят через поиск и ну-ка срочно переименовал. В этот момент появляется класс misc или класс utility.

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

Кто помнит, что такое SOLID? Покажитесь. Вам не нужен следующий слайд, на котором написано, что это значит. Вы это помните наизусть, молодцы! Я помню только букву L, всё остальное списал с Википедии. Будем откровенны, букву L я помню, не потому что постоянно в своей жизни осознанно следую букве L. Принцип сам по себе правильный, о том, что наследник класс не должен удивлять, когда воткнешь в то место где ожидался базовый класс, но будем откровенны. Принцип запомнился по другой причине, потому что Лисков это известный мужик по имени Барбара, еще и не мужик. Но по сколько давно американский то Лисков, а не Лискова. Это единственная причина почему я запомнил название этого принципа.

Помимо массы принципов под общим зонтиком SOLID, помимо массы принципов под общим зонтиком GRASP, помимо массы принципов про паттерны, visitor’s, singleton’ы, фабрики. В C++ есть прикольный жупел, просто потому что он в C++ особенно не радостно выпиливается под называнием: двойная диспетчеризация либо динамическая диспетчеризация. Это только про организацию кода, и это только про объектно-ориентированный дизайн.

Код не ограничивается объектно-ориентированным кодом, есть еще масса прекрасных отличных слов. Про функциональщину, про actor model, про модель программирования, когда всё асинхронно и совершенно непонятно какой из 17 простыкованных callback’ов в какой момент вызывается, но как-то всё работает. До тех пор, пока последний программист на NodeJS и переходит на Go.

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

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

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

Что есть на этот предмет?

Нет почти ничего. В мире С++, я старовер и плохо знаю, как писать на всех остальных языках. Про C++ немного знаю. В мире C++ к 2016 году, не так давно победили форматирование, усилиями фирмы Apple почему-то. Написав сначала lvm, потом шланг, потом clang-format.

Со всеми остальными пунктами какая-то попа.

Нейминг — зоркий глаз и личное чувство вкуса.

Компактность кода – автоматизированных средств проверки тоже нет, можно придумать автоматизированные метрики какие-то. Условно, здесь такая-то цикломатическая сложность, вот здесь столько-то строчек кода на такую-то user story. Ещё какие-то непонятные штуки. Но автоматического инструмента, который точно так же как сосед программист Вася посмотрел бы в код и сказал: ты зачем олень эти две страницы написал? Вот видишь helper, тут 3000 строк всего. Зачем мы делали этот helper, тут же всё есть, для вас же делали.

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

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

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

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

С комментариями только зоркий глаз.

Как обычно бывает?

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

Что же такое архитектура? Идеальная или просто хорошая.

Считаю две школы мысли.

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

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

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

Как я сразу и обещал, никаких революций и прорывов в научно-философской мысли не случилось.

Поэтому дедушка с бородой смотрит на нас осуждающе.

Счастья не будет. Идеальные коды и идеальную архитектуру сверху не спустят. Даже если наймут специального архитектора ничего не произойдет. Жизнь – боль, в коде всегда говно. Единственное что мы можем с эти сделать, это насадить практику на среди каждого конкретного программиста, под нехитрым названием: вижу говно, смываю. Подробности на слайде.

Надо увидеть в коде косяк, не игнорировать это, а немедленно отвлечься и исправить или хотя бы создать тикет, о том, что надо бы когда-нибудь исправить. Иногда, это еще отельная интересная боль, тут я уверен все поделятся историями о том, что злое начальство никогда не дает время на рефакторинг, на отдачу технического долга, на изучение новых технологий и т.д. Приходиться вот так, из-под полы. Оно и не даст. Раз такие дела то на супер-архитектора, который придет и наведет порядок, обеспечит вступление в Европейский союз, оно тоже денег не даст и времени тем более. Придётся как-то самим, что важно, надо делать это постоянно. Это моя боль вечная, под названием припадками то я умею и красиво рассказать, а вот так чтобы методично и каждый день, и каждую первую строчку нет. Это не просто, это тяжело. Может показаться, что так называемое «просто» у нас минимум на 50% всё есть, а то и на 90% по внутренним оценкам. Не совсем.

Приносите пачку денег, приносите примеры вашего кода, посидим, посмеемся — поразбираемся.

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

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

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

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

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

Компактность. Я приведу первый попавшийся пример, который зашел мне прямо в душу.
Выглядит он так:

Нормальный код, все такие пишут и я такой писал. Ничего стыдного в этом нет. Более того, этот самый увлекательный код, который что-то там делает, какие-то циклы, поверхности, непонятно. Он может быть именно в такой форме быть исторически обусловлен. Он такой и должен был бы быть, если там внутри 20 проверок и потом они уменьшились до одной. Одна проблема. Хочется на месте этого ада видеть одну строчку:

Я её специально написал с некорректным синтаксисом, который не скомпилируется.

Повторюсь в C++ можно приблизиться к идеалу, потому что 11-ый С++ дает какие-то лямбды и можно передать туда лямбда-функцию, определить агрументик, он будем немножко подлиннее, на пол строчки.

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

Мне эти 3 строки, а в идеале 1 сильно быстрее в разы. Если так делать с каждой строчкой, то улучшится в разы чтение кода в целом.

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

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

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

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

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

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

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

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

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

«Пробовал ли ты сам?» Должен возникнуть важный вопрос, хоть времени рассказывать нет, но да, пробовал. Могу сказать примерно следующее, что по ощущениям писать вот так вот, абсолютно набело на пятерочку с плюсом, назовём это, занимает не принципиально большее время. Может на 10 %, может 20% больше чем обычно, артефактов оттуда по времени примерно три.

Первый артефакт — оно тебе натурально самому нравится.

Второй артефакт — некоторые соседи по команде через силу признают, что вышло круто. Не все, это неизбежно.

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

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

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

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

Слайд для ПМ’ов. Неужели это все про программизм? Нет ПМ’ы тоже нужны, потому что, не смотря на увлекательные мотивационные доклады, программисты редко самоорганизовываются и все подобное внедряют сами. Значительно эффективнее насаждать огнём, мечём, в смысле депремированиями и увольнениями. Все тоже самое ничего интересного, внедряем код-стиль, внедряем принудительные review, процессы передачи знаний, кому интересны подробности, давайте еще обсудим в кулуарах.

Что с архитектурой делать?

Здесь еще сложнее давать унифицированные советы просто потому что все проекты разные и где-то достаточно совсем простенько, где-то ее недостаточно совсем.

Так что делать?

Если видишь в коде вот такое:

Или вот такое:

Это просто гениально, я плакал в голос, мне было завидно, это гений.

Почему это придумал кто-то? Прочему не я? Я никогда не буду так писать, это гениально.

Видишь в коде вот это, или вот такое (это я написал):

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

Доклад назывался «Снесите это немедленно». Меня зовут Андрей. Меня сейчас выгонят.

Андрей Аксенов — Снесите это немедленно. ^[3]

Автор: TM_content

Источник ^[4]