Привет!

Я - Артем Коротенко, и, возможно, вы слышали о том что в первом семестре в Белке проходит мой открытый курс геймдева (@gamedevkpi). В этом семестре мы совместно с Георгием Исаченко, которого вы знаете по лекциям по защиты информации (@softwareanddatasecurity) попробуем провести еще один курс совместно с кафедрой ВТ ФИВТа - Software Architecture & Development.

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

Чем будем заниматься?
Учиться проектировать приложения, смотреть на задачи с инженерной точки зрения, думать в категориях шире чем языки программирования и фреймворки. Будем говорить в большей части об архитектуре, частично - об организационной стороне процесса (про всякие аджайлы с точки зрения технических специалистов)

Какой порог входа?
Хорошее понимание основ программирования, минимальный опыт работы с ООП и\или ФП языками. Мы будем затрагивать многие вещи повторно, поэтому если курсы архитектуры или шаблонов проектирования у вас были, но совсем не усвоились или не оставили понимания как их применять - приходите.

Когда начинаем?
По субботам, в Белке, в 10:30. 23 числа будет первое, вводное занятие где мы детально рассмотрим проблемы, которые подталкивают к созданию такого курса, план на будущие ~10 лекций и общий набор скилов, который мы планируем немного прокачать за это время

Лекции будут открытыми, с записью на видео, если вам интересно - подписывайтесь на канал @softwarearchanddev и чат @softwarearchanddev_chat, ближе к субботе будет еще один анонс

​​Итак, уже завтра нас ожидает первая лекция из курса Software Architecture & Development.

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

Лекцию я озаглавил Product-oriented engineering и в самом названии уже скрыт намек на то, чего, по-моему мнению, нам часто не хватает в разработке. Мы поговорим о том, что же это за "продукто-ориентированность" и почему именно знания об архитектуре приложений и процессе разработки должны нам помочь в главной цели - создании более качественных и конкурентных продуктов. Именно это знание поможет нам перейти ко всем остальным узким и специфическим темам (которые мы завтра тоже перечислим и кратко обсудим). Приставка with pictures призвана успокоить всех заинтересовавшихся тем, что говорить будем простыми словами и с понятными примерами.

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

10:30, Белка (библиотека КПИ, 3 этаж), вход свободный.

На первой лекции курса мы рассмотрели:
1.Что можно называть "ориентированностью на продукт" в разрезе работы разработчика и почему этого часто не хватает?
2.Почему без полноценного вовлечения команды разработчиков в проект сложно построить качественную архитектуру приложения?
3.Какие проблемы в университете и последующей работе к этому приводят.
4.Основные темы предстоящих занятий, рассматривая которые мы будем стараться все эти проблемы хотя бы частично решить
https://www.youtube.com/watch?v=NkCfagj2VPI

В субботу с утра в Белке будет проходить Defcon Kyiv meetUp, в связи с чем нам нужно перенести время лекции. Если отталкиваться от того что проводить лучше в выходной день, есть два варианта:
public poll

Воскресенье утром - 10:30 – 95
👍👍👍👍👍👍👍 52%

Суббота, но вечером - 17:30 – 57
👍👍👍👍 31%

Подходят оба варианта – 31
👍👍 17%

👥 183 people voted so far.

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

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

Важно! В Белке завтра проходит ивент, поэтому лекция пройдет в воскресенье, в то же время - 10:30 в Библиотеке КПИ.

Пятница - праздник, в связи с чем много кто уезжает из Киева на три дня. Стоит ли проводить лекцию в субботу?
anonymous poll

Без разницы - я только видео смотрю – 138
👍👍👍👍👍👍👍 45%

Стоит, я приду – 88
👍👍👍👍 29%

Лучше перенести - у меня не получится прийти – 79
👍👍👍👍 26%

👥 305 people voted so far.

Что такое структурное программирование и почему современные языки избегают конструкции goto?
Какой основной принцип лежит в основе функционального программирования и позволяет вывести все остальные?
Почему Алан Кей (один из создателей технологии) считает термин ООП неудачным и в чем вообще суть ООП?

Ссылки на все материалы, которые я упоминал в лекции - в описании видео на ютубе https://youtu.be/PQfsUWaKsLI

​​В связи с первыми весенними выходными, и тем что наша следующая тема очень важная в курсе лекции завтра не будет - что такое настоящий SOLID мы рассмотрим в следующую субботу, 16 марта.

Если у вас остались какие-то вопросы после лекции о парадигмах - задавайте в чат.

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

На картинке - легендарная Ада Лавлейс, автор первой программы, Грейс Хоппер, создатель первого компилятора и уже знакомая нам Маргарет Гамильтон, программист команды "Аполлона" и автор термина "Software Engineering"

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

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

Белка (библиотека КПИ), суббота, начало в 10:30

Лекция о принципах SOLID - откуда взялись, какие проблемы решают, как правильно понимать (!) и как пользоваться.
Ссылки на литературу - под видео. В этот раз попробовал добавить таймкоды для удобной навигации - все-таки полуторачасовая лекция не самый привычный для ютуба формат.
https://youtu.be/BWJMnn9bVJg

