S0ER

Чтобы достичь какой-то цели ее нужно сначала поставить. Это необходимое, но недостаточное условие. Можно, конечно, ни к чему не стремиться и никаких целей не ставить - это личный выбор каждого. Если человеку и так хорошо живется, зачем что-то менять? Но обычно люди сами чувствуют, что нужно что-то менять в жизни, потому что текущее положение не устраивает. Они ставят перед собой какие-то цели, но не знают как их добиться. Я ориентируюсь на тех людей, которые осознали свою потребность и поставили перед собой цель лучше разобраться в программировании и получить навыки создания архитектуры. Я не пытаюсь убеждать сомневающихся, что им нужно что-то менять. И не пытаюсь мотивировать тех, кто явно не хочет ничего менять. Для меня основа достижения любой цели - это постановка и определение промежуточных шагов (слона едят по кусочкам). Поэтому я начал создавать платформу soer.pro и первым делом сосредоточился на постановке целей. Достижение цели - это всегда выполнения простых шагов, желательно при этом выводящих вас за зону привычного комфорта. Поэтому мне нравится формат челленджей - попробуйте сделать то, чего никогда не делали! Для меня основной источник информации - книги. Поэтому я придумал литературный челлендж, ведь если нет привычки читать книги, то она сама по себе не появится. Можно всегда найти причину чего-то не делать (устал, зачем это надо, сделаю завтра), но тогда вы просто зря тратите мое время, пытаясь узнать какой-то тайный способ как стать хорошим программистом, не тратя усилий. Я такого способа не знаю. Я стараюсь показывать какие усилия предпринимаю и в каких направлениях развиваюсь, какие идеи и цели преследую. Чтобы вам было понятно чего можно добиться пойдя тем же путем, что и я. Я знаю что делаю и к чему стремлюсь. Вопрос в том, знаете ли вы свои цели?:

Кажется, что делать что-то регулярно - это просто... Что-ж проверь себя - сможешь ли ты просто закрывать задачу каждый день в течение 2-х недель? Не забывая и не забивая? Челлендж проверяет одновременно и уровень целеустремленности и честности, твой результат - это процент выполнения по итогу двух недель ))))

За время с начала литературного челенджа (3 мая) я успел прочитать или перечитать: - Чистый Код (перечитал) - Создание событийно-управляемых микросервисов (прочитал) - Getting Structured Data from the Internet (прочитал)

Литературный челендж начали более 100 человек, из них закрыли хотя бы одну задачу всего трое...

Вы наверняка слышали фразу "Если вы не можете объяснить это простыми словами, вы не до конца это понимаете", по крайней мере если вы заведете свой ютуб канал и попытаетесь научить людей чему-то сложному, то услышите ее (или прочитаете) много много раз. И здесь кроется когнитивное искажение, которое сами негодующие плохо понимают. А именно "объяснить" и "научить" - это не совсем одно и то же. Хотя в процессе обучения объяснять приходится много раз, но есть существенный нюанс. Объяснить - это значит удовлетворить желание вопрошающего в получении информации, в процессе объяснения нужно опираться на базу знаний, которую имеет человек. Т.е. объяснения не ставит задача - расширить познания человека (если точнее, то предполагается расширить лишь незначительно - дав хоть какое-то представление о предмете вопроса). Научить - значит расширить познания человека до определенного уровня, который можно назвать "квалификацией". Т.е. человек в процессе обучения расширяет свое познание до того уровня, что бы понимать как устроен предмет изучения (по крайней мере в рамках поставленных задач). Естественно "объяснить" и "научить" пересекаются для некоторого множества простых вещей, но для всего множества сложных вещей эти вещи будут абсолютно разными. Например, после объяснения того как устроен двигатель внутреннего сгорания человек не научится его ремонтировать. Поэтому "объяснить простыми словами" я могу, просто это не значит, что человек чему-то научится по итогу э

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

Какой оптимальный тайминг видео для вас? Сегодня записал 40 минут только по принципам рест-ресурсов. И че-то сильно плотно, как по мне.

Тоже побуду душным и добавлю, что я путаю Coupling и Coupling... Бывает же такое...

Вот тут, кстати, правильно про сервер сказано, но более удачного термина я не подобрал. Тут также надо понимать, что "веб-сервер" и "аппаратный сервер" - это разные вещи. И слово server происходит от serve - служит. Я пытался объяснить, что сервис предоставляет законченную функциональность, которая по-хорошему не должна быть частью распределенной транзакции

Как же жить теперь?

Я не люблю когда архитектуру начинают объяснять примерами кода. Во-первых, код содержит кучу деталей и поэтому сложно воспринимать; Во-вторых, в коде могут возникать всякие паразитные зависимости, которые плохую архитектуру могут заставить выглядеть лучше В-третьих, всякие "фишечки" кода (аля декораторы или дженерики) тупо переносят реальную сложность "куда-то еще", а потом никто с этим не может разобраться. Лучше архитектуру описывать и обсуждать в виде принципов (соглашений) и простейших графических представлений (аля "стрелочки и квадратики").

Я в now подписываюсь на всех у кого есть аватарка. Если будите постить фотки, то добавьте аву и я на вас подпишусь.

