Miscellanea II

На самом деле откровенно плохой код в production встречается не очень часто. Ну вот прям плохой-плохой, ужас-ужас. Просто потому, что оно хоть как-то, но работает, что уже критерий. Зато откровенно плохая архитектура на среднем уровне (то, что умещается в ООП-архитектуру, в разброс модулей, в общий стиль, так сказать, внутренней интеграции) в каждом втором проекте. Одноразовая. Понятная только создателю. Ушедшая от предметной области невообразимо далеко. И всё из лучших побуждений ведь. Написать очень гибко. Написать очень академически. Написать очень, очень изящно и красиво. И чтобы сущность “яблоко” выражалась через десять метаабстракций. Слишком уж крестьянски выражать яблоко яблоком. Или хотя бы фруктом. Пусть это будет SomePatternObjectDomainClass. А перевыпилить эту пакость крайне ресурсоёмко.

Парадокс языков вроде Ruby и Python в том, что на них очень легко начать и легко писать всякое, но с линейным ростом сложности сервиса сложность написания качественного кода возрастает экспоненциально. Не могу пока это как-то формализовать толком, но вот так опыт подсказывает. Ну т.е. чтобы хорошо написать большой проект на Python, вкладываться сильными ресурсами надо так же, как если бы этот проект был на Java / C++.

Сложно понять людей, которым равнодушно происходящее на самом деле. Есть какая-то конструкция языка, отражающая что-то, что человеку не нравится. Допустим, унарный инкремент. Вот фу-фу прям. В языке эту конструкцию убирают, но не убирают трансляцию / компиляцию в неё. Человеку сразу норм. Или заменяют каким-нибудь сахаром. Едва ли не макросом. И снова человеку норм. Как он при этом может не знать и не думать о том, что на самом деле он всё равно пишет тот же унарный инкремент — не понимаю.

Фигня относительно большой текучки кадров в том, что у тебя меньше шансов (на|пере)учить разработчика в стратегических вопросах. В 1817 году ты ему говоришь, что вот так делать нельзя, через пару лет при текущей динамике база лопнет, сервис ляжет, пользователи разрыдаются. Не убедил. Разработчик в 1818 году увольняется в закат. В 1819 году база лопнула, сервис лёг, пользователи рыдают. А ты сидишь дурак дураком и некому сказать “я же говорил! давай ты больше так делать не будешь”. А он уже в другом месте такую же ошибку совершает.

Допустим, ваша команда не успевает в срок. Допустим, то, что успевает, работает плохо и уныло. Что иногда делают? Ровно наперекор анекдоту (“Когда в борделе падает доход, следует менять блядей, а не передвигать кровати”) — меняют технологический стек, методологии, подход к разработке. О, давайте теперь писать функционально. И чтобы аджайл. И скрам! И уберём стулья, работать стоя прикольно и модно. Уииии! Это не спасает. Разве что вы писали сервисы на BASIC, а потом додумались до языков 2016 года. Почти всегда проблемы не в технологиях, но в людях. Эти проблемы и надо решать, а не кровати двигать. Казалось бы, общее знание, но бесконечно одно и то же. Утомляет листать десятки страниц Youtube с выдачей вида “используйте язык / технологию / утилиту XYZ и ваши рабы запрыгают быстрее”.

Эстетика vs рационализм

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

