Топ самых полезных докладов TKconf по мнению VIAcode

8 октября прошла грандиозная IT-конференция, которая не оставила равнодушными наш виакодовский патруль)). Мы спросили ребят о том, что было самого полезного, самого интересного в докладах TKconf, и собрали такой вот топ-лист.

viacode3

1. Проектирование архитектуры крупных Web-проектов(Роман Ивлиев, на примере Banki.ru), рассказывает Даша.
Роман рассказал об основных направлениях при проектировании, о том, что при мониторинге системы полезно использовать профиль нагрузки, например, при создании бэкапов или подсчёте статистики во время нагруженной/ненагруженной системы. Указал на подводные камни, столь любимого программистами усреднения данных, так как зачастую средний результат не скажет ничего о нагрузке системы, потому что основной интерес представляют, как раз-таки периоды пиковых значений. Резюмируя свой доклад, Роман высказал ряд достаточно простых, но в тоже время актуальных идей, которые может взять на заметку любой разработчик:

– нет стандарта на разработку крупных систем;

– иногда самое простое примитивное решение является самым эффективным;

– рекомендовал не вестись на Hype.

2. Доклад Андрея Сумина «Как отвечать за продакшн» (на примере почтового сервиса Mail.Ru), снова Даша.

Было две самых ценных мысли:

1 мысль – Андрей рассказал, что каждый причастный к проекту на самом деле несёт ответственность за продакшн. Спикер моделировал ситуации, когда на проекте нет PM/QA/бизнес-аналитиков. Что в этом случае делает разработчик? При отсутствии тестировщиков, например, осуществляет большее покрытие кода тестами, а при отсутствии PM, например, проводит тщательное планирование и организовывает процессы. И что мешает делать это разработчику при наличии QA и PM? Вот такой риторический вопрос заставил аудиторию задуматься над пересмотром своей зоны ответственности и осознать, что на самом деле каждый разработчик способен влиять на процесс и результат разработки продукта гораздо больше, чем он думает.

2 мысль – Важно понимать, что проект должен интересовать конечных пользователей, что они будут пользоваться разрабатываемым решением. Здесь был пример про то, что надо сделать продукт, которым смогут пользоваться как можно раньше. Пусть там не будет какой-либо дополнительной и совершенной функциональности. Главное, что наберётся аудитория, заинтересованная в этом продукте. Андрей тут упоминал случай, когда одна команда пилила проект до последнего, а потом у этой команды не осталось средств, чтобы раскрутить этот проект и привлечь пользователей.
Мне понравилось, что, помимо Андрея, многие докладчики подчёркивали необходимость покрытия кода тестами и мониторинга системы в целом. А также рекомендовали не торопиться с переездом на непроверенные решения, претендующие на спасение от всех проблем на проекте.

3. Доклад Натальи Руколь “Обеспечение качества в продуктовых проектах”, рассказывает Дима. Наталья рассказала об основных инструментах и методах тестирования, приведя реальные примеры из проектов. Особый интерес как раз-таки составляют примеры из жизни, т.к. о теории предметной области всегда можно узнать из разных источников, а вот истории о том, как она применяется на практике, рассказывают не везде. Также из доклада была полезной информация про то, как правильно и при каких условиях применять те или иные инструменты тестирования. Например, мне было интересно узнать о моделировании тест-плана методом Realtime Board и об анализе пропусков и их цене в продакшене. Realtime Board, это по сути майнд-мэп проекта – доска со стикерами, которая визуализирует процесс, помогает планировать работу.

4.Доклад Александра Бындю “Impact Mapping: планирование разработки продукта с учетом бизнес целей”, рассказывает Сергей. Этот доклад привлек мое внимание заранее, т.к. Александр широко известен в русском дотнет сообществе. И хотя сам доклад не про разработку, а про управление процессом разработки, а если быть точнее, то скорее даже про ведение бизнеса в it сфере, он полностью оправдал мои ожидания! Александр познакомил нас с техникой “Impact Mapping”. Это подход, при котором на начальном этапе нужно вместе с заказчиком ответить на четыре вопроса:

Зачем?

Кто?

Как?

Что?

Основная идея в том, чтобы сначала выяснить: кто и какое действие может оказать на цель и только потом принимать решения о конкретных изменениях в системе. Все это дело оформляется в виде mind map. Один из самых очевидных бонусов – четкое понимание необходимости конкретной фичи. Вроде супер-кнопки от дизайнера, смелых архитектурных решений разработчиков или “падающих снежинок” от заказчика. Ведь нужно провести четкую связь на карте. Подробнее можно почитать в его же, пусть и немного устаревшей статье.

Конференция очень понравилась нашим ребятам. Каждый отметил, что уровень был достаточно высок, и это большой шаг вперед для всего it-сообщества Ростова-на-Дону.

Теперь кто-то из них, а может быть даже каждый, с нетерпением ждет TK Conf 2017! 🙂 


Related Posts



One comment

Leave a Reply

Your email address will not be published. Required fields are marked *