Айти банда в now потихоньку растёт! Теперь там можно подписаться на крутейшего программиста и музыканта - Дениса ака WestwindGaleaf (надеюсь не напутал)

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

Коротко про «Чистую архитектуру». На днях решил проверить несколько фактов, в «Чистой архитектуре», а в итоге перечитал всю книгу. По мере прочтения сделал несколько записей, которые хочу развернуть в видео на S0ER TALKS. Отмечу, что каждое новое прочтение вызывает все больше вопросов, и понимание того, что многие вещи раскрыты не полностью. Итак, кратки конспект: 1. Мое мнение о книге: отлично подходит для программистов, которые хотят понять влияние архитектуры на код. С позиции разработки именно «архитектуры» мало помогает, так как не рассматривает существенные моменты: сбор и анализ требований, определение векторов развития и т.д. Отлично подойдет для тех кто делает свои пет-проекты, стартапы или мелкую заказную разработку. 2. В книге довольно слабая позиция по построению архитектуры реальных проектов. В моей практике построение архитектуры больше похоже на узловую сборку. Т.е. никто не будет в реальном проекте писать свой «веб-сервер» или писать свою «СУБД». Узлы будут брать готовые, и брать с запасом прочности. Маловероятно, что в большом проекте кто-то скажет «ну нам пока хватает веб-сервера, написанного на коленке, а потом посмотрим». 3. Реальные проекты привлекают архитекторов с профильным опытом, а не строят каждый раз с нуля. Т.е. если вам нужен интернет магазин, то вы позовете человека, который уже разрабатывал интернет-магазин, а не будете сначала строить «интернет-ларек». Именно поэтому ко мне сейчас обращаются за консультациями – я могу на основе опыта сразу сказать где и чего не хватает. 4. «Кричащей архитектуры» на практике я не встречал, вся «информативность» достигается правильной стереотипизацией, если убрать с проекта «надписи», то кроме нагромождения «квадратиков» и «стрелочек» при всем желании не увидишь. 5. Проведение архитектурных границ в маленьких проектах делать особо смысла нет. Даже сам пример FitNesse, который разрабатывался самим «Дядюшкой Бобом» с архитектурной точки зрения плохо структурирован (по файловой структуре проекта не проведешь архитектурных границ), имеет низкий уровень абстракции (всего 0.2, при таком уровне большая часть классов должны быть неустойчивы, чтобы добиться общей стабильности проекта). 6. Отдельно про проект Fitnesse – это обычный пример сильнозацепленного монолита, с позиции архитектуры ничего особенного в нем нет. При уровне абстракции 0.2 у него есть всего два варианта реализации: a. высокое переиспользование интерфейсов (тогда они должны быть «устойчивыми» или сопровождение превратится в Ад), что повышает зацепление на архитектурных границах, и вероятно там есть циклические зависимости (графи зависимостей строить лень). b. Прямое использование и большое количество устойчивых классов (а не интерфейсов как в первом случае). В обоих случаях допустимо только в маленьких проектах, потому что при росте количества команд они тупо начнут друг-другу мешать. 7. Про анализ требований в книге сказано мало, что странно. Потому что, например, пример с использованием файлов, вместо СУБД относится к проекту, где изначально в СУБД предлагалось хранить статические Вики страницы. При анализе требований было бы сразу очевидно, что «преимуществ» для такого типа контента в хранении в СУБД нет. На практике любой архитектор не просто следует моде, выбирая решение, а делает анализ «За» и «Против». И в случае с хранением статических страниц в файлах – это выглядит весьма разумно. 8. Что касается примера с использованием «кластера» вместо более простого «монолита», то опять это проблема анализа требований. В данном случае непонятно почему авторы решили, что им понадобится кластерное решение. Но в итоге решение можно было эксплуатировать (хоть и с кучей доп. Действий) как небольшой монолит, но вот если бы была обратная ситуация «небольшой монолит» вдруг понадобилось бы переделать в «кластерное решение», то проблем было бы в разы сложнее. Но в любом случае ошибка в требованиях и их анализе. У меня возникает только один вопрос: «Что архитекторам сказал бизнес-аналитик?» и был ли он вообще.

Я возобновляю ответы на вопросы, на канале S0ER TALKS, раньше их можно было задавать в Инсте, сейчас можно зайти на platform.soer.pro, в секции "Вопрос/ответ".

Те кто читал "Чистую архитектуру" Роберта Мартина часто упрекают меня в терминологической неточности. Суть в том, что у Роберта Мартина используется иерархия Компонент -> набор классов (или модулей), а я использую иерархию Модуль -> набор компонент, компонент -> набор классов (или пакетов). Все дело в том, что современная разработка разделяется на фронт и бэк, количество команд становится больше, отношения этих команд становятся сложнее и привычного разделения на два уровня (компоненты / классы) уже не хватает. Поэтому проще использовать иерархию трехуровневую (модули, компоненты, классы). Если внимательно прочитать "Чистую архитектуру", то там хорошо видно, что компонент идет из классического процесса компоновки программ, которые редко были "клиент/серверными". Поэтому и связи в их архитектуре были проще, да и сама архитектура была иной, как правило интерактивной. Плюс у меня есть стойкая ассоциация, что модуль больше компонента. Поэтому вам остается только простить и понять меня )