Искусствоведы рассматривают продукт с точки зрения на исходный код. Насколько он изящен, насколько красив, изыскан и моден. У них подспудное желание верить, что красивый исходный код и работает красиво.
1-4Z0hHr7yQXtObJ7coD93fw
Assembly language © http://www.hexblog.com/?p=17
Эти же ребята акцент внимания устанавливают на синтаксис. Разговор о языках с ними — это разговор о том, как язык выглядит.
Внешность языка — один из ключевых параметров, по которым они оценивают то, насколько хорош.
В немецком слишком много умляутов, фу-фу, давайте на нём сервис не писать. А мне неопределённые артикли норм, английский рулит, пишем базу на английском. Слушайте, вы все ошибаетесь, посмотрите на китайские иероглифы, они ня. Сам ты ошибаешься, вон в японском какая изысканная строгость, хоть сейчас числодробилку на нём рисуй.
В какой-то (думаю, в большой) мере благодаря этим ребятам мир получал и получает языки, синтаксис которых позволяет выражать текст программ ближе к тому, что в естественном виде в голове разработчика.
И это хорошо.
Плохо то, что чем выше уровень [близости к человеку] языка, тем больше цена, которая платится. Верю, однажды будет вселенная, в которой Ruby переплюнет машинный код, но не сегодня. И тут начинают бунтовать прорабы.

Прорабы смотрят строго функционально. Код может быть лапшой, нечитаемым монолитом, в который залили цистерну односимвольных переменных и хардкорной арифметики указателей. Главное — насколько крепкий получился продукт.
У прораба линейка и секундомер. На искусствоведа он смотрит примерно так же, как мебельщик из Техаса на оформителя палат Людовика XV. Чувак, нужен стул, выдерживающий быка с ковбоем, а вот эти твои маленькие китайцы с завитушками не нужны.
Приоритет, ясен пень, на другом. Прораб готов что сам поле лопатой перепахать, что толпу кандидатов наук заставить картошку перебрать ради достижения результата. Результат (с большой буквы) для прораба — то, что отвечает суровому ТЗ, а то и переплёвывает его вдвое.
Тут занятно другое. У прораба тоже есть эстетика. Ему приятно смотреть на двигатели, на тысячу патрубков и миллион проводов. Он считает, что код — это проекция компьютерной архитектуры в текст. И чем больше фотографической точности, тем лучше. Предельная функциональность исходного кода (предмета искусства) — вот один из идеалов прораба. Рококо для него — это мишура, уродливый слой косметики, скрывающий прекрасное тело. Он не особо доверяет коду, который выглядит слишком пластиково, слишком декоративно.
Красивый код прораба — то же месиво патрубков и проводов. Оно прекрасно. Из него в разные стороны хлещет индустриальная жизнь. Оно блестит киберпанком и одновременно покрыто копотью. Прорабы каждой строчкой напоминают нам о том, что в разработке не картинки хоботом рисуются, но едва ли не чумазые шахтёры в забое соль жизни добывают. Просто в офисе. И не чумазые. И не шахтёры. Но от кода должно нести потом и кровью, а не Шанелью. Короче, прорабы за реальность и реализм.
И это хорошо.
Плохо то, что пока десяток прорабов маленькими надфилями и микронанометрами сотворит наикрепчайший киберпанковый стул в мире, один искусствовед на своём пиджинскрипте налабает десять табуреток.

Важно ли меньше букв в коде

Одна из скучных (об этом отдельное эссе, пожалуй) тем для споров — “язык X лучше языка Y потому, что меньше букв писать”. Обычно это Java (много букв) vs Python (мало букв). Давайте подумаем о том, насколько это важно.

