Враження про відвідини конференції CRAFT в Будапешті (23-25 ​​квітня)

    Всього якийсь місяць тому (23-25 ​​квітня) в славному місті Будапешт пройшла конференція для розробників CRAFT . Мені пощастило на неї потрапити і ось тепер дійшли руки написати відгук про побачене і почуте.
 
Конференція заманила до себе не тим, що можна за корпоративний рахунок вибратися до Європи, а підбіркою запрошених авторів, серед яких були Dan North, Michael Feathers, Bruce Eckel, Eric Evans, Greg Young. Дивно, що про неї не було згадки на Хабре. Не дивлячись на те, що конференція заявляли як конференція для розробників, вона була зовсім нема про технологіях. Було кілька доповідей про використання конкретних технологій, але більшість доповідей було про розробку взагалі.
 
Девізом конференції можна назвати заклик «Адаптуйся!». Ця думка звучала в дуже багатьох доповідях. Може організатори тому не видали блокнотів в пакеті учасників — хотіли, щоб ми адаптувалися? =) При цьому видали ручки і довелося шукати блокнот в навколишніх магазинах.
 
Під катом опис і відео доповідей, які мені здалися найбільш цікавими.
 
 Вставити відео прямо в статтю не вийшло, тому відео представлено посиланнями. Якщо хто допоможе зі вставкою самих відео, то буду вдячний.
 
Для себе я виділив кілька найбільш корисних і цікавих доповідей, а решта розташував у хронологічному порядку.
 
 

Найбільш корисні та / або цікаві доповіді (дуже рекомендую до перегляду)

 
How I Learned to Stop Worrying and Love Flexible Scope (Gojko Adzic)
 Відео доповіді
Дуже змістовний перший доповідь, який задав тон для всієї конференції. Основна думка: гнучкі підходи застосовні тільки там, де мінливий зовнішній світ. Якщо зовнішній світ статичний стосовно системи, то scrum вироджується в waterSrumfall , що тягне накладні витрати без додаткового профіту. Якщо ж зовнішній світ недостатньо відомий або швидко змінюється, то треба вміти адаптуватися. Як приклад, автор наводить досвід команди Дукаті під час їх дебюту на треку супербайка. У критичній ситуації все гнучко, тому що треба швидко адаптуватися, інакше не виживеш.
 
Як спосіб адаптації до ситуації автор пропонує користувальницькі історії (User Stories).
 
Основна думка: з користувацьких історій потрібно складати і використовувати roadmap за її прямим призначенням: як " карту доріг ". Автор каже, що більшість бачених ним roadmap представляли насправді тунель , а не карту доріг . Тунель передбачає рух тільки в одному напрямку, а не безліч варіантів шляхів. Як приклад автор наводить автомобільний навігатор. Він ідеальний для планування та орієнтування на місцевості, бо показує два основних інформаційних блоку, що описують поточну ситуацію:
 
     
відстань до наступного повороту;
 напрямок наступного повороту.
 
Далі автор перейшов до принципів Палчінского з книги Тіма Харфорд Adapt: ​​Why Success Always Starts with Failure : посилання на цитату про принципи.
 
Автор показує, що користувацькі історії потрібно використовувати для аналізу того що замовник насправді хоче, а потім для адаптації до поточної ситуації проекту. Не треба намагатися реалізувати всі історії, тому що це може бути або не потрібно, або дуже дорого. Замість цього треба розглядати користувальницькі історії як набір альтернатив (карта доріг), які можна вибирати при зміні ситуації навколо проекту.
 
Казав, що готує до виходу книгу «50 quick ideas to improve your User Stories».
 
 
Architecture War Stories (Stefan Tilkov)
 Відео доповіді
Доповідь з розряду «як так виходить, що розумні люди роблять дурні речі». Варто дивитися, щоб спробувати порівняти свою поведінку з прикладами. Приклади всі життєві з реальних проектів. Наприкінці автору навіть поставили запитання «а ви взагалі працювали на успішних проектах». Доповідь дуже легко виглядає через велику кількість прикладів і цікавих моментів, над якими можна посміятися.
 
Автор висміює архітектурні фейлов — рішення, які були прийняті в різних проектах в різний час, в тому числі і ним самим. Розповідає про те, як це рішення народжувалося, чому ідея здавалося крутий і чому втілення ідеї виходило жахливим. Більшість систем, про які він говорить, використовуються в реальності. Автор робить лаконічні висновки про те, що не можна робити або навпаки треба робити, щоб уникнути подібних проблем. Кілька основних тез (все не виписував — без контексту вони будуть не зрозумілі):
 
     
Don't cache the cache.
 Data should be free of code dependencies.
 Fight the madness.
 
 
