Программисты, отвечая на вопрос об их самом большом профессиональном кошмаре, часто говорят, что они работают над кодом, созданным другой командой или внештатным фрилансером. Это неудивительно. Без должного брифа и предварительных договоренностей в конце дня компания может получить тысячи хаотично написанных строк, понятных только ее создателям.
Множество проектов, нехватка времени, короткие сроки, нехватка персонала, развороты или внезапное развитие бизнеса - эти факторы часто приводят к тому, что часть задач компании передается на аутсорсинг. Однако получение кода от стороннего разработчика или компании-разработчика программного обеспечения - это только начало приключения. Что нужно сделать, чтобы с легкостью встать на их место? Как подготовить рекомендации, чтобы получить именно то, что вы ожидаете, и это прозрачный код?
Передача вашего продукта кому-то другому - важный процесс: он чувствителен к любым волнениям и имеет большое влияние на его будущее. Вот почему так важно спланировать этот процесс с самого начала. Я столкнулся с двумя разными подходами к этой задаче. Некоторые считают, что код просто должен работать, независимо от его качества и архитектуры. Однако это может привести к проблемам с масштабированием, которые рано или поздно произойдут. Что еще хуже, пропуск тестов целостности (индивидуальных или сквозных) опасен для всего продукта и может замедлить его развитие в будущем.
Прежде всего: сотрудничество
Второй подход, который явно предпочитает Indoorway, - это постоянный надзор за написанным кодом. Это требует сотрудничества с руководителями групп сторонней компании. Такая командная работа может частично замедлить процесс, но гарантирует соблюдение вашей политики качества. Когда вы решаете более активно участвовать в работе над запрошенным кодом, вы принимаете решения относительно его архитектуры и сами видите, какие потенциальные недостатки или недостатки может иметь окончательный код.
Как лучше всего начать такое сотрудничество? Вначале вы должны предоставить рекомендации для аутсорсера по качеству, желательно еще до вашей первой встречи. Это даст им возможность получить подробный и подробный обзор ситуации и позволит лучше планировать и оценивать их будущую работу. К сожалению, многие компании забывают о важности разработки руководящих принципов качества или относятся к стандартам документации либо пренебрежимо, либо регулярно. Заранее подготовить инструкции и собрать их в один файл того стоит! Они будут полезны как для аутсорсинга, так и для передачи передового опыта будущим сотрудникам.
Также важно вовлекать разработчиков, работающих над кодом, на встречи и договоренности с аутсорсером компании. Более того, вам следует запланировать исключительно технические встречи или семинары с обеими командами программистов. Они позволят им лучше понять разрабатываемый продукт, поделиться идеями друг с другом и точно найти правильный рабочий процесс. Это также хорошая возможность для всех встретиться с людьми, участвующими в вашем проекте, что упрощает дальнейшее общение.
Сроки согласованы и даны приветственные рукопожатия? Превосходно! Теперь пришло время писать код. Чтобы все было под контролем, не забывайте о трех ключевых принципах:
- Если код, переданный на аутсорсинг, является неотъемлемой частью ранее разработанного продукта, важно начать с подготовки моделей потоков данных между «внешним» кодом и кодом, который на данный момент был разработан вашей компанией.
- В случае сетевых сервисов рекомендуется как можно раньше составлять контракты, например, с помощью Swagger.
- Для серверных продуктов определите версию интерпретатора и среду, в которой они будут работать по умолчанию, тогда как для клиентских продуктов укажите минимальные требования, связанные с версиями веб-браузеров.
Клиенты всегда ожидают, что аутсорсеры будут выполнять свою работу максимально предсказуемо, поэтому не скрывайте продукт при его создании. Назначенная работа становится намного более гладкой, когда компания и ее внешний подрядчик вместе создают продукт. Вам необходимо обеспечить активное участие обеих сторон на каждом этапе работы. Для этого подрядчики должны предоставить актуальные тестовые версии продукта. В случае интернет-приложений это может быть специальный веб-сайт, а в случае мобильных приложений - платформы Fabric или TestFlight.
Следующий шаг: возвращение кода вам
Когда контракт подходит к концу, стоит потратить некоторое время на ознакомление себя и своей команды с кодом, написанным сторонней компанией. По опыту Indoorway, хорошо включать и обучать как можно больше людей, чтобы избежать создания так называемых разрозненных структур. Когда только один человек полностью осведомлен о проекте, нетрудно найти кризисную ситуацию в случае его отсутствия или болезни. Резервное копирование всегда является ключевым моментом!
Ваши аутсорсеры должны помочь вам глубже изучить код и понять его сложность. Обратите внимание, правильно ли задокументирован код. Есть ли в нем доступное «руководство пользователя»? Хорошая документация позволяет быстро познакомить команду с кодом, а также станет хорошей отправной точкой для будущих сотрудников.
Продукт должен быть протестирован в среде целевой инфраструктуры. Ваш аутсорсер должен знать, в каком программном обеспечении будет запускаться этот продукт. Я имею в виду и системное, и веб-программирование. Также рекомендуется провести тесты производительности кода, что позволит лучше оценить стоимость использования.
Проблемы с кодом: бесконечная история
К счастью, благодаря налаживанию хороших отношений с нашими аутсорсерами, Indoorway всегда могла обеспечить беспрепятственный перенос кода в свои продукты. Однако до того, как мы разработали хорошо работающую схему, мы учились на собственных ошибках, допущенных при работе над другими проектами. Например, уходящий в отставку разработчик в одной из моих предыдущих компаний не оставил никаких советов своим преемникам - в данном случае мне - ни схемы базы данных, ни текстового файла, объясняющего и направляющего других в его код. К тому же качество его кода было далеко не идеальным. Это самый крайний случай, но он научил меня, что вам нужно очень тщательно планировать свою работу и устанавливать требования к своему аутсорсеру.
Теперь я знаю, что наиболее важным с точки зрения человека, который берет или наследует код, является то, правильно ли он был описан: от предсказуемых и понятных имен методов до вспомогательных комментариев. Рекомендуется использовать автоматическое документирование кода. Для каждого популярного языка есть соответствующие инструменты, и многие библиотеки используют этот метод документации.
Как распознать хороших аутсорсеров? Если вы хотите быть уверены, что они предоставляют качественные услуги, при первом контакте обратите внимание, спрашивают ли они о состоянии кодекса и планируют ли проводить его детальный аудит. Если да, то можно уверенно вести переговоры дальше.
Этот пост изначально был размещен на j ustgeek.it (на польском языке).