Во-первых, это важно не программе и не пользователю, но разработчику. От того, что ваш код вдвое меньше, приложение не становится быстрее или удобнее. Потому сразу надо брать этот пункт в фон и постоянно держать, всякий раз обрубая поползновения объём кода переместить в другую плоскость.
Во-вторых, это субъективно. Вася с трудом осиливает ленту из десяти твитов за сутки, Петя за час пролистывает любой том БСЭ. Безусловно, есть какая-то граница, за которой слишком много букв уже для любого разработчика, да и в целом таки хочется меньше рутины, но насколько это действительно напрягает и проблема — оно таки от Петь и Вась зависит.
В-третьих, IDE. Если вы фигачите код в vim’е, который ещё и не настроили, кажется очевидной и огромной разницей разница между вашим отношением к объёму кода и отношением к оному бойца, у которого какая-нибудь IntelliJ IDEA, да ещё и с заточкой под конкретные руки. Все эти скобочки, переносы, ключевые слова и длинные имена исключений — они давно уже автоматически или из всплывашек долбятся. Субъективно мне кажется, что целиком я не набираю и половину Java-кода.
В-четвёртых, снова IDE. Исходный код — это давно уже не портянка, которую читать от первой строки до последней. Это граф из функций и данных. Современные IDE умеют помогать читателю бегать из узла в узел, подкрашивают, схлопывают, расхлопывают, а иногда ещё и картиночки генерируют для особо упоротых случаев. Когда вы видите на GitHub’е 1000’строчное полотно Java-кода… короче, в IDE это выглядит не так. И изучение чужого исходника у вас будет выглядеть иначе. При этом гораздо бОльшую роль будут играть имена, типы и прозрачность кода, а не его количество (крайний случай лаконичности — regular expression на половину экрана, очень понятно и клёво?).
В-пятых, а какую долю рабочего времени у вас занимает набор кода? Ну правда. Приходит задача. Обсуждается. Осмысляется. Чертится на бумажках. Исследуются библиотеки, если надо. Читается и пробуется документация / учебники. Пишутся какие-то наброски. Потом первый пристрелочный код. Если понятная текучка, то сразу что-нибудь исправляется. Если непонятная, то читаются логи. И вот во всей этой чехарде физический набор исходника занимает… ну… блин. У меня в лучшем случае 20% (с потолка) времени от общего времени задачи. Также в процессе написания думаю о том, что писать-то конкретно. В итоге сам набор ещё меньше.

В общем… если сравнивать языки по этому показателю, то после того, как всё остальное взвесили. Фишка тут в том, что всё остальное сознательно можно взвесить токмо при годном знании матчасти.
Сборка мусора, работа с памятью, многопоточность, оптимальность стандартных библиотек, скорострельность интерпретации, всё такое. Тут-то как-то спорщикам скучно становится. Мало того, что действительно надо знать, что и как работает, так ещё и доказать собеседнику, что это работает плохо или неправильно, да ещё и в каких-нибудь условиях. И доказывать не “бабушкой клянусь!” и не “я в 1917 году семь ошибок сделал из-за этого! я! Карл! семь!”, конечно же.
Синтаксис? В вопросах синтаксиса, знаете ли, субъективное Васино “фу, пакость какая” тоже не особо рулит, если нужен серьёзный конструктивный разговор. Примеры таких разговоров (хоть в какой степени) вот тут, например: Swift Programming Language Evolution
Если посмотреть на процесс зрелого (на уровне комитетов и острых переписок во всяких изданиях ACM) суждения про языки… послушайте, размер исходника вообще никого не волнует. Разве что на заре сетей задумывались глубоко о том, хватит ли каналов для передачи того и сего. А нынче не задумываются.
Хорошо бы и нам как-то из этого выйти.

Как заработать миллион

Строго говоря, заработать миллион российских рублей вы можете за восемь лет с копейкой, получая 10К в месяц, например. Но эссе про реализацию идеальной мечты: разработчику (!) собственной идеей (умом и руками) быстро (не за 50 лет) построить бизнес, который будет приносить постоянную (не продать бабушкин завод) и честную (не грабить прохожих по ночам и не впаривать сладкую вату в уши) прибыль в виде миллионов денег.
Да понятия не имею.
В реале все заняты бизнесом. Я тут в ночь залистался “Вестником государственной регистрации”. Знаете, в России только граждан ИП почти 3.67М, а коммерческих юр.лиц 4M с хвостиком. Это на 80М трудоспособного населения, если чё, из которых ~5M алкоголики и наркоманы, ~650K сидят за решёткой и т.д. Но всё равно как-то понятно. Крестьянин вырастил морковку. Морковный смузи всосал питерский хипстер. В промежутке около двадцати человек поимели копеечку от хранения и перевозки до приготовления и подачи. При этом две трети из них либо живут в долг (кредит), либо едва сводят концы с концами.
Разработчики не выращивают морковку. Это проблема. И с каждым годом ситуация всё более фиговая.

