Егор Георгиевич звучит круто, как будто в универ 90х попал, Егор спасибо тебе за контент который ты делаешь! Твой вклад в развитие русскоязычного ИТ очень огромный
Отличная лекция. Очень интересно и полезно послушать мысли от опытного разработчика на такие высокие материи. Сам до этого не дойдешь, пока за 10+ лет не наломаешь дров. Благодарю
Спасибо за лекцию, было интересно. Пару мыслей озвучу, в принципе созвучных. 1) Код всегда пишется людьми для людей и должен быть понятен людям. Компьютер сам разберётся. 2) Синьор должен писать так чтобы понял любой джун. Если это не так, то перед вами просто престарелый джун, а не синьор.
хороший обзор. 2 сча все через виртуалки фрилансеры на большие конторы работают, там уже все настроено индусами с кучей неактуального вики текста. резюмировал ты здесь все последние лет 10. так сказать жизнь в латеке или ппт. с магистра посмеялся в душе. любят у нас это, не отнять. хорошо выглядишь.
Когда я начинал программировать была популярна статья Фредерика Брукса "Мифический человеко-месяц", там была формула разделения ролей: "главный хирург - лично пишет код, второй пилот - код не пишет, но в курсе всего (на случай аварии с главным хирургом), специалист по языку, вспомогательный персонал. В то время таких объемных проектов, как теперь и в такие сжатые сроки никто не создавал, весьма популярной была идея второй итерации: сперва нужно "слепить уродца", а затем его переписать заново и этого достаточно.🙃
такие обзорные доклады, которые сжато и четко излагают принципы разработки - всегда интересно смотреть. спасибо пункт 8 - ошибка - должно быть High Cohesion. (+ Low Coupling)
Про tight сoupling интересно порассуждать. Например, есть сервис по работе с базой данных. И есть с десяток сервисов, которые используют этот сервис, как либу. И вроде бы нет прямой связи с бд, но по факту при добавлении нового поля в таблице - приходится сначала расширять метод в сервисе по работе с БД, а затем пробегаться по всем сервисам, которые его используют и расширять параметры там. Разве мы снизили coupling? Была связь десятка сервисов с бд, теперь связь десятка сервисов с новым сервисом + его связь с бд. Хороший ли это пример приминительно к coupling?
конкретно в вашем случае связность увеличивается из-за того что вы новый атрибут добавляете в контракт и потом на него оириентируетесь, если стараться применять объекты с поведением, инкапсулируя данные, связность системы будет значитально ниже и не так чувствительна к добавлению нового атрибута. В идеале у вас должно быть 2 точки интеграции: 1. место где данные читаются/записываются из/в базу и инкапсулируются в объект не покидая его 2. место вывода данных на экран либо в поток, но за это должен отвечать сам объект тогда все изменения будут в рамках одной сущности, понятное дело что легче сказать чем сделать, но главная идея это сокрытие данных насколько это возможно
@@deniszhukovsky2260 вы говорите о связности или сцеплении?)) Так как увеличение связанности это хорошо, а вот сцепления плохо. Ваши рассуждения не очень понял. Я привёл пример из реального проекта, это частая практика. У этого есть свои плюсы, но как пример по уменьшению сцепления, на мой взгляд, не самый лучший.
По поводу удаленки, у нас в команде общение по связи реже, больше пишем сообщения. Когда ты пишешь сообщения ты его обдумываешь, дабы не тратить время человека. А если бы сидели рядом это же постоянное дерганье.
Про анализ архитектуры может углубиться и всё-таки выпустить в свет какой-то вердикт? Типа "автоматическая проверка архитектуры невозможна". Или "проверка архитектуры - так сложно, что это невыгодно". Или "почему проверку архитектуры ещё не изобрели? потому что людям/бизнесу не хочется качества, им хочется денег". Или "индустрия идёт не туда" Или, наоборот, "анализ архитектуры это просто. внедряйте и пожинайте плоды. вот доклад как это сделать и почему это надо" И аргументировать как-то.
@@yegor256 я о том и писал, что если это возможно на практике (хотя бы базовые вещи), то стоит попробовать и рассказать о полученном опыте. Например: кол-во импортов соседних пакетов с другими модулями не больше двух на весь модуль (во всех классах модуля, если модуль не адаптер или прокси); реализация/декларирование больше двух фабрик в модуле; В полиморфных массивах вызов у объектов функций, которых нет в интерфейсе (а только в классах); Зарезервировать короткие имена для счётчиков, файловых переменных и соединений и отсекать любые другие короткие названия переменных меньше какого-то порога. Можно ещё copilot натравить проверять осмысленность названий переменных (но это уже не формализовать); Класс реализует слишком много интерфейсов (вся цепочка наследования) - низкая специфичность. И всё в таком духе, для начала. Описанное же вроде бы несложно делать, а на качестве проекта может сказаться.
Фраза про чтение кода 90% принадлежит не профессору Зуеву, а опубликована в книге дядюшка Боб много лет назад. Там ещё было что "компьютер прочитает любой скомпилированный код, лишь бы он выполнял нужную последовательность операций для АЛУ. А вот человек - нет". И это 100% факт
Егор, хотелось бы поподробней про "сложный" и "простой" код. Есть мудреный и запутанный код, а есть просто "тупые" и необразованные читатели технически сложного кода. Где-то должна быть грань. Михаил Михайлович Жванецкий как-то сказал: «Раньше миром управляли умные. Это было жестоко. Умные заставляли тупых учиться. Тупым было тяжело. Теперь миром управляют тупые. Это честно, потому что тупых гораздо больше. Теперь умные учатся говорить так, чтоб тупым было понятно. Если тупой что-то не понял, это умного проблема. Раньше страдали тупые. Теперь страдают умные. Страданий стало меньше, потому что умных становится все меньше и меньше»
Ваш вопрос имеет прямое отношение к собственно разработке архитектуры и его нужно объяснять отдельными лекциями. Если по-простому: 1. Если над кодом приходится думать (он сложный), то у него есть неочевидные побочные эффекты. Простой код не имеет побочных эффектов. 2. Из ролика показательно отношение времени чтения (90%) ко времени написания кода (10%). Тут я поправлю Егора, потому что программист не читает код (как это выглядит со стороны), программист в это время думает. И время размышлений тем меньше, чем продуманнее архитектура. 3. В общем виде для себя я сформулировал этот подход так: Если при изменении реализации любой части нужно ломать интерфейсы, то это плохая архитектура. Такой подход превращается в головную боль архитектора, но результат этого подхода будет качественный.
"Сложный" программист и "умный" программист -- это разные качества. Представьте, что программист это преподаватель. Он передает свои знания другим программистам, другим поколениям программистов. Один делает это просто, понятно и доходчиво, а второй -- сложно, запутанно и непонятно. При этом и тот и другой -- грамотные и "умные" программисты.
@@yegor256 ну это же ещё и очень субъективное восприятие. Кому-то код будет казаться понятным, а кому-то нет. Кто-то не может терпеть асинхронное программирование, кто-то не любит ООП и нормально делает процедурный структурный код. Для каждого из них отклонение от излюбленных траекторий будет сразу казаться "сложным и запутанным" кодом. Если память не изменяет, то в каком-то давнем видео у вас была дискуссия "зачем нужны эти стримы, есть же итератор, со стрима и все выглядит не так очевидно". Но это уже стандарт теперь, решают кучу вопросов, очень многим вполне понятны. Как уйти от субъективщины и "любимых тропинок" в этом случае?
@@vadimburavlev4773 бремя ответственности за простоту понимания кода лежит на его авторе, я считаю. Конечно, автор может ожидать наличия каких-то базовых знаний у читателя, например что "стримы -- это хорошо и понятно". Равно как и учитель физики ожидает наличия знаний алгебры у своих учеников. Что есть "алгебра" для программиста -- вопрос открытый :)
Как между собой уживаются первые 2 причины, в контексте стремления избежать потери знания всей архитектуры проекта? Где решение по 1-ому пункту "один ответственный архитектор" повышает этот риск, так как на одного архитектора становится больше завязано ответственности и знаний, и где решение по 2-ому пункту "работа не в одной локации", наоборот, стремится снизить риск потери знаний о проекте, путём увеличения документируемой коммуникации и практики работы в разных окружениях. То есть с одной стороны делаем одного человека ключевым для всей архитектуры - если он уйдёт, будут проблемы, а с другой - диверсифицируем знания об архитектуре (или об отдельных модулях?) на уровне команды.
Если вся кодовая база покрывается тестами, есть ли тогда смысл писать на строго типизированных языках? Ведь теперь признание работоспособности когда лежит уже не на компиляторе ,а на наборе тестов!
Есть еще одна причина провалов сложных архитектур. Она описана в известной книге Йордана "Смертельный марш" или в переводе на русский название книги было "Путь камикадзе". Так вот: люди - идиоты. 🙂
Егор, почти любой менеджер будет воспринимать свой проект как стартап, а следовательно не давать внедрять практики, линтеры, покрытие. Мол или мы сейчас что-то выкатим клиентам или у нас закончатся деньги и мы не получим следующий раунд (мы не успеем к дате, наш клиент, которому мы наврали с три короба, уйдёт). И что тут делать, говнокодить?
Монорепозиторий делают не для того чтобы был единый релизный цикл у всего, это невозможно, это делают для того, чтобы когда ты меняешь свою либу была возможно прогнать с ней чужие тесты.
@@yegor256 Часть. Возможно, мы под словом "единый релизный цикл" понимаем разное. Я сюда вкладываю еще время отведения релизных бранчей и раскатку артефактов. Ты можешь жить в монорепе и выкатываеться раз в полгода, а твой сосед по монорепе - раз в неделю. Наверно лучше назвать это не единый релизный цикл, а одинаковый релизный цикл.
Егор, твои рекомендации неизбежно приводят к нищите всех программистов и дают безграничные возможности владельцам денег, как тем, кто может лучше всех мотивировать вклад
![PMBA 6/10: Resources Management [project management crash course] [eng sub]](http://i.ytimg.com/vi/cpexAQZEPUE/mqdefault.jpg)
![PMBA 6/10: Resources Management [project management crash course] [eng sub]](/img/tr.png)
![ละลาย (LALALYE) - DAOU PITTAYA ต้าห์อู๋ พิทยา [OFFICIAL MV]](http://i.ytimg.com/vi/wo6r9TgausI/mqdefault.jpg)
Егор Георгиевич звучит круто, как будто в универ 90х попал, Егор спасибо тебе за контент который ты делаешь! Твой вклад в развитие русскоязычного ИТ очень огромный
Рад стараться, спасибо, что смотрите!
Представление Егора это как отдельный вид искусства. Мне кажется именно так представляли вельмож в средние века.
забавный комментарий)
Егора нужно клонировать! Как всегда ценно, точно, остро и главное практика доказывает что верно. ❤
аминь.
Спасибо за выкладывание такого крутого контента в открытый доступ.
Егор, ваша книжка по ООП - шедевр. Читал и периодически вскакивал и орал: "Да! Именно так!". Спасибо вам за нее.
Приятно) Спасибо за отзыв!
Отличная лекция. Очень интересно и полезно послушать мысли от опытного разработчика на такие высокие материи. Сам до этого не дойдешь, пока за 10+ лет не наломаешь дров. Благодарю
Спасибо за лекцию! Продолжайте пожалуйста выкладывать свои лекции!
Егор, спасибо! Очень полезные мысли вы даете на подумать.
Второй день смотрю нонстопом разные выступления и интервью Егора. Прям как бальзам на душу.
спасибо на добром слове :)
Прекрасный вебинар.
Теперь бы его до руководства довести.
Как всегда топ, отличный и как всегда не тривиальный свод причин!
Спасибо за лекцию, было интересно. Пару мыслей озвучу, в принципе созвучных.
1) Код всегда пишется людьми для людей и должен быть понятен людям. Компьютер сам разберётся.
2) Синьор должен писать так чтобы понял любой джун. Если это не так, то перед вами просто престарелый джун, а не синьор.
хороший обзор. 2 сча все через виртуалки фрилансеры на большие конторы работают, там уже все настроено индусами с кучей неактуального вики текста. резюмировал ты здесь все последние лет 10. так сказать жизнь в латеке или ппт. с магистра посмеялся в душе. любят у нас это, не отнять. хорошо выглядишь.
то, что нужно)
спасибо!
Индустриальный ландшафт программирования был бы плоским и серым без такого неординарного спикера. Обожаю Егора.
А я обожаю слушателей, которые оставляют комменты)
Когда я начинал программировать была популярна статья Фредерика Брукса "Мифический человеко-месяц", там была формула разделения ролей: "главный хирург - лично пишет код, второй пилот - код не пишет, но в курсе всего (на случай аварии с главным хирургом), специалист по языку, вспомогательный персонал.
В то время таких объемных проектов, как теперь и в такие сжатые сроки никто не создавал, весьма популярной была идея второй итерации: сперва нужно "слепить уродца", а затем его переписать заново и этого достаточно.🙃
такие обзорные доклады, которые сжато и четко излагают принципы разработки - всегда интересно смотреть. спасибо
пункт 8 - ошибка - должно быть High Cohesion. (+ Low Coupling)
Tight coupling или синоним high coupling - это антипатерн, Егор все верно написал, он же проблемы выделяет в своем докладе
Ждемс лекции по разным архитектурам.
Согласен с каждым пунктом!
Ура, хоть что-то на русском! Спасибо!
По поводу тестирования архитектуры - для kotlin есть библиотека konsist, которая позволяет писать тесты архитектуры
это все прекрасно, жаль не работает в реальных условиях заказной разработки
Про tight сoupling интересно порассуждать. Например, есть сервис по работе с базой данных. И есть с десяток сервисов, которые используют этот сервис, как либу. И вроде бы нет прямой связи с бд, но по факту при добавлении нового поля в таблице - приходится сначала расширять метод в сервисе по работе с БД, а затем пробегаться по всем сервисам, которые его используют и расширять параметры там. Разве мы снизили coupling? Была связь десятка сервисов с бд, теперь связь десятка сервисов с новым сервисом + его связь с бд. Хороший ли это пример приминительно к coupling?
Но связи этих сервисов с промежуточным модулем значительно "тоньше", чем были между ними и БД
конкретно в вашем случае связность увеличивается из-за того что вы новый атрибут добавляете в контракт и потом на него оириентируетесь, если стараться применять объекты с поведением, инкапсулируя данные, связность системы будет значитально ниже и не так чувствительна к добавлению нового атрибута. В идеале у вас должно быть 2 точки интеграции:
1. место где данные читаются/записываются из/в базу и инкапсулируются в объект не покидая его
2. место вывода данных на экран либо в поток, но за это должен отвечать сам объект
тогда все изменения будут в рамках одной сущности, понятное дело что легче сказать чем сделать, но главная идея это сокрытие данных насколько это возможно
@@deniszhukovsky2260 вы говорите о связности или сцеплении?)) Так как увеличение связанности это хорошо, а вот сцепления плохо. Ваши рассуждения не очень понял. Я привёл пример из реального проекта, это частая практика. У этого есть свои плюсы, но как пример по уменьшению сцепления, на мой взгляд, не самый лучший.
Практически все эти проблемы регулярно встречаю, к сожалению
По поводу удаленки, у нас в команде общение по связи реже, больше пишем сообщения. Когда ты пишешь сообщения ты его обдумываешь, дабы не тратить время человека. А если бы сидели рядом это же постоянное дерганье.
Как всегда топ.
Про анализ архитектуры может углубиться и всё-таки выпустить в свет какой-то вердикт?
Типа "автоматическая проверка архитектуры невозможна".
Или "проверка архитектуры - так сложно, что это невыгодно".
Или "почему проверку архитектуры ещё не изобрели? потому что людям/бизнесу не хочется качества, им хочется денег".
Или "индустрия идёт не туда"
Или, наоборот, "анализ архитектуры это просто. внедряйте и пожинайте плоды. вот доклад как это сделать и почему это надо"
И аргументировать как-то.
Можно попробовать, но все это будут теоретические рассуждения. На практике показать нечего (по крайней мере мне)
@@yegor256 я о том и писал, что если это возможно на практике (хотя бы базовые вещи), то стоит попробовать и рассказать о полученном опыте.
Например: кол-во импортов соседних пакетов с другими модулями не больше двух на весь модуль (во всех классах модуля, если модуль не адаптер или прокси);
реализация/декларирование больше двух фабрик в модуле;
В полиморфных массивах вызов у объектов функций, которых нет в интерфейсе (а только в классах);
Зарезервировать короткие имена для счётчиков, файловых переменных и соединений и отсекать любые другие короткие названия переменных меньше какого-то порога. Можно ещё copilot натравить проверять осмысленность названий переменных (но это уже не формализовать);
Класс реализует слишком много интерфейсов (вся цепочка наследования) - низкая специфичность.
И всё в таком духе, для начала. Описанное же вроде бы несложно делать, а на качестве проекта может сказаться.
Фраза про чтение кода 90% принадлежит не профессору Зуеву, а опубликована в книге дядюшка Боб много лет назад. Там ещё было что "компьютер прочитает любой скомпилированный код, лишь бы он выполнял нужную последовательность операций для АЛУ. А вот человек - нет". И это 100% факт
Всегда полезно. Как дела с Zerocracy?
Егор, хотелось бы поподробней про "сложный" и "простой" код. Есть мудреный и запутанный код, а есть просто "тупые" и необразованные читатели технически сложного кода. Где-то должна быть грань.
Михаил Михайлович Жванецкий как-то сказал: «Раньше миром управляли умные. Это было жестоко. Умные заставляли тупых учиться. Тупым было тяжело. Теперь миром управляют тупые. Это честно, потому что тупых гораздо больше. Теперь умные учатся говорить так, чтоб тупым было понятно. Если тупой что-то не понял, это умного проблема. Раньше страдали тупые. Теперь страдают умные. Страданий стало меньше, потому что умных становится все меньше и меньше»
Ваш вопрос имеет прямое отношение к собственно разработке архитектуры и его нужно объяснять отдельными лекциями. Если по-простому:
1. Если над кодом приходится думать (он сложный), то у него есть неочевидные побочные эффекты. Простой код не имеет побочных эффектов.
2. Из ролика показательно отношение времени чтения (90%) ко времени написания кода (10%). Тут я поправлю Егора, потому что программист не читает код (как это выглядит со стороны), программист в это время думает. И время размышлений тем меньше, чем продуманнее архитектура.
3. В общем виде для себя я сформулировал этот подход так: Если при изменении реализации любой части нужно ломать интерфейсы, то это плохая архитектура. Такой подход превращается в головную боль архитектора, но результат этого подхода будет качественный.
"Сложный" программист и "умный" программист -- это разные качества. Представьте, что программист это преподаватель. Он передает свои знания другим программистам, другим поколениям программистов. Один делает это просто, понятно и доходчиво, а второй -- сложно, запутанно и непонятно. При этом и тот и другой -- грамотные и "умные" программисты.
@@yegor256 ну это же ещё и очень субъективное восприятие. Кому-то код будет казаться понятным, а кому-то нет. Кто-то не может терпеть асинхронное программирование, кто-то не любит ООП и нормально делает процедурный структурный код. Для каждого из них отклонение от излюбленных траекторий будет сразу казаться "сложным и запутанным" кодом. Если память не изменяет, то в каком-то давнем видео у вас была дискуссия "зачем нужны эти стримы, есть же итератор, со стрима и все выглядит не так очевидно". Но это уже стандарт теперь, решают кучу вопросов, очень многим вполне понятны.
Как уйти от субъективщины и "любимых тропинок" в этом случае?
@@vadimburavlev4773 бремя ответственности за простоту понимания кода лежит на его авторе, я считаю. Конечно, автор может ожидать наличия каких-то базовых знаний у читателя, например что "стримы -- это хорошо и понятно". Равно как и учитель физики ожидает наличия знаний алгебры у своих учеников. Что есть "алгебра" для программиста -- вопрос открытый :)
Такие люди (21:30) точно существуют :) Мне капец как важно чтобы код и мой, и моих подчинённых был качественный.
А что за прослойка между сервисами и бд? Вы сказали там может быть свой язык. Подскажите плз, какие используются средства для реализации.
Как между собой уживаются первые 2 причины, в контексте стремления избежать потери знания всей архитектуры проекта? Где решение по 1-ому пункту "один ответственный архитектор" повышает этот риск, так как на одного архитектора становится больше завязано ответственности и знаний, и где решение по 2-ому пункту "работа не в одной локации", наоборот, стремится снизить риск потери знаний о проекте, путём увеличения документируемой коммуникации и практики работы в разных окружениях.
То есть с одной стороны делаем одного человека ключевым для всей архитектуры - если он уйдёт, будут проблемы, а с другой - диверсифицируем знания об архитектуре (или об отдельных модулях?) на уровне команды.
В топ10 только 9 пунктов
Если вся кодовая база покрывается тестами, есть ли тогда смысл писать на строго типизированных языках? Ведь теперь признание работоспособности когда лежит уже не на компиляторе ,а на наборе тестов!
Хз, про архитектуру последние два пункта. Остальное про организацию процессов
Есть еще одна причина провалов сложных архитектур. Она описана в известной книге Йордана "Смертельный марш" или в переводе на русский название книги было "Путь камикадзе". Так вот: люди - идиоты. 🙂
Егор, почти любой менеджер будет воспринимать свой проект как стартап, а следовательно не давать внедрять практики, линтеры, покрытие. Мол или мы сейчас что-то выкатим клиентам или у нас закончатся деньги и мы не получим следующий раунд (мы не успеем к дате, наш клиент, которому мы наврали с три короба, уйдёт). И что тут делать, говнокодить?
Какое отношение всё сказанное кроме первого пункта имеет к архитектуре?
Монорепозиторий делают не для того чтобы был единый релизный цикл у всего, это невозможно, это делают для того, чтобы когда ты меняешь свою либу была возможно прогнать с ней чужие тесты.
А "прогнать чужие тесты" разве не часть релизного цикла?
@@yegor256 Часть. Возможно, мы под словом "единый релизный цикл" понимаем разное. Я сюда вкладываю еще время отведения релизных бранчей и раскатку артефактов. Ты можешь жить в монорепе и выкатываеться раз в полгода, а твой сосед по монорепе - раз в неделю. Наверно лучше назвать это не единый релизный цикл, а одинаковый релизный цикл.
всё хорошо, но 720п это печально
согласен
Егор, чем отличаются 1 и 4 причины?
Сначала вы говорите что за модуль должен отвечать один человек, а потом говорите что это плохо.
За всю систему один человек. А вот у модулей внутри системы "владельцев" быть не должно.
Егор, твои рекомендации неизбежно приводят к нищите всех программистов и дают безграничные возможности владельцам денег, как тем, кто может лучше всех мотивировать вклад
Приводят к нищете ленивых плохих программистов, я бы сказал
У него ж свой вайб.. что давайте выгоним всех тупых и ленивых.. Вот тогда заживём))