На следующей лекции мы поговорим о теме, которую по многим причинам недолюбливают разработчики. Потому что их код «и так работает».
Зачем же тогда нужно автоматическое тестирование, особенно если в команде есть тестировщики? Зачем писать тесты, если и так видно что код действительно рабочий и это легко проверить? Чем отличаются 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 - если вы не из КПИ, не забудьте взять документы

Не смотря на то что у всех сегодня перенос рабочего дня, библиотека оказалась неожиданно и плтоно закрыта. Прошу прощения за неточный анонс, лекцию о аджайле придется перенести ещё на неделю
https://youtu.be/x05Z6SjLZF0

​​Повторный анонс - на прошлой неделе лекция не состоялась из-за графика работы библиотеки, что мы обязательно наверстаем завтра

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

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

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

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

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

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

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

Завтра в 10:30 студенты будут писать контрольную работу, поэтому лекции не будет. Если вы посещали\смотрели лекции и тоже хотите проверить свой уровень знаний - можете тоже приходить и попробовать.

Формат задания: спроектировать в свободной форме предложеную систему.

Семестр плавно движется к концу, наши планы на ближайшее время:
1. В чате (@softwarearchanddev_chat) я выложил задания контрольной работы этого года. Если есть желание попробовать её написать - выбирайте любой вариант и сбрасывайте мне (@artemkorotenko) решение в свободной форме.
2. Последнее занятие в этом году мы проведем через неделю, в субботу 8 июня, где рассмотрим эти задания вместе со всеми наиболее частыми ошибками\замечаниями.
3. В очереди еще ждет три видео: про agile, вторая часть про tdd и работу с legacy, которые я скоро выложу.
4. Завтра, в первый день лета - отдыхаем

Долгождання лекция об Agile-разработке: почему все технические специалисты должны об этом знать и разбираться, откуда это дело пошло, с чем его есть, а так же как научиться распознавать и бороться с Agile карго-культом
https://www.youtube.com/watch?v=WUAfzlsz5AY

Не менее долгождання вторая часть лекции о TDD, из которой можно узнать о моках, стабах, сабтитьютах, а также увидеть разбор практических примеров написания тестов
https://www.youtube.com/watch?v=Bi-vOpKEJTE