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

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

Мне стало интересно, потому что у меня давно работает xdonate - https://donate.s0er.ru это простенький mvp на реактивной архитектуре с приемом донатов и возможностью опубликовать сообщения в OBS. Я рассматривал его создание в воркошпах на https://soer.pro

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

Но мне кажется, что для разработчиков собственная система (а исходники моей системы доступны на тарфие PRO) позволяют на собственном VPS развернуть не только базовую функциональность, но и дописать свои модули.

К чему я все это пишу. Думаю, что базовая система xdonate пойдет в opensource, а модули и возможность кастомизации - это тема для новых воркшопов. А там есть сделать - это и "подарки" за донаты (например, возможность скачать файл тем кто задонатил), и голосовалки, и связь с чатами и чат-ботами...

Интересно стоит ли копать эту тему (палец вверх - за, палец вниз - против)?

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

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

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

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

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

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

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

Так что формализация - это не вопрос "надо/не надо", это показатель квалификации в первую очередь.

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

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

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

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

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

Для интересных решений предусмотрены подарочные "коды" для получения тарифа "PRO" на soer.pro. Т.е. по факту бесплатная возможность получить все материалы. Ну а в конце года я выберу лучшего из лучших и он получит награду "золотой Соер", ну или "золотая печенька". ) Второе название нравится мне все больше.

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

Я не видел в информационном поле людей, которые делали что-то подобное. Как правило встречается пересказ уроков, объяснения в тысячный раз базовых принципов, а чего-то по настоящему творческого и интересного нет.

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

Запустил стрим https://youtu.be/2Bog1FpL1PU

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

Принцип KISS - Keep it simple, stupid
Принцип, который говорит о том, что простые решения работают и выполняют поставленные задачи, как правило, лучше сложных. Идея принципа в том, чтобы стремиться к "простому", избегая "сложного".
Этот принцип интуитивно понятен - не делай "велосипеды", не используй лишнее, не додумывай задачу, не стремись к универсальному решению.
Вот только частенько, делая все "по KISS", на выходе получается не элегантное, удобное решение, а глюкавый монстр.
Почему так?
Об этом я порассуждаю в своем следующем видео "Принцип создания хороших решений - KISS".

Принцип KISS

Запустил стрим - https://youtu.be/fVkx7JBvM1g

Есть ли у вас проблема с доведением идей до реализации?
Поясню о чем я, делая контент и развивая свои социальные проекты я реализую всего-лишь около 30% тех идей, которые у меня появляются. У меня есть много наработанного материала, который лежит и пылится, а я не могу снять по нему видео.
Понимая, что распыляюсь, я пытаюсь сузить фокус, но все равно КПД остается низким.
Не думаю, что это плохо, потому что лучше выполнить 30% от большой цели, чем 100% от маленькой. Смотреть на абсолютные цифры тоже надо.
Мне просто интересно узнать если такая проблема у вас - если так же реализуете далеко не все, что задумали, то палец вниз, если реализуете более 75% своих целей, то палец вверх.

Планирую сделать несколько видосов по формальному анализу проектов.
Для начала хочу поговорить про зависимости и развитие проекта, вот такой график "количество зависимостей (внешних пакетов) / версия" для npm. Много чего интересного из него можно "вытащить".