SOER. Страница 2
Блог программиста S0ER. Мысли, ранний доступ к видео, фоточки, короткие посты. Ничего конкретного, но что-то будет полезным.
-
SOER
Опубликовал видео по ардуинке. Для меня это в первую очередь попытка сделать более динамичный и разнообразный монтаж, больше визуальной информации добавить в видео (в отличие от обычного формата говорящей головы), ну и ожидаю жесткого разноса, чтобы по-быстрому подтянуть проблемы терминологии и исправить свои ашибки. YouTube | RuTube | VK -
SOER
Качать хардскилы программистов или улучшать методы тестирования? С утра пораньше в Кругах на полях IT устроили небольшой срач о том, что программисты должны писать код, а тесты искать в них ошибки. Т.е. программист не должен думать и проектировать перед выполнением задачи, он должен фигачить как можно быстрее код, который решает проблемы бизнеса. О том, что это за проблемы должны подумать аналитики, а о том насколько качественный код должны подумать тестировщики и автотесты. Кратко тезисы "за тесты": - развитие инструментов тестирования - это прогресс - программист все равно будет ошибаться, поэтому "без тестов" лучше не получится - хороший программист решает проблемы бизнеса и не более того Кратко тезисы за "хардскилы": - тесты не доказывают отсутствие дефектов, а только проверяют их наличие - у тестов есть "эффект пестицидов", который проявляется в том, что тесты требуют постоянного улучшения и обновления, что приводит к работе "только на тесты" - метрика "количество ошибок, отловленные тестами" ведет только к увеличению количества ошибок, которые допускают программисты, нужно стремить к тому, чтобы уменьшилась метрика "недовольные пользователи", а этого достичь без развития программистов невозможно. Мысль моя вот в чем: - тесты - это условно "средство контроля", а программисты - это условно "средства производства", невозможно улучшить качество итоговой продукции улучшая только "средства контроля", поэтому улучшать и углублять свои знания программисты просто обязаны, чтобы совершать меньше ошибок. - Основные усилия должны тратиться на развитие кодовой базы проекта, а не на развитие кодовой базы тестов. КРУГИ НА ПОЛЯХ IT Айтишники в естественной среде обитания.
-
SOER
У Вернона стратегия включает: единый язык, предметная область, предметная подобласть, смысловое ядро, ограниченный контекст, карта контекстов. Мне стоило пояснить, что в "домен приложения" входит карта контекстов и предметная область. Хорошее дополнение. #DDD #теория 
-
Реклама
-
SOER
DDD основное, что нужно помнить В предметно ориентированном дизайне задачу построения архитектуры приложения можно разделить на две части "Стратегическую" и "Тактическую". Стратегия Определяется решением следующих вопросов: - Выделением общего языка - Созданием пользовательских историй - Выделение домена приложения При этом для архитектур с централизованным хранилищем данных DDD чаще бывает излишним, чем полезным, DDD стоит рассматривать если у вас минимум 30-40 пользовательских историй. Стратегия оправдывает себя даже если вы не реализуете конкртеные шаблоны DDD в коде, так как позволяет прийти к единому пониманию предметной области, отделить бизнес термины от технических терминов. Тактика Включает в себя реализацию шаблонов для организации объектной модели приложения. В первую очередь выделяются слои приложения (от внутреннего к внешнему): - Entities, Value objects, Domain Events, Aggregates - Repositores, Domain Services - Application services - UI Aggregate Агрегаты - это абстрактное понятие, которое на диаграммах можно представить как "границу" всех сущностей (entities) и объектов значений (value objects), а в коде агрегат представлены "корнем агрегата", который как правило является сущностью, включающей в себя другие сущности. Value Object vs Entity Чтобы лучше понять когда что создавать помните: - идентификация сущности делается по Id, value object идентифицируется всеми своими полями - сущность имеет маскимально длинный жизненный цикл, объекты значения наоборот имеют очень короткий жизненный цикл - сущности могут изменять свой стейт (спорно, но в целом так), объекты значения только создаваться новые, изменять старые не принято - логика в объектах значениях обычно простая (объект делается "легким"), в отличии от сущностей Domain Service Чаще всего в доменные сервисы размещается общая логика, которую сложно связать с сущностями. Обычно доменных сервисов стараются много не создавать. Репозиторий Во многом это чисто техническое решение для того, чтобы инкапсулировать (не обязательно скрыть, но собрать вместе) логику свзяывающую СУБД и приложение, в сущностях не должно быть логики сохранения в БД. Плюс репозитории отвечают за создание коллекций сущностей. Репозиторий - "один ко многим", может включать логику массовых операций. Сущность - "один к одному", включает бизнес-логику и стейт. #DDD #знания #теория -
SOER
Вчера пообщались про школу №21 от Сбера. Основная фишка их обучения - отсутствие наставников, вместо этого каждый оценивает каждого (peer-to-peer). В процессе обсуждения приши к мысли, что процесс их обучения очень похож на то, что мы делаем в Naris. Например, у нас принцип peer-to-peer называется devs2devs, который гласит что сами участники делают ревью кода других участников. У нас наставничество не совсем исключено, но сведено к минимуму, по сути у нас так же используется принцип "равный среди равных" и в рамках ревью нужно не просто высказать свое мнение, но и конструктивно аргументировать. Если компетенция команды в школе 21 ограничена уровнем учеников, которые в массе своей - джуны, то у нас компетенция ограничена людьми уровнем мидлов, которые часто приходят в проект. Мне кажется, что это куда лучше, когда действующие разрабы общаются между собой (поэтому собственно devs2devs, а не peer-to-peer). Еще одно отличие Naris и школы 21 в том, что мы делаем один проект, но по всем правилам разработки. Т.е. структура работы ничем не отличается от хороших "боевых" команд, которые используют современные практики программирования. Почему я вдруг решил вспомнить этот разговор и сравнить Naris и школу 21? Для меня это подтверждение моих мыслей о том как должно быть выстроено обучение разработчиков, которых нужно быстро ввести в специальность. Идея объединить людей вокруг проекта и делать практические вещи находит поддержку в очень крутых компаниях таких как Сбер или Хуавей. А это в свою очередь говорит о том, что путь выбран правильно и нужно продолжать движение в Naris. -
SOER
Пожалуй, сегодня была самая мощная встреча соеров, обсудили много важных вопросов, рассказали истории из жизни, провели короткий стрим. Были ребята из Питера, Краснодара и Сочи. Спасибо всем кто пришёл, было очень классно. -
SOER
Напоминаю, что завтра в 10 утра в Сочи состоится грандиозная встреча соеров ) -
SOER
Есть у нас группа для общения ютуберов между собой, называется "круги на поля IT" (https://t.me/itkrugi), мы там обычно просто стебемся друг над другом, выкладываем кружки из жизни и в целом бездарно тратим ресурсы интернета. Но сегодня получился конструктивный разговор, который многим может быть интересен. Все началось с вброса ExtreamCode мол если бы кому-то были важны оптимизации, то Bool бы занимал один бит. Понятно, что любой соер в этот момент делает "рука лицо" и ворчит про "и эти люди говорят, что образование не нужно". Потому что для юзеров высокоуровневых языков, которые видят все через абстракции над абстракциями, кажется: "ну а чо? выделим один бит и делов-то, это бесплатно и очень просто". На самом деле, если раскрутить абстракции и понять, что реально адресовать один бит данных нельзя (почему смотрите на канале), то становится понятно, что это один байт выбран не потому что создатели компиляторов - ленивые идиоты, которые не догадались выделить один бит, а все ровно наоборот, просто программисты сегодня вообще не понимают о чем рассуждают (что, впрочем, не мешает им делать умный вид и красиво говорить на камеру). Как говорится, фронтендеры они и в Африке фронтендеры, чего с них взять? Нужно понять и простить... Но что-то я слишком увлекся, если коротко, то в кругах мы сегодня знатно разъебали безграмотность современных экстримальных программистов, которые ляпнули глупость. КРУГИ НА ПОЛЯХ IT Айтишники в естественной среде обитания.
-
SOER
г. Сочи, ул. Войкова 4В "Мой кофе" в субботу 1 июля в 10:00 Сходка настоящих соеров - только хардкор, только программирование, только те кто реально любит наше дело. 😎 -
SOER
1 июля повторим? -
SOER
Чем отличается "разработка решения" от "реализации решения"? Поясню на примере, вот есть у нас задача "Решение квадратного уравнения". Оно будет состоять из двух этапов "разработка" и "реализация" Разработка решения выглядит так: "Я посчитаю дискриминант (по формуле D = b^2 - 4ac), затем посчитают по формуле корней (+-b - sqrt(D)) / 2a значения х1,х2" Реализация решения - это уже готовый код, но можно описать в общем виде: "Я возьму Матлаб, создам новый документ, в нем заведу общие переменны a, b, c для квадратного уравнения виде ax^2 + bx + c, далее рассчитаю D, затем рассчитаю x1, x2" Т.е. разработка решения - это описание общей логики (алгоритма) решения, а реализация - это конечное решение, которое решает поставленную задачу. Проблема в том, что когда надо "Разработать решение", очень часто вместо разработки делается общее описание реализации, которое по сути тот же код, но на псевдоязыке. Это неправильно, нужно развивать алгоритмическое мышление и отделать "логику" от "реализации". -
SOER
У Димы подписчик задаёт вопрос о том, что ему скучно на работе, потому что ему не хватает задач. Подозреваю, что проблема а том, что чувак хочет делать только интересные ему задачи и не заниматься рутиной, которой у среднего разраба обычно 80%. Исключение - сильные программисты, которых никто не будет кидать на покраску кнопок. Поэтому хочешь решать интересные задачи - развивайся. Что значит "развивайся"? Это значит, самому искать слабые места в коде и улучшать их, изучать архитектуру, покрывать код тестами и фитнес функциями, инициировать обсуждения с коллегами. В любом случае если сидеть и ждать задачи - это приведёт только к стагнации. https://t.me/seniorsoftwarevlogger/1287 Senior Software Vlogger ❓ Вопрос. Сейчас я столкнулся с проблемой на работе, которая беспокоит меня. У меня нет достаточного количества задач, чтобы заполнить свое время. После планирования, моя загрузка на двухнедельный спринт всего на 1-2 дня. Чтобы заполнить это свободное время, мне предлагают задачи, которые кажутся бессмысленными, например, изменение цвета кнопки. Это вызывает у меня скуку на работе, но в то же время я не могу заниматься чем-то личным, потому что меня все время беспокоит, что я должен что-то говорить на дейли, куда-то списывать время и т. д. Поэтому каждое утро я трачу 30-40 минут на поиск того, чем я могу заняться сегодня. Я не рассматриваю возможность поиска новой работы, поскольку, во-первых, рынок сейчас не благоприятен для этого, и, кроме того, я отработал недостаточно долго на текущем месте работы. — Если вы работаете по спринтам, то работа должна даваться на команду, а не лично. Но скрам конечно все понимают неправильно. В результате у всех проблемы (скрамно). Если твоя работа кончилась, например, ты единственный…
-
SOER
-
SOER
Важно! я не уверен, что завтра буду делать стрим, сильно зависит от того соберем ли интересные темы. В любом случае, если даже стрим будет, то это последний стрим этого сезона, до сентября стримов не будет. Поэтому запускаю сбор тем на субботний стрим с учетом оговорки выше: 1. ЗЭН - пишите в комментариях вопросы (буду выбирать самые популярные или которые понравятся мне) - ответ будет в субботнем стриме 2. Ревью кода и проектов - может быть вам интересно узнать мое мнение по вашему репозиторию (можно от фрагментов кода, до своих проекто) на github - тогда можно написать ссылку в комментариях и примерно чего вы ожидаете, буду выбирать на свое усмотрение и желание и в субботу на стриме будет обзор 3. Как всегда все что будет на https://donate.s0er.ru буду рассматривать в обязательном порядке (если по АйТи, все провакационные вопросы и подколы не рассматриваю). Если есть интересные видосы на "сплетни нашего ютуба", тоже можно кидать. -
SOER
Проектирование WebAPI обычно не вызывает никаких проблем, пока не возникает требование унификации. Под унификацией я понимаю продумывание построение url-ов и возвращаемых результатов таким образом, чтобы они подчинялись общим правилам. Если хочется понять что это за правила такие, по которым api строится, рекомендую вот этот видос www.youtube.com/live/KS…ed4yyoDM -
Реклама
-
SOER
Про логирование Заметил, что если архитектурных примеров на гитхабе полно, то примеров с грамотным логированием еще надо поискать. В итоге люди уделяют внимание архитектуре и делают совершенно непригодные для сопровождения проекты. Предполагая, что сопровождать проект будет тот кто его разрабатывает. Считается, что потом в реальных проектах их этому научат, но те кто читал логи разных интерпрайзов знает, что нет, не научат. Элементарный пример - guid, который в логах один из основных источников информации о сущностях, что мешает снабдить его человекопонятным префиксом? Сколько человеческих нервов можно было бы сэкономить благодаря этому. Но нет, всегда голый uuidV4 - наше все. Ошибки тоже обычно информативны только для тех, кто видит и знает как написан код, в то время как в боевых системах код никто не видит, видят только сухие строчки логов. В итоге чтобы декодировать что написано в логах нужно дергать разрабов, без которых разобраться невозможно. Вывод: учитесь писать логи, господа. Учитесь писать логи... -
SOER
Продолжаю искать красивый код для анализа. Интересно найти что-то "боевое", построенное по классике DDD, но пока нахожу только примеры сомнительного качества. Например, https://github.com/asc-lab/better-code-with-ddd вроде как сравнивает обычный слоеный монолит, с ддд-ым монолитом. Наверное нравится должен больше ДДД-ый вариант, но че-то вообще не нравится. Поделитесь ссылкой на гитхаб репо с хорошим ДДД "боевым", а не высосанным из пальца примером. -
SOER
И мы в эфире youtube.com/live/j0…qpElgDQ4