Понимание кодовой базы вашей новой организации очень быстро!
Вы только что присоединились к новой организации в качестве инженера-программиста и готовы начать подниматься по карьерной лестнице. У вас есть контрольный список, который включает в себя загрузку кодовой базы с github, установку slack, настройку локальной среды для API и внешнего интерфейса. Вы, наконец, со всем этим разбираетесь и решаете проверить код — вау! Это много! С чего начать?
Внимание, готовьтесь…
Начать… Начать смотреть код. Вот и все. Были сделаны.
👀
Ладно, ладно… Я пролью.
У моих друзей из твиттера есть несколько советов, как это сделать. Давайте посмотрим на них, тогда я добавлю к этому свои 2 цента.
Естественно, когда кто-либо присоединяется, он пытается просмотреть предоставленный ему источник. Кто-то из команды, скорее всего, даст вам обзор (в том числе и глубокий) того, что происходит. Для меня наличие кого-то, к кому я могу с комфортом обратиться за разъяснениями, играет важную роль. Комфортно здесь включает в себя время отклика, способность повторять, слушать, поощрять, а также должно быть технически хорошо, потому что много вопросов, которые могут выходить за рамки, но могут помочь моему пониманию, учитывая, что мы из разных слоев общества. , может подойти. ~Адамантий
Я думаю, что самый быстрый способ сделать это — разобраться в бизнесе (поговорить с разработчиками бизнеса или людьми, не являющимися техническими специалистами). Вы, вероятно, все равно поймете кодовую базу, поэтому их вклад должен помочь вам понять проблемы, которые кодовая база на самом деле пытается решить ~ Голубая фишка I.C.
Я думаю, что понимание бизнеса и системы работает очень хорошо. Это лучше помогает вам понять, как каждый компонент системы влияет на другой, поэтому при внесении изменений вы знаете, на что обращать внимание, чтобы убедиться, что вы ничего не сломали. ~Ардиль
Продукт вместо кода
Как разработчики, мы иногда хотим пропустить документацию и встречи, посвященные адаптации. Мы хотим просто взяться за первую задачу и начать писать код. Расслабляться!
Самый быстрый способ обойти кодовую базу — это понять продукт, который представляет код. Понимание продукта поможет вам узнать конечный результат каждой задачи/тикета и то, как он вписывается в продукт.
Читать код по пути
Выберите функцию и проверьте, с чего она начинается. Если это веб-приложение, вы можете проверить браузер, чтобы увидеть, какая конечная точка подвергается атаке, а затем начать оттуда.
Если это репозиторий github, у вас есть возможность щелкнуть по функциям, а затем перейти туда, где они определены. Вы можете открыть его в коде VS и сделать то же самое — CMD + клик должен привести вас к определению.
Идея состоит в том, чтобы посмотреть, что делает код, когда вы добираетесь до функции, класса, вы идете к определению и смотрите, что там происходит. Это должно помочь вам понять код самостоятельно, если он достаточно ясен. Берите по одной «функциональности» за раз, и вскоре у вас будет глубокое знание кодовой базы.
Используйте тесты, если они у вас есть
Тесты рассказывают вам, как используется класс/функция. У вас есть образцы входных данных и ожидаемые результаты. Ознакомьтесь с ними, чтобы узнать, как использовать фрагменты кода, фактически не запуская их.
Используйте своих товарищей по команде… Смиренно
До сих пор мы рассматривали, как самостоятельно разобраться в кодовой базе. Вы действительно не можете сделать все это самостоятельно большую часть времени, поэтому обратитесь за помощью, когда у вас будет такая возможность.
Свяжитесь с ними красиво, но переходите прямо к делу и не тратьте их время. Старшим инженерам не нравится «Привет, как дела? Как продвигается кодинг? Красиво, мило!»… Нет! Попробуйте это: «Эй! У вас есть время? Как это работает? ‹исправьте ссылку на строку кода в github здесь›. Не совсем точно, но вы правильно поняли?
Кстати, поздравляю с получением новой работы!
Вот твит, который предшествовал этой статье: Twitter thread
