Как включиться в проект по разработке ПО
Общий список рекомендаций
- Изучить высокоуровневую архитектуру приложения
- Не очень надеяться на официальную документацию и неофициальные описания
- Изучить контекст приложения
- Создать простые документы-инструкции по подготовке рабочего места
- Найти хороший инструмент для навигации по коду и полнотекстовому поиску
- Стремиться к экспоненциальному накоплению знаний
- Определить критические пути исполнения кода
- Изучить пути кода, связанные с пользовательским взаимодействием
- Читать / писать юнит-тесты и предположения (
assert) - Читать описания и содержимое ранних патчей и коммитов
- Наблюдать за исполнением кода
- Анализировать процесс сборки и развертывания приложения
- Много спрашивать у авторов кода
- Определить границы модулей / подсистем
- Изучить основы используемых технологий
- Написать / использовать инструменты анализа кода
- Обдумывать свои варианты реализации функций системы
Детализация рекомендаций
Экспоненциальное накопление знаний
Каждый следующий уровень изучения кода должен базироваться на всей ранее полученной информации. Лучше, если базовые принципы будут усвоены в полном объеме в первую очередь, это позволит быстрее схватывать большой объем более детальной информации об отдельных сегментах кода
Критические пути исполнения кода
Изучение наиболее важных сценариев работы с продуктом позволит в первую очередь разобраться с той областью кода, плотность важных концепций в которой максимальна. Тут же стоит разобраться с производительностью и сложностью кода на этом критическом пути. Также возможно найти основные циклы обработки событий или основные обработчики и сконцентрироваться на них.
Изучить пути кода, связанные с пользовательским взаимодействием
Полезно, потому что даст возможность глубоко изучить возможности продукта и облегчит поиск багов, обнаруженных QA и пользователями. К тому же, пользовательские сценарии обычно довольно широко охватывают код, поэтому их изучение даст возможность увидеть более полную картину.
Читать / писать юнит-тесты и предположения (assert)
Юнит-тесты надо писать на каждый исправленный баг + на любое непонятное место в коде. Это позволит лучше понимать поведение кода и застраховаться от повторения багов. На каждую изученную функцию необходимо написать юнит-тесты, чтобы удостовериться в уровне понимания. Разработчик должен представлять себе, что происходит, должен уметь зафиксировать свои ожидания в виде теста и обнаружить в ходе выполнения тестов неожиданное поведение системы. Тут же можно попробовать порефакторить систему.
Не очень надеяться на официальную документацию, неофициальные описания и знания участников проекта
Как и тесты, документация имеет тенденцию устаревать. К тому же, всегда полезно держать особенности кода в голове, это своего рода кэш, оптимизирующий производительность программиста.
Читать описания и содержимое ранних патчей и коммитов
Отлично дополняет изучение критических путей, потому что позволяет проследить, как код развивался, какие основные моменты были изначально реализованы.
Наблюдать за исполнением кода
И проходить отдельные фрагменты в отладчике. Выбрать интересующую область кода, найти точку входа в нее и запустить пошаговое выполнение, начиная с нее. При этом нужно стремиться как можно более полно понять и как можно точнее сформулировать, что делает каждый конкретный класс / метод / функция по ходу кода.
Анализировать процесс сборки и развертывания приложения
Сборка - это абсолютно такая же часть продукта, как и исходный код. Она также может быть неэффективной или с дефектами, ее точно так же нужно поддерживать и точно так же оптимизировать.
Изучить высокоуровневую архитектуру приложения
Но не слишком углубляться в диаграммы взаимодействия классов, оперировать больше шаблонами и реализованными решениями, чем относительно низкоуровневыми взаимосвязями.
Много спрашивать у авторов кода
На начальном этапе - это очень важно, но с течением времени становится не самым эффективным вложением времени. Опять же лучше спрашивать о высокоуровневых вещах, а детали реализации выяснять самому.
Определить границы модулей / подсистем
Полезно понимать, какой код на какой влияет, а какой - не может быть причиной именно этого конкретного бага.
Изучить контекст приложения
Краткий обзор того, что призвана делать рассматриваемая система. Обычно это фиксируется в документе типа ТЗ. Тут же нужно изучить используемые проектные решения, особое внимание уделив часто используемым шаблонам. Тут же ознакомиться с зависимостями проекта и сторонними библиотеками. Изучить текущее состояние проекта - открытые задачи и неисправленные баги, последние правки и фиксации в репозитории
Написать / использовать инструменты анализа кода
Например, заставить каждую функцию выводить в лог время начала и окончания работы, чтобы проанализировать дерево вызовов и получить представление о наиболее важных / часто вызываемых функциях.
Советы изучающим серьезные программные продукты
- Не пытайтесь охватить весь проект целиком. В первые месяцы работы с проектом это непосильный труд и к тому же лишняя, ненужная работа. Многие Senior-разработчики, участвующие в проекте год или больше, не знают, как работают отдельные фрагменты кода, чего уж ждать от новичка.
- Сосредоточьтесь на непосредственном вкладе в проект. Как можно раньше начните приносить пользу. По мере исправления багов и добавления новых маленьких функциональных возможностей вы начнете лучше понимать архитектуру системы. “Крадите” время на изучение системы в перерывах между исправлением багов, при этом в первую очередь сосредоточьтесь на изучении юнит-тестов.
- Важные навыки: способность быстро находить проблемные места и способность оценить влияние изменений на другие части системы.
- Вспомогательные инструменты и процессы.
- Для поиска проблемных мест можно либо читать статичный код (Architexa, AgileJ, UModel, Poseidon, etc), либо отслеживать ход исполнения кода (MaintainJ, Diver, jSonde, Java Call Tracer,etc).
- Для оценки влияния изменений: статика (Lattix, Structure101, Coverity, nWire and IntelliJ’s DSM) и динамика (MaintainJ)
- Ни в коем случае:
- Не ухудшать качество кода, потому что времени на поставку мало
- Не пренебрегать изучением архитектуры системы