Советы как изучать исходный код незнакомого продукта

Перевод статьи «Learning a New Codebase» (Ben Ramsey)

Несколько дней назад мой друг Эд Финклер (Ed Finkler) перешёл на новое место работы. На той же неделе он написал в Твиттер:

First days humble us all@funkatron

Я и сам только устроился на другую работу, поэтому понимал чувства Эда. Буквально на прошлых выходных во время конференции «Madison PHP Conference» мы обсуждали, что должен бы сделать разработчик во время интервью, чтобы получить представление о том, что из себя представляют программные продукты компании. Ведь во время собеседования кандидат точно так же может изучить потенциального работодателя, как и работодатель изучает его. Будет стрёмно, если тебя наймут и тебе достанутся проекты в ужасном состоянии. Так вот узнай о коде побольше ещё до подписания «Соглашения о неразглашении коммерческой тайны» и до того, как увидишь сам код.

Я считаю, что эти полезные советы помогут тебе определить, как там в компании пишутся программы. И если у тебя есть ещё идеи — добавь в комментарии.

1 Узнай, каких стандартов кодирования придерживаются в компании. Они вообще могут о каких-нибудь стандартах сказать? Настаивай на подробностях. И убедись, что тебе отвечает разработчик, а не менеджер, иначе не получится составить представления о том, как эти стандарты влияют на их работу.

Если речь идёт о проектах на PHP, то должны прозвучать такие слова, как PSR-2 или PSR-1. Ну хотя бы упоминание о стандарте кодирования PEAR.

2 Спроси, используются ли в компании средства для управления зависимостями и сборками. Ответ на этот вопрос покажет, насколько близко они придерживаются философии «not invented here (NIH)», насколько боятся использовать или жмотятся покупать чужие готовые решения. На моей практике, компании, в которых используется сторонний программный код, как правило, лучше структурируют свой программный код, делают его понятнее. Я не знаю точно, почему это так, но подозреваю, что знакомство с чужими хорошо оформленными решениями оказывает большое влияние на качество своих решений, и разработчики таким образом делятся передовым опытом.

В контексте проектов на PHP желательно услышать об использовании Composer. Ну или хотя бы упоминание про PEAR, хотя он уже уступает позиции.

3 Спроси, сколько кода покрыто тестами. Есть модульные тесты, функциональные тесты, интеграционные тесты и приёмо-сдаточные испытания. Может быть, есть и другие, о которых я не в курсе. Начни с того, какие стратегии тестирования используются в компании и сколько тестов у них есть.

Для PHP и веб-проектов есть много различных инструментов для тестирования. По крайней мере я ожидал бы услышать о РНРunit, но даже если не так, то есть много других фреймворков для модульного тестирования, так что они, возможно, решили использовать какой-то другой. Если это так, спроси почему. Не важно, какие решения приняты в компании, но я думаю, это покажет, какие факторы привели их к таким решениям.

4 Попроси описать процесс развертывания приложений. Как разработчик, ты сам будешь развертывать код или этим будут заниматься разные люди или команды? Сможешь ли ты сразу, в свой первый день или в первую неделю, запушить что-нибудь? Не так важен срок, как процессы развёртывания. Постарайтесь получить представление о том, простой ли это процесс или бессистемный, подверженный ошибкам.

И вот, после того, как ты пришёл в компанию, ты столкнулся с грандиозной задачей по изучению неведомого тебе исходного кода. Сегодня утром Эд спросил в IRC канале #phpmentoring:

<funkatron> Как ты вообще разбираешься с той огромной кучей кода, которая тебе незнакома?

Вот два подхода, взятые из моего личного опыта:
1 С помощью отчётов об ошибках, исправляя ошибки. Это позволит изучить код, не теряя производительности.
2 С помощью написания тестов. Если тестов ещё нет, просто начни их писать. В качестве подходящих частей кода для начала выбери те, у которых низкий процент покрытия (5-10%). Это позволит тебе изучить код очень быстро.

А что бы посоветуешь спросить у потенциальных работодателя? Что посоветуешь по поводу изучения неизвестного исходного кода на новой работе?

Конец перевода.

Мои вопросы к работодателю:
* Что если после релиза посыпятся критические ошибки? Как много времени займёт откат версии? Это вопрос дополняет вопрос про простоту обновления серверов, но даёт понять, будешь ли ты спокойно спать по ночам.

* Есть ли документация на программный код? Она свежая? А учебники какие-нибудь? Иногда бывают слайдшоу, иногда — скринкасты, иногда — спецификации и технические задания.

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

* Можно ли мне получить персональную тестовую среду, где я смогу издеваться над кодом и никто от этого не пострадает?

Мои советы по изучению кода:
* Читай документацию, если есть. Проверь актуальность. Напиши новую или поправь, если это не так.

* Не пытайся всё раскурить в одиночку. Общайся с другими разработчиками о программном коде.

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

$cntTries = 0;
$run = true;
while ($run)
{
	if (Documentation::exists())
	{
		Documentation::read();
		$ohNowIUnderstand = ExistsCodeBase::createCodeSnippets()->doThatINeed() && ExistsCodeBase::CallSomeFunctions();
		if ($ohNowIUnderstand)
		{
			echo "You are ready for your first coding task";
			$run = false;
		}
		else
		{
			$cntTries++;
			if ($cntTries == MAX_TRIES)
			{
				echo "You are fired!";
				$run = false;
			}
		}
	}
	else
	{
		echo "Your first task is to write documentation";
		$run = false;
	}
}

Павел Волынцев

Уже более 15 лет занимаюсь разработкой веб-проектов. Fullstack Senior Developer. IT евангелист — доношу свет знаний об информационных технологиях. Профессиональные цели: Дать людям возможность дать людям больше.

Читайте также: