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

Давайте сначала уберемся с дороги. Я не «технолог», «практик» или технический директор с «техническим образованием». Я инженер, делающий вещи, которые работают. Я не участвую в лингвистических дискуссиях (то есть в пресловутых Haskell / Go / something-trendy- «новый» -язык-следующий-следующий против «старой» Java) или пуристических спорах (ООП, ФП и т. Д.). Они теоретические.

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

Спортивная перспектива

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

Каким бы ни был ваш случай (может быть, даже кокаин или другой стимулятор, j / k), вы просто знаете, что должны были быть программистом. Ты любишь это. Вы превосходите своих коллег. Как бы вы ни достигли своего текущего профессионального уровня, вы обладаете сверхчеловеческой силой, чтобы крутить педали в гору на более высокой передаче, обгоняя всех. Итак, вы смотрите свой любимый турнир: скажем, Тур де Франс (на фото выше) ради этой дискуссии, восхищаетесь победителем на пьедестале почета и невольно думаете: «Разве я не должен получить большой приз за то, что финишировал первым в своем? спорт? »

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

Почему разговоры о деньгах всегда такие секретные - их тщательно избегают в HR и других корпоративных кругах? Это просто мое - вечно чрезмерно квалифицированный сотрудник - восприятие? Все, начиная от правительства с его налоговой шкалой и заканчивая моими непосредственными начальниками, которые каждый день напоминали мне о том, что я «второй по величине высокооплачиваемый разработчик» или просто «мы вам много платим», пытались заставить меня стыдиться и желая большего. Почему? Даже, особенно когда «второе место» было немного ниже среднего по отрасли и составляло 1/3 сопоставимого вознаграждения Google.

Последнее частично объясняет вещи. Если сравнить программирование с ездой на велосипеде, горстка ведущих технологических работодателей (Google, Facebook, Amazon и т. Д.) Представляет профессиональные турниры, такие как Tour. Все, что находится за пределами этого круга, в лучшем случае является местными благотворительными гонками, если не только воскресным развлечением «воинов выходного дня». Чтобы выиграть приз, нужно соревноваться профессионально.

Признав это, что, если я стану специализироваться на другом виде «гонок» (помимо потребительских технологий Google и Facebook)? Представьте себе, если бы только минималистичные односкоростные гонки без тормозов (специализированные потребительские товары, такие как блоги, мессенджеры и электронная коммерция) были объявлены профессиональными, в то время как многомесячные многоступенчатые гонки на выносливость по труднопроходимой горной местности (надежная автоматизация сложных бизнес-процессов и запутанные постановления правительства) считались любителями.

Видите проблему здесь? Редкие и требовательные к качеству программы сами по себе больше не являются профессиональным видом спорта. «Наука» искусственного интеллекта и других ярких видов есть. Точно так же, как до этого была расплывчатая достойная «архитектура предприятия». Все три: программирование, наука о данных / искусственном интеллекте и архитектура программного обеспечения, полностью чуждые богатым и влиятельным, но технически неграмотным лицам, принимающим решения по программе MBA, заявляют о чем-то достойном.

Устранены ли в мире все программные ошибки и утечки ресурсов, чтобы предотвратить почасовые сбои серверов критически важного программного обеспечения, установленного в банках и страховых компаниях? Избавился ли он, наконец, от доисторических мэйнфреймов 1970-х, известных как «устаревшие» системы, которые, как ожидалось, не переживут проблему 2000 года? Нет, это не так. Спустя долгое время после присоединения 1 млрд населения Индии к западным ИТ-специалистам, на Земле заканчиваются программисты, чтобы поддерживать старое дерьмо. Наряду с тоннами спагетти, бездумно набираемых кодовыми обезьянами на «более новой» (примерно 2002 г.) корпоративной Java.

