как читать чужой код php
Как читать код: 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. Оригинал здесь.
Как научиться читать чужой код
Предположим, от такого занятия Ваши веки постепенно тяжелеют, и… Приходится пробудиться от необходимости понять чужой код и привести его в порядок. На мой взгляд, визуально сканировать иероглифы не так сложно как может показаться сначала. Как бы то ни было, необходимо уметь читать чужой код и редактировать, и один процесс не существует без второго.
Понимание этого приходит во время изнурительных тренировок. Особенно хорошо мы запоминаем, когда много раз сталкиваемся со своими ошибками из-за отсутствия навыков правильного чтения чужого кода.
Говоря о вероятности наличия ошибок, заметим, что в старых, тысячу раз проработанных файлах их меньше. Обычно массу ошибок мы встречаем в файлах, который никогда не меняли.
Перед реконструкцией кода иногда проще привести его в удобный для Вас порядок и потом вносить небольшие изменения, нежели сначала написать стили или события, а потом изменять верстку, например.
Лучше не оставлять черновых вариантов в рабочих файлах, поскольку Вы обязательно про что-нибудь забудете.
Когда над проектом работает команда, становится необходимостью сначала позаботиться о понимании концепции будущего сервиса. Вы обязательно вспомните этот совет, когда заметите, что продуктивно работали не возвращаясь к вопросам о том как это должно быть. Каждый специалист знает свою работу, и не стоит заблуждаться в том, что кто-то имеет такое же представление о том как будет реализована задача и что оно будет совпадать с Вашим. Поэтому не бойтесь советоваться с коллегами по цеху, чтобы последствия не вышли из области Вашего контроля и не стали неожиданностью.
Если Вы совершаете повторный поиск чего-то, на что вновь потребовалось приличное количество времени – необходимо обратить на это внимание.
Проведите анализ – с чем чаще всего пришлось повторно столкнуться; какого рода элементы вы ищите долго и почему. Возможно, это происходит из-за того, что Вы бы написали определенный фрагмент кода иначе, или не до конца ясна логика. В любом случае, надо действовать исходя из осознания того, что работа с кодом — уже Ваша задача, а не того, кто первым его написал.
Работая с чужими файлами, мы начинаем понимать, что хотел человек, каким он видел будущий сервис. Ход закодированных мыслей становится для нас все более логичным, а иногда и самым верным для реализации конкретной задачи.
Решения многих задач ждут Вас в сетях интернета, и поиск их занимает не так много времени, как кажется может показаться на первых порах.
Приятно воспользоваться благами обычных блокнотов. Например, CTRL + G (поиск по номеру строки) и прочие удобности, что значительно экономит время.
Работая с кодом желательно оставлять комментарии. Со временем они приобретут лаконичную форму и будут размещены в нужном месте. Это облегчает работу не только Вам, но и другим коллегам.
Приблизительно в середине работы над изменением кода для небольшой разгрузки можно просмотреть его на содержание синтаксических ошибок.
Рекомендуется так же редактировать файлы по маленьким частям, а начинать с самого сложного. Если Вы надолго застряли на каком-то моменте — переключитесь на что-нибудь другое. Вернитесь к трудности завтра, с утра, чтобы не тратить много времени на восстановление в памяти последних мыслей.
Не сомневаюсь, что частенько у Вас бывает поток мыслей о том, что необходимо исправить в разных участках кода. Для этого лучше все записывать. В конце рабочего дня это будет хорошим подспорьем. Так проще рассчитать время, необходимое на выполнение поставленной задачи, а так же, пригодится для отчетности.
Когда уходите на перерыв или домой, просмотрите что необходимо еще сделать. Когда перед Вами не будет кода и в памяти будет «висеть» задача, Вы заметите появление свежих оригинальных мыслей, даже если не будете намеренно думать о способе решения. Особенно такой прием подходит для сложных задач. Не говоря о пустяковых, конечно.
Как изучить/разобраться в чужом PHP коде?
XDebug.
Ставится брекпойнт, изучаются трейсы. Повторяется.
Хороший код понять очень быстро таким способом.
Еще очень помогает чтение тестов.
OnYourLips не все занимаются аутсорсом, иногда просто надо.
Я посмотрел бы как бы Вы дебажели T-Mobile платформу биллинга, если у неё таймаут 6 секунд, или какую либо распределённую систему с фалт толерансом.
Но вообще, в клиент-серверах очень часто просто нельзя пользоваться точками останова в принципе. И именно по этому, у людей, для которых э то не есть проблема такие высокие hourly rate.
У ТС речь идёт о «изучения и понятия работы чужого кода», «cофт показывающий диаграммы функций/классов». xDebug в ЭТОМ точно поможет, да и xdebug больше чем дебагер.
Есть средства для слежения за качеством кода — различные тесты, phpcs, phpmd, phploc, phpcpd, но ничто не может ГАРАНТИРОВАТЬ качество кода, это касается не только php, но и других языков, в том числе и со статической типизацией.
По методике:
Я начинаю изучение фреймворков с точки входа (скрипта, который вызывается при получении HTTP запроса, в случае веб фреймворка). Смотрю на возможные пути дальнейшего выполнения кода в этом входном скрипте. Затем изучаю каждый из путей выполнения, доходя до точки завершения работы этого пути (т.е. изучаю от входа к выходу, сверху вниз). Пытаюсь понять предназначение каждого из путей и участков кода, которые на этом пути встречаются. В итоге пытаюсь понять как данный фреймворк вписывается в известную мне модель работы веб технологий (HTTP и т.п.), какая часть фреймворка предназначена для устранения дублирования кода и т.п.
По софту:
Для статического анализа кода поищите по запросам «php reengineering», «php reverse engineering». Обратный инжинеринг PHP кода есть, например, в Enterprise Architect: www.sparxsystems.com.au/platforms/php_uml.html
Для динамического анализа кода можете с помощью xdebug сделать профилирование вызова и на основе полученного файла построить граф с помощью специальной программы (например, KCacheGrind). Подробнее здесь: xdebug.org/docs/profiler
Ещё ссылки на некоторые инструменты: stackoverflow.com/a/4156265/925775 (мне там приглянулся PHP Call Graph)
P.S.: по софту мог где-то ошибиться, т.к. нет большого опыта в использовании описанных инструментов.
Спасибо за ссылку на напоминание о Enterprise Architect. Интересно, можно ли этим вообще пользоваться на больших проектах?
К примеру, можно ли с помощью этого инструмента определить
1) «возможен ли вызов метода X из метода Y (через любое количество промежуточных вызовов и вывести пути вызовов)?
2) Возможно ли изменение переменной\свойства X из метода Y (через любое количество промежуточных вызовов и вывести пути вызовов )»
3) Какие максимальные side-effect существуют при вызове метода X
И тому подобное. По красивым картинкам трудно искать сайд-эффекты в чужих программах.
Средств статистического анализа толковых для PHP просто нет. Да и теоретически не во всех случаях это возможно.
Для похожей задачи на PHP3 г;%:?*коде я сделал следующую поделку:
Используя Tokenizer Залил 2 таблички:
functions: id, className, funcName, fileDef, lineDef
ussage: functionsID, calledFunctionsId
inherit: parentClassName, chieldClassName
После этого с помощью простых SQL мне стало легко искать где и что вызывается.
Поделка решала свою узкую задачу, по этому код её не публиковал. Кому интересно — может сделать толковую.
В дополнение всего вышесказанного хочу порекомендовать простую, но иногда очень полезную, (повторюсь иногда и для специфических задач!) утилитку Strace.
Как разобраться в чужом коде php-сайта?
Есть файлы php, как отдельные части сайта. Где можно узнать, как, каким образом их соединить в единый сайт, если сам к написанию сайта отношения не имел? Подойдет все: книги, статьи и т.д.
3 ответа 3
Учите PHP по книжкам (а не по чужому коду), когда багаж знаний будет большим, то и само собой научитесь разбираться в чужом коде.
Нужно смотреть конкретные php-скрипты. Если в них есть обращение к конкретному серверу (к тому, откуда стырили файл), то нужно заменить эти обращения на адрес своего сервера. Если скрипт работает «сам по себе», то можно просто закинуть его на FTP-сервер вашего сайта. Если скрипт использует какие-то ресурсы сервера, на котором находится (например, открывает картинку /images/image.png), то нужно найти или создать эти ресурсы и залить в соответствующую папку (т.е., в данном примере, создать в каталоге с php-скриптом каталог images и в него залить image.png), но это опять смотреть сам скрипт. Если скрипт связан с другими скриптами с этого сайта, то их тоже нужно скачать и залить на свой сервер. И, конечно же, нужно просмотреть все скрипты и изменить конкретные данные (например, имя сайта, копирайт, и т.п.).
Ну а вообще, что бы «разобраться в чужом коде» (т.е. понимать, что и как этот код делает), нужно для начала знать язык этого кода, в данном случае PHP.
Обычно включал отображение ошибок, в том числе, notice и все их исправлял. Подходит для простых и средних движков, как правило, самопальныхписных. По сложным(типа IPB, drupal) обычно имеется документация.
Используйте продвинутые IDE, они помогут сообразить где чего и откуда берется.
Ну, да, требуется знание PHP, этого не отнимешь. =)
Не судите чужой код строго
Так сложилось что большую часть своей сознательной жизни я программирую на PHP. Наш мозг, воспринимая информацию из любого источника, делает это без отрыва от авторитетности этого источника. Грубо говоря, если вы любите PHP — вы автоматически добавили очков авторитетности автору этой статьи, а если не любите — автоматически отняли. Этот процесс происходит на бессознательном уровне и является по сути призмой восприятия, которая с одной стороны защищает нас от падения в бесконечный анализ информации любой степени авторитетности, но с другой стороны ограничивает нас в поиске новой более актуальной информации. Самое поганое здесь то, что авторитетность источника редко когда проверяется на сознательном уровне (потому что на это нужны время и ресурсы в виде драгоценных калорий), я могу быть с той же долей вероятности разработчиком плюсов, домохозяйкой-кухаркой, водопроводчиком без принцессы или генетически модифицированным котом. Не судите мою статью строго, у меня лапки.
То же самое относится к чтению чужого кода: если его автор сидит по левую руку от вашего трона, работает в вашей фирме 10+ лет и зарабатывает на один ноль больше вас, это совершенно не то же самое, что автор, которого уволили за что-то плохое, а вас наняли на его место. Но по сути то и там и там код — это всего лишь набор байтов, которые было бы полезно оценивать без привязки к авторитетности источника.
Когда мы читаем чужой код, нас могут посещать самые разнообразные эмоции: восхищение, смех, раздражение, разочарование, полное неприятие. Полезно знать о том что проявление любых эмоций в любом контексте — это автоматический ответ низшего (первого) уровня нервной системы, сформированный эволюционным путем, необходимый в первобытной среде. Основная задача такого ответа, в случае «негативной» эмоции — запустить механизм действий «бей или беги» с одной единственной целью — выжить. В нашей текущей офисной среде при анализе чужого кода подобный ответ становится скорее бесполезным и даже вредным, поскольку вы тратите на него драгоценное время и ресурсы, плюс загрязняете свой мозг нейромедиаторами, понижающими вашу сообразительность в угоду скорости реакции. Хорошая новость в том что этот ответ можно перепрограммировать. Можно подавлять негативные эмоциональные реакции, а можно их инвентировать, например, смеяться там где вы раньше злились. Смех, в отличие от злости, выбрасывает в мозг хорошие вкусные полезные нейромедиаторы, доставляющие удовольствие, закрепляющие опыт и мотивирующие на дальнейшую работу.
Для того чтобы перепрограммировать эмоцию, нужно мысленно выйти в мета-позицию, чтобы вместо осуждения чужого кода оценить собственную обстановку, оценить себя. Почему этот кусок чужого кода вызывает во мне отвращение? Действительно ли дело в том что его писал дилетант, а мне такому хорошему и опытному теперь приходится страдать? Если я такой хороший и опытный, то почему у меня возникают проблемы с тем чтобы понять чужой код и переписать его так как я считаю нужным? Возможно мне просто не хватает оперативной памяти для того чтобы осознать эту лапшу? Возможно автор этого куска знает что-то чего не знаю я?
Современные средства разработки позволяют практически на лету преобразовывать чужой код в более понятные и приятные структуры. Функция или переменная плохо названа — ctrl+shift+R и в пару секунд она называется по хорошему. Табуляции вместо пробелов, неудобно, непривычно раскиданы отступы и открывающиеся бракеты в египетском стиле — ctrl+shift+F и форматирование восстановлено! Комментарий избыточен или устарел — ctrl+D и его нет. Если изменить призму восприятия, чтение чужого кода может превратиться в увлекательную интерактивную детективную игру.
Код это всего лишь инструмент. Как бы плохо и ужасно он не был написан, в конкретное время и в конкретном месте он успешно решал конкретную проблему, а значит он уже «оправдан». Что-то изменилось в бизнес-требованиях, что то было не учтено — код поломался или стал не актуален, и это нормально. Код имеет свойство эволюционировать самыми разными путями: и постепенно, обрастая пластами и революционно, переписываясь с нуля. Конечно хорошо, когда программист предвидит будущее и на начальных этапах закладывает в код возможности для дальнейшего его развития. Но эта секира остра с двух сторон, вы можете ошибиться с предсказыванием будущего, будущее может не наступить вовсе, а время и ресурсы будут безвозвратно утеряны. Тут важно понимать код какой степени качества от вас требуется. Если это огромная распределенная система, модули к которой программируют ваши коллеги из самых разных точек земного шара в фирмах слабо связанных с вашей, тогда да, имеет смысл использовать модные паттерны, оборачивать модули в сервис-контейнеры даже там где вы не можете себе представить зачем это нужно. Но если это маленькая локальная CRM для одной фирмы, модули которой зависят друг от друга настолько жестко, что отключение любого модуля по сути ведет к остановке работы всей системы… в этом случае вполне оправданно вызывать чужие методы напрямую, это уменьшит количество классов, облегчит вашу оперативную память и сократит время на отладку проблем. Но вот возникает ситуация когда маленькая локальная CRM превращается в нечто расширяемое, что ваша фирма хочет выложить в открытый доступ и продавать. Бизнес-требования изменились. Стоит ли винить программиста в том что он не предвидел этого?
Стандартизация
Код это всего лишь инструмент, но его создание — это чистое творчество. Любую задачу можно решить бесконечным числом самых разнообразных способов. Некоторые из них более производительны, чем другие — пример объективной оценки. Некоторые из них более читабельны, чем другие — пример субъективной оценки. Даже если вы убедите весь офис в том что какой-то кусок кода не читабелен, все еще останется как минимум один автор, который с вами не согласится. Стандартизация кода направлена на то чтобы преобразовать чистое творчество в как можно более рутинный набор действий для того чтобы другим программистам было проще разбираться в вашем коде. То есть, по сути, чтобы вас можно было заменить другим специалистом, более покладистым и дешевым. А через пару десятков лет так и вовсе искусственным интеллектом. Стоит помнить, что если какой-то стандарт противоречит здравому смыслу, возможно его имеет смысл нарушать в некоторых местах, а то и вовсе отказаться от него или заменить на другой, более подходящий.
Матёрые стандарты продают себя с позиции «при выборе стандарта обратите внимание на популярность сообщества». Интересно как они продавали себя когда только-только вышли в свет. Основная мысль в том, что популярность того или иного стандарта это не тот фактор, который вы бы хотели учитывать в первую очередь при выборе. Популярность и сообщества очень инертны и могут на протяжении многих десятилетий отвергать новые более хорошие стандарты. Особенно если они революционны.
Аналогичные примеры встречаются сплошь и рядом и в культуре программирования. Стандарт PSR ратует за 4 пробела вместо табуляции, игнорируя очевидный факт: среда разработки большинства PHP-программистов изменилась с консольных редакторов на полноценные IDE, в которых оперировать табуляциями удобнее во многих смыслах: и удалять проще, нажимая Backspace один раз, и настроить можно индивидуальную длину табуляции по вкусу.
Применяя тот или иной стандарт задавайтесь вопросом: кому вы делаете удобнее? Кому неудобнее? Кому станет лучше от правила «именуем имена методов лоуерКамелКейсом»? Очевидно лишь тем, кто привык их так именовать. Всем остальным станет неудобно, им придется адаптироваться, а это потери времени и ресурсов абсолютно на пустом месте, учитывая то что
а) теперь у нас есть волшебные IDE, подсвечивающие разными цветами разные элементы кода,
б) программисты имеют свойство перескакивать с проекта на проект, стандарты кодирования в которых могут различаться.
Лично я при разработке своих проектов использую:
Умение разбираться в чужом коде
Триггер, вызывающий рвотные порывы у подавляющего большинства программистов (пример субъективной оценки). Вам никогда не казалось странным, что зачастую нам проще переписать весь код с нуля, чем разбираться в чужом? В любой другой отрасли мы действуем иначе: сперва учимся читать, потом — писать; сперва пользоваться (электроприборами, зданиями), затем — их проектировать. Мне кажется все дело в нашем образовании (конкретно в области программирования). Нас учат достигать цели самым прямым и быстрым способом, используя некоторые свеже-приобретенные знания. В результате мы комбинируем их (знания) ровно до тех пор пока «оно» не заработает, немного тестируем и отправляем учителю на модерацию. На мой взгляд было бы неплохо добавить в этот процесс дополнительную ступень, на которой мы сравниваем наш код с мастер-кодом, который хоть и не является идеальным и единственно правильным, но дает альтернативный путь решения, зачастую более оптимальный и читабельный.
Что касается триггера, чтобы его отключить, достаточно просто мысленно поставить себя на место заказчика, который всю свою жизнь наблюдает за уходящими-приходящими программистами, утверждающими что работа их предшественников это фекалии и нужно все переписать чтобы стало хорошо. Заказчик не обладает компетенцией чтобы выяснить говорите ли вы правду или просто ленитесь разбираться в чужом коде. Чтобы завоевать его доверие в подобном вопросе, следует покопаться в чужом коде и найти парочку гигантских дыр в безопасности и продемонстрировать их заказчику. Но даже в этой ситуации с точки зрения бизнеса, возможно, будет выгоднее «закостылить». Особенно если это аутсорс с конкретными сроками и деньгами. Нужно ли винить программиста в этом?