Идет мужик по лесу, смотрит - другой мужик лес рубит топором.
- Что делаешь?
- Лес рублю.
- Бензопила же рядом лежит. Возьми её - быстрее будет.
- Я не умею ею пользоваться.
- Инструкция лежит же рядом. Возьми, прочитай.
- Мне некогда - лес рубить надо.

К чему я вспомнил этот анекдот? Состояние кода может замедлить разработку более, чем на порядок, и продолжать замедлять по экспоненте.

В процессе программирования программист вводит символы с клавиатуры не более 10% времени (зачастую - не более 1% времени). Остальное время он читает существующий код и борется со сложностью.

Плохой код пишется одним программистом, однократно, не более 10% времени. А читается он всеми программистами команды, многократно, постоянно, более 90% времени программирования. Т.е. однократно написанный одним программистом плохой код будет замедлять всю команду более 90% её времени.

Таким образом, фраза "некогда писать правильно" является самообманом. Если у команды медленный темп разработки, то он более чем на 90% времени вызван медленным чтением и затрудненным пониманием написанного ранее кода. Именно поэтому скорость разработки деградирует обычно в геометрической прогрессии.

Самообманом является и фраза "потом исправим". Как сказал Randy Shoup, если у вас нет времени сделать это правильно, то с чего вы взяли, что у вас будет время сделать это дважды? Тем более, что потом скорость разработки будет ниже, а напряжение - выше.

Количество введенных символов слабо коррелирует со скоростью разработки. Например, ребята, увлекающиеся спортивным прохождением кат по программированию, заметили, что используя TDD они пишут в разы больше объем кода, но проходят каты процентов на 10% быстрее, чем без ТДД.

Все просто - используя TDD, появляется слабосвязанный код (иначе его сложно было бы протестировать), который легче читать и понимать.

Но я сейчас не об этом. А о том, что для того, чтоб писать высокоэффективный код, нужно обладать определенными знаниями.

Я вспоминаю, когда я начал работать с литературой по Software Design, то мой код начал существенно преображаться. Мой старый код вызывал у меня стыд. Я взял паузу в программировании Open Source проектов и засел за книжки. Я понимал, что лучше "прочесть инструкцию к бензопиле", нежели продолжать "рубить топором" то, что потом все-равно переделывать.

К тому моменту я уже начал немного разбираться в том, чем хороший код отличается от плохого. И я хотел, чтоб то же самое испытал мой товарищ, который продолжал "рубить топором" и не находил времени на прочтение "инструкции к бензопиле".

Хороший код отличается простотой, и выполняет главный императив разработки - управление сложностью. Но хороший код не спасает от еще одной сложности, про которую недавно написал @BorisRomanov (начиная отсюда). На эту же тему писал Егор Толстой и даже сам E. Dijkstra:

💬 "Simplicity is a great virtue but it requires hard work to achieve it and education to appreciate it. And to make matters worse: complexity sells better."
—Edsger W. Dijkstra, 1984 On the nature of Computing Science (EWD896)

Менеджмент не сможет оценить качество кода, если не обладает соответствующим образованием. Но менеджмент рано или поздно заметит разницу в темпах разработки между вашей командой и другими командами, и начнет доверять вам больше. Если, разумеется, у вас хватит выдержки дотянуть до этого момента. Тут главное - взобраться на горку.

Труднее обстоит дело, когда вы не можете передавать знания команде личным примером, например, на позиции лида или архитектора. Для менеджмента ваши "инструкции к бензопиле" - просто отвлекание команды "от рубки леса". Возникает дилемма: спасать менеджмент от самого себя, вопреки его воле, понимая, что он никогда это не оценит, или же проявить внешний конформизм, осознавая, что
💬 "Те компании, которые не осознают, что знания являются средством производства более важным, чем земля, труд или капитал, постепенно умрут и никогда не поймут, что их погубило."
—Ларри Прусак

Хотелось порассуждать дальше, но закончилось место. Ладно, потом...

Так, пацаны, все меняется, нас заменит не ChatGPT, а Devin но это неточно!

Брендированные типы в typescript

