/ фото Alexandre Dulaunoy CC
На прошлой неделе в нашем блоге на Хабре мы обсуждали тему коммуникации в рамках команды. Речь шла о том, какие вещи лучше не говорить разработчикам и тестировщикам. На этот раз мы зайдем с другой стороны и обсудим рабочие моменты, в которых иногда заблуждаются сами девелоперы.
1. Eat, sleep, code, repeat!
Известно, что этой концепции следуют многие разработчики – она стала своеобразной мантрой, которую повторяют наиболее приверженные своему делу трудяги. Однако в ней скрывается опасный подтекст. Если задуматься, то эта фраза пропагандирует нездоровый образ жизни, внушая мысль, что программирование – это всё. Якобы, чтобы преуспеть в этой области, необходимо целиком посвящать себя разработке. Но на деле все совершенно наоборот.
Есть еще множество других увлекательных занятий помимо программирования: чтение, походы, садоводство, прогулки с собакой, катание на горных лыжах, гонки на мотоциклах и так далее. Список можно продолжать бесконечно.
Когда вы отвлекаетесь на другую деятельность, ваш получает возможность «подышать» воздухом вдали от трансляторов и компиляторов. Именно это сделает вас лучшим разработчиком, разовьет гибкость ума и такие качества, как креативное и терпеливость. Их нельзя культивировать, занимаясь лишь написанием кода.
Техническая индустрия любит гиперболизировать, мол, как иначе вам стать гуру программирования, если не посвящать все часы бодрствования разработке приложений? Да, энтузиазм способен вознести вас на вершину успеха, но чтобы там удержаться и стать действительно хорошим программистом, зарезервируйте в своем расписании местечко под развлечения «простых смертных».
2. Митапы не нужны
Среди разработчиков бытует мнение, что приложения доставляются в срок только в том случае, если программисты пишут код, а не просиживают на «разборах полетов». Но нужно понимать, чтобы создать хороший продукт, уделять время этим разговорам необходимо, иначе компания рискует уйти не в ту сторону.
Кто-то считает встречи корпоративным кошмаром. Долгие часы тратятся еженедельно на собрания, во время которых не принимается никаких особо важных решений. Планерки – наиболее популярная их разновидность, когда десяток людей собирается, чтобы поговорить о ситуации и будущих проектах. Многие их участники скучают и не уделяют должного внимания докладам, витая в облаках, спускаясь на землю только тогда, когда нужно ответить на вопрос.
Однако митапы необходимы, чтобы организовать работу. Это дает возможность каждому члену команды ознакомиться со статусом проекта. Как ни странно, в первую очередь это важно для руководства.
Питер Тиль (Peter Thiel), соучредитель компании PayPal, как-то отметил: «Как генеральный директор вы являетесь центром организации, однако иной раз вы знаете меньше всех в компании». Потому даже небольшие доклады длительностью 5-7 минут позволят боссу держать руку на пульсе и не чувствовать себя аутсайдером.
Если вам действительно жалко времени на подобную «групповую терапию», то попробуйте предложить руководству проводить совещания тет-а-тет или отдавать общий отчет на откуп лидеру команды. Это высвободит драгоценное время на разработку.
3. UI можно сделать и самому…
Глубоко внутри каждого разработчика скрывается начинающий дизайнер. Если вы позволите ему вырваться, то вас ждут неприятности. Ну или как минимум проблемы ждут пользователей приложения.
Есть интерфейсы, которые мгновенно вызывают улыбку. Вы можете представить себе поток мыслей, проносившийся в голове разработчика в момент создания сего шедевра. Часто это неказистое диалоговое окно или какое-нибудь утилитарное приложение.
Вот здесь он хотел отобразить некую информацию, потому создал это поле, разумеется, с намерением позднее удалить его. Здесь он решил, что неплохо бы добавить еще пару параметров – так появились несколько новых кнопок и выпадающих списков. Так, а почему этот параметр нигде не выводится? Непорядок. Добавим еще один ползунок. В результате рождается что-нибудь подобное:
Внешний вид создаваемого интерфейса-монстра становится настолько привычным, что команда разработки перестает замечать его «нагроможденность». Позднее, когда это всплывет наружу, привести все в порядок достаточно сложно.
Тем, кто жаждет научиться разрабатывать хорошие интерфейсы, стоит начать с изучения этой темы на Stack Overflow.
4. …и протестировать все самостоятельно
Разработчик не может быть тестировщиком (разумеется, исключения есть всегда). Это связано с тем, что девелопер слишком хорошо знает все тонкости созданного им программного обеспечения, потому ему сложно сделать какие-то выводы о жизнеспособности кода – этот факт хорошо известен тестировщикам.
Разумеется, разработчики могут принимать участие в процессе тестирования, особенно в случае Agile, но необходимо помнить о «слепых пятнах». Вот несколько из них:
1) Родительская любовь к написанному коду
Известный факт: свое творение сложно оценить объективно. Разработчики эмоционально привязаны к написанным ими операторам и функциям.
Наглядный пример – дети. Родители считают своих детей идеальными (не замечают недостатков) и сердятся, если кто-то ругает их чадо.
2) Позитивное
Большинство усилий разработчика направлены на эффективную реализацию функций. В тестировании же необходимо искать «неэффективные» способы их использования (что может пойти не так?) – переключить сознание за короткий период времени достаточно проблематично.
3) Упрощение сложных сценариев
Тестировщики учатся искать сложные сценарии использования функций, например, выполняют множество действий одновременно или повторяют одну и ту же операцию несколько раз, чтобы «сломать» систему и выявить баги. По сути, они ищут способы усложнить простой процесс. Разработчики же, наоборот, разбивают сложные процессы на мелкие компоненты, которые позволяют им найти решение.
4) Слабый «нюх»
Хороший тестер «чует» баги и легко выявляет, что не вписывается в общую картину приложения. Это приходит только с большим опытом.
Большинство разработчиков не имеют четкого представления о том, как пользователи будут обращаться с ПО. Тестировщики же понимают, как именно пользователи добиваются поставленных целей, и умеют «симулировать» их работу с приложением.
5. Быть заказчиком и разработчиком в одном флаконе
Проблема разработчика и заказчика в одном лице заключается в том, что разработчики акцентируют все внимание на решении проблем, а задачей заказчика является их поиск. Бывает сложно переключиться с одного сценария работы на другой.
Разработчик фокусирует внимание на коде и архитектуре продукта. Заказчик думает о бизнес-требованиях. Иногда эти два человека не хотят слышать друг друга.
Также стоит отметить, что, выступая как разработчик, заказчик ограничивает в правах команду разработки, поскольку последнее слово будет всегда оставаться за ним. Делегировать все полномочия девелоперам тоже не удастся. Вы же не сможете писать код и не высказывать свое мнение о проекте?
6. «Стэлс-режим» или «Alone In The Dark»
Код «пахнет» – так говорят, когда в листинге с первого взгляда видны потенциальные проблемы и недоработки. Мартин Фаулер (Martin Fowler), автор ряда книг и статей по архитектуре ПО, называет такой «запах» индикатором проблем, присутствующих в системе. На сегодняшний день написаны сотни статей на тему определения плохого кода (например вот, вот и вот). Зачастую эта проблема связана с излишней сложностью, запутанностью, бездумным копированием и т. д.
Однако код, написанный одним человеком, также будет «издавать неприятный запах». Это не означает, что он плохой, просто, если показать его другим экспертам, со 100% вероятностью они его улучшат.
Так происходит потому, что, когда вы работаете один, требуется невероятная выдержка, дабы не начать искать легких путей. Документация будет неполной, процессы будут не оптимизированы, о рефакторинге иной раз можно забыть.
С другой стороны, программирование «при свете» дает только положительный результат. В процессе работы вы начинаете задумываться о мелочах, например о названиях переменных, а отзывы других разработчиков помогут вам вырасти как специалисту.
Возможно, это достаточно очевидная вещь, но не каждый девелопер готов отдать свою работу на суд других. Просить о фидбеке непросто – никто не любит слышать, что он был неправ.
Мы в 1cloud считаем, что о разработках нужно рассказывать, делиться опытом со знакомыми и коллегами. Хороший код и сервисы не рождаются из ниоткуда, они становятся такими, закаляясь в огне критики. Для этого отлично подходит Хабр, а нам остается только оперативно реагировать на любую критику и давать максимум информации о своем IaaS-провайдере.
Автор: 1cloud.ru
