▍ Страдание
На момент написания этой статьи на моих часах 21:30.
Этим утром я проснулся в хорошем, оптимистичном настроении, рассчитывая на прекрасный день, но теперь вымотан.
Я вымотан не физически, а, скорее, разочарован тем, что, несмотря на все имеющиеся у нас замечательные технологии, позволяющие писать наилучшее ПО, мы, как люди, профессионально пишущие код, по множеству причин склонны ценить больше сложность, а не простоту.
Если конкретнее, при написании или поддержке кода мы склонны постоянно попадать в ловушку случайной сложности. Я наблюдал это с первого дня попадания в эту отрасль, и эта тема стала основной темой моей презентации, посвящённой техническому долгу (Purging the Technical Debt by Using Static Code Analysis Tools на YouTube).
На появление во мне любви к разработке ПО чрезвычайно сильно повлиял Фредерик Брукс, написавший сборник эссе под названием Мифический человеко-месяц.
В этой книге Брукс проливает свет на два типа сложности, очень хорошо вербализованных Эдрианом Колье в его блоге The Morning Paper постом No Silver Bullet — essence and accident in software engineering:
Брукс рассматривает сложности, возникающие при разработке ПО, и разделяет их на два вида: принципиальные сложности, которые неотъемлемо связаны с природой ПО; и случайные сложности, когда мы усложняем жизнь себе больше, чем это необходимо, и сложность при этом не является неотъемлемой для процесса. От случайных сложностей мы можем постепенно избавиться, но принципиальные остаются всегда.
▍ Допущение
Как я сказал ранее, мы не будем перечислять причины, по которым склонны направлять наш код на территорию неожиданной сложности, но я ненадолго углублюсь в эту тему.
Люди — не роботы. Мы эмоциональные существа. У нас бывают взлёты и падения. Мы
не понимаем полностью всего, за что берёмся, а иногда делаем свои допущения истиной. К тому же мы ленивы и непредсказуемы. Всего этого должно быть достаточно, чтобы понять или представить, почему при написании кода мы обычно стремимся двигаться по лёгкому пути, приводящему нас в город неожиданной сложности.
Но в то же время мы и увлекающиеся существа.
Мы стремимся уделять время пониманию вещей, обучению, удовлетворению своего любопытства, попыткам, неудачам, творчеству, совершенствованию, совместной работе. Мы стремимся быть лучше, чем были вчера, и планируем заранее, чтобы завтра становиться лучше, чем сегодня.
И мы умные.
Мы очень умные.
Но в то же время ленивые, непредсказуемые, эмоциональные и так далее.
▍ Предложение
Умные люди выполняют свои задачи, больше полагаясь на воображение, чем на ум. Столкнувшись с проблемой, они позволяют креативности и воображению решать её так, как это будет наиболее выгодно с точки зрения времени, денег и других важных для них ресурсов. Последние части проблемы могут быть решены при помощи разума, который по большей мере является сплавом опыта, мудрости, проб, успехов, провалов и знания.
Мы склонны искать короткие пути, позволяющие нам попасть из точки А в точку Б за наименьшее время, наименьшим количеством усилий и некой обоснованной гордостью за то, что короткий путь оправдал себя.
Например, если вы хотите улучшить качество кода, то выбираете придерживаться принципов программирования SOLID. Я согласен с принципами и идеями SOLID. Лично я считаю, что резюмировать их основу можно как корректную реализацию объектно-ориентированного программирования со стремлением правильно делать правильные вещи. Однако когда я занимался консалтингом, то заметил, что многие люди восхваляют принципы SOLID, не уделяя внимания их ценностям, что часто приводит к созданию хрупкого кода (по перечисленным выше причинам). Когда я просил их сформулировать своими словами то, что они по-настоящему понимают в SOLID, то обычно получал неполные, неструктурированные, неуверенные ответы. Возможно, так получалось потому, что большинство принципов немного абстрактно.
Умные люди обычно обладают способностью объяснять сложные или абстрактные понятия людям любых возрастов. Вульгаризируя и применяя метафоры, они способны аккуратно объяснить сложное понятие даже ребёнку. И все мы знаем, что если ты можешь объяснить что-то ребёнку, а ребёнок понимающе кивает, то велика вероятность того, что ты сам хорошо понимаешь тему, которую только что рассказал.
А как насчёт такого предложения: что, если мы используем свой «ум», чтобы просто писать STUPID-код. Код, настолько STUPID, что если бы компилятор мог генерировать эмоции, то вы бы увидели слёзы, льющиеся с монитора, а колонки воспроизвели бы звук громких аплодисментов. [Прим. пер.: stupid в переводе с английского — «глупый».]
Так что же я вам предлагаю? Что это за STUPID?
Ну, это довольно просто. Первая буква и расшифровывается как simple [«простой»].
▍ S расшифровывается как SIMPLE
Какое-то время назад я написал статью Замедлитесь. Выполняйте задачи быстрее. В ней я рассказал о важности замедления для лучшего понимания того, что вы делаете. Если достаточно замедлиться, то можно достичь своей цели не только быстрее (потому что вам не придётся откатываться назад или вносить ненужные изменения), но и проще.
Этот более простой путь позволит вам изменять код на основании постоянно меняющихся требований, которые ждут вашу систему в будущем. На мой взгляд, это и есть настоящее определение адаптивности.
И ниже я расскажу о том, как метод STUPID продвигает адаптивность интуитивно понятным образом.
По сути, нужно поддерживать простоту кода, избегая «необходимости» добавления неожиданной сложности и увеличения технического долга без веской причины.
Помните популярную аббревиатуру KISS? Keep it simple, STUPID.
▍ T означает TESTABLE («тестируемый»)
Допустим, вы можете доказать, что код работает сегодня, но, возможно, не сможете доказать этого завтра, когда в кодовую базу будет добавлен побочный эффект. Поэтому тесты должны быть основной частью кодовой базы.
Будь то юнит-тесты или интеграционные тесты, обращайтесь с ними с тем же уважением, что и с ремнями и подушками безопасности, когда едете по опасному шоссе с окружающими вас непредсказуемыми водителями. Потому что именно через это придётся пройти вашему коду в среде исполнения. Перестаньте предполагать, что что-то работает. Вместо этого потратьте время на доказательство того, что это работает. Благодаря этому, вы сможете продолжать развивать свою кодовую базу, зная, что любые допущения, сделанные в прошлом и вносимые сегодня, по-прежнему остаются истинными.
Хотите быть адаптируемым? Пишите тесты. Без тестов вы можете считать, что движетесь быстро, но это заблуждение. Или вы движетесь быстро, но в обратном направлении, или вы будете двигаться быстро, но потом столкнётесь с преградой, которая доставит вам больше неприятностей, чем простой откат назад.
Пишите простой (SIMPLE) и тестируемый код (TESTABLE). Это уже достаточно хорошее направление, позволяющее придерживаться agile-программирования.
▍ U означает Ubiquitous («повсеместный»)
Эта идея была изложена Эриком Эвансом в его новаторской книге Domain-Driven Design: Tackling Complexity in the Heart of Software. Это один из моих любимых аспектов, которые необходимо учитывать при программировании.
Повсеместно используя язык на основе модели и не останавливаясь, пока он не будет работать чётко, мы приближаемся к полной и исчерпывающей модели, составленной из простых элементов, которые в сочетании выражают сложные идеи.
…
Специалисты в предметной области должны бороться с элементами или структурами, которые неуклюже или неадекватно передают понимание предметной области; разработчикам следует отыскивать двусмысленности и несогласованности, запутывающие архитектуру.
Какой бы объект вы ни создавали в своей кодовой базе, убедитесь, что он или минимизирует, или, что ещё лучше, полностью устраняет нюансы и неоднозначность, которые могут возникнуть у читающего код. Помните, что вы пишете код не для удобства компилятора, компилятор не позвонит вам посреди ночи, чтобы рассказать, насколько великолепен ваш код. С другой стороны, вам может позвонить коллега во время его ночного дежурства, чтобы задать вопрос, зачем вы добавили объект X, имеющий в кодовой базе то же самое значение, что и объект Y, но без понимания побочных эффектов X.
Это неожиданная сложность, и она очень неприятна.
Предпринимайте усилия к тому, чтобы сохранять во всей кодовой базе один язык. Если вы выберете язык предметной области, тем лучше. При обсуждении X с клиентом убедитесь, что это тот самый X, который присутствует в коде. Чётко и осознанно именуйте объекты (классы, методы, свойства, типы, модули и так далее.)
Если вы не знаете, как что-то назвать, то есть вероятность, что вы не понимаете, чего хотите достичь. В игре отсутствует кусок пазла. Но это нормально. Потратьте время на поиск этого куска, поговорив со специалистами в предметной области или с людьми, имеющими необходимые знания в предметной области. Пазл можно собрать лишь тогда, когда в наличии есть все его фрагменты.
▍ P означает Proper («чистый»)
Мы принимаем душ, чтобы избежать болезней и проблем с кожей, а ещё чтобы хорошо пахнуть. Мы чистим зубы, чтобы не тратить слишком много денег на стоматолога, но в первую очередь для того, чтобы избежать неожиданных осложнений с кариесом и другими заболеваниями.
Итак, принцип вы поняли. Быть чистым — хорошо. Но дело не только в этом. Чистым быть важно. И в той же степени это применимо к вашей кодовой базе. Мы чистим то, то нам важно, поэтому нам нужно прибраться в своей кодовой базе, потому что мы прикладываем к ней много усилий, а она в ответ приносит нам ещё больше пользы.
Баланс этой пользы всегда должен быть положительным.
Поддерживая чистоту кода, вы мотивируете других уважать и ценить его; но ещё важнее то, что это позволяет быстрее его менять. Видите, как принцип STUPID снова обеспечивает адаптивность кодовой базы? Вам по какой-то причине нужно отрефакторить части кода в шаблоны? Никаких проблем, чистый код встречает такие изменения с распростёртыми объятиями.
Недавно на работе один и тот же разработчик писал мне во время пул-реквеста одни и те же комментарии: "Код плохо отформатирован. После фигурной скобки должно быть два пробела."
Поэтому я решил автоматизировать форматирование всей кодовой базы, интегрировав в неё этап линтинга. Проблема решена. Теперь этот разработчик может делиться в пул-реквестах чем-то более конструктивным. Но он был прав, важно заботиться об эстетических деталях кодовой базы.
А ещё важнее то, что это позволяет читателю разбираться в коде. Как говорилось выше, мы пишем код не для компилятора, а для читателя. Для бедного человека, которому придётся поддерживать или менять вашу кодовую базу, пока вы в отпуске или уже уволились. А может быть, для себя в будущем. Пишите код так, чтобы будущий вы был благодарен прошлому себе, принявшему решение почистить код.
▍ I означает Incremental («инкрементный»)
Однажды я услышал фразу Кента Бека, запечатлевшуюся в моей памяти:
Заставь это работать. Сделай это правильно. Сделай это быстрым.
Недавно я дал себе разрешение добавить в этот список ещё один пункт.
Сделай это лучше.
Или на каждой итерации, или в каждый возможный момент, даже оптимизировав свой код до невозможности, позволь себе поразмыслить о том, как сделать его лучше. Возможно, лучше тестируемым? Или лучше портируемым на другие платформы? Что бы в вашем понимании ни делало его лучше, возьмите на себя ответственность сделать его таким.
Мы не пишем ПО с нуля. Для создания ПО, точно так же, как для и сборки пазла, нужно время и инкрементные усилия. Инкрементность может возникнуть из-за изменений в требованиях или же из-за новой фичи или исправления ошибки.
Если вы стабильно обеспечиваете простоту, тестируемость, повсеместность и портируемость кода, то его легко создавать инкрементно. Кирпич за кирпичом. Получая всё более глубокие знания в предметной сфере, осваивая технологии, вы совершенствуете кодовую базу, повышая её ценность.
Если вы разработчик, то помните, что нужно создавать систему инкрементно. Прочитайте ещё раз цитату Кента Бека. В ней говорится об инкрементном подходе к созданию ПО. Необязательно сделать всё за первый день. Рим не за день построили, то же самое относится и к вашей системе.
Не спешите.
Двигайтесь медленно, чтобы завершать быстрее.
▍ D означает Decoupled («несвязный»)
Невозможно легко тестировать систему, сильно привязанную к внешним сервисам — базе данных, сторонней системе или Интернету.
Невозможно выполнять быструю разработку на локальной машине, если ваш код привязан к подобным жёстким зависимостям. Если не верите мне, то спросите моего коллегу, что он думает об отладке нашей системы, связанной с SAP-сервисом в Висконсине. Поверьте, ему совсем невесело.
Отвязывайте зависимости от системы. В прошлом я освоил архитектурный шаблон Entity-Control-Boundary, основанный на гексагональной архитектуре.
Мне он нравится.
Настолько сильно, что при помощи этой методики я разработал Cloudgenda. Я соло-разработчик этого SaaS-проекта и уверен, что могу быстро и непрерывно повышать ценность системы для клиентов благодаря тому, что ни одна из зависимостей не связана напрямую с внешними сервисами. На самом деле, каждая зависимость открыта и обрабатывается через объект Port and Adapter и реализуется с инъецированием зависимостей через конфигурацию. Благодаря этому, я могу очень легко тестировать свою кодовую базу и при желании рефакторить. К тому же с ней приятно работать.
Всё это рука об руку идёт с буквой D из принципов SOLID, которая расшифровывается как Dependency Inversion Principle (принцип инверсии зависимостей). Но этот принцип также можно применить к изолированию таблиц баз данных при их денормализации. Или когда вы правильно используете парадигму объектно-ориентированности, выбирая в некоторых случаях композицию вместо наследования. Мы можем назвать это «логическим изолированием», но преимущества этого такие же, как и при «физическом изолировании».
▍ В заключение
На моих часах уже 23:30, и я уже достаточно устал, чтобы идти спать.
Но прежде я бы хотел повторить, что разработка ПО не должна быть сложной. И на самом деле она не сложна. Это интересное и приятное занятие. Но оно иногда становится сложным из-за «случайных» решений, пробуждающих весь этот хаос, который мы называем «неожиданной сложностью».
Именно она замедляет вас, когда вы пытаетесь двигаться быстро. Именно она толкает вас вниз, когда вы стремитесь ввысь. Именно она заставляет вас смотреть вакансии в LinkedIn, когда вы готовы отказаться от работы над кодовой базой на текущем месте работы. Возможно, стоит дать себе шанс… а ещё лучше, дать шанс STUPID.
Возможно, однажды вы будете рассказывать на конференции о методике STUPID. И если это произойдёт, я, наверно, буду там в этой футболке, потому что знаю, что она работает.
А если серьёзно, когда вы пишете код, помните, что вы пишете его для будущего себя и для других. Потратьте своё время сейчас, чтобы сделать ваш код здоровым живым существом в цифровом мире, где он может постепенно стать ценным вкладом в наш мир и наши жизни.
Вы умны. А умные программисты пишут STUPID-код, потому что это умный способ писать код.
Узнавайте о новых акциях и промокодах первыми из нашего Telegram-канала ????
Комментарии (69)
johnfound
18.10.2023 13:33+5А кто сказал, что профессионал должен делать свою работу хорошо? Профессионал должен только и всего получать деньги за свою работу. Нет никаких других требований.
Некоторые думают, что плохо работающий профессионал со временем перестанет быть профессионалом, из за всяких там рынков, конкуренций и т.п. Но реальный мир полон некомпетентных профессионалов и они никуда не исчезают.
Так что автор объясняет очевидное – профессионал с большей вероятностью напишет рутинно-плохой код, чем отличный. В лучшем случае – рутинно-никакой.
MinimumLaw
18.10.2023 13:33+18Хм... Я, в нулевых, наблюдал с каким упоением автомеханники, всю жизнь занимающиеся отечественным автопромом, ковыряли немцев 70-80х годов выпуска. "Надо же - все как мы привыкли, и все для человека!". Никаких тебе гаек, отвернуть которые можно только на заводе. Никаких хитрых мест, куда полезть можно только заранее загнутой арматуриной...
Умение делать "для людей" - оно дорогого стоит. Что до избыточной сложности, то тут есть о чем поговорить с автором. В общем случае уровень сложности решения должен четко коррелировать с уровнем сложности задачи. И, безусловно, всегда помня о том, что решение "на века" невозможно почти никогда. А значит те, кто придут за тобой (включая тебя самого, только более опытного) должны понимать сделанное.
По мне именно это является признаками отличного кода.
CrazyElf
18.10.2023 13:33+10"Код пишется один раз, а читается много раз", как говорится. Поэтому нужно экономить время читающего и писать так, чтобы было понятно.
copist
18.10.2023 13:33+4Многие части моего кода вообще никто никогда не читал. Работает и работает.
doctorw
18.10.2023 13:33+16Значит требования к нему у Вас не менялись никогда, такое бывает далеко не всегда и не со всеми.
MinimumLaw
18.10.2023 13:33+5Варианты есть
код написан Богом на священных скрижалях и редактированию не подлежит по определению, а всех несогласных сжигают
код проще переделать даже не читая, чем исправлять
все забили на оптимизацию работы и живут по принципу "работает - не мешай"
вы единственный разработчик (как минимум допущенный до того кода) и эта ситуация целенаправленно поддерживается
код создан для морально устаревшего решения, которое давно надо заменить. Но все ждут пока жареный петух не клюнет, а он как назло не торопится
Может еще что-то. Вообще есть расхожая фраза про исключения, которые только подтверждают правило. Но, и с ними, если покопать поглубже, обычно все оказывается очень интересно.
demimurych
18.10.2023 13:33+2Еще чаще єтот код выполняется. Так может код нужно писать так, чтобы он єффективно выполнялся, а не читался?
BlackSCORPION
18.10.2023 13:33+1Не весь код выполняется достаточно часто чтобы его оптимизировать в ущерб читаемости.
Обычно для этого осуществляют перфоманс тестирование, чтобы выявить какой именно код стоить оптимизировать.
Можно сделать код быстрее в любом месте, даже во всех. Но в 99.9% случаев это абсолютно никак не повлияет на скорость конечного продукта, лишь на энергоэффективность которая сэкономит копейку инфраструктурному провайдеру но вам он её не зачтет так что такое себе развлечение, если ты супер активный эко активист то норм.
johnfound
18.10.2023 13:33+18ковыряли немцев 70-80х годов выпуска. "Надо же - все как мы привыкли, и все для человека!". Никаких тебе гаек, отвернуть которые можно только на заводе.
Вы вообще видели как ремонтируется автомобиль, или только слышали??? Немецкие (и вообще западные) машины полны тонких мест и условно «гаек, которых не открутишь без специального инструмента». На их фоне, у русских машин ремонтопригодность на высшем уровне.
alexkuzko
18.10.2023 13:33+2Тут видимо про осознанность в первую очередь. Т.е. вещи логичны, даже когда видишь что сэкономили. Конечно, сейчас машины не те что раньше, сложность больше, удельная стоимость ниже, отсюда и проблемы с качеством...
Urvin
18.10.2023 13:33+15На самом деле, от немецкой техники я поражен тем, что:
1. Есть подробный мануал. На заводе прямо составили, и для конкретной модификации.
2. Если нужен хитровыделанный ключ для откручивания хитровыделанной гайки - у него будет номер и его можно заказать и забрать в магазине. Искользовать арматуру или самоделки - себе дороже.
3. Мануал создан для откровенных мартышек. Если ты умеешь читать и понимать, что прочел - справишься.
4. Есть моменты затяжки всех гаек, винтов и болтов, написано чем почистить, где нанести и какой фиксатор резьбы..
GospodinKolhoznik
18.10.2023 13:33+8Просто у них есть очень подробный мануал по сборке машины на заводе. И выдержки из него они выпускают в качестве мануалов по ремонту. А то, что в мануалах к жигулям не указано с каким моментом силы нужно крутить гайку, так это потому, что этой информации нет даже у сборщиков - на заводе крутят кто во что горазд (если вообще крутят, а не забирают кувалдой)
johnfound
18.10.2023 13:33+2Нельзя забить болт кувалдой. Вот возьмите, попробуйте и убедитесь сами.
GospodinKolhoznik
18.10.2023 13:33+1Но если взять болт резьбой чуть поменьше...
johnfound
18.10.2023 13:33+1Нет болтов резьбой чуть поменьше. Они стандартизованы. Болт поменьше не надо забивать, он сам свободно войдет в гайку.
IvanPetrof
18.10.2023 13:33Если вкручивать болт не в гайку, а в нарезанную в отверстии в детали резьбу, то можно нарезать резьбу стандартизованным метчиком в отверстии чуть большего диаметра, чем положено. Тогда болт вполне можно забить кувалдой. Особенно, если материал детали с резьбовым отверстием несколько мягче чем материал болта.
Задача решена?))
johnfound
18.10.2023 13:33+1Нет, не решена. Попробуйте сами. Болт. Кувалдой. Опубликуйте снимки и числовые данные эксперимента.
IvanPetrof
18.10.2023 13:33-1без проблем.
Берём пластиковую деталь,
сверлим отверстие
нарезаем резьбу
Наживляем металлический болт на пару витков резьбы
Добиваем молотком
Prоfit
Я много раз так делал. Процесс не снимал. Не думал, что кому-то это будет интересно. Уж извините.
IvanPetrof
18.10.2023 13:33Вот видите, вы уже начинаете понимать принцип (принцип "злого джинна")).
На самом деле достаточно алюминия и чуть бОльшего чем положено отверстия (раз уж болты у нас стандартные).
На каждый стандартный болт можно найти чуть большее чем нужно сверло из стандартного ряда свёрл (плюс есть стандартный ряд нестандартных китайских свёрл))
Пластик я взял для более наглядной демонстрации, (чтобы обойтись без фото-видео)
johnfound
18.10.2023 13:33Как говориться, если джентльмен не может выиграть по правилам, он их меняет. Сэр.
IvanPetrof
18.10.2023 13:33Сэр, в процессе нашей беседы вам несколько раз было озвучено про различные свойства материалов. Вы несколько раз это проигнорили акцентировав свои требования лишь на
Болт. Кувалдой
так же уточнили, что
Нет болтов резьбой чуть поменьше. Они стандартизованы.
всё это было учтено. про диаметр отверстия, как и про свойства материалов, от вас возражений не последовало вплоть до финала спора, где вы поняли, что они тоже имеют значение (собственно, показать это и было целью "спора").
При всём уважении, Сэ-э-р..
Vladimirsencov
18.10.2023 13:33+2В люминтий можно. В сталь не забьешь. Проверено. Привет из Тольятти.
iig
18.10.2023 13:33-1Да никто не забивает болты кувалдой. А вот мимо резьбы закручивают очень легко.
johnfound
18.10.2023 13:33+5Мануалы о ремонте западных автомобилей обычно выпускают совсем не производители, а независимые издательства. Например Haynes. И они их пишут сами, разбирая и собирая автомобили в своих мастерских. Кстати мне кажется что о русских и советских автомобилей тоже есть такие книжки – я их читал. Хорошо помню, что когда отец купил Москвич, к нему была довольно объемистая книжка о поддержки и легкого ремонта, а также комплект инструментов. Покажите мне один современный автомобиль с инструментами.
Urvin
18.10.2023 13:33У нас также есть такие инструкции от всяких мелких издательств.
Конкретно по Ваш пример не скажу, но наши по части изложения и рядом не стояли с сухим немецким - много ничего не значащих картинок и ноль объяснений, например, где какой болт найти.
И у меня талмуд именно от производителя, Published by BMW Aftersales.
Tempelfeld
18.10.2023 13:33+1К отечественной технике точно такие же мануалы. Да, попадаются поверхностные, но это от того, что на рынке слишком много мануалов, выпускают все, кому не лень. По крайней мере, однажды я смог по мануалу перебрать движок уазика и тормозную систему. Это был мой первый опыт автомеханика.
Urvin
18.10.2023 13:33+15
На самом деле, оцените просто случайную иллюстрацию, здесь изображена часть процесса располовинивания двигателя.
Мне нравится, что, во-первых, видно где сидят болты, во-вторых - какие именно. И, если я захочу положить все болты, которые у меня есть, в пакет, и перетрясти пятнадцать раз- а я непременно это сделаю - я все равно найду, чем собрать мотор обратно.
И вот, что я могу найти по части ремонта российской тачки. Субъективно оценю издательство как относительно крупное, по числу книг по ремонту разных марок.
И, замечу, что у этой серии автомобиля было 7 вариантов двигателей - по чуть-чуть разных.
iig
18.10.2023 13:33Кто-то вкладывается в написание документации, кто-то генерирует ее автоматически.
MinimumLaw
18.10.2023 13:33+1Вы вообще видели как ремонтируется автомобиль, или только слышали???
У меня было да Opel'я. Ascona 1989-ого и Omega 1994-ого года. Ascona была сделанной для людей девяткой, Omega такой же Волгой. И это не мои слова. Это слова тех, кто ремонтировал в основном отечественное. А под специальным инструментом понимался не ключ под специальную голову (вот тут как раз сложность, соответствующая поставленной задаче), а изыски типа головки, наваренной на согнутую в двух местах арматурину. Если вы реально видели как ремонтируют отечественные автомобили (даже на официальном сервисе) то с подобным инструментом должны быть знакомы. Но в целом - "Залез в карман куртики. Там ключ на 10 аккумулятор отключать, маленькая отвертка карбюратор регулировать, на всякий случай еще большая отвертка и банка WD'шки. Opel - это не машина, это стиль жизни". Известная шутка тех времен с OpelClub'а. Продолжать надо?
А еще была ОКА... Не сама плохая их отечественных машин. В силу размера не сильно сложная. И так же перебиралась и ремонтировалась. Так что с чем сравнивать лично мне точно есть... И сравнение сильно не в пользу отечественного автопрома. При всей любви немцев к "звездочкам" и не самым стандартным шестигранникам.
P.S.
И как, блин, в программировании. Вот ни разу, за все время владения немцами, мне не попался в заказе ни один болт со слизанными гранями или кривой резьбой. Все прокладки идеально подходили к деталям, а конструкции узлов и агрегатов не мешали работе ключей и головок с воротками. Что это, как не продуманная архитектура?
Kanut
18.10.2023 13:33+1При всей любви немцев к "звездочкам" и не самым стандартным шестигранникам.
Просто в Германии они как раз стандартные. Потому что гораздо более удобные.
MinimumLaw
18.10.2023 13:33Да, я оценил. Бог с ними, с шестигранниками, но звезды реально хороши и реально практичнее шестигранных головок. Но я не специалист в механике, потому кроме собственного мнения ничего предъявить не могу. А оно, как известно, всегда субъективно.
DMGarikk
18.10.2023 13:33+1. Потому что гораздо более удобные
(вспоминаю как откручивал сорванные винты с сорванными гранями у шестигранника)
гораааздо удобнее...его фиг выкрутишь и сорвать грани в разы проще
Kanut
18.10.2023 13:33В разы проще чем у крестовины или плоского шлица? Вы серьёзно?
DMGarikk
18.10.2023 13:33+1у звезды точек приложения усилия больше, её тяжелее сорвать (только её надо именно звездой откручивать, а не шестигранником как иногда некотрые делают)
а у шестигранника, хиленькие бортики которые на раздва слизываются... я в этих винтах потом плоский шлиц вырезал и отверткой плоской выкручивал..иначе только высверливать
Kanut
18.10.2023 13:33Я не знаю что у вас были за шестигранники. Но по моему опыту крестовины или шлицы сорвать намного проще. Особенно если крутить чем-то "электрическим".
MinimumLaw
18.10.2023 13:33В Опеле были болты (винты?) в головкой в виде звезды-папы. Вот они реально лучше, чем шестигранные в жигулях. Единственный вопрос - это набор соответствующих воротков. А уж когда заменил все, которые до меня крутили "чем было" включая шестигранные ключи - вообще счастье наступило.
Шестигранник был в единственном месте - у тормозного суппорта. Но по тем временам подходящий с трудом удалось найти только у велосипедистов и берег его очень серьезно. Так с машиной и продал.
Что до винтов во звездами или шестигранниками мамами... Ну не знаю. Оно, возможно, и лучше, но... В не самых ответственных местах я бы все же предпочел крест. Шестигранник хорош для мебельных, а звезда в качестве секретки, чтоб абы кто не залез. Особенно со штырьком посередине.
Но опять - это исключительно мое мнение.
Urvin
18.10.2023 13:33В сорванный шестигранник вбивается звезда, дальше откручиваете согласно мануалу.
SUNsung
18.10.2023 13:33Вот как раз вы видимо только "слышали")
Я не говорю про современные автомобили массового потребления - там цена стоит впереди всего.
Вот как раз таки немцев-бмв нулевых годов. Да нужно читать мануалы (неожидано правда?) но в остальном все очень доступно, интуитивно понятно и самое главное разбирается и собирается без кувалды и лишних деталей. Как икея. Только пять таки нужно в правильной последовательности разбирать (мануалы)
Промышленая техника тех годов вообще пример и зерцало того как нужно делать.
И относительно кода то же самое. То что сейчас на рынке переизбыток говнокодеров не есть хорошо. Выпускаются лаганые продукты с кучей "детских" болячек, 80% которых решантся на уровне правильно написаного кода.
Появление тестирование для кода позволило говнокодерам цвести и пахнуть, так как большую часть косяков за них найдет тесты и можно даже не задумыватся о том как оно работает и как должно.
DMGarikk
18.10.2023 13:33+2Хах, а я про японца могу пример привести
Да, конечно гайки все откручиваются ничего не закисает это всё так, но некоторые решения сделаны...какбы..
вот был у меня MMCLancer 98 года, европейский. и нужно мне стало поменять магистрали топливную и тормозную...а для этого надо снять двигатель с коробкой!! просто потому что оно не рассчитано на то что ктото её будет менять, а на заводе из собирают именно в этом порядке, плюс еще (я так понимаю особенность японцев) то что кузов унифицирован под правый и левы руль и коммуникации соответственно проложены как под правый но адаптированы к левому...и тормозные магистрали под капотом делают поворот на 90 градусов и подходят к ГТЦ...из за чего их невозможно извлечь никак только вытащив двигатель и сняв кучу проводов трубок и рулевую рейку..хотя если бы они проходили по своей стороне то проблем бы не было
(я конечно её туда с дикими матюгами и изгибая - засунул...не в сэсэср чтоле родился.....опыт после жигулей остался)
zac04
18.10.2023 13:33+2на это есть старая фраза:
-любой дурак может написать хороший грамотный кусок кода используя все особенности языка вероятно даже близкий к идеалу по производительности.
-только профессионал способен написать нормально работающий код понятный дуракам без объяснения.
p.s. дурак понятие условно собирательное описывающего некоего сео/пм/манагера который очень давно что то слышал о данном коде но уже много лет не работавшего с кодом нигде.
tonymictian
18.10.2023 13:33ковыряли немцев 70-80х годов выпуска
А если бы ковыряли форды, говорили бы по-другомуMinimumLaw
18.10.2023 13:33Может быть и так. Но с Итальянцами так не получилось. Красивые внешне, они отвратительны внутри. Да и "разойдись, Америка без тормозов летит" в эфире дальнобоев и до сих пор совсем не редкость. Потому может быть, а может и не быть...
WVitek
18.10.2023 13:33+4Имхо, невозможно решить действительно сложную (объёмную) задачу простым кодом.
Ну разве что задача, которая кажется сложной, на деле таковой не является.
Можно сказать, что действует "закон сохранения сложности"))
Т.е. реализовать решение сложной задачи можно следующими вариантами:
- долго думать* и по результатам размышлений написать достаточно простой код (но стороннему наблюдателю "не в теме" он может показаться сложным);
- сразу начать писать очень простой код, но его будет очень много (сложность в объёме кода);MonkAlex
18.10.2023 13:33Об этом и речь. Не надо делать сложную систему, выполняющую сложные задачи.
Нужно сделать комплексную систему, делающую много маленьких простых задач.
ПС: что всё равно плохо работает с быстро меняющимся бизнесом, к слову.
rtemchenko
18.10.2023 13:33+7Чет звучит как "Делайте как надо, а как не надо не делайте". Практические рекомендации слишком абстрактные.
Кодобаза поддерживаемая одним человеком скорее всего не сильно большая, потому понимать и поддерживать ее просто. Попытайтесь заскейлить это на проект в котором больше 5 разработчиков, и внезапно окажется, что у вас несколько понятийтого, чот такое лучше, тестируемость, и т.д.
Andruh
18.10.2023 13:33+4Очередное переливание из пустого в порожнее. Ни одной новой мысли (да он и сам везде ссылается). Просто натягивание совы на новый нужный автору акроним.
А вот будет абстрактный программист писать STUPID, будет ли у него SOLID - ещё большой вопрос.
funca
18.10.2023 13:33Просто натягивание совы на новый нужный автору акроним
У Дяди Боба такие трюки раньше хорошо получались. SOLID теперь на каждом углу. Интересно, чего нехватает нонейму из интернета, чтобы его акроним так же растиражировали?
demimurych
18.10.2023 13:33+1Может быть образования?
К примеру, солид дяди боба, єто попытка адаптировать естественные для функционального программирования обстоятельсва, к реалиям императивного программирования.
Стоит ли сообщить дяде Бобу, о его манипуляции с акронимами?
funca
18.10.2023 13:33+2адаптировать естественные для функционального программирования обстоятельсва, к реалиям императивного программирования
Поистине, искусство это не то, что делал творец, а то, что воспринимает зритель).
У него на странице есть ссылки, где до сих пор доступна история возникновения SOLID. Парни просто трындели в своем доисторическом чатике обо всём хорошем. Начинали кажется с 20 принципов, но посчитали такое количество непрактичным и оставили 7. А поскольку в слове SOLID только 5 букв, то лишние отсекли уже те, кто растаскивал на цитаты. Это чистой воды конструкт - мем, а не какие-то основы.
Bone
18.10.2023 13:33-1Автор просто заставил читателей впустую потратить несколько минут времени на чтение его полностью бесполезной статьи про то, как он придумывает сокращения.
antmihlin
18.10.2023 13:33+1Отличная статья. Спасибо за перевод.
Последнее время часто думаю на эту тему и внедряю в код. Искренне не понимаю зачем усложнять. Но почему-то многие программисты, даже опытные имеют тенденцию усложнять.
rusik2293
18.10.2023 13:33+1Усложняют от незнания как сделать просто, например в университете я прошел тему про if else, а switch пропустили, пришлось писать сложный для чтения код
Или как с задачами на алгоритмы, самый производительный код обычно выглядит проще всего
vvbob
18.10.2023 13:33+1Понятненько.. Автор, что-бы упростить разработку, вводит еще одну новую аббревиатуру для собеседований.
КМК только опыт, бесчисленное количество набитых шишек и написанного кода, подскажет тебе когда можно и нужно писать максимально тупо и примитивно, а когда стоит заморочиться и написать сложно. Все эти длинные статьи полезны только в плане того что дают повод задуматься и поднимают саму проблему, но готового решения они не дают.
fishHook
18.10.2023 13:33+3В слове STUPID букв больше чем в SOLID, а по сути постулируются те же самые принципы, но более многословно, расплывчато и неконкретно. "Отвязывайте зависимости от системы." - ну офигеть совет, а как я это должен соединить с выше декларированным "избегайте «необходимости» добавления неожиданной сложности"? Ну, блин, товарищ, чтобы избежать связности мне придется вводить слои абстракции, например, как вы же советуете "Entity-Control-Boundary". Это не добавление сложности? А что? А как мне руководствуясь вашей статьёй понять, это уже "лишняя" сложность или ещё нет? Думаю, что отвечая на вопрос, вы начнете аппелировать к опыту, чутью, здравому смыслу и прочим спорным понятиям и вкусовщине. Мне вообще кажется, что автор сначала придумал броское словечко, а потом вымучил более-менее осмысленные определения для каждого. Я так в детстве стихи сочинял - сначала рифмы придумывал, а потом заполнял строфы чем угодно, главное чтобы хоть как-то по смыслу подходило.
FadeToBlack
18.10.2023 13:33+2Заставь это работать. Сделай это правильно. Сделай это быстрым.
А я для себя придумал принцип. "Камень-ножницы-бумага". Просто сделай (тяжелый и большой камень). Ножницы-рефакторинг. Бумага - оптимизация (легкость). Только вот я понял, что вся эта философия вокруг кода - это личные муки каждого. Все эти буквы, принципы, паттерны. Когда ты встречаешь разработчика, который пишет совсем не так, как ты привык, у него скобки на другой строке, чем у тебя, и амперсанды со звездочками он прилепляет с другой стороны. А ты попал к нему в проект. Ты попал. Или он к тебе. Он попал. На этом заканчивается обычно KISS и dependency injection или там SOLID. Просто пиши код "как надо". Ну а главное - DRY (Do Not Repeat Yourself!)funca
18.10.2023 13:33Заставь это работать. Сделай это правильно. Сделай это быстрым.
Это довольно популярный в прошлом мем https://wiki.c2.com/?MakeItWorkMakeItRightMakeItFast. Хотя в переводе на русский звучит непривычно.
igrishaev
18.10.2023 13:33Опять: простыня текста без малейшего примера. Разбирайтесь как хотите: что читабельно, а что нет, что тестируемо, а что нет.
Rampages
18.10.2023 13:33Что-то мне подсказывают, что кто-то любит всякие аббревиатуры KISS, DRY, YAGNI, SOLID and etc ???? ну будет одной больше STUPID...
Еще сразу вспоминаю рассказыв про советсткие СВЯЗКО и ПЕРДА ????
ReadOnlySadUser
Сломался здесь) Слишком корявый перевод)