как разобраться в чужом коде
Как научиться читать чужой код
Предположим, от такого занятия Ваши веки постепенно тяжелеют, и… Приходится пробудиться от необходимости понять чужой код и привести его в порядок. На мой взгляд, визуально сканировать иероглифы не так сложно как может показаться сначала. Как бы то ни было, необходимо уметь читать чужой код и редактировать, и один процесс не существует без второго.
Понимание этого приходит во время изнурительных тренировок. Особенно хорошо мы запоминаем, когда много раз сталкиваемся со своими ошибками из-за отсутствия навыков правильного чтения чужого кода.
Говоря о вероятности наличия ошибок, заметим, что в старых, тысячу раз проработанных файлах их меньше. Обычно массу ошибок мы встречаем в файлах, который никогда не меняли.
Перед реконструкцией кода иногда проще привести его в удобный для Вас порядок и потом вносить небольшие изменения, нежели сначала написать стили или события, а потом изменять верстку, например.
Лучше не оставлять черновых вариантов в рабочих файлах, поскольку Вы обязательно про что-нибудь забудете.
Когда над проектом работает команда, становится необходимостью сначала позаботиться о понимании концепции будущего сервиса. Вы обязательно вспомните этот совет, когда заметите, что продуктивно работали не возвращаясь к вопросам о том как это должно быть. Каждый специалист знает свою работу, и не стоит заблуждаться в том, что кто-то имеет такое же представление о том как будет реализована задача и что оно будет совпадать с Вашим. Поэтому не бойтесь советоваться с коллегами по цеху, чтобы последствия не вышли из области Вашего контроля и не стали неожиданностью.
Если Вы совершаете повторный поиск чего-то, на что вновь потребовалось приличное количество времени – необходимо обратить на это внимание.
Проведите анализ – с чем чаще всего пришлось повторно столкнуться; какого рода элементы вы ищите долго и почему. Возможно, это происходит из-за того, что Вы бы написали определенный фрагмент кода иначе, или не до конца ясна логика. В любом случае, надо действовать исходя из осознания того, что работа с кодом — уже Ваша задача, а не того, кто первым его написал.
Работая с чужими файлами, мы начинаем понимать, что хотел человек, каким он видел будущий сервис. Ход закодированных мыслей становится для нас все более логичным, а иногда и самым верным для реализации конкретной задачи.
Решения многих задач ждут Вас в сетях интернета, и поиск их занимает не так много времени, как кажется может показаться на первых порах.
Приятно воспользоваться благами обычных блокнотов. Например, CTRL + G (поиск по номеру строки) и прочие удобности, что значительно экономит время.
Работая с кодом желательно оставлять комментарии. Со временем они приобретут лаконичную форму и будут размещены в нужном месте. Это облегчает работу не только Вам, но и другим коллегам.
Приблизительно в середине работы над изменением кода для небольшой разгрузки можно просмотреть его на содержание синтаксических ошибок.
Рекомендуется так же редактировать файлы по маленьким частям, а начинать с самого сложного. Если Вы надолго застряли на каком-то моменте — переключитесь на что-нибудь другое. Вернитесь к трудности завтра, с утра, чтобы не тратить много времени на восстановление в памяти последних мыслей.
Не сомневаюсь, что частенько у Вас бывает поток мыслей о том, что необходимо исправить в разных участках кода. Для этого лучше все записывать. В конце рабочего дня это будет хорошим подспорьем. Так проще рассчитать время, необходимое на выполнение поставленной задачи, а так же, пригодится для отчетности.
Когда уходите на перерыв или домой, просмотрите что необходимо еще сделать. Когда перед Вами не будет кода и в памяти будет «висеть» задача, Вы заметите появление свежих оригинальных мыслей, даже если не будете намеренно думать о способе решения. Особенно такой прием подходит для сложных задач. Не говоря о пустяковых, конечно.
Как читать код: 8 принципов, которые стоит запомнить
«Ненавижу читать чужой код», — эту мантру часто можно услышать от разработчиков любого уровня. Тем не менее, это необходимое умение, особенно для разработчиков, которым предстоит освоиться в существующей кодовой базе, и если вы подойдете к этой работе с правильным настроем и правильными инструментами, это может быть весьма приятным и просветляющим опытом.
Мы не любим читать чужой код по той причине, что он написан не нами. Само собой разумеется, что в глубине души мы считаем себя лучшими программистами на планете и никто не сможет написать такой крутой код, как мы. Написание кода — это интенсивный мыслительный процесс, а пассивный читатель не испытывает ничего подобного.
Код, который вы видите на экране, мог быть написан несколькими людьми. Возможно, в процессе споров и сотрудничества. Возможно, им потребовались недели, чтобы выдать код, который обходил какие-то недокументированные ограничения, о которых вам неизвестно, и это знание осталось только в головах тех, кто его писал.
Все, что вы увидите как читатель — это законченный продукт. И если не провести некоторых раскопок, единственный контекст, с которым вы будете работать — это тот самый код на вашем экране.
1. Учитесь копать
Когда вы впервые знакомитесь с серьезной кодовой базой, возможно, вы не будете чувствовать себя разработчиком. Скорее вы будете себя чувствовать археологом, частным сыщиком, или исследователем религиозных книг. Это вполне нормально, ведь в вашем распоряжении есть несколько инструментов для «раскопок». Если вам повезло, и ваши предшественники использовали контроль версий, это стоит отпраздновать! У вас есть доступ к богатству метаданных, и это очень сильно облегчит вам понимание контекста, в котором создавался код. Далее я исхожу из того, что вы используете Git, но в случае с SVN, все будет примерно так же.
git blame
git log
2. Вернитесь в прошлое
Вы можете переключиться на какой угодно коммит и запустить проект так, как будто бы этот коммит был последним. Вам может понадобиться переключиться на коммит, который был последним перед появлением какой-нибудь сложно отслеживаемой проблемы. А может вам просто станет скучно и вы захотите покопаться в истории кода и увидеть, каким был проект за годы до того, как вы туда пришли.
Если проект хранится на GitHub или подобном сервисе, вы можете получить уйму информации, читая тикеты, пулл-реквесты и код-ревью. Обращайте внимание на тикеты, в которых было больше всего обсуждений. Там могут быть «болевые точки», с которыми вы можете столкнуться в будущем, поэтому хорошо бы заранее иметь о них представление.
3. Читайте спецификации
Спецификации — это новые комментарии. Читайте юнит-спецификации, чтобы выяснить предназначение функций и модулей, и возможные пограничные случаи (edge-cases), которые они обрабатывают. Читайте интеграционные спецификации, чтобы выяснить, как пользователи будут взаимодействовать с вашим приложением и какие процессы поддерживает ваше приложение.
4. Думайте о комментариях, как о подсказках
Если вы наткнулись на непонятную функцию и прочли комментарий к ней, который еще больше вас запутал, возможно, что этот комментарий просто устарел и не обновлялся.
Глаза программиста имеют способность пропускать пропускать зеленый текст комментариев, и возможно, что этот поставивший вас в тупик комментарий относился к функции, которая исчезла уже много месяцев (или лет) назад, и никто, кроме вас, этого не заметил.
5. Найдите Main
Это может казаться очевидным, но в первую очередь убедитесь, что вы понимаете, где код начинает исполнение и что происходит в процессе запуска. Посмотрите, какие файлы подключаются, какие классы инстанцируются, какие опции конфига устанавливаются.
Скорее всего, вы будете постоянно сталкиваться с ними и в остальном коде. Некоторые модули будут иметь очень общее назначение, и будут выделяться из остального кода. Они представляют собой более маленькие и понятные кусочки функционала, с которыми вам следует познакомиться перед тем, как пытаться разобраться со всем приложением полностью.
Выполните git blame на этом файле и посмотрите, какие части основного файла были изменены недавно. Недавно измененный код может подсказать вам, над какими проблемами работала команда в последнее время. Возможно, они представили новую библиотеку, или долго пытались наладить библиотеку, которая не слишком хорошо работала. А может быть, там просто какой-то бойлерплейт код, который нужно регулярно обновлять.
Попробуйте найти отсылки к этим модулям в других частях кода, чтобы понять, как и когда они используются. Это может помочь вам понять место и роль модулей в основном приложении.
6. Обращайте внимание на стиль.
Вы ведь изучаете это приложение не просто так, и рано или поздно ваш код тоже туда попадет, поэтому обращайте внимание на стиль. Это включает в себя такие вещи как соглашение о стандартах оформления кода: именование, пробелы, скобки, а также соглашение о написании кода.
Каков общий уровень абстракции? Если это высокоабстрактный код со многими уровнями абстракции, то вам следует писать так же. Если вы хорошенько покопались в истории, то наверное сможете найти момент, когда один из разработчиков решил абстрагировать часть кода. Как он выглядел до этого, и что стало с ним после выноса на новый уровень абстракции? Пытайтесь следовать тем же соглашениям, когда пишете свой код.
7. Ожидайте встретить мусор
Вам могут встретиться функции, а может, и целые файлы, которые никогда не используются. Вы можете встретить закомментированный код, который простоял нетронутым несколько лет ( git blame в помощь). Не тратьте на это слишком много времени, и не бойтесь избавляться от подобных артефактов.
Если этот код был нужен, кто-нибудь отметит это на код-ревью. А вы сделаете доброе дело, уменьшив количество умственной нагрузки для следующего, кто будет читать этот код.
8. Не отчаивайтесь
Держите предыдущие пункты в голове, и не падайте духом, если чувствуете, что совершенно запутались. Изучение кода — это не линейный процесс, не ожидайте сразу понять все на 100%. Обращайте внимание на важные детали и знайте, как копать, чтобы найти ответы на вопросы, и вы довольно быстро обнаружите, что все становится понятно.
Автор: Уильям Шон, консультант и разработчик в Ann Arbor. Оригинал здесь.
8 советов для быстрого понимания чужого кода
На Quora матёрые программисты дали тонну советов и техник, которые помогут сориентироваться в базе кода, написанного не вами и не вашей командой.
Такое часто случается с проектами, доставшимися «по наследству» от предыдущих разработчиков. Вам уже нужно писать новые блоки, а в старой базе over 9 000 строк кода. Как быстро освоиться и не утонуть юному падавану?
Самый очевидный совет — найти программиста, который уже знаком с этим кодом, и слёзно попросить его отвечать на все ваши глупые вопросы в течение пары следующих недель. Ещё лучше поговорить с тимлидом проекта и заранее попросить его снизить нагрузку на программиста, который любезно согласится побыть вашим наставником.
Отсюда две линии развития событий:
— Вы нашли себе учителя (если вы работаете в команде)
— Вы не нашли себе учителя (такое может случиться, если вы работаете над опенсорсным проектом)
I. Вариант с менторством. Как облегчить жизнь себе и вашему кунг-фу гуру?
II. Вариант без менторства. Как разобраться во всём самостоятельно и ничего не сломать? (программа на 3 недели)
Так или иначе, в обоих вариантах новичку (даже если вы не новичок в программировании, вы можете быть новичком в этом коде) нужно задать себе четыре глобальных вопроса:
— Что делает этот код?
— Как он это делает?
— Что нужно сделать, чтобы он стал лучше?
— В каком месте это нужно сделать?
Ответы на эти вопросы находятся в самом коде. Если код уже выполнен аккуратно и разбит на чёткие модули и объекты, проблем у вас не возникнет. Пользуйтесь баг-трекером, отладчиком, читайте документацию и не стесняйтесь приступить к исправлению найденных багов.
Ужасы чужого кода: как найти смысл и не умереть
Даже самым крутым программистам трудно читать чужой код. Узнайте, почему это так страшно и как с этим справиться.
В жизни каждого разработчика наступает момент, когда нужно взяться за код, написанный другим человеком. Это может быть связано с поддержкой старого проекта, оптимизацией legacy-кода, переделыванием приложения, которое не доделал другой программист.
Хорошо, если этот код написан по архитектурному паттерну, у него есть документация, комментарии или хотя бы понятные названия переменных. Однако чаще всего приходится работать с говнокодом (это термин, если что).
В этой статье я опишу личный опыт чтения ужасного кода. Поэтому приготовьтесь сначала лицезреть моё страдание и только потом получить какие-то полезные советы.
Пишет о программировании, в свободное время создает игры. Мечтает открыть свою студию и выпускать ламповые RPG.
Виновник торжества
Мне и раньше приходилось сталкиваться с плохим кодом (например, своим), но недавно попался настолько ужасный, что я решил написать об этом статью.
Для начала попробуйте понять, что делает этот цикл, зная только, что приложение работает с 3D-графикой:
Первое, что бросается в глаза, — нарушение традиций в выборе имени счётчика.
Чтобы разобраться, что тут происходит, нужно понять, что такое msh, object и gm. С последним всё предельно просто:
Теперь остаётся только понять, что такое oo. Это очень хороший вопрос, потому что oo — это глобальная переменная, объявление которой нужно ещё поискать.
Вот другой фрагмент:
Название метода не вносит никакой ясности. Не говоря уже о том, что разработчик игнорирует соглашение об идентификаторах. Он даже единого стиля не придерживается, потому что в этом же файле можно встретить метод, который называется getPointOfIntersection ().
Складывается ощущение, что разработчик не знает главного правила программирования:
«Пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где вы живёте».
Как с этим жить
Очевидно, что невозможно заставить всех писать чистый и понятный код. Поэтому единственный выход — научиться читать всё, что попадается под руки. Это умение можно разделить на два навыка: чтение и расшифровка (эти названия условные).
Расшифровка может пригодиться, когда нужно срочно понять, как работает код. Особенно если он настолько ужасный, что просто пытаться вникнуть в проект — глупо. Рассмотрим на примере:
Это достаточно небольшой метод, который, однако, записан таким образом, что невозможно понять, что он делает. В этом случае не стоит тратить силы, чтобы вникнуть, — лучше сразу привести его в человеческий вид.
Для начала можно расставить пробелы и переносы строк:
Сделать это можно с помощью специальных инструментов, но лучше попробовать вручную. Возможно, в процессе получится что-то понять. Попутно можно добавить комментарии:
Становится понятно, что метод проверяет коллизию двух двумерных объектов. Поэтому можно поменять названия переменных и самого метода:
Когда весь код приобретёт более-менее человеческий вид, можно будет провести рефакторинг:
Например, можно вместо координат принимать объекты:
Всё это должно помочь разобраться в коде здесь и сейчас. Если же нужно постоянно работать с чужими проектами, то есть смысл попрактиковаться в чтении. Есть несколько простых советов, которые помогут в этом нелёгком деле.
1. Пробуйте писать в разных стилях
Обычно я пишу вот так:
Даже если нужно выполнить одну инструкцию, я всё равно использую фигурные скобки. Мне кажется, так легче понять, что является частью ветвления, а что — нет.
Но иногда стоит посмотреть, как пишут другие, и попробовать так же. Например, вот так:
Если часто практиковаться, можно привыкнуть, и тогда читать такие конструкции будет проще.
2. Читайте чужой код
Попробуйте зайти в случайный репозиторий на GitHub и разобраться, как там всё устроено и как оно работает. Изучите несколько проектов, чтобы научиться понимать разные стили.
Подумайте, почему разработчик пишет так, а не иначе, как он составляет документацию и так далее. Так вы не только научитесь читать чужой код, но и, возможно, найдёте пару интересных приёмов, которые захотите использовать сами.
3. Давайте другим читать ваш код
Дайте другому разработчику посмотреть ваш проект. Сразу будьте готовы к тому, что ваш код тоже так себе. Обратная связь поможет понять, что вы делаете не так, а если повезёт, получите несколько рекомендаций, как улучшить свой код.
В процессе вы можете понаблюдать, что делают более опытные коллеги, чтобы вникнуть в ваш проект.
4. Попробуйте прочесть код, который писали давно
Скорее всего, сначала вы ничего не поймёте, а потом почувствуете сильный стыд. Это нормально и случается со всеми программистами.
Сейчас вы уже лучше, чем были когда-то давно, поэтому сможете увидеть, что делали не так. Возможно, вы заметите, что до сих пор используете те же самые приёмы, и исправите это.
5. Больше рефакторинга
Иногда код необходимо переделать, даже если он работает. Конечно, это касается в первую очередь проектов, которые нужно поддерживать. Если не прибегать к рефакторингу, то придётся постоянно держать в голове весь плохой код, чтобы не приходилось каждый раз вникать заново. Кроме того, вы вряд ли заметите баги и уязвимости, потому что весь код выглядит как одна большая уязвимость.
Заключение
Последний совет: не обманывайте себя. Вы, я и любые другие разработчики пишут ужасно. Просто потому, что так устроено программирование — приложения не могут быть безупречными и совсем понятными.
Однако это не значит, что можно окончательно забить на чистоту и читаемость кода. Просто нужно понимать, что мастерство в программировании, как и в любом другом деле, это не пункт назначения — это сам путь.
Нужно стремиться к тому, чтобы писать совершенный код, но помнить, что не нужно зацикливаться на этом. Именно так мы подходим к обучению на курсе «Профессия C#-разработчик». Студенты учатся писать чистый, поддерживаемый код с документацией, который не стыдно показать коллегам.
Профессия C#-разработчик
130 часов — и вы научитесь писать программы на языке, созданном Microsoft. Вы создадите 5 проектов для портфолио, даже если до этого никогда не программировали. После обучения — гарантированное трудоустройство.
Быстрый способ разобраться в чужом коде
Данный метод будет очень полезен в типовых конфигурациях, так как там может быть очень глубокий стек вызовов процедур, в котором новичку разобраться достаточно сложно.
Предположим, нужно разобраться, как устроен механизм печати БП 3.0.
Идем в конфигуратор, запускаем режим отладки. Кстати, некоторые процессы, например, формирование отчетов могут выполняться фоново, и для их отладки требуется настроить автоматическое подключение.
Также в типовых конфигурациях есть дополнительный параметр запуска «/РежимОтладки», который так же отключает фоновое выполнение.
После запуска режима отладки заходим в документ для формования печатной формы, но перед выполнением печати запустим механизм замера производительности.
Данный механизм позволит увидеть список выполненного кода за период работы механизма.
Далее выполняем печать и отключаем замер производительности.
Теперь нужно решить: какой ключевой оператор поможет найти требуемую процедуру, в которой формируется печатная форма. Для формирования печатной формы требуется в любом случае создать объект Табличный документ, таким образом ключевой оператор будет «Новый ТабличныйДокумент» или просто «ТабличныйДокумент». Находим нужную строку, используя ключевой оператор, устанавливаем точку останова и запускаем формирование отчета.
После остановки отладки на требуемой строке кода запускаем стек вызовов.
Выходит окно со списком вызванных процедур, по которым можно выполнять переход для изучения механизма печати.
Специальные предложения
Вчера только сделал короткую заметку, что можно применять поиск в окне замера производительности
(9) Десять лет назад я тоже начинал «расследование» от кнопочки «Сформировать». Но пару лет назад мне попалась УНФ, а там на банальную печать документа жесткая мешанина из процедур модуля менеджера этого документа, специальной печатающей именно этот документ обработки и кучи вызовов из общих модулей, часть из которых спрятана в БСПшных кишках, и часть из которых вызывается вообще в фоне. Почухал репу и на меня снизошло озарение про «Замер производительности», благодаря которому очень быстро все вызовы проанализировал.
В итоге чем выше уровень абстракции, тем легче воспринимать программу, как систему взаимодействующих сущностей. А дальше кже детали реализации конкретного объекта, которые и составляют основную сложность в программировании.