Если вы спросите меня, мир выживет без более совершенных потребительских гаджетов и более умного (все еще довольно раздражающего) контента Facebook и анализа лайков с помощью машинного обучения и других алгоритмов анализа данных. Однако он не может позволить себе настоящий кризис 2000 года, который, несомненно, наступит раньше, чем все ожидают, когда все, что производилось в / для крупных банков, больниц и других ИТ-отделов из списка Fortune 1000 с 2000 года, поддается экспоненциальному увеличению количества ошибок и утечек памяти. В то время как более мелкие информационные предприятия, такие как врачебные кабинеты и индивидуальные страховые агентства, задыхаются без настоящего корпоративного программного обеспечения, которое было объявлено многомиллионным доменом Oracle и Salesforce. AI не собирается писать эти системы для клиентов из малого и среднего бизнеса в ближайшее время, не так ли?

Меритократия не так проста вне спорта. Между сильной стороной и призом существует множество логистических препятствий, самая большая из которых - применение профессиональных качеств для создания чего-то, что продает, чтобы заплатить заслуженное вознаграждение. Настоящая проблема здесь не в дешевизне или несправедливости начальства, а, как я уже намекал выше, в отсутствии самого «турнира». Вы утверждаете, что всегда финишируете первым. Что закончить? Воскресная поездка? Даже самые длинные и сложные из них по-прежнему не считаются гонками. У профессиональных гонок есть рекламодатели и другие спонсоры (то есть клиенты), которые финансово поддерживают большой приз. Почему вы соревнуетесь со своими приятелями-любителями, а не с профессионалами? Как попасть на эксклюзивные гонки? Все становится на свои места, когда вы присоединяетесь к гонке и прикладываете свои силы для ее победы. Но как найти правильную расу?

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

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

Вращение педалей на высшей передаче

Педали на более высокой передаче, несомненно, быстро… как только вы к этому привыкнете. Делает ли человек все в жизни для удовольствия / радости или находит удовлетворение, выходя за пределы уровня комфорта, прилагать дополнительные усилия сложно и очень неприятно. Этот пост является предвзятым и личным. Я выбрал «много работай, много играй». Что-то мне подсказывает, что если вас беспокоит справедливость компенсации, вы редко покупаете «баланс между работой и личной жизнью» HR BS. Высшая меритократия заключается в вознаграждении за болезненные дополнительные усилия. Вы знаете, что тур - это не неспешный круиз по пляжу.

Все казалось ясным, когда я приступил к разработке первой версии платформы разработки Lionstack под кодовым названием Px100 framework. Если вам интересно, это означает «Производительность x100». Как хороший инженер, я все тщательно спланировал. Я несколько раз прокручивал этот план в своей голове. Я подправил его во время разработки. Все проверено. Так я и подумал - до «высшей передачи» сюрприз.

Px100 - это не ракетостроение: Google или Amazon «переманивают» меня с помощью специального маршрута найма, минуя длинную череду мам-тигров, воспитывающих идеальных ученых с GPA, соревнующихся в алгоритмических собеседованиях. Нет никакого умопомрачительного машинного обучения или другой науки об искусственном интеллекте, поддерживающей Px100. Он собран из обычных зрелых частей, таких как Spring, Mongo и распределенных сетей памяти, хотя и связан очень нетрадиционным кодом Java. Он также включает в себя хорошо известные шаблоны программирования, а также многие уроки, извлеченные за мои 25 с лишним лет в ИТ: в первую очередь, о том, чего не следует делать.

Я просто подумал: давайте использовать объектно-ориентированное программирование по прямому назначению: моделировать сложный внешний мир. ООП имеет решающее значение для моделирования сложных молекул лекарств и расшифровки генома человека. Почему спустя 30 с лишним лет после изобретения C ++ все, кто занимается автоматизацией бизнес-процессов, все еще пишут тупые, так сказать, «структуры с функциями»? Я знаю, кого волнуют старые основы, верно? Это самые модные аббревиатуры, которые якобы принесут вам немного больше - по крайней мере, до тех пор, пока орды аутсорсинговых кодовых обезьян не догонят через несколько месяцев, набив те же учебники и добавив те же аббревиатуры в свои резюме.

