Перевод статьи «5 Effective tips for maintaining code written by someone else».
Из вашей команды кто-то уходит? Вам передают legacy-код? Вы сами переходите в другую команду? Это лишь некоторые из причин, по которым разработчики могут столкнуться с задачей поддержки чужого кода.
Работа с кодом, который не вы писали и с которым вы не знакомы, может быть связана с некоторыми проблемами. Вам могут передать код для незнакомой вам технологии, причем код, требующий доработки. Или может возникнуть необходимость срочно исправить баг, обнаруженный в старой кодовой базе.
Чтобы лучше справляться с подобными задачами, важно знать о потенциальных проблемах и иметь какую-то наработанную систему их решения.
Если вы занимаетесь разработкой на профессиональном уровне, скорее всего, вы уже попадали в ситуации, когда приходилось работать с чужим кодом. Но если нет — поверьте мне, это лишь вопрос времени!
В этой статье мы рассмотрим несколько советов, способных облегчить работу с унаследованным кодом.
1. Проведите сеанс передачи кода с автором
Если у вас еще есть контакт с человеком, который написал этот код, проведите с ним сеанс передачи. Или два! А может и три.
Используйте эти сеансы как способ ускорить процесс ознакомления с кодовой базой. Без этого вам придется разбираться во всем самостоятельно, а это займет больше времени. Разработчик, создавший этот код, может рассказать вам о его логике, а также указать на любые скрытые «секреты» или «хаки».
Перед сеансом передачи непременно сами просмотрите код и запишите возникающие у вас вопросы. Таким образом во время совместного просмотра кода с его автором вы будете знать, на что обращать внимание и что спрашивать. И конечно же, во время совместных сеансов ведите записи.
Передача вам кода самим автором — вероятно, самый быстрый способ познакомиться с новой для вас кодовой базой.
Поэтому, если у вас еще есть возможность обратиться к этому разработчику, непременно ею воспользуйтесь. Если ваш коллега собирается покинуть компанию, сеансы передачи кода должны быть у вас в приоритете, ведь вам нужно успеть их провести до его ухода.
Бывают и другие ситуации, когда полезно пройтись по кодовой базе вместе с кем-то, кто ее хорошо знает. Например, если вы сменили команду, нужно, чтобы кто-то из новых коллег рассказал вам о структуре кода. Это позволит ускорить ваше знакомство с новой для вас кодовой базой.
2. Прочтите всю доступную документацию
Документация — это все доступные документы, относящиеся к проекту, для которого был написан код.
Спецификации проекта? Спецификации программы? Файлы README? Прочтите все это.
Время, потраченное на чтение этих документов, вы сэкономите в будущем.
Вы можете часами биться в попытках выяснить, почему код был реализован определенным образом, но ответ можно найти, просто прочитав README. Можно попытаться самостоятельно понять назначение разделов кода, но они могут быть хорошо описаны в спецификациях приложения.
Читать документацию важно, даже если вы провели сеанс передачи с разработчиком, написавшим код. Все эти документы существуют не без причины. А сеансы передачи вряд ли охватят все существенные моменты.
Чтение документации особенно важно для устаревшего программного обеспечения. Речь идет о случаях, когда у вас нет ни малейшего шанса поработать с авторами кода. Поскольку сеанс передачи невозможен, все, что у вас есть, — это исходный код и любая доступная документация.
Последний совет по этому поводу: помните, что файлы README не зря называются README («прочти меня» — прим. перев.)!
3. Запустите программу и попользуйтесь ею
Этот совет надо понимать буквально. Запустите код и попробуйте использовать приложение так, как задумано. Таким образом вы сможете лучше понять, что оно делает.
Это может показаться очевидным, но практика показывает, что многие игнорируют этот этап.
Если разработчик составляет представление о программе, лишь читая код и строя догадки, это может привести к проблемам. Поэтому обязательно запустите приложение и попробуйте использовать его как конечный пользователь. Это даст вам общее понимание того, что на самом деле делает приложение, а также представление о его функциях и ограничениях. В результате вам будет проще разобраться в коде.
Это относится и к приложениям, написанным для определенного оборудования или платформ. Получите доступ ко всему необходимому и запустите приложение на соответствующих платформах.
Если вы пытаетесь исправить баг, запуск кода — логичный первый шаг в процессе отладки. Это тоже вроде бы очевидно, но лучше еще раз об этом сказать.
4. Тестируйте, тестируйте, тестируйте!
Если вы имеете дело с незнакомой кодовой базой, прежде чем вносить какие-либо изменения, убедитесь, что есть тесты для проверки работоспособности программы. Тесты помогут подтвердить, что после внесения изменений ничто не сломалось.
Безопасное внесение изменений — еще более сложная задача, чем просто знакомство с чужим кодом!
И если исходить из того, что вам передали код именно для внесения правок и улучшений, то наличие тестов имеет решающее значение.
Если тестов нет, попробуйте написать их самостоятельно. Это могут быть юнит-тесты, дымовые, ручные или автоматизированные. Любое тестирование обычно лучше, чем его отсутствие.
5. Примите вызов
Когда вам приходится взяться на поддержку незнакомого кода, попробуйте воспринять это как личный вызов. Справляясь со всеми сопутствующими трудностями, вы существенно улучшите свои навыки.
Во-первых, вы разовьете навыки чтения и интерпретации чужого кода. Это позволит вам лучше улавливать намерения разработчиков при чтении кода. Благодаря практике вы сможете легче справляться с задачами поддержки программ.
Во-вторых, поддерживая чужой код, вы сможете перенять полезные методы и приемы, которые улучшат ваш собственный. Чтение кода других разработчиков можно считать методом непрямого обучения. Только будьте осторожны и избирательны в отношении перенимаемых методов.
Осознание того, что в конечном итоге вы получите выгоду от этого опыта, должно вас мотивировать. Так что не бойтесь и принимайте брошенный вам вызов!
Вывод
Поддержание кода, написанного кем-то другим, безусловно, связано со многими проблемами. Но это всего лишь еще одна сторона работы разработчика, с которой нам всем когда-нибудь придется столкнуться.
И вы сможете куда лучше подготовиться к работе с чужим кодом, если не только будете следовать советам из этой статьи, но и разработаете собственные систематические методы для работы с незнакомой кодовой базой.
[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]
