Введение
это сборник мыслей о разработке программ собранный разработчиком с мозгом груга
разработчик с мозгом груга не очень умный, но разработчик с мозгом груга программирует много лет и научился кое чему, хоть всё равно часто запутывается
разработчик с мозгом груга хочет собрать знания в маленькую, простую и интересную страницу не только для тебя, молодой груг, но и для себя, потому что разработчик с мозгом груга стареет и забывает важные вещи, например что ел на завтрак или надеть штаны
разработчиков с большим мозгом много, некоторым страница не понравится, скривят кислая рожа
Ещё больше-больше ДУМАЮТ, что они разработчики с большим мозгом и им она тоже не понравится
(груг раньше думал груг с большим мозгом, но потом всё понял)
это ладно!
груг надеется, что тебе понравится читать и может ты научишься на много-много ошибка груг совершил за длинную жизнь программиста
Вечный враг: сложность
главный охотник на груга это сложность
сложность плохо
скажу снова:
сложность очень плохо
теперь ты скажи сам:
сложность очень, очень плохо
если выбрать между сложность и биться с динозавром, груг выбери динозавр: груг хотя бы видеть динозавра
сложность это демон дух, в кодовую базу его пускают добрые но просящие дубину не груги и менеджеры проектов которые не боятся демона духа сложности или иногда не знают про него
один день кодовая база понятная и груг может делать работу, всё хорошо!
другой день невозможно: демон дух сложности попал в код и очень опасная ситуация!
груг не может видеть демона сложности, но груг чувствует что он в кодовой базе
демон дух сложности дразнит сделай изменение здесь сломай в другом месте не понять где и почему!?! смеётся ха ха смешно очень
груг любит программировать, а не собирать блестящие камни как старший советчик груга
дубина не ломает демона духа сложности, а плохая идея бьёт дубиной разработчика впустившего духа: иногда это сам груг!
жалко, часто это сам груг
поэтому груг говорит и говорит часто: сложность очень, очень плохо
Говорить «нет»
лучшее оружие против демона духа сложности это заклинание «нет»
«нет груг не пишет эту фичу»
«нет груг не делает эту абстрацию»
«нет груг не моет тело каждый день и не пьёт меньше чёрной жижи для мыслей хватит повторять»
помни это хороший совет для разработчика но плохой для карьеры: «да» это заклинание чтобы получить больше блестящих камней и тебя назначить вождём большого племени разработчиков
грустно но правда: научись «да» потом обвиняй других гругов когда не получится, лучший совет для карьеры
но груг должен быть настоящий груг, а «нет» заклинание груга. Сначала сложно говорить, особенно если добрый груг и не любит разочаровывать людей (много таких гругов!) но потом проще хотя куча блестящих камней будет не такая большая
это ладно: разве гругу нужно много блестящего камня?
Говорить «ладно»
иногда компромисс нужен или нет блестящего камня, то есть нет мяса динозавра, нехорошо, жена твердит гругу маленьким гругам нужно крыша, еда, так далее, не хочет пятнадцатый раз слышать груг сердится на демона духа сложности
в этой ситуации груг рекомендует «ладно»
«ладно, груг пишет эту фичу»
потом груг долго думает о решении 80/20 задачи и пишет его.
решение 80/20 значит решение «80 что нужно в 20 код»: может быть не все звенелки которые хочет менеджер проекта, может быть немного кривой код, но работает и делает почти что нужно, и почти всегда отгоняет демона духа сложности
может иногда лучше не говорить менеджеру проекта и делать 80/20. проще просить прощение чем разрешение, иногда менеджер проекта как золотая рыбка устаёт от работы с много гругов. часто забывает что должна делать фича, берёт другую работу или увольняется или его увольняют: груг видел много таких случаев
но обычно в интересах менеджера проекта чтобы груг не очень огорчался такому подходу
Факторизация кода
следующая стратегия очень сложнее: правильно разбивать кодовую базу (красивое другое слово: «правильно факторизировать код»)
тут сложно давать общий совет: каждая система разная. но одно груг знает: не факторизуй приложение слишком рано!
в начале всё в проекте очень абстрактное и как вода: очень мало веток за которые может хвататься мозг груга. постепенно разработай «форму» системы и узнай что вообще происходит. груг пытается не факторизировать проект рано, рано или поздно в кодовой базе появляются линии для разреза
хорошая линия для разреза имеет узкий интерфейс с остальной системой: маленькое количество функций или абстракций прячут демона сложности внутрь, как будто он попался в кристалл
гругу нравится когда демона сложности ловят в кристалл. лучше некуда поймать смертельного врага!
груг пытается терпеливо ждать появления в коде линий для разреза и медленно рефакторит, а кодовая база постепенно с опытом принимает форму. тут нет точных правил: груг узнаёт линию разреза когда видит линию разреза, учись смотреть и терпению
иногда груг торопится и делает неправильную абстракцию, поэтому груг лучше подождёт больше
разработчики с большим мозгом часто это не любят и изобретают много абстракций с начала проекта
груг хочет схватить дубину и орать «большой мозг не поддерживает код! большой мозг уходит в другой комитет по архитектуре а груг возись с кодом!»
но груг учится управлять чувствами, основное различие груга и животного
вместо этого груг пытается снизить опасность разработчика с большим мозгом в начале проекта дав ему что-нибудь наподобие UML-диаграммы (не вредит коду, наверно, её всё равно выбросят) или потребовав сделать завтра рабочее демо
рабочее демо очень хорошая хитрость: заставляет большой мозг сделать то, что можно обсудить и посмотреть на код, помогает большому мозгу быстрее увидеть реальность
помни! у большого мозга большой мозг! его нужно ограничивать только для добра а не помогать демону духу сложности, такое много раз бывало
(лучший мозг груга может гнать стадо большого мозга в нужном направлении и делать много кристаллов ловушек для демона сложности, большая куча блестящих камней ждёт такого груга!)
иногда называй демо «прототипом»: менеджеру проекта так приятнее
груг говорит: делай прототип в начале разработки, особенно если много больших мозгов
Тестирование
груг любит и ненавидит тест: тест экономит гругу много бесчисленного времени и груг любит и уважает тест
жалко что есть много шаманов тестов. некоторые шаманы тестов делают из тестов идолов, требуют «делай тесты» ещё когда груг не начал писать код или когда груг ещё не знает хорошо область применения!
как груг тестирует если груг ещё не понимает область применения?
«не бойся: тесты покажут что тебе нужно делать»
груг снова сдержал груга медленно берущего дубину, но груг остаётся спокойный
груг предпочитает писать большинство тестов после этапа прототипа, когда код начинает становиться чётче
но хорошо запомни: тут груг должен быть очень дисциплинированный!
груг легко может пойти дальше и не писать тесты потому что «всё работает на машине груга»!
оно очень, очень плохо: нет гарантии работы на другой машине, нет гарантии работы на машине груга в будущем, много раз
шаман тестов правильно говорит о важности теста, даже если шаман тестов за всю жизнь не сделал ничего полезного готового и только всегда говорит о тесте, заслуживает дубины, но сердце его доброе
ещё шаман тестов часто говорит про юнит-тесты, но груг не думает, что они очень полезные. опыт груга говорит, что идеальные тесты это не юнит-тест и не сквозной тест, а промежуточный тест
юнит-тесты хорошо, ладно, но ломаются после изменения реализации (совсем как api!) и делают сложным рефакторинг, к тому же многие баги всё равно из-за взаимодействия с другим кодом. часто приходится выбрасывать, когда меняется код.
груг пишет юнит-тест в основном в начале проекта, помогает развитию, но не привыкай к ним и не ожидай долговременную пользу
сквозные тесты хорошие, показывают работу всей системы, но! сложно понимать когда ломаются и очень часто злят груга, иногда груг просто перестаёт обращать на них внимание потому что «ой, всегда ломаются» — очень плохо!
груг слышал, шаман называет промежуточные тесты интеграционным тестированием, иногда с кислой рожей. но груг считает, что интеграционный тест лучший по мнению груга: достаточно высокий уровень, чтобы хорошо тестировать правильность системы, достаточно низкий уровень, чтобы с хорошим отладчиком легко видеть что сломалось
груг предпочитает немного юнит-тестов, особенно в начале, но тест не 100% всего кода и точно не «сначала тест». «тест по ходу дела» вполне подходит гругу, особенно пока груг разбирается в системе
груг пишет самые свирепые интеграционные тесты когда появляются точки разреза и система стабилизированная! api линии разреза обычно стабильнее реализации и интеграционный тест остаётся полезный много длинное время и легко отлаживать
ещё полезный хорошо проверяемый набор сквозных тестов чтобы работал постоянно. главное делай важный сквозной тест для самых общих фич UI и нескольких самых важных пограничных случаев, но не очень много иначе становится невозможно поддерживать и потом бросают
оно идеальный набор теста для груга
ты можешь не любить, но это лучшее тестирование груга
ещё гругу не нравится mock-объект в тесте, нужен только в крайнем случае (редко/никогда) и при грубом макетировании (линий разреза/систем), только так
одно исключение для нелюбимого гругом «сначала тестируй»: когда нашёл баг. груг всегда пытается сначала воссоздать баг при помощи регрессионного теста, потом устранять баг, только такой способ почему-то работает лучше
Agile
груг думает agile не плохой и не хороший
не худший способ организации разработки, может лучше других, которые груг считает хорошими
но опасный шаман agile! много, много блестящих камней потеряно из-за шамана agile!
agile-проект развалился, шаман agile говорит «вы неправильно делаете agile!» груг считает, это ужасно удобно для шамана agile: можно просить больше блестящих камней улучшать agile обучать молодых гругов agile, опасность!
груг хочет взять дубину когда слишком много говорят про agile, но всегда остаётся спокойный
чтобы успешно делать программы, лучше писать прототипы, инструменты и нанимать хороших гругов: agile-процесс ладно и помогает кому-то, но иногда ущерб воспринимают слишком серьёзно. никогда нет серебряной дубины, что бы ни говорил шаман agile (опасность!)
Рефакторинг
рефакторинг хорошее дело и часто хорошая идея, особенно попозже, когда код уже сформировался
однако много раз в карьере груга «рефакторинг» выходил из под контроля и давал больше вреда, чем добра
груг не знает, почему один рефакторинг делается хорошо, другой проваливается, но груг заметил, чем больше рефакторинг, тем больше опасность провала
поэтому груг пытается делать относительно небольшой рефакторинг и «не отплывать слишком далеко от берега» при рефакторинге. в идеале система работает постоянно и каждый этап заканчивается до начала другого.
здесь спасают сквозные тесты, но очень сложно понять почему ломаются… такая жизнь при рефакторинге.
ещё груг заметил, что добавление слишком много абстракции приводит к провалу рефакторинга и системы. хороший пример внедрение J2EE, много больших мозгов сидело и придумало слишком много абстракции, ничего хорошего не вышло и навредило многим проектам
ещё хороший пример когда компания, где работает груг, внедрила OSGi, чтобы управлять/ловить демона духа сложности в кодовой базе. OSGi не только не помог, но и сделал демона сложности намного сильнее! пришлось потратить много человеко-лет лучших разработчиков для переделки! больше духа сложности и теперь фичи невозможно реализовать! очень плохо!
Забор Честертона
мудрый шаман груг честертон однажды сказал
Такое может происходить в случае какой-то установки или закона; давайте ради простоты представим поставленные на дороге забор или ограду. Современный реформатор беспечно подойдёт к ним и скажет: «Я не вижу в них пользы; давайте снесём их». На это более умный реформатор ответит: «Если вы не видите в них пользы, я точно не позволю их снести. Отойдите и подумайте. Когда вы вернётесь и скажете мне, что увидели, в чём их польза, то я, возможно, позволю их снести».
многие старый груг хорошо выучили этот урок не начинать ломать код не подумав, даже если он страшный
груг понимает все программисты в чём-то платонисты: хотят в коде слышать идеальную музыку сфер. но здесь опасность, часто-часто мир уродливый и некрасивый, такой и код должен быть
смирение не часто есть у большого мозга или кто считает себя большой мозг и даже у груга, но груг часто знает «гругу не нравится, груг надо исправить» приводит к много часов мучений и система может стать не лучше а хуже
в начале карьеры груг часто нападает на кодовую базу дико размахивая дубиной и ломая всё, научись это плохо
груг не говорит не улучшать системы никогда, это глупо, но советует потратить время понять систему сначала, особенно большую систему и уважать работающий сегодня код пусть не идеальный
здесь часть тесты хорошо показывают почему забор нельзя ломать!
Микросервисы
груг не понимает зачем большой мозг берёт самую сложную задачу, правильно факторизует систему и добавляет сетевой вызов
очень непонятно для груга
Инструменты
груг любит инструмент. инструмент и управление чувствами отличает груга от динозавров! инструмент позволяет мозгу груга делать код который без него не может быть, думает за груга, всегда хороший помощник! в новом месте груг всегда тратит время на изучения окружающих инструментов для максимизации продуктивности: изучил инструменты две недели часто делает разработку дважды быстрее и часто заставляет просить других разработчиков о помощи, нет документации
дополнение кода в IDE позволяет гругу не запоминать все API очень важно!
программирование на java почти невозможно без этого для груга!
из-за этого груг начинает задумываться
хороший отладчик ценен как много блестящих камней, а на самом деле даже больше: когда нашёл баг груг часто хочет отдать все блестящие камни и может немного детей за хороший отладчик
груг всегда советует новому программисту изучать отладчик очень хорошо, фичи вроде условных контрольных точек, вычисления выражений и другое
груг говорит никогда не переставай улучшать инструменты
Системы типов
груг очень любит системы типов упрощают программирование. для груга системы типов самая польза когда груг нажимает точку на клавиатуре и магией открывается список что может сделать груг. это 90% пользы от системы типов для груга
но здесь бойся больших мозгов!
некоторые большой мозг думают системами типов и говорят леммами, могут быть очень опасные!
большой мозг шаман систем типов часто говорит главное в системе типов корректность типов, но груг заметил что некоторые большой мозг шаман систем типов не часто выпускает готовый код. груг думает наверно корректный код это который никогда не выпустят, но груг понимает корректный код не совсем так
груг говорит главная польза системы типов магический инструмент показывает что можно делать и дополнение кода, корректность тоже хорошо но не так как помогательный инструмент и не так, как думает большой мозг
ещё бойся: опасная абстракция слишком высокая, а код типа большого мозга становится астральная проекция платонической обобщённой модели вычислений тьюринга в кодовой базе. груг запутан и согласный какой-то уровень очень изящный но с ним очень сложно делать реальные задачи например записать количество дубин для компании «Груг и сыновья»
дженерики здесь особенно опасные, груг старается ограничить дженерики классами-контейнерами чаще всего так самая большая польза
соблазн очень больших дженериков это ловушка! демон дух сложности любит эту ловушку! берегись!
всегда самая польза от системы типов такая: нажимай точку смотри что груг может сделать, не забывай!
Сложность выражений
раньше груг любил сокращать количество строк кода. писал такой код:
if(contact && !contact.isActive() && (contact.inGroup(FAMILY) || contact.inGroup(FRIENDS))) {
// …
}
потом груг понял это трудно отладка, научился надо писать так:
if(contact) {
var contactIsInactive = !contact.isActive();
var contactIsFamilyOrFriends = contact.inGroup(FAMILY) || contact.inGroup(FRIENDS);
if(contactIsInactive && contactIsFamilyOrFriends) {
// …
}
}
груг слышит крики молодых гругов — ужас много строка кода дурацкая переменная, груг готов защищаться дубиной
начинается бойня дубинами другие разработчики нападают и груг кричит: «проще отладка! вижу результат каждого выражения и имя хорошее! проще понимаю условное выражение! ПРОЩЕ ОТЛАДКА!»
отладка точно проще и когда бойня дубинами закончилась успокоились и молодой груг подумал и понял груг прав
груг всё равно ловит себя пишет код как первый пример и часто жалеет, поэтому груг не осуждает молодого груга
Замыкания
груг любит замыкания где полезно, а полезно обычно абстрагирование операции с коллекцией объектов
груг предупреждает замыкания как соль, системы типов и дженерики: немного хорошо, но легко портит вещи если много и даёт рано инфаркт
разработчики javascript называют особого демона духа сложности в javascript «callback hell», потому что очень много замыкание используют библиотеки javascript. очень печально но груг правда считает разработчики javascript получают что заслуживают
Логирование
груг большой любитель логирования и говорит всем давай логируй, особенно в облаке. некоторые не груги говорят логирование дорогое и не очень важное. груг так не думает больше
смешная история: идол груга роб пайк работает в google над логированием, груг решил: «если роб пайк работает над логированием, зачем гругу это делать?!?», не стал заниматься. оказывается логирование очень важное для google, поэтому конечно над ним работает лучший программист, груг!
не будь таким мозгом груга, теперь гораздо меньше блестящих камней!
ладно, груг всё равно нашёл хорошую компанию, а роб пайк одевается
всё страннее, так что всё удачно, но смысл не меняется: логирование очень важное!
советы груга про логирование:
логируй все основные логические ветвления в коде (if/for)
если «запрос» распространяется на несколько машина в облачной инфраструктуре, добавь на все ID запроса, чтобы логи можно группировать
если можно сделай логи динамически управляемыми, чтобы груг мог включать/отключать когда нужна отладка проблем (много!)
если можно сделай уровень логирования для каждого пользователя, чтобы можно отлаживать проблему конкретного пользователя
два последних пункта особенно удобная дубина очень часто когда охотишься на баги в продакшен-системах
жаль библиотеки логов часто очень сложные (java, зачем так?), но надо вложить усилия сделать инфраструктуру логирования правильно — опыт груга говорит очень сильно полезно потом
груг думает логирование надо больше учить в вузах
Конкурентность
груг как все разработчик в своём уме, боится конкурентность
груг старается как можно больше использовать простые модели конкурентности, например, обработчики stateless-веб-запросов и простые очереди воркеров удалённых задач, где задачи не взаимозависимые и простой api
для веба подходит оптимистичная конкурентность
иногда груг пользуется локальной переменной потоков, особенно когда пишет код фрейворков
в некоторых языках есть хорошая структура конкуретных данных, например ConcurrentHashMap в java, но всё равно чтобы сделать правильно нужна аккуратная работа груга
груг никогда не пользовался erlang, слышал хорошие слова, но гругу язык выглядит странный, простите
API
груг любит хорошие api. хорошие api не требуют чтобы груг слишком много думал
жалко многие api очень плохие, заставляют груга много думать. причин много, вот две:
создатели API думают о реализации или области применения API, а не об использовании API
создатели API думают слишком абстрактно и как большой мозг
обычно гругу не важно подробности api: нужно записать файл или отсортировать список, просто хочет вызвать write() или sort()
но разработчики api большой мозг говорят:
«не торопись, груг! открываешь этот файл для записи? ты определил Comparator для сортировки?»
груг снова хватает свою руку которая тянется к дубине
пока ему не важно это всё, просто хочет сортировать и записывать файлы, мистер большой мозг!
груг понимает дизайнер api большой мозг в чём-то прав и иногда это важно, но часто нет. разработчики api большой мозг лучше если проектировать для простых случаев с простым api, делать сложные случаи возможными с более сложным api
груг называет это «многослойный» api: два или три разных api с разным уровнем сложности для разных нужд груга
ещё если объектно-ориентированный, добавь api на элемент, а не в другое место. хуже всех в этом java!
груг хочет фильтровать список на java
«Ты преобразовал его в поток?»
ладно, груг преобразовал в поток
«Хорошо, теперь можно фильтровать»
хорошо, но теперь нужно вернуть список! а есть поток!
«Ты собрал свой поток в список?»
что?
«Определи Collector<? super T, A, R>, чтобы собрать поток в список»
груг клянётся могилой предка будет бить дубиной каждого в комнате, но считает до двух и остаётся спокойный
добавь обычную вещь типа filter() для списка и пусть возвращает список, слушай меня разработчик java api большой мозг!
никому не нужен «поток» и никто не слышал про «поток», не сетевой api, все груги java используют списки мистер большой мозг!
Фронтенд-разработка
некоторые не груги, имея дело с веб-разработкой говорят:
«Знаю, я разобью кодовую базу на фронтенд и бэкенд и использую новую крутую SPA-библиотеку, общающуюся с бэкендом GraphQL JSON API через HTTP (это забавно, потому что я не передаю гипертекст)»
теперь у тебя есть две норы для демона духа сложности
хуже: демон дух сложности фронтенда стал ещё сильнее и управляет всей отраслью фронтенда, как видит груг
бэкенд-разработчики стараются не усложнять и могут работать хорошо, но фронтенд-разработчики делают очень сложно очень быстро и добавляют много кода, демона духа сложности
даже когда веб-сайту нужно просто положить форму в базу данных или простой сайт брошюра!
сейчас все так делают!
груг не знает зачем может так говорят facebook и google, но для груга это не очень хорошая причина
гругу не нравятся большие сложные фронтенд библиотеки, которые все используют
груг делает htmx и hyperscript чтобы без них
низкая сложность, простой HTML, без много javascript, это отпугивает демона сложности
может они тебе подойдут, но не для карьеры, простите
react лучше для карьеры и некоторых приложений, но ты становишься служителем демона сложности, хочешь или нет, такая жизнь фронтенда