Как выбрать хорошего подрядчика для разработки вашего проекта?

«Мы специализируемся на предоставлении клиентам профессиональных услуг по разработке программного обеспечения». Такое заявление понравится любому потенциальному клиенту, но увы, любой соискатель-подрядчик позиционирует себя как профессионал. Действительно, если честно признаться в непрофессионализме, то ни к какому проекту вас и близко не подпустят. Но как клиент, обычно не разбирающийся в тонкостях разработки ПО, может убедиться, что подрядчик действительно знает свое дело? Если бы существовал простой ответ на этот вопрос, то можно было бы сэкономить массу денег, которые сегодня тратятся на проекты, с первого дня обреченные на провал. Эта статья предлагает простейший тест на профессионализм, сравнимый с «лакмусовой бумажкой»: в ней перечислен минимальный набор навыков, присущих хорошему разработчику. Неопытный клиент должен ставить перед подрядчиком именно такие вопросы – и он вправе рассчитывать на содержательные ответы. Сразу оговорюсь: я составлял этот список с самыми благими намерениями. Программы можно разрабатывать и при частичном или полном отсутствии этих навыков, и это может быть вполне профессиональная разработка. С другой стороны, даже наличие всего перечисленного не гарантирует триумфального завершения проекта. Итак, допустим, вы – клиент, занятый поиском подходящего подрядчика на разработку программного обеспечения. Для вас это может быть как фрилансер, так и компания. Можете просто вооружиться этим списком и по порядку задать кандидату все вопросы из него. Послушайте, что они ответят, и попросите продемонстрировать те или иные навыки на практике. Поначалу вам вряд ли удастся отличить блестящую реализацию от тривиальной, но постепенно вы научитесь это делать. Суть такова: если разработчик может без труда продемонстрировать тот или иной навык, то, скорее всего, он действительно хорошо им владеет.

Минимальные навыки

Список навыков выстроен в порядке возрастания их непосредственного влияния на качество разработки. Представление о качестве учитывается на трех уровнях: с вашей (клиентской) точки зрения, с точки зрения конечного пользователя и с точки зрения следующего разработчика, который получит исходный код от первого разработчика.

Система управления исходным кодом

Эта техника имеет ряд различных названий: управление исходным кодом (SCM), система контроля версий (RCS или VCS). Она используется для отслеживания любых изменений, вносимых со временем в код. При помощи такого механизма разработчик сможет с точностью узнать, какое изменение и когда было внесено в код, в какой версии это произошло и кто это сделал. Позже такое изменение даже можно отменить. Если ваш собеседник говорит, что имеет опыт работы с конкретными инструментами контроля версий – например, Git, Subversion, Perforce или Mercurial, то этот вопрос можно считать решенным. Предложите подрядчику продемонстрировать типичный цикл «синхронизации-редактирования-правки» и попытайтесь понять, что он вам говорит. Большинство разработчиков любит хвастаться своими мастерскими навыками работы с системами контроля версий.

Отслеживание задач

Система отслеживания задач (а также отслеживания ошибок) – это инструмент, сохраняющий все запросы, отчеты об ошибках, пожелания и жалобы, которые вы вносите. Его можно сравнить со справочной системой «талонов о неисправностях» (trouble tickets). Система отслеживания задач предоставляет разработчику своеобразный «план действий» и выступает в качестве объективной документации вашего общения с разработчиком. Если вы не можете получить прямой доступ к системе отслеживания задач на сайте, предложите кандидату продемонстрировать типичный сценарий – например, составить отчет об ошибке. Как минимум, разработчик должен предоставлять вам список решенных проблем по каждой версии вашего ПО.

Непрерывная интеграция

Это сравнительно новый инструмент, обладающий, однако, значительным потенциалом. Его также можно назвать «сервером сборки приложений» (build server). Также говорят о «ночной сборке» (nightly build). Мы исходим из того, что сборка вашего проекта будет автоматизироваться, когда это только возможно. В случае непрерывной интеграции новая сборка происходит после каждой отправки новой порции исходного кода в систему контроля версий (о ней мы говорили в первом пункте нашего списка). Попросите разработчика продемонстрировать, что происходит автоматически после отправки кода в систему контроля версий. Спросите кандидата о «времени сборки» вашего проекта (или других проектов). Время сборки – это период, необходимый для получения новой версии, которую вы сможете протестировать. Если время сборки довольно невелико (скажем, несколько минут) – попросите внести в проект небольшое изменение и дождитесь результата. Вполне возможно, что ваш разработчик затронет не только тему «непрерывной интеграции», но и «непрерывного развертывания». Всплывут вопросы, связанные с «подготовкой файлов» (staging), «очередью сборки» (build queue), «тестовой установкой» (test installation) и т.д. Вот и отлично! Дайте ему возможность продемонстрировать «непрерывное развертывание» на практике. Вы, вероятно, будете впечатлены, а разработчик получит еще один шанс козырнуть перед вами..

Верификация (она же тестирование)

