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