Привет, с вами снова @devmargooo и сегодня мы с вами поговорим о типизации в приложении на typescript. Структурная типизация в typescript, в отличие от номинативной, определяет совместимость типов, основываясь не на названии типа, а на его наборе полей. В этом структурная типизация похожа на утиную: если это выглядит как утка, плавает как утка и крякает как утка, то, вероятно, это утка. К сожалению, это может приводить к проблемам. Следующий код не приведет к ошибке компиляции, несмотря на то, что тип some_string указан как string, а не Email :

type Email = string;

function auth(login:Email) {}

const some_string:string = "some_string";

auth(some_string); // ok

Тип string структурно идентичен типу Email , поэтому ошибки нет.

Номинативные типы работают по-другому - они совместимы только при явном использовании. К сожалению, встроенной поддержки таких типов в typescript нет, но есть хак, который называют брендированием. Его суть заключается в том, что мы добавляем к типу уникальное свойство:

type Email = string & { _: 'Email' };

Теперь тип Email будет структурно не совместим с типом string. Мы получим ошибку компиляции:

type Email = string & { _: 'Email' };

function auth(login:Email) {}

const some_string:string = "some_string";

auth(some_string); // Argument of type 'string' is not assignable to parameter of type 'Email'.

Чтобы код заработал, нам придется явно указывать, что переменная имеет тип Email:

const some_string = "some_string" as Email;

Или добавить проверку в наш код, которая также будет выводить нужный нам тип:

function isEmail(value:string): value is Email {
    const emailRegex = /^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$/;
    return emailRegex.test(value);
}

Для удобства создания брендированных типов можно воспользоваться дежнериком:

type Brand<B extends string, T> = T & { readonly _: B }

Пример использования:

type Email = Brand<'Email', string>;

На Boosty добавил запись стрима "Как разбить монолит на компоненты" (доступ только для подписчиков Boosty, так же стрим доступен на soer.pro)

У нас в клубе много профессионалов, которые открыто делятся знаниями, хочу порекомендовать человека из клуба, который завёл канал, где фиксирует мысли по менеджменту, канал называется "Management stuff". Не реклама, реально ведёт один из наших соеров.

На Boosty опубликовал запись стрима "Архитектура простого гибридного веб-приложения с реактивным поведением". Доступно подписчикам уровня "Стрим". Так же оригинальная запись доступна на soer.pro

Отличный доклад про моделирование предметной области на типах:
https://www.youtube.com/watch?v=2JB1_e5wZmU&t=2s&ab_channel=KanDDDinsky

Небольшой, но интересный обзор нашумевшей технологии ИИ-инженера Devin

Обсуждаем в клубе идеальное резюме, вот такой вариант мне прям очень понравился (по оформлению) https://cdn.myresume.ru/wp-content/uploads/2022/02/Rezjume-po-GOSTu.png

В связи с развитием AI найм в айти будет сильно меняться. Можно, конечно, верить, что все останется как сейчас, но лучше подготовиться к разным вариантам развития.

Среди желающих попасть в айти найти хорошего специалиста очень трудно. Новичков много, средний уровень становится все ниже. Плюс рынок уже не готов брать кого угодно. Проблема усугубляется тем, что нейронные сети развиваются со скоростью света и уже формируют требования к новым специалистам, которые просто обязаны иметь соответствующие навыки для работы с AI.

Дальше тренд будет только усиливаться, новички будут подвергаться все более строгим проверкам и конкурс на место будет только расти.

Мне кажется, что из-за возросших требований, формируется тренд на профессиональные сообщества, которые будут в условиях нового рынка помогать своим участникам развиваться и соответствовать новым требованиям.

Рекомендации и нетворкинг работают и сейчас, но я думаю, что их роль будет усиливаться.

Поэтому, мы будем в Соер клубе особое внимание уделять проблемам найма, и всячески оказывать помощь при поиске первой работы. Сегодня это цель номер один.

Я люблю идеи OpenSource ещё с тех пор, когда начал писать первые игры (1998 год) и познакомился с библиотекой Allegro, которая строго говоря не называлсь тогда OpenSource, но была ярким примером свободного софта.

Моё понимание OpenSource в значительной мере связано с идеями свободного софта, ведь здорово когда люди делятся своими наработками, получают обратную связь и в целом делают индустрию лучше.

Недавно в России проводили интересный опрос о том как обстоят дела с OpenSource. Ожидаемо, что свободным софтом пользуются почти все, очевидная польза открытых проектов доказана практикой многих компаний. Но так же важно, что больше половины людей считают что нет отдельного российского OpenSource.

