Каждый разработчик программного обеспечения, вероятно, придет к моменту, когда ему придется внести свой вклад в большой проект, будь то гигантская кодовая база с многочисленными коммитами и каталогами или среда с различными приложениями в сервис-ориентированной архитектуре.

От вас, как от опытного разработчика, можно ожидать, что вы очень быстро взломаете (или быстро наберетесь опыта), но интересная правда заключается в том, что стать легендой на большой базе кода - это обычно не прогулка по парку. Определенно становится лучше с большим опытом.

Мне посчастливилось запустить несколько проектов, а также присоединиться к другим, довольно крупным (более 25 тысяч коммитов). Конечно, я активно слежу за репозиторием Rails (сейчас более 70 тысяч коммитов). По моему опыту, следующее могло бы облегчить жизнь, когда вы только начинаете работу над большим проектом.

  • Разберитесь в бизнесе. Этого трудно переоценить. Чтобы вы, как разработчик программного обеспечения, вносили активный вклад в любой бизнес, вам необходимо как можно лучше разбираться в бизнесе. Хорошо, это очень сложный бизнес, который кажется безумным для понимания на ходу, вы должны хотя бы понимать, как ваша команда влияет на бизнес. Вы сначала являетесь сотрудником (или основателем), прежде чем вам будет предоставлен доступ к базе кода компании.
  • Взаимодействие с рабочим приложением. Как бы интуитивно это ни звучало, многие люди никогда не тратят время на взаимодействие с рабочим приложением своей команды, пока они не собираются развернуть свой код. Вы должны, это дает больше понимания вариантов использования и крайних случаев приложения. Однако, если вы хотите попробовать что-то экстремальное, что может сломать приложение, вам лучше попробовать это в среде staging / dev / review.
  • Прочтите документацию. Обычно в проекте должен быть полный файл readme, вики или документация. В то время как приличная команда сообщит вам, где вы можете найти это во время адаптации, вы обязаны прочитать это и обратить внимание на информацию, которую вы там найдете. Возможно, вам не нужна часть этой информации в первые дни, но они были помещены туда по какой-то причине.
  • Прочтите сообщения о фиксации: если команда заботится о следующем разработчике, вы должны увидеть сообщения о фиксации, которые фактически информируют вас о том, что делают дополнения кода. Это не означает, что вы должны читать все сообщения о фиксации, но если вы собираетесь работать с файлом, вы можете потратить несколько минут, чтобы проверить историю этого файла.
  • Участвуйте в проверке кода. Это помогает как новым, так и существующим членам команды узнать, что происходит, а также узнать больше о стилях командного программирования, передовых методах и предпочтениях. Если вы не чувствуете себя достаточно уверенно, чтобы делать комментарии, вы можете хотя бы взглянуть. Я просмотрел PR, где все, что я мог сделать, это пересмотреть синтаксис и логику. У меня не было достаточно знаний о бизнес-кейсе для PR. Если бы я чувствовал, что это хорошо, я бы добавил комментарий вроде: «Мне нравится. Хотя я не очень хорошо разбираюсь в том, что делает этот пиар ». Помимо очевидного факта, что теперь у меня есть представление о том, что такое PR, он также информирует других членов команды о том, что нужно время, чтобы просмотреть PR.
  • Тесты. Пройдите тесты, особенно для файлов, над которыми вы собираетесь работать. Он информирует вас о случаях, которые в настоящее время волнуют команду, и о крайних случаях, которые они уже рассмотрели. Это также иногда помогает вам увидеть, как ваши объекты и сущности должны быть связаны (фабрики) и как они взаимодействуют. Вам также следует добавить / обновить тесты для добавленной вами функциональности, чтобы убедиться, что вы ничего не сломали или, по крайней мере, исправить то, что вы сломали, перед запуском. Скорее всего, вы все равно не пройдете CI 😅

Совет. Если вы не уверены, никогда не запускайте все спецификации локально. Они могли занять долгие минуты или часы. Вы должны запускать только те спецификации, которые относятся к вашей работе на местном уровне. Выполнение всего набора тестов входит в обязанности вашего CI.

Ой, у некоторых проектов нет тестов и это совсем не смешно 💀

  • Семена и аннотации. Если вы работаете с Rails, в вашем проекте, скорее всего, есть несколько семян, это хорошее место, чтобы увидеть, как вы можете быстро создавать объекты и их ассоциации. Если ваша группа также использует аннотации к модели, вы должны иметь возможность видеть все активные поля, ограничения, значения по умолчанию, внешние ключи и индексы в файлах модели.
  • Объединитесь и задавайте вопросы. Объединение с кем-то, кто более знаком с кодовой базой, очевидно, значительно облегчает жизнь. Не стесняйтесь задавать вопросы!
    Я знаю, что есть некоторая озабоченность по поводу того, чтобы задавать вопросы некоторым людям, это будет обсуждение на другой день, но да, задавайте вопросы! Обычно экономит много времени.
  • Поиск. Вы всегда должны быстро выполнять глобальный поиск идентификаторов (или файлов) в редакторе. Я видел, как многие люди пытались найти, где что-то определено, в течение нескольких минут, тогда как глобальный поиск сделает это за секунды.
  • Начните с самой маленькой части: создаете ли вы объект, пишете спецификацию, пытаетесь пройти какую-то логику или отлаживаете, начните с самой маленькой части и тщательно ее поймите.

Вот несколько вещей, которые я узнал, работая в командах с большими кодовыми базами. Некоторые из них я освоил довольно легко, некоторые мне пришлось выучить со временем. Мысли? Не стесняйтесь оставлять их в комментариях. Ваше здоровье!