Jackstones: the journey to mastery (Dan North)
 Відео доповіді — на жаль відео починається приблизно з 10-ї хвилини. У першій частині Ден міркує про те як професіонали в різних областях вправляються у майстерності.
 
Доповідь про те як подорожувати до Майстерності і що таке Майстерність взагалі. За основу взято розповідь про складання орігамі «Jackstone», який автор не міг скласти 15 років.
 
Основне визначення: Майстерність — це можливості в контексті. Про цей доповідь складно щось розповісти, чи не переказавши його повністю. Рекомендую до перегляду всім, кому цікава тема вдосконалення своєї майстерності.
 
 
Acknowledging CAP at the Root — in the Domain Model (Eric Evans)
 Відео доповіді
Ця доповідь була найбільш очікуваним для мене — хотілося почути про ці три літери DDD з перших рук. Але, як не дивно, ця доповідь виявився одним з найбільш нудних доповідей на конференції. Може бути ще тому, що вже досить багато знаю про це і мало що нового почув з доповіді. Еванс розповідав зовсім без емоцій, академічним тоном. Слухати було важко, але суть передавав досить ясно.
 
Перша частина доповіді присвячена опису того як важливо правильно виділяти агрегати і їх коріння і як це може вплинути на працездатність і живучість системи в майбутньому. Розповідь базувався на прикладі з поставкою вантажних контейнерів через океани і координацією розкладу поставки. Показував як залежно від вибору агрегатів та їх коренів змінюється поведінка системи і які граблі виходять в кожному з випадків. Основні тези: правильно формулювати питання до системи і балансувати між нормалізацією і денормалізації.
 
Неконсістентность між станами агрегатів — це нормальне явище і існує в будь-якій складній системі. Тому вона повинна регулюватися угодами (SLA), які регламентують як довго така неконсістентность може існувати в системі.
 
Наприкінці доповіді трохи зачепив bounded context'и. Між контекстами треба використовувати Enevtual Consistencey.
 
 

Просто хороші і цікаві доповіді в хронологічному порядку

 
Going Reactive: Event-Driven, Scalable, Resilient & Responsive Systems (Jonas Bonér)
 Відео доповіді
Хороший вступний доповідь у принципи реактивного програмування і подієво-орієнтованої розробки. Автор гоовріт, що основною пробелми реактивного програмування є великий поріг входження, але після подолання цього порогу підхід стає очевидним і простим. Основні тези:
 
     
завжди треба використовувати слабке зв'язування;
 проектувати треба так, щоб не було блокувань ніколи;
 проектувати треба асинхронне взаємодія спочатку;
 дійові особи спілкуються тільки за допомогою обміну повідомленнями;
 використання Shared nothing architecture;
 прозорість розташування;
 
 
Agility and the essence of software architecture (Simon Brown)
 Відео доповіді
Нічого не буває безкоштовно. За будь-яке архітектурне рішення доводиться платити, тому немає ідеальної абстрактної архітектури. Гнучкість архітектури (як і системи) завжди відносна і залежить від часу. Тому завжди треба досліджувати і адаптуватися.
 
Через різних інтересів різних стейкхолдерів неможливо створити одну універсальну діаграму. Сукупність діаграм треба розглядати як набір карт різного масштабу, в яких набір абстракцій набагато важливіше набору нотацій. Пропонується використовувати C4 модель:
 
     
System Context
 Containers
 Components
 Classes
 
Мислити треба в компоненті, а реалізовувати в Класах. Важливо розрізняти ці дві точки зору. Ну і на закінчення, ключовий посил від автора доповіді: поверніть архітектуру назад розробникам !
 
 
What Makes a Good Development Process? (Bruce Eckel)
 Відео доповіді