«Будут ли в исходном коде содержаться автоматизированные тесты?» – о, это вопрос деликатный. В нашем деле ожидаемая ценность каких-либо автоматизированных тестов по-прежнему стремится к абсолютному нулю. Но, если в ответ на этот вопрос кандидат просто недоуменно воззрится на вас – это плохой знак. В случае содержательного ответа не так важно, будут ли упомянуты «модульные тесты», «интеграционные тесты» и даже «приемочные тесты». Важнее другое: пусть кандидат продемонстрирует вам реализацию автоматических тестов в вашем (или подобном вашему) проекте. Убедитесь, что сервер непрерывной интеграции (подробнее о нем – в третьем пункте) действительно осуществляет автоматизированные тесты, причем при каждой сборке. Таким образом, если откажет любой компонент, подкрепленный тестами, то вы об этом сразу же узнаете, и вам не придется сталкиваться с ошибками, которые вновь и вновь появляются в каждой следующей версии (такой симптом называется «регрессия»). Возможно, ваш разработчик окажется настоящим энтузиастом тестирования. И пусть каждый час его труда стоит немалых денег – не сомневайтесь, что деньги на тестирование тратятся не зря. Считайте, что этим вы перестраховываетесь от любого неожиданного поведения вашей программы в будущем. В ходе разработки сами тесты, скорее всего, будут незаметны, поскольку они используются внутрисистемно. Попросите разработчика рассказать о том, как он организует отчетность о тестировании. Может быть, составляется отчет о «тестовом покрытии», сопровождающий список задач (такой список рассмотрен во втором пункте)? Если специалист утверждает, что практикует «разработку через тестирование» (test-driven development) – можете быть уверены, что он старается проводить максимально детализированные тесты. Позвольте ему продемонстрировать вам достоинства такого подхода и смоделируйте цикл реализации небольшого изменения в вашем проекте. Возможно, это убедит вас в полезности подобной перестраховки.

Документация по проекту

Все софтверные проекты, кроме самых элементарных, содержат такую массу деталей, что человек просто не в состоянии запомнить их все, и рано или поздно что-то забывает. Ваш разработчик должен иметь некоторый практический опыт хранения информации о проекте, не только «в коде» и «в системе отслеживания задач». Популярным вариантом реализации этого требования является документирование проекта в wiki-форме – именно в такой форме написана всем известная Википедия. Задумайтесь о возможности использования онлайнового текстового редактора с функциями структурирования информации. Если у вас нет доступа к самому инструменту документирования, попросите разработчика продемонстрировать его на практике. Попросите выдержку из документации по вашему проекту, например, в формате PDF или HTML. Не придирайтесь к эстетическим сторонам документа, основные его качества должны быть – удобство и простота поиска нужной информации. В конце концов, подойдет даже рукописная документация, если она в порядке и хранится в одном определенном месте.

Соглашения в исходном коде

Практически любой исходный код является машинно-читаемым. Но встречаются такие образчики кода, которые совершенно нечитабельны для коллеги-программиста, а то и для самого автора. Расспросите разработчика о том, какие правила форматирования кода он применяет. Возможно, он действительно представит вам письменные правила, реально применяемые при создании кода. В большинстве языков программирования есть инструменты, позволяющие проверять форматирование на соответствие определенным правилам. Такие программы называются «инструментами для инспекции кода» и идеально подходят для работы с сервером непрерывной интеграции (см. третий пункт). Правда, некоторые аспекты читабельности исходного кода нельзя проверить алгоритмически – скажем, выбор имен или ясность концепций. Хорошие разработчики регулярно инспектируют код, критически обсуждая его с коллегами и предлагая варианты оптимизации. А хороший клиент открыто указывает на необходимость code review, даже если сам не собирается в ней участвовать. В долгосрочной перспективе вы скоро сами убедитесь, насколько от этого улучшается качество программ.

Участие в жизни сообщества

Разработка программ – это стремительно развивающаяся сфера деятельности, в которой то и дело происходят судьбоносные открытия – не реже, чем раз в год или два года. Отдельно взятый разработчик не может отслеживать развитие всех непрерывно изменяющихся инструментов, феноменов и возможностей в сфере своей профессиональной деятельности. Приходится полагаться на опыт сообщества коллег и единомышленников, а также опытных экспертов, готовых делиться своими знаниями. Спросите разработчика, как он взаимодействует с сообществом коллег. Какие (технические) книги он недавно прочитал? Какие книги изучены всей командой разработчиков? Вы как клиент, пожалуй, не сможете сразу оценить, насколько ценны названные разработчиком книги, но это и не самое важное. Как и в случае с тестами, список книг, прочитанных средним программистом, может и не быть слишком велик. Важно, что команда разработчиков является достаточно сплоченной и обладает общей базой технических знаний, почерпнутых в специальной литературе. Но и книгами дело не ограничивается. Ведь печатные книги просто не успевают за развитием отрасли! Спросите о том, в каких технических конференциях участвует кандидат, а также состоит ли он в пользовательских группах по обсуждению языка программирования, используемого в вашем проекте. Как организована совместная работа? Любит ли разработчик делиться своим опытом и находками? Кстати, для этого достаточно просто вести свой блог (например, такой, как вы сейчас читаете). Попросите программиста показать вам свой блог. Сколько статей он опубликовал за определенный промежуток времени, каков отклик на них? Может быть, ваш кандидат пишет статьи для специального журнала или даже работает над книгой? А теперь можно будет и поинтересоваться у других разработчиков их мнением об опубликованных материалах. Возможно, вы нашли настоящего профессионала – остается вас только поздравить! .

Но и это еще не все, далеко не все...

Этот список не исчерпывает всех тех навыков, концепций и инструментов, с которыми должен уметь работать хороший специалист. Это всего лишь минимальный набор, который можно и нужно дополнять и улучшать. Существуют целые комплексы навыков, такие, как «разработка чистого кода», – обо всем невозможно упомянуть. Спросите о том, что интересно самому разработчику. Будем надеяться, его уместное бахвальство и профессиональный сленг быстро убедят вас, что вы действительно имеете дело с профессионалом. А меньшим довольствоваться и не следует. ИСТОЧНИК

Помогаете devby = помогаете ИТ-комьюнити.

Засапортить сейчас.