S0ER

Планы на развитие "Золотого Соера". Я в прошлом году начал "прощупывать" тему создания собственной награды за вклад в развитие российского АйТи (нескромно? Да! Но почему нет?) и сначала хотел чтобы эта награда доставалась ютуберам. Но чем больше я думаю об этом, тем больше понимаю, что айти поддерживают те, кто пишет реальный код. Сам смысл слова "soer" - это сокращение от "software engineer". Поэтому решил модифицировать правила следующим образом: - переодически выпускать ролики с небольшим заданием на разработку - все желающие пишут свое решение и публикуют у себя в гитхабе (ссылку кидают в телегу в комментария к видео) - я проверяю решению, нахожу наиболее интересное и делаю ревью на канале (возможно рассматриваю несколько решений) Для интересных решений предусмотрены подарочные "коды" для получения тарифа "PRO" на soer.pro. Т.е. по факту бесплатная возможность получить все материалы. Ну а в конце года я выберу лучшего из лучших и он получит награду "золотой Соер", ну или "золотая печенька". ) Второе название нравится мне все больше.

Интересная статья про устранение программных дефектов https://www.ifpug.org/content/documents/Jones-SoftwareDefectOriginsAndRemovalMethodsDraft5.pdf

Если говорить про наиболее эффективные способы поиска ошибок, то мат. моделирование - это самый эффективный способ, его эффективность составляет от 60% до 80%, различные неформальные инспекции где-то 35%-55%, формальные инспекции 45% - 60%. При этом эффективность тестирования - это результат комбинации разных подходов (вы можете написать тест руководствуясь результатами формальной инспекции, или мат. модели).

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

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

Я уже писал ответ Роме, на эту часть комментария. С позиции "интуиции" тут понятно, что каждый сам доопределит что вкладывается в термин "операция сложения", а вот с позиции формального подхода очевидно, что "операция сложения" в компьютере может быть по-разному определена даже для чисел, не говоря о массивах, строках и т.д. Есть много видео о том как советуют проходить собеседования в ФААНГ, везде говорят, что нужно задать дополнительные вопросы для того, чтобы понять все ограничения задачи. А это и есть формализация задачи. Те кто кидаются решать задачи сразу, полагаясь на интуицию имеют меньше шансов на высокие результаты. Так что формализация - это не вопрос "надо/не надо", это показатель квалификации в первую очередь.

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

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

Видео: "Мощный метод поиска багов в программе"

Мне стало интересно, потому что у меня давно работает xdonate - https://donate.soer.ru это простенький mvp на реактивной архитектур с приемом донатов и возможностью опубликовать сообщения в OBS. Я рассматривал его создание в воркошпах на https://soer.pro Понятно, что MVP для приема персональных сообщений это совсем не тоже самое, что разработка системы, которая имеет многопользовательский режим работы. Но мне кажется, что для разработчиков собственная система (а исходники моей системы доступны на тарфие PRO) позволяют на собственном VPS развернуть не только базовую функциональность, но и дописать свои модулю. К чему я все это пишу. Думаю, что базовая система xdonate пойдует в opensource, а модули и возможность кастомизации - это тема для новых воркшопов. А там есть сделать - это и "подраки" за донаты (например, возможность скачать файл тем кто задонатил), и голосовалки, и связь с чатами и чат-ботами... Интересно стоит ли копать эту тему?

На канале Диджитилизируй рассматривается процесс создания системы донатов. Вот второе видео из серии https://www.youtube.com/watch?v=FjGTtkWT_Pw

Читая разные материалы устал от неразберихи с понятиями "связность" (cohesion) и "зацепление" (coupling). Глаза ломаются когда читая "высокое зацепление" (High Cohesion), даже по смыслы "зацепление" - это связь между двумя компонентами, где один "зацепился" за другой, а связность (не путать со связанностью) это сила связей внутри компонента. Не знаю кто прав, кто виноват, но есть такое расхождение, о нем просто нужно знать.

Подписчик подсказал интересный ресурс - https://feature-sliced.design/ Пока глубоко не копал, но на первый взгляд интересный подход

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

Перезалив: Популярная архитектура под ВЕБ

Популярная архитектура под ВЕБ

Теперь Телеграм заменит мне все социальные сети. Раньше какие-то свои мысли я писал в Твиттер, что-то писал в постах на ютбе, что-то писал на сайте https://soer.pro Но теперь у меня будет моноаккаунт в телеге. Здесь и посты, и видео, и размшления. И что самое важное - общение по OpenSource проектам. - Сейчас у меня уже вложен черновик (потому что пока проектом я стесняюсь эту поделку назвать) OBSOverlay - https://github.com/soerdev/obsoverlay - Кроме этого фронтовая часть сайта soer.pro - https://github.com/soerdev/soer Последний, кстати, это как раз пример того, что я буду двигать на канале и для патронов - пример полноценной реактивной архитектуры и разработки на базе монорепозитория. Монорепо - потому что я "маленький", т.е. у меня нет команды и все приходится делать самому, а монорепо помогает снизить издержки. Некоторые архитектурные идеи я пока не могу реализовать. Например, пришлось экстренно решать вопрос с приемом платежей на soer.pro, по-хорошему можно было сделать нормально функционирующий сервисно-ориентированный платежный шлюз, который далее использовать и для xdonate и для soer.pro. Но время заставляет делать на скорую руку. Стандартная боль стартапов. Правда, это позволит в будущем показать как разруливать такие ситуации и эволюционировать в сторону нормальных архитектур.

Зрители канала предложили использовать телеграм в том числе для постинга видео с канала. Решил для начала перенести сюда несколько хороших видео и посмотреть что получится.

Завел резервный канал на Яндекс Дзен - https://zen.yandex.ru/id/5f578bdf22e26e081a67cfd2

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