Во-первых, 999 идей из той 1000, что пришла вам в голову, уже сделаны кем-то. Не факт, что проданы успешно. Скорее всего, пылятся на задворках Интернета, на пятисотой странице App Store или Google Play.
Во-вторых, прибыль очень многих бизнесов… ну, малая в сравнении с. Допустим, в средней Москве средняя зарплата среднего программиста равна 100К белых рублей на руки. Это нынче ~$1540. Чтобы ваше приложение в App Store приносило такую же прибыль после всех вычетов вроде доли магазина, его надо продать минимум на ~$2300. Иначе говоря, какое-нибудь маленькое приложение должно быть настолько прикольно, полезно и выделяемо среди миллиарда подобных, чтобы его ежемесячно покупала тысяча человек. При этом вам надо поддерживать его, развивать и отбивать потраченные на него сотни часов. И где-то на горизонте налоги маячат.
В-третьих, предсказуемость рынка, мне кажется, нулевая. Пару лет назад опишите вслух идею Pokemon GO и попытайтесь угадать его судьбу (ежедневные покупки на $10M). При этом Twitter показывает убытки в пару миллиардов. А примитивнейшую игру SAMOLIOTIK поставили себе 83K человек, 14-летний пацан заработал тысячи долларов. Он-то молодец, спору нет, но кхм. Проведите эксперимент. Придумайте идею софта, спрогнозируйте рынок, потом погуглите попытки реализации идеи и продаж. Интересный опыт.
В-четвёртых, не приведи Бжнька хоть как связывать свой софт с реалом. Едва разработчик начинает общаться с внешним миром (поставщики, логистика, таможня, монтаж и т.п.)… короче, всё плохо. Этим должен заниматься специальный человек со специальными нервами и специальным опытом.
В-пятых, в какой-нибудь “промышленной” сфере вы будете конкурировать с open source. Грубо говоря, если захотите подарить миру крутой http-сервер, надо будет победить nginx, да при этом убедить мир в победе. И так уже везде в любой теме. Хоть какое гуано на костылях, но наверняка уже будет и даже в массовом production.
В-шестых, скорее всего, вы не знаете реальную нужду какой-либо категории населения в каком-нибудь софте. С одной стороны разработка крута тем, что в теории применима ко всему. Огурцы автоматизируй, спутники выращивай, бухгалтеров пугай, Везувий шатай. С другой стороны разработчики обычно компетентны и эрудированы в… удивительно, но в разработке. И ни байта не шарят в огурцах и спутниках. Потому гениальный софт от разработчиков — тудушницы, календарики, справочники резисторов и какая-нибудь ещё фигня. На всё остальное боец смотрит наивными глазами крота. Если уверяет, что шарит в огурцах, скорее всего, копал у бабушки на грядке пару сезонов, потому великий специалист.
В-седьмых, в-восьмых, в-девятых…

Всё это к чему. Каким-то магическим образом люди придумывают и создают то, что их штырит, да ещё умудряются вштырить окружающих, да ещё зарабатывают на шалаш в Разливе. Мне кажется, те, кто делает это без инвесторов, без надутого хайпа, без паразитирования на человеческой жажде зрелищ… вот в наше время они крутые, ибо пробивают такую созревшую толщу шума и пресыщенности, что диву даёшься.
Я так не умею. Уныл и скучен.

Обучение детей

В темах обучения современных детей чему-либо красным канатом проходит следующее: они тупые и им ничего не надо, если нельзя поржать и снять на мобилу. Если уж кто делает учебную программу, то максимально простую, ну и чтобы цыганки с медведями в грязи боролись. На выходе дети с каким-то бесполезным дипломчиком и смутным ощущением “я программист?” Не программист, конечно. И даже не разработчик. Все попадавшиеся мне на глаза учебные планы готовили в лучшем случае болванку, которая знает, что бывают десктопы, а ещё ноутбуки, уиии.
Если я начну рулить планетой, всё будет иначе.

