Чтобы прояснить, мне интересно знать, что люди думают, что вы должны реализовать, пока еще работаете над одним человеком (контроль исходного кода команды, документация, сборки и т. Д.), И что не нужно делать до того момента, когда придет второй человек. на проект.
Любой, у кого есть опыт в продвижении по этому сценарию, их понимание будет оценено.
Ответы:
Что я узнал (Я пробовал другой порядок. Я был не прав. Это порядок, в котором все становится актуальным.)
Поместите все в контроль исходного кода. Используйте то, к чему все имеют доступ, и начните прямо сейчас . Без исключений. Никаких задержек. Никаких оправданий.
Создайте область QA / Test, полностью отделенную от вашей личной "рабочей" или "среды разработки". По крайней мере, отдельный идентификатор пользователя. В идеале на отдельной ВМ.
Полностью отдельный. Нет возможности совпадения с вашей текущей рабочей средой.
Прекратите тестирование после модульного тестирования в вашей собственной рабочей среде. Код и юнит-тест вы делаете «как сами». Все остальные тесты (интеграция, производительность, что угодно) вы делаете на отдельной виртуальной машине. Никогда не проверяйте себя. Всегда тестируйте как отдельный пользователь QA. В идеале на отдельной ВМ.
«Работает для меня» - плохо говорить своим членам команды. Очень плохо. Вы должны выяснить, что они делают неправильно. Несколько раз в день.
Планирую записать все. Используйте инструмент разметки в виде простого текста (RST или Markdown или что-то в этом роде), чтобы вся документация в репозитории контроля версий была в виде простого текста. Инструмент может создавать HTML-страницы (т. Е. Docutils для RST), PDF-файлы или что-то еще, что кажется лучшим. Не используйте проприетарные форматы документов (например, MS-Word). Они могут не очень хорошо работать с некоторыми системами контроля исходного кода.
Первое, что вам нужно записать, это следующее.
Как создать рабочую среду разработки. В случае сомнений создайте виртуальную машину и выполните всю операцию на этой виртуальной машине. Убедитесь, что шаги действительно работают и документация понятна . Актуальные строки набираются в фактической командной строке для ясности.
Как запустить пакет модульных тестов. Опять таки. Будьте уверены, что инструкции работают и не требуют обдумывания. "Введите это:" "Подтвердите, что:" такие вещи. Дело не в том, что члены вашей команды глупы. Дело в том, что вы не помните, что вы предполагаете, если не запишите все это.
Как запустить комплект интеграционных тестов.
Не тратьте много времени на описание архитектуры или принципов дизайна. Вы должны получить кого-то и работает первым. Вы можете объяснить вещи позже.
Следующие вещи, которые нужно документировать, - это истории пользователей. И тестовые случаи, которые поддерживают эти истории. И данные, необходимые для тестовых случаев, которые поддерживают эти пользовательские истории.
Вы будете делиться этим. Это идет под контролем исходного кода.
В конце концов, вы можете документировать другие 4 вида.
Логическое представление является полезным документом. Фотографии здесь приемлемы. Это имеет тенденцию развиваться быстро, поэтому не тратьте время на сбор устаревшей информации. Разработайте способ сотрудничества с членами вашей команды.
Представление процесса часто полезно. Зависит от общего применения, насколько это важно.
Вид разработки - модули, библиотеки, фреймворки и т. Д. - часто описывается неформально. Картинка может помочь, но, как известно, сделать это достаточно сложно, чтобы кто-то мог взять документ и сделать из него голову или хвост. Даже давно созданные, очень публичные проекты имеют библиотечную документацию, которая просто игнорируется. (Приводит ко многим вопросам переполнения стека.)
Помимо того, что это приемлемо, чтобы быть неформальным, это имеет тенденцию быстро меняться.
Информация о развертывании. Серверы. IP-адреса. Учетные данные базы данных. Все эти вещи должны быть записаны. В конце концов.
источник
Инструменты и методология
Что необходимо, чтобы успешно сотрудничать и быть продуктивным?
Управление / работа в команде
... или что-то еще на межличностном уровне
Книжные ссылки
Я перечислю некоторые из наиболее часто упоминаемых книг, которые я на самом деле прочитал, и я думаю, что стоит прочитать, для более подробного описания или для большего количества книг, вы можете проверить некоторые вопросы о SO, спрашивая именно об этом, например, этот или этот вопрос.
Эти книги действительно стоит прочитать в отношении команд, организаций и программных проектов:
Ни одно из этих практических руководств о том, как реализовать методологию X (кроме оценки программного обеспечения, эта книга поможет вам выбрать подходящий процесс оценки). Конечно, книги, более сфокусированные на самом программировании, такие как Code Complete, также очень обогащают.
источник
Я буду говорить из опыта, но имейте в виду, что все разные. Эти вещи не универсальны.
Одно - отпустить это лично. Этот проект - это то, с чем вы жили и жили в течение 18 месяцев - вы, естественно, хотели бы, чтобы каждое изменение было таким, как если бы вы это делали. Дайте коллеге буфер для ошибок, чтобы учиться. Создайте комнату, чтобы они были полезны. И имейте в виду, что это может произойти не сразу. Также было бы здорово, если есть что-то, часть кода, которую они чувствуют, что преуспевают в улучшении или создании, что похоже на успех за короткий промежуток времени. Терпение и терпимость имеют хорошие показатели здесь. Не пытайтесь заниматься микроуправлением, и если вы хотите критиковать, говорить «вы не правы», убедитесь, что у вас есть заслуга, вы можете доказать это, это не «религиозная» борьба.
Другой ключевой вопрос - найти подходящего человека для вас. В идеале лучше найти кого-то умнее себя. Это субъективно и относительно, но если вы чувствуете, что у человека есть знания и навыки, которых у вас нет, это к лучшему. Это будет взаимовыгодное сотрудничество.
Есть два способа, которыми он может пойти - коллега будет драг, и вы в конечном итоге будете переделывать то, что он или она сделали, или умения двух из вас умножатся, а не просто сложатся, и вы действительно оцените совместную работу.
По теме «чистый, быстрый, многократно используемый код» - предлагаю на собеседовании попросить написать небольшого менеджера по микроядрам / сервисам и / или исполнителя работ. Посмотрите, как подключаемые компоненты указаны и настроены. Не нужно заканчивать, это мысль, которая имеет значение. А также вы быстро научитесь людям, которые хорошо знают, как это сделать, захотят приличные деньги ;-) Удачи!
источник
Мое мнение: начните с документирования архитектуры вашего внутреннего проекта для кого-то ... кто не знает об этом. Попытайтесь объяснить, какие предположения существуют, и когда / где вы отклонились от общепринятых практик и почему.
Автоматизация сборки: отличная идея, могу я добавить автоматизацию конфигурации для машины разработчика. Легче всего построить, чем больше будет (тем больше / быстрее тестируемое развертывание).
Еще одна идея (однажды она мне очень помогла): попросите нового разработчика выполнить некоторые мелкие задачи по очистке в различных областях вашей кодовой базы, чтобы он привык к инструментам верстки и т. Д. Одна хорошая идея - удалить затемнение областей, которые могут привести к путанице позже (пример: если вы использовали emmm python для двух строк сценария оболочки где-то, а ваш проект основан на java, попросите эти две строки переписать в java, так что разработчику №3 потребуется меньше знать, чтобы работать)
источник
Я бы сосредоточился на автоматизации всего, что требует ручной работы, поэтому может быть испорчен неопытным человеком . Который, основываясь на вашем кратком комментарии выше, включает в себя следующее:
Если вам не удастся сделать это, либо вы будете прикованы к выполнению этих задач навсегда, либо (некоторые из) новый парень (-ы) неизбежно что-то испортит рано или поздно.
Другая важная задача, как отметил @dimitris, документация. @S. Лотт добавил гораздо больше подробностей об этом, поэтому просто +1 к нему, а не повторять :-)
источник
Вот некоторые мысли, частично основанные на личном опыте:
Документируйте свой проект. Проектные спецификации, схемы, руководства и комментарии помогут новому сотруднику набрать скорость. Объяснение сложной системы только в устной форме может оказаться медленным и разочаровывающим. Документация часто игнорируется в проектах с одним человеком. Убедитесь, что ваше исключение.
Сначала сконцентрируйтесь на коде уровня API / ядра, предоставляя новому сотруднику некоторую работу «прикладного уровня» или исправляя ошибки, чтобы постепенно познакомить их с кодом. Как правило, начните с более простых , но значимых и, таким образом, полезных задач .
Общение важно. Быть отзывчивым на вопросы, комментарии и идеи нового сотрудника. Объясните, почему, по вашему мнению, идея не очень хорошая. Свежая пара глаз может найти место для улучшения на удивление хорошо. Если ваш новый сотрудник достойный, он может просмотреть ваш код и в конечном итоге принять участие в архитектурных решениях. Обсудите, отразите идеи друг от друга. Это одно из величайших преимуществ наличия сотрудника в вашем проекте.
Четко определите обязанности , как только вы узнаете, какие задачи выполняет ваш новый член команды. Установите методы документирования и соглашения о кодировании, чтобы все было гладко.
Используйте систему контроля версий . Поддерживать логическое расположение исходного файла и дисциплину сборки .
Что касается собеседования - я не большой поклонник искусственных тестов кодирования или хитрых вопросов, если только вы не хотите попробовать стрессоустойчивую способность кандидата. Даже самые умные из решателей проблем могут запереться в такой ситуации. Среди прочих качеств, которые вы будете искать: честность , профессиональные возможности , технологические знания / понимание , энтузиазм и взаимная совместимость . Рабочая атмосфера может много значить; нежелательно выбирать партнера по команде, который вам не нравится. Разместите ваши вопросы правильно и проведите неформальную дискуссию, чтобы получить хорошее представление о вашем кандидате. Удачи!
источник
Технологии
Если вы привлекаете кого-то еще в качестве разработчика, есть три ключевых момента, которые я бы порекомендовал установить и запустить до их запуска.
Если эти три вещи работают правильно, вы устраните около 75% общей проблемы, возникающей при привлечении нового члена команды. Смысл этих технологий заключается в том, чтобы взять многое из того, что происходит только в вашей голове, и показать, где член вашей команды может с ней взаимодействовать.
Контроль исходного кода гарантирует, что вы оба работаете над одним и тем же. Отслеживание проблем поможет вам одновременно отслеживать, что необходимо сделать, и облегчит вам понимание того, над чем они работают и выполняют. Непрерывная интеграция и тестирование помогут убедиться, что у вас есть повторяемый процесс сборки и что новые улучшения не нарушают другие части кода.
У Pragmatic Programmer есть несколько довольно хороших книг по этому вопросу. Вот несколько, которые я бы порекомендовал. Они имеют другие похожие названия в зависимости от того, какой язык программирования вы используете или какой контроль версий вы хотите использовать:
http://www.pragprog.com/titles/tpp/the-pragmatic-programmer http://www.pragprog.com/titles/tsgit/pragmatic-version-control-using-git http: //www.pragprog. ком / название / авто / прагматичная-проект-автоматизация
личный
Зачастую трудности, с которыми вы сталкиваетесь, связаны не столько с технической стороной, сколько с обучением, которое нужно отпустить. Может быть трудно дать кому-то еще контроль над аспектами проекта - особенно если вы привыкли делать все это самостоятельно и принимать каждое отдельное решение. Вы избавите себя от некоторого горя, если сможете найти область, где вы можете заставить нового человека работать с разумной степенью свободы в начале, чтобы вы могли развить основу доверия. Если вы нанимаете хорошего человека, вы, вероятно, будете учиться тому, как доверить другому человеку хорошую работу, даже если все его индивидуальные решения не совпадают с принятыми вами.
Вы хотите дать своему новому наему свободу решать проблемы так, как это работает для них, сохраняя при этом меры предосторожности, чтобы вы могли выявлять проблемы на ранних этапах.
источник
Эти пункты являются наиболее важными на мой взгляд:
И последнее, но не менее важное: получить систему контроля версий. Subversion просто отлично. Но не добавляйте те файлы Eclipse (или что-то еще), которые являются специфическими для пользователя и поэтому постоянно изменяются. Они заставляют вас тратить часы. Не стесняйтесь спрашивать о Stackoverflow, если у вас есть проблемы с ним.
источник