Доповідь про те, з чого збирається якість процесу розробки в загальному. Не тільки написання коду, але взагалі всього процесу. Доповідь можна подивитися, якщо помста хвилин 50 вільного часу. не дивлячись на очевидність основних тез, вони не скрізь застосовуються, що призводить до поганих результатів. КО віщає:
 
     
Використання репозиторіїв для Версіонування, тестування всього що можна тестувати і автоматізіаціі всього, що робиться більше 1 разу, включаючи тести.
 Комунікація, чесність і прозорість протягом усього життєвого циклу проекту. У першу чергу перед замовником.
 Випускати в мінімально цінний продукт (Minimum Valuable Product). Але треба випускати продукт, цінний для замовника, а не для розробника. Виходячи з цього треба вибудовувати пріоритети у вирішенні конкретних завдань.
 Автоматична безперервна доставка (Continuous Delivery), як механізм постійного оновлення версії. Це дозволяє випустити першу версію MVP якомога раніше і далі допрацьовувати по найбільш важливих функцій.
 Помилки неминучі. На них треба вчитися і адаптуватися (знову «Адаптуйся!").
 BrainStorming замінити на BrainWriting. Під час BrainWriting учасники в письмовій формі висловлюють свої думки, а потім всі збираються разом і обговорюють. Це краще, ніж BrainStorming, бо висловитися можуть всі, а не тільки самі горласті.
 Найбільш зрозуміле і підтримуване рішення є найкращим вибором в більшості випадків.
 Необхідно робити CodeReview.
 
 
McDonalds, Six Sigma, and Offshore Outsourcing: Unexpected Sources of Insight (Chad Fowler)
 Відео доповіді
Доповідь від колишнього саксофоніста, який став розробником. Введений доповідь другого дня конференції, тому він про світ розробки в цілому. Про натхнення і куражі при розробці, про якість програмного забезпечення, протиріччях в поглядах і цілях розробників і замовників, які народжують неякісні рішення.
 
Автор згадує про процес розробки в заставі розповіді про Six Sigma , про те, що для замовника важлива Функція, а для розробника — форма. Завжди йде протистояння внутрішнього і зовнішнього якості. Тут треба вміти балансувати, бо внутрішньо якість визначає, але не завжди, зовнішнє. І ось це «не завжди» треба вміти виявляти.
 
 
Responsibly maximizing craftsmanship in software engineering (Theo Schlossnagle)
 Відео доповіді
Софт — відстій. Решта доповідь — пояснення цієї тези і пошук причин, чому це так. основні причини:
 
     
Розробка якісного програмного забезпечення є дуже складним завданням (практично не здійсненна).
 Інженери схильні до «традиціям». Тут так прийнято і це працює, тому не чіпай.
 Розробники не читають академічну літературу і не знають азів.
 Команди всередині компанії або навіть проекту не діляться напрацюваннями.
 Інженери відмінно працюють автономно (але в невеликих проектах), тому у великих проектах виникають проблеми.
 Найчастіше простіше написати з нуля, ніж рефактору, але більшість воліє рефактору.
 
 
Polyglot Data (Greg Young)
 Відео доповіді
Доповідь про переваги підходу Event Sourcing перед традиційними нормалізованими базами даних. Будь СУБД — відстій (Every database sucks!). Але кожна відстійних своїм унікальним і неповторним чином. Тому треба для кожного конкретного завдання застосовувати відповідний для цього завдання інструмент. Зберігання потоку подій, замість станів дозволяє добитися цього. Виділити конкретні тези у мене не вийшло, бо це вже був останній доповідь у другий день конференції, але подивитися доповідь варто.
 
 

Ну і доповіді, на які не варто витрачати свій час

 
Find the Right Abstraction Level for Your Tests (Gerard Meszaros)
 Відео доповіді
Для мене ця доповідь була з розряду одкровень Капітана Очевидності: робіть Автотест найбільш автономними. Тест повинен тестувати одну частку функціоналу на потрібному рівні абстракції. Якщо вибраний не той рівень абстракції, то Автоматизація тестування UI неможлива, тому що на UI треба дивитися, щоб оцінити його якість.
 
 
Data-Driven Software Engineering (Jevgeni Kabanov)
 Відео доповіді
Дивний доповідь. Набір слайдів зі статистикою з Developer Productivity Report
 
 
Databases & Schemas in an Agile World (Andrew Godwin)
 Відео доповіді
Очікував від доповіді якихось сакральних знань про те як можна робити дійсно гнучкі бази даних, але все виявилося банально:
 
     
використовуйте PostgreSQL, тому що він дає мінімальний час на простий і блокування при зміні схеми;
 схему треба модифікувати тільки в рамках транзакції;
 ну і пропонує використовувати гібридні (частина даних в типізованих колонках, а інші в blob полях у вигляді xml або ще чого-небудь) схеми для оптимізації між гнучкістю і швидкістю.
 
    
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.