Добро пожаловать в клуб психологической поддержки тех, кому "посчастливилось" разбираться в чужом коде. Как бы нам это не нравилось - скилл этот должен быть прокачан, в особенности у тех, кому по долгу службы приходится копаться в уже существующих базах.
Если посмотреть на эту проблему под нужным углом, да еще и с правильным инструментом, процесс этот может стать вполне приятным и даже увлекательным. И вот что для этого нужно сделать:
1. Научиться копать глубже
Когда вы впервые погружаетесь в уже сформированную базу кода, не рассматривайте ее с позиции разработчика. Представьте, что вы Индиана Джонс, или даже Джеймс Бонд в мире программирования. И знаете что? Вам крупно повезло, потому что в вашем распоряжении куча примочек, которым может позавидовать сам 007 со всем своим MI6 вместе взятым.
Если вы будете работать с кодовой базой, которая с самого начала была в системе управлении версиями, у вас будет доступ к множеству метаданных, значительно облегчающих вашу работу по пониманию не только кода, но и контекста. Предположим, вы пользуетесь Git, но и с SVN применимы те же идеи.
git blame
Можно использовать команду 'git blame [filename]', чтобы узнать имя автора кода, последнюю измененную информацию, коммит хэш для каждой строки. Если вам повезет, вы благополучно выйдите на авторов с помощью git blame и выведаете всю необходимую информацию.
git log
Используйте команду git log, чтобы посмотреть историю коммитов всего репо. Эта команда печатает сообщения коммита, поэтому не забывайте про grep, если вы хотите осуществить поиск коммитов, в которых сообщение коммитов выдает ссылку someFunction: git log | grep someFunction -C 3 (-C 3 покажет ваши совпадения с тремя линиями контекста).
git log также может показать вам историю каждого файла с -p flag: git log -p index.js.
Обращайте внимание на людей, которые указаны в поздних модификациях файла, тогда вы будете точно знать, кому адресовать вопросы, если таковые возникнут.
2. Отмотать время назад
Вы можете проверить любой коммит и запустить его, будто он самый последний коммит в проекте. Возможно вы захотите проверить последний исправный коммит, перед багом который все застопорил. Если ваш проект размещается на GitHub или на чем-то похожем, у вас есть отличная возможность вникнуть в кодовую базу: читайте обзоры, опросы и отзывы. Обращайте внимания на проблемные вопросы, которые вызвали большое количество обсуждений. Это могут оказаться те самые болевые точки, о которых вы еще ничего не знаете, но в скором времени возможно по которым вас как следует стукнет.
3. Читать технические условия
Читайте технические характеристики, чтобы определить какие функции и модули нужно сделать, и для каких случаев они разработаны. Изучите спецификации интеграции, чтобы выяснить, как пользователи будут взаимодействовать с вашим приложением и какие виды рабочих процессов оно поддерживает.
4. Вдумываться в комментарии и подсказки
Если вы столкнулись с запутанной функцией, а потом еще прочитали комментарий к этой функции, который еще больше вас запутал, подумайте, может комментарий этот давно устарел и не поддерживается.
5. Приготовиться ко встрече с огромным количеством мусора
Мусорного кода может быть очень много — функции или целые системы, которые уже давно не используются. Компании частенько меняют свои бизнес модели, при этом, забывая поменять систему, следовательно, нет ничего не обычного в том, что вы находите одинаковые или похожие цели / функции, достигаемые с помощью различных «технологий».
6. Найти главное
Это может показаться очевидным, но убедитесь, что вы знаете, где код начинает выполняться и как он себя настраивает. Изучите файлы в него включенные, созданные классы и установленные конфигурации. Какие-то модули, скорее всего, будут универсальными и отделенными от остальной базы. Они представляют собой более мелкие и удобоваримые куски, с которыми вам следует ознакомиться, прежде чем приступать к более крупным кускам. Запустите в этом файле git blame и посмотрите, какие части файла недавно изменялись. Кусок кода, который недавно изменился, может указать вам на некоторые проблемы, с которыми столкнулась команда разработчиков в последнее время. Будь то библиотека или ее настройка, или даже стандартный код, который необходимо постоянно обновлять. Попробуйте найти ссылки на эти модули в некоторых других исходных файлах, чтобы понять, как и когда они используются. Это может дать вам представление о том, как они вписываются в общую картину.
7. Найти автоматизированные тесты
Это должно быть No 1 в вашем чеклисте по чтению чужого кода. Юнит-тесты должны быть максимально простыми. Вам даже не нужно смотреть на реальный тест — просмотр названий юнит-тестов даст вам представление о том, что они тестируют, и, следовательно, что делает система.
Не ждите быстрых результатов. Вряд ли вам откроются все истины на 100%. Держите в голове эти семь простых правил, и, главное, не теряйтесь в километрах чужих строк кода. Сеанс психотерапии объявляется закрытым.
Добавить комментарий