Разработчик с мозгом груга +164



Введение


это сборник мыслей о разработке программ собранный разработчиком с мозгом груга

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

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

разработчиков с большим мозгом много, некоторым страница не понравится, скривят кислая рожа

Ещё больше-больше ДУМАЮТ, что они разработчики с большим мозгом и им она тоже не понравится

(груг раньше думал груг с большим мозгом, но потом всё понял)

это ладно!

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

Вечный враг: сложность


главный охотник на груга это сложность

сложность плохо

скажу снова:

сложность очень плохо

теперь ты скажи сам:

сложность очень, очень плохо

если выбрать между сложность и биться с динозавром, груг выбери динозавр: груг хотя бы видеть динозавра

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

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

другой день невозможно: демон дух сложности попал в код и очень опасная ситуация!

груг не может видеть демона сложности, но груг чувствует что он в кодовой базе

демон дух сложности дразнит сделай изменение здесь сломай в другом месте не понять где и почему!?! смеётся ха ха смешно очень

груг любит программировать, а не собирать блестящие камни как старший советчик груга

дубина не ломает демона духа сложности, а плохая идея бьёт дубиной разработчика впустившего духа: иногда это сам груг!

жалко, часто это сам груг

поэтому груг говорит и говорит часто: сложность очень, очень плохо

Говорить «нет»


лучшее оружие против демона духа сложности это заклинание «нет»

«нет груг не пишет эту фичу»

«нет груг не делает эту абстрацию»

«нет груг не моет тело каждый день и не пьёт меньше чёрной жижи для мыслей хватит повторять»

помни это хороший совет для разработчика но плохой для карьеры: «да» это заклинание чтобы получить больше блестящих камней и тебя назначить вождём большого племени разработчиков

грустно но правда: научись «да» потом обвиняй других гругов когда не получится, лучший совет для карьеры

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

это ладно: разве гругу нужно много блестящего камня?

Говорить «ладно»


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

в этой ситуации груг рекомендует «ладно»

«ладно, груг пишет эту фичу»

потом груг долго думает о решении 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 лучше для карьеры и некоторых приложений, но ты становишься служителем демона сложности, хочешь или нет, такая жизнь фронтенда

Мода


груг заметил много моды в разработке, особенно сегодня в фронтенде

бэкенд лучше скучнее наверно все плохие идеи уже проверены (некоторые пытаются повторить!)

в фронтенд разработке продолжают пробовать все плохие идеи поэтому много меняется и сложно понимать

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

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

Страх выглядеть глупо


помни! очень хорошо если груг сениор может сказать всем: «хммм, это слишком сложно для груга!»

многие разработчики боятся выглядеть тупой, груг раньше тоже боятся, но груг научился бороться: очень важный груг сениор говорит «это слишком сложно и запутанно для меня»

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

убрать силу страха очень хорошо для сениор груга

но помни: надо делать мыслительное лицо и казаться большим мозгом. будь готов большой мозг или чаще думает он большой мозг сарказм говорит про груга

сильный будь! не надо страх!

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

Синдром самозванца


груг замечает много таких чувств самозванца в разработке

груг всегда одно из двух состояний: груг хозяин вся равнина, носит дубину кода как тор ИЛИ груг не понимает что происходит

больше времени груг второе состояние, но нужно его прятать

груг делает сильные программные обеспечения и успех в open source, но сам груг часто не понимает вообще что происходит! очень часто! груг всё ещё боится сделать ошибку поломать код всей команды и разочаровать других гругов, самозванец!

это может само программирование такое для большинства гругов и лучше сказать тут ладно: никто не самозванец, если все самозванец

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

Почитать


гругу нравятся эти:


Вывод


сам скажи: сложность очень, очень плохо




