На первой лекции курса мы рассмотрели:
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 в Белке (библиотека КПИ). Если вы не студент КПИ - не забудьте взять с собой документы
Лекция о шаблонах проектирования, в которой мы успели поговорить о синглтонах, наблюдателях, проблемах инстанцирования (различные фабрики), стейт-машинах и еще некоторых мелочах типа 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