На одном из стримов я уже говорил, что начиная с марта у меня дикая загрузка по консультациям. Многих интересует в чем заключается эта "работа". Большая часть - это анализ технических заданий, выработка ТЭО или ревью уже готовой архитектуры. Почти все из этого - рутинная, условно бумажная (условно, потому что результат в электронном виде) работ. Результатом, как правило, является документ, в котором перечисляется список предложений и замечаний, а так же расчетная часть по основным показателям.
Отмечу, что заметно сложнее стало с выбором технологий и оборудования для реализации АС. Требования поголовно включают импортозамещение и в полной мере данное требование на данный момент не реализуемо. В этой сложности есть своеобразный вызов, который делает работу интереснее, но я по прежнему больше люблю писать код, консультации - это просто способ заработать денег, возвращаться к этой работе на фултайм я не хочу.
На практике использую все те вещи, про которые рассказываю на стримах - декомпозиция, проведение архитектурных границ, распределение обязанностей, выделение абстракций и интерфейсов, управление зависимостями и т.д.
В планах доделать последний отчет, передать ребятам и взять таймаут до сентября. Очень тяжело работать в таком темпе. И тогда появится больше времени на канал и съемку видео, по крайней мере я на это надеюсь.
Отмечу, что заметно сложнее стало с выбором технологий и оборудования для реализации АС. Требования поголовно включают импортозамещение и в полной мере данное требование на данный момент не реализуемо. В этой сложности есть своеобразный вызов, который делает работу интереснее, но я по прежнему больше люблю писать код, консультации - это просто способ заработать денег, возвращаться к этой работе на фултайм я не хочу.
На практике использую все те вещи, про которые рассказываю на стримах - декомпозиция, проведение архитектурных границ, распределение обязанностей, выделение абстракций и интерфейсов, управление зависимостями и т.д.
В планах доделать последний отчет, передать ребятам и взять таймаут до сентября. Очень тяжело работать в таком темпе. И тогда появится больше времени на канал и съемку видео, по крайней мере я на это надеюсь.
👍47🔥9💩1
Проблема с планами, такая же как с тестами - все любят когда план есть, и тебе просто говорят что делать, но никто не любит составлять и продумывать планы, особенно командные.
С тестами тоже самое - классно когда они есть и работают, но делать их самому - брррр....
С тестами тоже самое - классно когда они есть и работают, но делать их самому - брррр....
👍46👎1
Как программисты предсказывали бы погоду:
"В общем, я не особо понимаю как делаются прогнозы погоды, но выскажу свое мнение, вы обязательно проверяйте любое мнение. В общем что я вижу сейчас на небе, сейчас на небе есть облака, а облака это по сути нечто похожее на тучи, а тучи они обычно несут дождь, но бывает и снег, но раз сегодня плюсовая температура, то тучи несут только дождь, т.е. если ничего не изменится, то завтра пойдет дождь. Но это всего лишь мое мнение, проверяйте его, послушайте что говорят другие. "
"В общем, я не особо понимаю как делаются прогнозы погоды, но выскажу свое мнение, вы обязательно проверяйте любое мнение. В общем что я вижу сейчас на небе, сейчас на небе есть облака, а облака это по сути нечто похожее на тучи, а тучи они обычно несут дождь, но бывает и снег, но раз сегодня плюсовая температура, то тучи несут только дождь, т.е. если ничего не изменится, то завтра пойдет дождь. Но это всего лишь мое мнение, проверяйте его, послушайте что говорят другие. "
😁69👍12🤔8❤4👏4👎3
https://youtu.be/cFDreel2qFw
Знаю, что вы уже ненавидите меня за всякую дичь, которую я здесь пишу, вместо глубоко технического и обучающего контента, не сдерживайте себя и проживите это чувство до конца. Потому что я опять не про АйТи.
Очень люблю ребят из "Мы обречены" и их рубрику "Доктор кот". Я только сейчас начал понимать, что все эти разговоры про чувства, эмоции, переживания и т.д. это все по-настоящему, а не шутка юмора или хайп. Особенно мысль о том, что если тебе кажется, что у тебя нет психологических проблем - это еще не значит, что их нет. Надо идти к доктору и прорабатывать свое отрицание. И тут у меня возникает рекурсия, не может ли стать психической проблемой то, что тебе кажется, что у тебя есть какая-то скрытая психическая проблема, но ты не можешь ее найти? И эти некомпетентные психологи, просто неспособны ее отыскать...
Знаю, что вы уже ненавидите меня за всякую дичь, которую я здесь пишу, вместо глубоко технического и обучающего контента, не сдерживайте себя и проживите это чувство до конца. Потому что я опять не про АйТи.
Очень люблю ребят из "Мы обречены" и их рубрику "Доктор кот". Я только сейчас начал понимать, что все эти разговоры про чувства, эмоции, переживания и т.д. это все по-настоящему, а не шутка юмора или хайп. Особенно мысль о том, что если тебе кажется, что у тебя нет психологических проблем - это еще не значит, что их нет. Надо идти к доктору и прорабатывать свое отрицание. И тут у меня возникает рекурсия, не может ли стать психической проблемой то, что тебе кажется, что у тебя есть какая-то скрытая психическая проблема, но ты не можешь ее найти? И эти некомпетентные психологи, просто неспособны ее отыскать...
YouTube
Как пройти собеседование и не умереть от страха, выдержать критику и разобраться в себе — Доктор Кот
AvitoTech — команда, где круто выстроены процессы разработки, топовая культура, а ещё можно работать удалённо.
Вакансии, опенсорс-проекты, полезные статьи и видео от инженеров можно найти на сайте AvitoTech: https://bit.ly/3E8SXwc
Заглядывайте в телеграм…
Вакансии, опенсорс-проекты, полезные статьи и видео от инженеров можно найти на сайте AvitoTech: https://bit.ly/3E8SXwc
Заглядывайте в телеграм…
👍42🤔7🤮7❤1
Те кто читал "Чистую архитектуру" Роберта Мартина часто упрекают меня в терминологической неточности.
Суть в том, что у Роберта Мартина используется иерархия:
- Компонент
-> набор классов (или модулей),
а я использую иерархию:
- Модуль
-> набор компонент,
- компонент
-> набор классов (или пакетов).
Все дело в том, что современная разработка разделяется на фронт и бэк, количество команд становится больше, отношения этих команд становятся сложнее и привычного разделения на два уровня (компоненты / классы) уже не хватает. Поэтому проще использовать иерархию трехуровневую (модули, компоненты, классы).
Если внимательно прочитать "Чистую архитектуру", то там хорошо видно, что компонент идет из классического процесса компоновки программ, которые редко были "клиент/серверными". Поэтому и связи в их архитектуре были проще, да и сама архитектура была иной, как правило интерактивной.
Плюс у меня есть стойкая ассоциация, что модуль больше компонента.
Поэтому вам остается только простить и понять меня )
Суть в том, что у Роберта Мартина используется иерархия:
- Компонент
-> набор классов (или модулей),
а я использую иерархию:
- Модуль
-> набор компонент,
- компонент
-> набор классов (или пакетов).
Все дело в том, что современная разработка разделяется на фронт и бэк, количество команд становится больше, отношения этих команд становятся сложнее и привычного разделения на два уровня (компоненты / классы) уже не хватает. Поэтому проще использовать иерархию трехуровневую (модули, компоненты, классы).
Если внимательно прочитать "Чистую архитектуру", то там хорошо видно, что компонент идет из классического процесса компоновки программ, которые редко были "клиент/серверными". Поэтому и связи в их архитектуре были проще, да и сама архитектура была иной, как правило интерактивной.
Плюс у меня есть стойкая ассоциация, что модуль больше компонента.
Поэтому вам остается только простить и понять меня )
👍92🔥4😢2👎1
Я возобновляю ответы на вопросы, на канале S0ER TALKS, раньше их можно было задавать в Инсте, сейчас можно зайти на platform.soer.pro, в секции "Вопрос/ответ".
Ответы смотреть на канале, через некоторое время.
Ответы смотреть на канале, через некоторое время.
🔥13👍8❤1
Коротко про «Чистую архитектуру».
На днях решил проверить несколько фактов, в «Чистой архитектуре», а в итоге перечитал всю книгу. По мере прочтения сделал несколько записей, которые хочу развернуть в видео на S0ER TALKS.
Отмечу, что каждое новое прочтение вызывает все больше вопросов, и понимание того, что многие вещи раскрыты не полностью.
Итак, кратки конспект:
1. Мое мнение о книге: отлично подходит для программистов, которые хотят понять влияние архитектуры на код. С позиции разработки именно «архитектуры» мало помогает, так как не рассматривает существенные моменты: сбор и анализ требований, определение векторов развития и т.д.
Отлично подойдет для тех кто делает свои пет-проекты, стартапы или мелкую заказную разработку.
2. В книге довольно слабая позиция по построению архитектуры реальных проектов. В моей практике построение архитектуры больше похоже на узловую сборку. Т.е. никто не будет в реальном проекте писать свой «веб-сервер» или писать свою «СУБД». Узлы будут брать готовые, и брать с запасом прочности. Маловероятно, что в большом проекте кто-то скажет «ну нам пока хватает веб-сервера, написанного на коленке, а потом посмотрим».
3. Реальные проекты привлекают архитекторов с профильным опытом, а не строят каждый раз с нуля. Т.е. если вам нужен интернет магазин, то вы позовете человека, который уже разрабатывал интернет-магазин, а не будете сначала строить «интернет-ларек». Именно поэтому ко мне сейчас обращаются за консультациями – я могу на основе опыта сразу сказать где и чего не хватает.
4. «Кричащей архитектуры» на практике я не встречал, вся «информативность» достигается правильной стереотипизацией, если убрать с проекта «надписи», то кроме нагромождения «квадратиков» и «стрелочек» при всем желании не увидишь.
5. Проведение архитектурных границ в маленьких проектах делать особо смысла нет. Даже сам пример FitNesse, который разрабатывался самим «Дядюшкой Бобом» с архитектурной точки зрения плохо структурирован (по файловой структуре проекта не проведешь архитектурных границ), имеет низкий уровень абстракции (всего 0.2, при таком уровне большая часть классов должны быть неустойчивы, чтобы добиться общей стабильности проекта).
6. Отдельно про проект Fitnesse – это обычный пример сильнозацепленного монолита, с позиции архитектуры ничего особенного в нем нет. При уровне абстракции 0.2 у него есть всего два варианта реализации:
a. высокое переиспользование интерфейсов (тогда они должны быть «устойчивыми» или сопровождение превратится в Ад), что повышает зацепление на архитектурных границах, и вероятно там есть циклические зависимости (графи зависимостей строить лень).
b. Прямое использование и большое количество устойчивых классов (а не интерфейсов как в первом случае).
В обоих случаях допустимо только в маленьких проектах, потому что при росте количества команд они тупо начнут друг-другу мешать.
7. Про анализ требований в книге сказано мало, что странно. Потому что, например, пример с использованием файлов, вместо СУБД относится к проекту, где изначально в СУБД предлагалось хранить статические Вики страницы. При анализе требований было бы сразу очевидно, что «преимуществ» для такого типа контента в хранении в СУБД нет. На практике любой архитектор не просто следует моде, выбирая решение, а делает анализ «За» и «Против». И в случае с хранением статических страниц в файлах – это выглядит весьма разумно.
8. Что касается примера с использованием «кластера» вместо более простого «монолита», то опять это проблема анализа требований. В данном случае непонятно почему авторы решили, что им понадобится кластерное решение. Но в итоге решение можно было эксплуатировать (хоть и с кучей доп. Действий) как небольшой монолит, но вот если бы была обратная ситуация «небольшой монолит» вдруг понадобилось бы переделать в «кластерное решение», то проблем было бы в разы сложнее. Но в любом случае ошибка в требованиях и их анализе. У меня возникает только один вопрос: «Что архитекторам сказал бизнес-аналитик?» и был ли он вообще.
На днях решил проверить несколько фактов, в «Чистой архитектуре», а в итоге перечитал всю книгу. По мере прочтения сделал несколько записей, которые хочу развернуть в видео на S0ER TALKS.
Отмечу, что каждое новое прочтение вызывает все больше вопросов, и понимание того, что многие вещи раскрыты не полностью.
Итак, кратки конспект:
1. Мое мнение о книге: отлично подходит для программистов, которые хотят понять влияние архитектуры на код. С позиции разработки именно «архитектуры» мало помогает, так как не рассматривает существенные моменты: сбор и анализ требований, определение векторов развития и т.д.
Отлично подойдет для тех кто делает свои пет-проекты, стартапы или мелкую заказную разработку.
2. В книге довольно слабая позиция по построению архитектуры реальных проектов. В моей практике построение архитектуры больше похоже на узловую сборку. Т.е. никто не будет в реальном проекте писать свой «веб-сервер» или писать свою «СУБД». Узлы будут брать готовые, и брать с запасом прочности. Маловероятно, что в большом проекте кто-то скажет «ну нам пока хватает веб-сервера, написанного на коленке, а потом посмотрим».
3. Реальные проекты привлекают архитекторов с профильным опытом, а не строят каждый раз с нуля. Т.е. если вам нужен интернет магазин, то вы позовете человека, который уже разрабатывал интернет-магазин, а не будете сначала строить «интернет-ларек». Именно поэтому ко мне сейчас обращаются за консультациями – я могу на основе опыта сразу сказать где и чего не хватает.
4. «Кричащей архитектуры» на практике я не встречал, вся «информативность» достигается правильной стереотипизацией, если убрать с проекта «надписи», то кроме нагромождения «квадратиков» и «стрелочек» при всем желании не увидишь.
5. Проведение архитектурных границ в маленьких проектах делать особо смысла нет. Даже сам пример FitNesse, который разрабатывался самим «Дядюшкой Бобом» с архитектурной точки зрения плохо структурирован (по файловой структуре проекта не проведешь архитектурных границ), имеет низкий уровень абстракции (всего 0.2, при таком уровне большая часть классов должны быть неустойчивы, чтобы добиться общей стабильности проекта).
6. Отдельно про проект Fitnesse – это обычный пример сильнозацепленного монолита, с позиции архитектуры ничего особенного в нем нет. При уровне абстракции 0.2 у него есть всего два варианта реализации:
a. высокое переиспользование интерфейсов (тогда они должны быть «устойчивыми» или сопровождение превратится в Ад), что повышает зацепление на архитектурных границах, и вероятно там есть циклические зависимости (графи зависимостей строить лень).
b. Прямое использование и большое количество устойчивых классов (а не интерфейсов как в первом случае).
В обоих случаях допустимо только в маленьких проектах, потому что при росте количества команд они тупо начнут друг-другу мешать.
7. Про анализ требований в книге сказано мало, что странно. Потому что, например, пример с использованием файлов, вместо СУБД относится к проекту, где изначально в СУБД предлагалось хранить статические Вики страницы. При анализе требований было бы сразу очевидно, что «преимуществ» для такого типа контента в хранении в СУБД нет. На практике любой архитектор не просто следует моде, выбирая решение, а делает анализ «За» и «Против». И в случае с хранением статических страниц в файлах – это выглядит весьма разумно.
8. Что касается примера с использованием «кластера» вместо более простого «монолита», то опять это проблема анализа требований. В данном случае непонятно почему авторы решили, что им понадобится кластерное решение. Но в итоге решение можно было эксплуатировать (хоть и с кучей доп. Действий) как небольшой монолит, но вот если бы была обратная ситуация «небольшой монолит» вдруг понадобилось бы переделать в «кластерное решение», то проблем было бы в разы сложнее. Но в любом случае ошибка в требованиях и их анализе. У меня возникает только один вопрос: «Что архитекторам сказал бизнес-аналитик?» и был ли он вообще.
👍78🔥6❤1👎1
9. На практике архитекторов губит не желание сделать «посложнее», а наличие «бюджета», даже из примеров, которые приведены в книге, понятно, что проекты с «неудачной» архитектурой были запущены в прод, а значит финансирвоание было сильно больше достаточного (раз они смогли более дорогую архитектуру в итоге), что «развязало» руки архитекторам. Если дать архитектору миллион, то он построит архитектуру на миллион, если дать миллиард, то для той же задачи, он построит на миллиард. Это всегда так.
10. Про то что при проектировании архитектуры нужно делать минимум, а все лишнее «отложить на потом». С одной стороны совет правильный, но если понимать что «отложить на потом» - это спрятать за «абстракцией». Но на практике есть сроки и «откладывая на потом» нужно понимать, что не должно получиться так, что у тебя завтра час сдачи проекта, а ты только и успел что проработать абстракции высокого уровня.
10. Про то что при проектировании архитектуры нужно делать минимум, а все лишнее «отложить на потом». С одной стороны совет правильный, но если понимать что «отложить на потом» - это спрятать за «абстракцией». Но на практике есть сроки и «откладывая на потом» нужно понимать, что не должно получиться так, что у тебя завтра час сдачи проекта, а ты только и успел что проработать абстракции высокого уровня.
👍51🔥5👏2❤1
Я в now подписываюсь на всех у кого есть аватарка. Если будите постить фотки, то добавьте аву и я на вас подпишусь.
💩34👍17😁10🤔2