Привет.
Вот хочу поделиться интересным видео
Евгений Кривошеев — Long live your project!
https://www.youtube.com/watch?v=_Kex5hwGE-w
Вот всегда поражался таким людям. Создается такой впечатление или это боги программирования спускаются на нашу землю чтобы нас учить или это я полный нуб в программировании, которому место только на Basic.
Чрезвычайно интересная и полезная лекция.
Что касается ведущего, то можно сказать, что у человека:
(1) хорошо поставлено мышление;
(2) отлично разбирается в инженерно-архитектурном менеджменте, а это тема общая тема, но в данном случае приложена к разработке ПО.
(3) Харизматичный лектор.
Сразу нужно отметить, что лектор дает ответы или по крайней мере ориентиры по многим спорным вопросам, которые мы здесь обсуждали, но не пришли к единому мнению. Единственное что не обсуждается — это необходимость использования ООП там где это нужно, так как это само собой разумеется.
Вот мой конспект лекции:
Если не понятно — то делай проще.
В конце концов спроси себя: Что ты делаешь: конкретную систему или фреймворк подобных систем?
Извечная борьба с неопределенностью:
что нужно?
что делать?
фокусируйтесь на тех точках зрения, что важны для проекта, а не те что кажутся сложными или легкими.
Меньшая связанность позволяет тестировать компоненты автономно.
Пилотировать на Питончике и затем уже внедрять на Энтерпрайз уровне на «кровавой» Джаве
Нормальный менеджер не позволит сделать коммерческий проект на редкой технологии, так как он просто не найдет позже студентов, которые его будут поддерживать, так как таких студентов не готовят. ([мой вывод: пока вузы готовят студентов-джавистов — она бессмертна, так как для бизнесу как воздух нужно иметь на рынке труда свежее, дешевое мясо]).
Быстрая, интерактивная спринтовая разработка суть которой заключается в возможности быстрее получить фидбек
задачи методологии дать инструменты борьбы с неопределенностью
паттерн «красная пятница»
нужно отделять бизнесовую необходимость от инженерных амбиций
неизбежная проблема неопределенности
а вот здесь я не заложил абстракцию и теперь новые требования не попадают в точку изменчивости проекта
для продуктовой разработке является нормой бесконечное перепиливание системы.
Архитектура — это набор элементов и связей, которые образуют вашу систему.
И:
Архитектура — это набора компонентов и связей и принципы построения
и в конце концов:
Архитектура — это решения адресованные на ключевые проблемы.
И если вы ошибетесь с решением, то убъете бизнес.
А дизайн — это любые другие решения, которые можно отложить или делегировать это решение на не самого главного сотрудника.
Можно начать проект с ключевых абстракций, а позже наращивать мясо .
Вначале стабилизировать контракт, закрыть тестами, затем делать реализацию.
ООП позволяет сформулировать контракт, ключевые компоненты, а реализация — это потом.
Выстраивание и реализация логики Main flow or Happy pass занимает - 20% времени
а вот Alternative flow - 80% времени.
архитектурный антипаттерн «Микроменеджер»: хочу контролировать все!
Доверяйте и делегируйте решения, которые не несут ключевых рисков, иначе начнется демотивация в стиле «работаю от забора и до обеда».
делается в соответствии с собственным мировоззрением, которое не соответствует проектному
нужно проверить важные архитектурные гипотезы ASAP
и после не умереть под «техническим долгом»
«с шахматами и поэтессами» ([это шутка отнаследованна от базовой шутки «с блекджеком и шлюхами»])
«я художник, я так вижу»
Делитесь тем, что важного вы услышали в этой лекции.