Я подумал: давайте использовать 100% ядра Spring, чтобы найти правильный баланс между методами конфигурации, необходимыми для повторного использования кода (соединение различных существующих частей), и функциональным программированием, чтобы внедрить маленькие кусочки точной логики прямо там, где они должны быть. Сколько людей используют Spring таким образом? Каждый Java-разработчик должен просто «использовать» Spring, верно? Это всегда было? Я вспоминаю мир до весны. Это было плохо. Весна не была изобретена для того, чтобы ее помещали в резюме и нанимали людей. Он решает фундаментальную проблему разработки программного обеспечения: настройку кода и сервисов.

В совокупности все, от важных решений, например, использования решеток RAM в качестве первичной базы данных до небольших оптимизаций, было объединено, как я и планировал, и я получил то, что хотел: точный инструмент для написания кода в 100 раз меньше по сравнению с ERP старой школы (эпоха мэйнфреймов) и дисфункциональные корпоративные группы Java, укомплектованные внештатными кодовыми обезьянами, и в 10 раз меньше по сравнению с нынешней лучшей в своем классе платформой для разработки корпоративного программного обеспечения: Salesforce 1999 г. и «хорошие» (небольшие) поставщики Java-решений. Apex от Salesforce очень похож на Java, поэтому разница в производительности минимальна, если вам интересно.

Естественно предположить, что меньше (кода) означает меньше усилий. Вот откуда пришла моя метафора «высшей передачи». Понимаете, дело не в коде. Если вы не разрабатываете блог, мессенджер, игру или другой одноцелевой потребительский продукт, полная автоматизация среднего бизнес-процесса средней сложности, например Ежедневный распорядок автодилера или страхового агента включает в себя тысячи маленьких логических элементов: если, циклы, исключения, запланированные / запланированные операции и множество других вещей, выходящих за рамки обычного специализированного разработчика потребительских технологий (Google, Facebook и т. д.) продолжительность концентрации внимания.

Google и Facebook делают удивительные (научные) вещи. Но они не хотят прикасаться к корпоративному программному обеспечению 10-футовой стойкой. Используя приведенную выше метафору езды на велосипеде, потребительские технологии действительно сродни гонкам по плоской дорожке, независимо от того, является ли разработка программного обеспечения для бизнеса многоступенчатой ​​гонкой на выносливость в тысячу миль. Вот велосипедная версия аутсорсинга. Да ладно, ты знал, что я не смогу сопротивляться.

Вас просят доставить посылку из пункта А в пункт Б по кратчайшему маршруту: по сложной горной дороге. Ваши конкуренты не пройдут даже первые 10 миль. Таким образом, они выбирают в пять раз более длинный, хотя и более плоский обходной путь (написание большего количества кода и интеграция малопригодных модулей, которые можно просто написать с нуля до точной спецификации, и т. Д.). В их команде больше гонщиков, каждый из которых проезжает 20 миль, а затем падает, затаив дыхание, и его заменяет следующий товарищ по команде. Они бы тебя побили, да? Сила в числах? Зависит от. Упаковка хрупкая. Он может выдержать только определенную управляемость - передачу от одного гонщика к другому. Программное обеспечение ломается, поскольку все больше людей, особенно самые дешевые «кодировщики», работают над ним, внося пять ошибок, исправляя одну.

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

Вот лучший вариант: есть ли у каждого профи подходящий байк, чтобы крутить педали быстро (на более высокой передаче) и вовремя доставить посылку? Я не ученый, работаю в Facebook или Google, которые в настоящее время считают себя частными гигантскими лабораториями Массачусетского технологического института и Калифорнийского технологического института. Единственная наука, которая применима к Px100, - это Первый закон термодинамики (известный как Золотое правило механики в контексте коробки передач). Никакая энергия не может быть создана или уничтожена. Взгляните на классическую концепцию более высокой передачи по сравнению с медленным движением и тратой большего количества энергии, например на трение. Но эй, энергия (деньги) никуда не денутся. Он просто попадает в карманы, отличные от ваших, особенно в карманы посредников.

Что это за чертова «бизнес-логика»?