Последний вывод важен тем, что соответствует вайбу открытого софта, это важно помнить и понимать, как только появляются границы, идея превращается в тыкву.

Как относитесь к переходу многих технологий - Redis, как недавний пример, на двойное лицензирование, вместо лицензии, которая соответствовала open source?

Для меня здесь несколько моментов:
1. Для создания хорошего софта нужны деньги и компании всегда будут искать варианты монетизации своих продуктов. Это нормально.
2. Переупаковка софта с открытым кодом с целью дальнейшей продажи - часто встречаются на рынке и то что Redis хочет ограничить такую возможность - это нормально.
3. Не нормально то, что теперь людям надо дважды думать, что они могут делать с кодом от Redis, а чего нет. Это дополнительная сложность, которая может быть ложкой дёгтя в бочке мёда. Хотя ядро, вроде, осталось под BSD лицензией, но все равно не все прозрачно и понятно.

В целом рынок становится все сложнее, компаниям хочется зарабатывать и развиваться, так что как говорится се ля ви.

12 факторов, влияющих на качество веб-приложений

1. Кодовая база
В проекте должна быть единая кодовая база для развертывания на всех стадиях тестирования и работы в проде. Кодовая база должна подвергаться многократному ревью в процессе работы.

2. Система конфигурирования
Конфигурация должна быть выделена в отдельную подсистему, а сами конфигурационные данные обрабатываться и храниться в рамках единой политики (например, использовать среду окружения)

3. Сервисный подход
Инфраструктурные вещи должны использоваться через надежные сервисы, а не переписываться каждый раз с нуля.

4. Явные зависимости
Зависимости должны быть определены прозрачно и группироваться (или изолироваться) по отношению к собственному коду

5. Разделение на четкие стадии развертывания
Сборка, развертывание, запуск должны быть отдельными стадиями.

6. Процессы
Разработка программного обеспечения должна быть организованна по процессным подходам (минимально - процессы проектирования, документирования, контроля качества и разработки)

7. Резервное копирование
Должна быть предложена внятная политика резервного копирования как пользовательских, так и служебных данных

8. Горизонтальное масштабирование
Должна быть проработана стратегия увеличения производительности за счет увеличение количества узлов, на которых развернуто программное обеспечение

9. Вертикальное масштабирование
Должна быть проработана тактика увеличения ресурсов на одном узле, с целью повышения производительности

10. Контроль и улучшение производительности
Должны профилироваться время загрузки, время отклика системы, количество единовременных конкурентных запросов и т.д. Должны быть проработаны контрольные точки (SLA) в рамках которых должна функционировать система

11. Логирование
Должна быть продумана подсистема логирования и составлен список логируемых данных (по списку можно проводить моделирование проблемных ситуаций и выявлять недостающие данные, которые нужно логировать).

12. Администрирование
Должна быть проработана политика администрирования программного продукта.

#знания #теория

Старые добрые структурные подходы, которые много лет используются в разработке программного обеспечения, не всегда хорошо работают в современных системах, завязанных на асинхронной обработке данных.

Для лучшего понимания сути проблемы рекомендую к прочтению старую заметку о том как структурные проблемы можно решать за счет Behavior programming

#знания #теория #ссылка #рекомендация

На boosty делаю зеркало записей стримов, размещенных на soer.pro, сегодня перенес запись "Архитектура с общей шиной и очередью". В видео рассказываю чем шина отличается от очереди, как правильно использовать шину и очередь в своих проектах.

Полный архив всех стримов есть на soer.pro

что думаете по поводу предстоящего релиза snapdragon x elite, будущего арм vs х86, и кто будет лидировать на рынке не-apple arm процессоров?

1. Мне нравится активный движ, который идет в сторону arm процессоров
2. Думаю что массовое применение вопрос недалекого будущего, на ноутах АРМ процессоры вполне себе могут вытеснить x86
3. x86 пока выглядит сильно "роднее" и эту инертность сознания еще надо преодолеть
4. Пока непонятно что будет с десктопами, не слышал про выпуск процессоров отдельно, только в сборке с ноутом или планшетом
5. Кто будет лидировать не знаю, скорее всего легко могут появиться и новые игроки, и старые делить рынок в разных пропорциях. Не располагаю данными для прогноза