​​В теме четвертого занятия из нашего курса наконец появляется слово "архитектура", и завтра мы будем говорить о:
1. Собственно, архитектуре приложения и некоторых подходах к ее созданию - "чистая" архитектура, шестиугольная (hexagonal) и т.д.
2. Почему у UML не получилось, а юзкейсами неправильно пользуются.
3. Способах разделения отображения внутри программы (MVC, MVP, MVVM) и почему MVC - паттерн, а не архитектура.

Приходите, будет насыщенно. Суббота, 10:30, библиотека КПИ (пока еще турникеты не работают, вход свободный)

На следующей лекции мы поговорим о теме, которую по многим причинам недолюбливают разработчики. Потому что их код «и так работает».
Зачем же тогда нужно автоматическое тестирование, особенно если в команде есть тестировщики? Зачем писать тесты, если и так видно что код действительно рабочий и это легко проверить? Чем отличаются unit-тесты от интеграционных тестов, и какое кому до этого дело?

Ну и конечно же, что такое Test Driven Development и как такой подход помогает проектировать чистый код.

❗️ Завтра в Белке проходит ивент IT KPI, поэтому лекция состоится в воскресенье, в 10:30, в Белке

❗️❗️❗️ В связи в вводом в действие турникетов слушателям не из кпи нужно обязательно взять с собой документ (например, паспорт) и регистрироваться в форме: https://forms.gle/UT53WtN6DWzGaFhYA

По поводу пропущенной лекции: Из-за технических проблем лекция о чистой архитектуре не записалась на видео :( Мы её повторим на следующей неделе, и видео появится через пару недель

На этой лекции мы говорили о темах, которые по многим причинам недолюбливают разработчики: unit-тесты (также называемые модульными тестами) и Test Driven Development.

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

https://www.youtube.com/watch?v=HLbQ3vUJ0q4

Теперь, после того как мы крупным планом посмотрели на архитектуру и познакомились с TDD, мы немного вернемся к менее абстрактным вещам и поговорим о проблемах, которые возникают в нашем коде во время разработки и проектирования (и которые мешают нам пистаь чистый код) и некоторых общепринятых решениях этих проблем - собственно, их мы и знаем под названием "шаблоны проектирования".

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

Белка, суббота, 10:30 - не забудьте взять документы, если вы не из КПИ - турникеты уже работают

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

Не болейте, пейте чай и не смотрите политических новостей до 21 апреля.

Анонс новой лекции будет вечером, а пока наконец выкладываем многострадальное видео лекции о Чистой Архитектуре и вариациях шалона MVC
https://www.youtube.com/watch?v=FsW9p8EHQLY

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

Беда в том, что продукты редко ограничиваются такими легко-тестируемыми алгоритмами, и намного чаще состоят из огромных и сложных компонентов, которые между собой взаимодействуют. Так просто не протестируешь поведение, работающее с базой данных, или с удаленным сервером, или использующее многопоточность, или с множеством одновременных запросов от клиентов, или «абсолютно нетестируемые» продукты, вроде компьютерных игр. Даже если мы возьмем простой случай обычного пользовательского интерфейса, как писать unit-тесты чтобы удостоверится, что все работает по плану?

Более того, часто возникает потребность покрыть тестами уже существующий код. А он обычно не блещет красотой, так как изначально не был написан с расчетом на то, что кто-то возьмется его покрывать тестами? Как тогда покрыть тестами поведение, которое использует статические классы, изменяемые глобальные состояния, синглтоны, локаторы сервисов и прочее.

Об этом мы с вами будем говорить на паре завтра, в 10:30 в Белке (библиотека КПИ). Если вы не студент КПИ - не забудьте взять с собой документы

В связи с длинными праздниками и общими разъездами следующая лекция состоится через неделю, 4 мая. Ожидайте скоро два новых видео!

Лекция о шаблонах проектирования, в которой мы успели поговорить о синглтонах, наблюдателях, проблемах инстанцирования (различные фабрики), стейт-машинах и еще некоторых мелочах типа null-objectов или адаптеров

https://www.youtube.com/watch?v=7MAfmlFbyYI

Наконец пришло время поговорить о самой технической теме из списка кажущихся нетехническими. Время поговорить об Agile-разработке.

Как так получилось, что Agile-манифест составили программисты и технические специалисты, а сам набор техник в итоге традиционно считается чем-то менеджерским и чисто организационным? Почему организация процесса разработки (и понимание того, какие проблемы в нем приходится решать) - критически важный навык для технического специалиста? Почему один из авторов Agile, Мартин Фаулер (тот самый), много говорит о неправильности его использования сегодня?

Завтра мы поговорим немного об истории разработки ПО, озвучим проблемы, которые появились в сфере, обозначим возможные пути их решения и перспективы. Даже если вы не фанат гибких методик, после завтрашней лекции вы сможете увидеть, почему в вашей организации Agile не работает.

Белка, суббота, 10:30 - если вы не из КПИ, не забудьте взять документы