Творческая часть корпоративного программирования, оставшаяся после автоматизации большей части технической сантехники, называется «бизнес-логикой». Это всегда было довольно спорным понятием в ИТ. Я не говорю о так называемом «среднем уровне» классического трехуровневого мобильного или веб-приложения. Здесь нет никакой логики, просто тупой переход в базу данных; в любом случае устаревшие базы данных NoSQL - путем сохранения захваченного пользовательского ввода в его естественном: иерархическом («объектно-ориентированном», если хотите) формате.

Реальная бизнес-логика обычно находится в пользовательском интерфейсе, о чем свидетельствует популярность надежных фреймворков JavaScript, ориентированных на пользовательский интерфейс, таких как React. Он отвечает за проверку пользовательского ввода, все аккуратные анимации для скрытия / отображения и включения / отключения полей и разделов, навигацию по экрану, безопасность (кто что видит) и общий поток данных.

Это звучит примерно так: «И когда пользователь вводит значение больше 15 в это поле, серверная часть должна вызвать следующий API, чтобы убедиться, что у учетной записи текущего пользователя есть разрешения на это, и если он / она это делает, следующие три поля отключены, а остальные пять отображаются в правом столбце, последнее выделено красным, вместе с обновленным значком главного меню в элементе «Ограничения учетной записи». Однако, если пользователь использовал все свои кредиты и больше не имеет разрешения делать ставки по более чем 15 пунктам, система должна отобразить всплывающее окно со следующими четырьмя полями, последние два доступны только при следующих условиях… »

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

Становится лучше. Вы хотите дать своим подписчикам пробный период на месяц. Что, если кто-то зарегистрируется, воспользуется какой-нибудь дорогой услугой, например. отправляет массовые сообщения, говорит, что он / она не интересен, закрывает учетную запись и снова регистрируется с другого IP-адреса? Надо отслеживать контент (имена записей, адреса электронной почты, местоположение и т. Д.), Верно? Если этого было недостаточно, абсолютно все должно быть исправимо и обратимо, например большая часть расходов должна быть возмещена, на самом деле ничего не удаляется, так как клиент может сказать «упс» и попросить вас «восстановить» и т. д. и т. д.

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

Мои маркированные списки становятся более подробными по мере того, как я открываю и вспоминаю больше логических элементов. Например. Фраза «обновить значок меню» сначала кажется достаточно простой, но когда я начну ее реализовывать, я буду спрашивать: «Подождите секунду ... Как мне рассчитать этот значок? Подсчитывает ли он уже оплаченные лимиты учетной записи или также добавляет кредиты, выданные службой поддержки клиентов? » Хорошо, я не хочу, чтобы твоя голова взорвалась, поэтому я остановлюсь.

Одно интересное наблюдение, которое я сделал в своем самом первом проекте на базе Px100, заключалось в отсутствии другой, более технической, но простой логики программирования (по сравнению с бизнес-логикой, ориентированной на предметную область, описанной выше): так называемого «сантехнического», известного как «клей-код». ». Нас учат устранять (скрывать) как можно больше технической сантехники, что дает нам возможность работать над драгоценной бизнес-логикой - единственной, которая имеет значение для клиента. Типичным примером логики программирования является перевод данных из одного формата в другой, потому что некоторые базы данных или сторонние API ожидают плоский список вместо объектно-ориентированной иерархии и наоборот. Другой пример - выполнение вызовов библиотеки или API в определенной последовательности для постепенной обработки данных или вычисления чего-либо.

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

Можно ли целый день работать с бизнес-логикой? Может ли человек дышать чистым кислородом? Вы знаете, что ограничивает текущие характеристики истребителя, то есть радиус боевого разворота? Не мощные двигатели с векторной тягой. Не прочность планера. Способность пилота выдерживать маневры с большой перегрузкой. Так что, хотя я не думаю, что «передача» Px100 слишком высока, это чертовски неудобно. У меня просто нет другого способа добиться успеха, кроме как уснуть, крутить педали на более высокой передаче и доставить что-то, команда из 100 человек не может - получить мой приз. В то время как другие неспешно «изобретают» Facebook и Snapchat или соревнуются с бесплатными приложениями для заполнения форм Zoho.