Во-первых, чёткая постановка цели — надо выращивать годных программистов. Негодные сами появляются аки грибы в Чернобыле. Детей много, учителей мало, лучше из тысячи кандидатов сотворить десяток будущих senior developer, чем сотню вечных junior / middle винтиков. Подчеркну: остальные категории массово порождаются и без особого внимания. Штучный ресурс надо штучно же вылавливать и готовить.
Во-вторых, никакого упрощения. Только хардкор. В 9..11 классах мозг раскручен на максимум и впитывает всё с благодарностью. Держать его в этот период на диете — преступление. Архитектура компьютера / микропроцессора, алгоритмы, сети, операционные системы, основы ассемблера, C/C++. Всё давать в полной мере, устраивая каждый квартал экзамены, залёт на которых означает вылет.
В-третьих, никакой жалости. Взрослая жизнь должна начинаться с 9-го класса. Если твоё решение не умещается в заданное ТЗ, ты вылетаешь. Если не смог ответить правильно на 75% вопросов теста, ты вылетаешь. Если не делаешь домашнее задание, ты вылетаешь. И т.д. Иными словами, если ты не выкладываешься и не заинтересован в том, чтобы быть программистом, отойди в сторону, освободи место тем, кто вытянет. Это ровно та же система, что применяется в сертификации взрослых людей. В ней нет “Вася гонял мячик, он лучший спортсмен школы, не успел, но давайте поставим ему хотя бы четвёрочку”.
В-четвёртых, с младых ногтей боевая практика. Каждое полугодие рандомно собираются команды, рандомно назначается тимлид, после чего команда получает задание типа “написать nginx lite” или “вот <известный фреймворк>, у него открыто N тикетов в трекере, закройте M тикетов”. Никаких абстрактных олимпиадных шняг. Получили задачу, сделали работу, лучшие получат деньги.
В-пятых, никакого сокращения по срокам. Три последних года школы будущие бойцы должны пахать и рвать зубами гранит минимум пять часов в неделю. Это 780 учебных часов. Примерно столько же должны тратить дома. Итого 1500+ часов учёбы. Кружок по интересам на час в неделю — это вот лучше оставить курсам “Excel для секретарей за 12 часов”.
В-шестых, дополнительно терзать другой полезной эрудицией. Как минимум, хорошо бы экономику, производство и прочее, невежество в чём срубает половину стартапов уже в первый месяц.

Что в итоге получится? Если на Россию 20 таких школ по 15 человек на курс, ежегодно будут выпускать три сотни спартанцев (что сравнимо с выпуском пары факультетов вуза), вокруг которых могут формироваться команды / отделы / бизнесы. Три года выпуска достаточно, чтобы наводнить / создать годными кадрами крупняк вроде Яндекса или Mail.ru.
Выгода со всех сторон. Т.к. школы будут в одной системе, наши спартанцы образуют клуб, в котором каждый всех знает — будущие профессиональные связи. Финансировать такую специализированную систему проще и прозрачнее. Обеспечивать ясный вектор в будущее тоже проще (напомню, не надо тащить на себе кандалы “программа должна быть средней, чтобы выучить средний уровень класса”) — смело тащим новинки, мейнстрим, экспериментальное железо и прочее. Злобность и жёсткость отсева позволят поднять уровень диплома до “выпускник лениво отмахивается от просьб хотя бы посидеть на стуле в отделе кадров любой конторы мира”, что в свою очередь поспособствует притоку кандидатов, из которых будут выбираться 30%-е сливки.
Тогда и будет толк. А если готовить мегатонны обслуживающего персонала, толк от мегатонн будет соответствующий.
Хау. Меня в президенты.