Комментарии (69):

  1. FD4A
    /#24480062 / +21

    И я груг.

    • tvr
      /#24480092 / +17

      И ты, груг?!

      • vya
        /#24481344 / +3

        И, он - груг.

        • Javian
          /#24482028 / +2

          Груг гругу друг
          Это знают все вокруг
          Понятно всем, как дважды-два,
          Нет добрее существа

  2. nikweter
    /#24480088 / +7

    А я всегда думал что Грут.

  3. ACO-Andrew
    /#24480096 / +11

    Who the fuck is «груг»?

    • PatientZero
      /#24480114 / +7

      Портрет автора в начале статьи

  4. dayslar
    /#24480108 / +5

    Это божественно

  5. ABy
    /#24480192 / -1
    • atomlib
      /#24480818 / +6

      По той же причине, что ставите ударение в слове «виски» на первый слог.

  6. FLU911
    /#24480230

    Топчик)Текст на цитаты)

  7. Aleksandr-JS-Developer
    /#24480264 / +8

    демон дух сложности дразнит сделай изменение здесь сломай в другом месте не понять где и почему!?! смеётся ха ха смешно очень

    Хватило серьёзного фейса ровно до этих слов. Идеально подходит для мема с собакой, которая делает больно по-другому

    А вообще, некоторое "слабоумие" и "лень" при написании кода естественным образом оберегает умного и не очень разработчика.
    Лень писать гигантскую абстракцию, лень её потом поддерживать, да и не совсем понятно, как её написать. А если уметь вовремя включить антигруга и побыть им на пару минут - вообще можно сказать сеньор.

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

    Однозначно к прочтению и неоднократно) Автор гениален)

  8. milkground
    /#24480400 / +41

    Как глоток свежего воздуха среди статей "Любая_компания уходит из РФ" , "Как мы в нашей_крутой_компании делаем крутые_штуки в крутой_команде" и гонке переводов зарубежных авторов. Даже немного старым Хабром повеяло.

    • Fartzilla
      /#24480632 / +2

      В любой нормальной стране автора бы уже посадили за дискриминацию гругов.

      • Dabbuger
        /#24483726

        шутка же вроде? зачем минусы

    • FanatPHP
      /#24480670 / +4

      А вы точно уверены, что этот автор не зарубежный? :)

      • milkground
        /#24481434 / +8

        Автор то зарубежный, но я не совсем про это. Этот текст переведён в первую очередь потому, что он интересный, нестандартный и определённо заслуживает внимания. Если бы он не был переведён, то его определённо бы стоило перевести. А в корпоративных блогах переводы делаются из-за контент-плана. Достаточно посмотреть количество статей в профиле публикующих, чтобы понять о какой гонке я говорю. Очень часто там попадаются вторичные статьи, темы которых были пережёваны миллион раз. Более того, там иногда попадаются статьи, которые уже были переведены и опубликованы на Хабре.

        • FanatPHP
          /#24481820

          Ну в этом смысле я с вами конечно согласен на все сто.

  9. Aleks_ja
    /#24480616 / +9

    сложность плохо

    скажу снова:

    сложность очень плохо

    теперь ты скажи сам:

    сложность оченьочень плохо

    И в чём груг не прав? :)

    • Akon32
      /#24481096 / +1

      "Сложные проблемы требуют сложных решений"...

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

      • dizatorr
        /#24482386 / +5

        Всё гениальное - просто. (с) Груг.

      • iRumba
        /#24483278 / +1

        Сложную проблему можно разбить на множество простых

        • agoncharov
          /#24487384 / +5

          Тогда само разбиение может оказаться сложным

          • iRumba
            /#24487706 / +1

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

    • movl
      /#24481442 / +2

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

      • Aleksandr-JS-Developer
        /#24482674 / +1

        Как-то один крутой дизайнер сказал, что сложность в простоте.

        Можно запросто обвесить интерфейс кучей кнопочек, баннеров и панелей. Можно их стилизовать, расставить как по учебнику, вымести баги и очень сильно оптимизировать.

        А вот выкинуть всё лишнее и оставить, условно, пару кнопок и одну панель - вот это действительно сложно.

  10. akadenis
    /#24480634

    Слегка забавный, и слегка полезный текст. Или наоборот.

    • не груг не понимай груг, это нормально. гругу как бы пофигу

  11. arheops
    /#24480752 / +3

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

    • взрослый груг бери дубину и бей всея вокруг со спокойно лицо

      • arheops
        /#24484524 / +1

        Груг с большой мозг не любят когда их бить дубина.
        Шаман не любит когда их бить дубина.

        • Aleksandr-JS-Developer
          /#24487276 / +2

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

  12. N1versdack
    /#24480780 / +1

    Спасибо синьор груг, и
    >сложность очень, очень плохо

  13. GothicJS
    /#24480936

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

    груг делает htmx и hyperscript чтобы без них

    низкая сложность, простой HTML, без много javascript, это отпугивает демона сложности

    А вот кто бы рассказал, как так получилось, что логика с бэка перетекла на фронт ? Какие то демоны подшаманили)

    • sainomori
      /#24481362 / +17

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

    • Rinsewind
      /#24482672 / +3

      Груг держать логика в серверный коробка, но динамическое обновление и сортировка таблиц вынуждает тащить логику на фронт

  14. romandeveloper
    /#24481468 / +8

    че это вообще было?)

  15. Xander_d
    /#24481482 / +3

    Великолепно.

    Отправил всем своим гругам.

  16. SadOcean
    /#24481546 / +2

    Это просто потрясающе

    Нужно занести в методические материалы

  17. olddeity
    /#24481596 / +2

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

  18. BlackHarold
    /#24481598 / +1

    Груг нравится этот груг!

  19. DungeonLords
    /#24481690 / +1

    Напомнило известный сборник законов с хабра.

  20. Antikiller
    /#24481912 / +3

    я есть груг

    • tvr
      /#24483146 / +1

      Груг есть тебя.

  21. napa3um
    /#24482190 / +7

    Усложнять - просто, упрощать - сложно. (Груг I)

  22. IFITOWS
    /#24482260 / +4

    груг говорить спасибо этот груг
    очень понятный для другой груг письмена про тест

  23. elFurion
    /#24482292 / +2

    хороший отладчик ценен как много блестящих камней, а на самом деле даже больше: когда нашёл баг груг часто хочет отдать все блестящие камни и может немного детей за хороший отладчик

    Это было очень смешно) Однозначно плюс

  24. DmitryKoterov
    /#24482326 / +2

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

    • SharUpOff
      /#24482422 / +1

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

      • doctorw
        /#24482514 / +1

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

        • SharUpOff
          /#24482900 / +1

          Что ещё раз подтверждает, что не бывает универсальных практик :)

    • veydlin
      /#24484462 / +1

      Груг рука тянется к дубине

      • Bobovor
        /#24486184 / +2

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

  25. sexcalibur
    /#24482600 / +1

    спасибо, груг!

    этот груг говорить: сложность оченьочень плохо

  26. IvanFilippov
    /#24483004 / +2

    Эта шедевра стоит многих блестящих камней

  27. event1
    /#24483234 / +7

    Особый респект переводчику. Переводить такие тексты очень не просто

  28. nikitron2021
    /#24483444 / +2

    груг говоритЬ

    груг делатЬ

    Не склонять!

    • akuli
      /#24484718

      Хах, хорошо что я не один об этом подумал. Прям легче стало.

  29. souls_arch
    /#24483662 / +1

    "Если груг оказался вдруг

    И не груг и не враг, а так...

    Если сразу не разберешь

    - Плох он или хорош.

    В разработку тяни-рискни,

    Не бросай одного его..." Спел бы Семеныч, далее допойте сами, дабы не плодить много строк.

  30. Dabbuger
    /#24483730

    Совсем не смог осилить, слишком далеко от меня.

  31. AnthonyMikh
    /#24484288 / +2

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

    Самая вредная мысль в статье. Польза типов простирается значительно шире просто автодополнения.


    добавь обычную вещь типа filter() для списка и пусть возвращает список, слушай меня разработчик java api большой мозг!

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

  32. Arbane
    /#24484468

    Я груг. C# груг. В закладки. Иду дать команда читать

  33. maslyaev
    /#24484760 / +2

    Статья читать от счастья плакать

  34. lartie
    /#24484844 / +2

    абзац про DRY и другие потерялись, молодой и взрослый груг быть полезным читать про другие абзац

    груг вежливо просить продолжений, хвалить автор

    • PatientZero
      /#24486328 / +3

      Не потерялись, просто их в начале процесса перевода ещё не было в тексте. Если обновлений наберётся на ещё один пост, думаю, переведу.