В индустрии программного обеспечения было множество попыток устранить «некоммерческую» логику - обычно как наивное желание избавиться от программирования, превратив разработку программного обеспечения в самостоятельную деятельность для «опытных пользователей». Оказалось, что все «упрощенные» бизнес-ориентированные языки, начиная с их дедушки COBOL и заканчивая отполированным Java-подобным Salesforce Apex, по-прежнему имели переменные, операторы if и циклы, непонятные для самых умных компьютерно-грамотных «пользователей», и, следовательно, по-прежнему требуются программисты. «Упрощение» только усложнило программирование, убрав сложные инструменты, на которые полагаются профессионалы.

Представьте себе обычные автоматические трансмиссии с гидроприводом в гоночных автомобилях - в попытке популяризировать Формулу 1, сделав ее любимым видом спорта в футболе. Потому что эти чертовы гонщики зарабатывают слишком много. Я не сноб-компьютерщик. Пока настоящий ИИ не заменит программистов, они все еще будут нужны миру. Пусть профессионалы выбирают себе инструменты промышленного класса. Это то, что я сделал с Px100 - решил ту же проблему (устранив техническую сантехнику) способом программиста. Как я уже сказал, результат оказался несколько неожиданным.

После достаточного количества алхимии Spring, OOP и FP я нашел правильный рецепт, чтобы полностью скрыть технические детали внутри конфигурации. Теперь мне нужно было беспокоиться только о бизнес-логике, то есть написать тысячу строк кода, посвященных в среднем 100 бизнес-правилам (10 строк на каждый фрагмент бизнес-логики). Против. те же 1000 строк обычного кода в день, которые охватывают в лучшем случае только 10 бизнес-правил вместе со всеми вручную запрограммированными шаблонными техническими деталями. Мы запрограммированы подсознательно оценивать нашу работу по кодированию. Мне плохо, если я напишу всего 100 строк кода, охватывающих одни и те же 10 бизнес-правил. Теперь, если бы я все еще работал на этого человека, я, вероятно, ограничился бы этими 10, не платя ноль за дополнительные работы. Но сейчас я сам себе худший босс, и я хочу делать больше, оплачивая непосредственно мои клиенты.

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

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

Опять же, это соотношение моих личных усилий и вознаграждения. Во что бы то ни стало, расскажите мне о своих планах разбогатеть, расслабляясь. Непринужденная жизнь в кабинах 90-х, как я уверен, несколько десятилетий назад, была эм ... аутсорсингом. Я не думаю, что сегодняшние ведущие разработчики из США даже заслуживают свои 150–180 тысяч долларов - половину заработной платы до аутсорсинга с поправкой на инфляцию. Меня сильно озадачило, почему мне платили 90 долларов в час (180 тысяч долларов), когда я приехал в США в 1996 году - за написание шаблонной ерунды DAO и DTO и отчитывание часов. Тайны больше нет. Обезьяны кода за 5 долларов в час (20–50 долларов за час) делают это теперь, а «архитекторы» за 90 долларов в час обеспечивают надзор и устраняют все неизбежные беспорядки. Я «подписался на это дерьмо» (цитируя Мишель Родригес из «Аватара») только первые пару лет в США. Я хочу делать (и зарабатывать) больше.

Теперь другой вопрос, сможете ли вы «сделать больше» с помощью традиционных технологий, обслуживающих раздутые команды посредственных разработчиков, занятых набором шаблонного связующего кода. Остерегайтесь: если вы пойдете моим путем и разработаете более продвинутый инструмент, вы не уйдете на пенсию, продав его Oracle или кому-либо еще в сети Great IT Consulting Food, ориентированной на численность персонала. Не говоря уже о Google, которому наплевать на тяжелое корпоративное программное обеспечение с бизнес-логикой. Они не будут знать, что делать с вашим велосипедом с более высоким оснащением. У вас не будет выбора, кроме как взять свое специальное оборудование и начать крутить педали на более высокой передаче.