как разбираться в чужом коде
5 простых правил удобного для восприятия кода
Задаетесь вопросами: «Как написать чисто, понятно? Как быстро разобраться в чужом коде?»
Вспомните о приведенных ниже правилах и примените их!
В статье не рассматриваются базовые правила именования переменных и функций, синтаксические отступы и масштабная тема рефакторинга. Рассматриваются 5 простых правил по упрощению кода и снижению нагрузки на мозг в процессе разработки.
Рассмотрим процесс восприятия данных, чтобы соотнести описанные правила с процессом восприятия и определить критерии простого кода.
Упрощенный процесс восприятия состоит из следующих этапов:
Ученые разделяют память на кратковременную и долгосрочную. Кратковременная память мала по объему, но извлечение и сохранение информации выполняет мгновенно. Кратковременная память — кэш мозга. В нем может храниться 7+-2 слов, цифр, предметов. Долгосрочная память больше по объему, но она требует больших затрат энергии (усилий) на сохранение и извлечение информации, чем краткосрочная.
Правило 1. Используем в условиях утверждение, избавляемся от «не».
Удаление оператора «не» уменьшает количество анализируемых элементов. Также, во многих языках программирования для оператора отрицания используется «!». Данный знак легко пропустить при прочтении кода.
Правило 2. Уменьшение уровня вложенности.
Во время анализа кода каждый уровень вложенности требуется удерживать в памяти. Уменьшаем количество уровней – уменьшаем затраты мыслетоплива.
Рассмотрим способы уменьшения количества уровней вложенности.
1) Возврат управления. Отсекаем часть случаев и сосредотачиваемся на оставшихся.
Расширенный пример приведен в правиле 5. Обратите внимание на выброс исключения.
2) Выделение метода. Имя функции — результат обобщения.
3) Объединение условий.
4) Вынесение переменных и разделение на смысловые блоки. В результате блоки можно изменять независимо, а главное читать и воспринимать такой код гораздо проще. Один блок – одна функциональность. Частый случай — поиск с обработкой. Необходимо разбить код на отдельные смысловые блоки: поиск элемента, обработка.
Правило 3. Избавляемся от индексаторов и обращений через свойства.
Индексатор — операция обращения к элементу массива по индексу arr[index].
В процессе восприятия кода, мозг оперирует символами [] как разделителями, а индексатором как выражением.
Индексатор — место частых ошибок. В силу кратких имен индексов перепутать I, j или k очень легко.
В приведенном выше примере в строчке result[fieldsGroups[j].groupName] = <>; допущена ошибка:
используется j, вместо i.
Для того, чтоб обнаружить где используется именно i-тое значение приходится:
1) визуально выделять переменную массива
2) анализировать каждое вхождение на использование нужного индексатора I,j, i-1, j-1 и т.д., держа в восприятии места использования индексаторов и уже отождествленные обращения.
Выделив индексатор в переменную, сократим количество опасных мест и сможем легко задействовать мозг на восприятие переменной, без необходимости запоминания.
Визуальное выделение происходит гораздо проще, а современные среды разработки и редакторы помогают, выделяя подстроки в разных участках кода.
Правило 4. Группируем блоки по смыслу.
Используем психологический эффект восприятия — «Эффект близости»: близко расположенные фигуры при восприятии объединяются. Получить код, подготовленный для анализа и обобщения в процессе восприятия, и сократить количество информации, сохраняемой в памяти, можно расположив рядом строки, объединенные смыслом или близкие по функционалу, разделив их пустой строкой.
В верхнем примере 7 блоков, в нижнем 3: получение значений, накопление в цикле, установка свойств менеджера.
Отступами хорошо выделять места, на которые стоит обратить внимание. Так, строки
помимо зависимости от предыдущих вычислений, накапливают значения в переменной accumulatedPercentage. Для акцентирования внимания на отличии, код выделен отступом.
Одним из частных случаев применения правила является объявление локальных переменных как можно ближе к месту использования.
Правило 5. Следование принципу единственности ответственности.
Это первый из принципов SOLID в ООП, но помимо классов может быть применён к проектам, модулям, функциям, блокам кода, проектным командам или отдельным разработчикам. При вопросе кто или что отвечает за данную область сразу ясно — кто или что. Одна связь всегда проста. Каждый класс обобщается до одного понятия, фразы, метафоры. В результате меньше запоминать, процесс восприятия проходит проще и эффективнее.
В заключении комплексный пример:
После замены индексаторов ContainsKeу, инвертирования ветвления, выделения метода и уменьшения уровней вложенности получилось:
Первая функция отвечает за получение состояний из словарей, вторая за их комбинирование в новое.
Представленные правила просты, но в комбинации дают мощный инструмент по упрощению кода и снижению нагрузки на память в процессе разработки. Всегда их соблюдать не получится, но в случае если вы осознаете, что не понимаете код, проще всего начать с них. Они не раз помогали автору в самых затруднительных случаях.
Как быстро вникнуть в чужой код?
я гоняю код профилировщиком, получаю карту выполнения кода и изучаю их.
плюс ИДЕ для удобной навигации.
такой подход закрывает большинство вопросов.
при затыках иду штормить окружающих. но не раньше собственных попыток въехать.
Привет всем сторонникам самодокументирования
По идее у вас должна быть вика с описанием архитектуры и списка методов
При подключении к проекту только просматриваете комменты и понимаете как оно работает
Если же нужно рефакторить то начинайте с комментов дальше прочитайте метод три раза
Первый бегло
Второй раз вдумчиво с анализом где баг
Третий где что исправить
Потом уже начинайте писать код
Кстати поэтому хорошо получать пачку багов тогда у вас код не уйдёт из головы и вы быстрее все перепишите
Многозадачность она сложная как для компов так и для людей
должна быть вика с описанием архитектуры
Как быстро разобраться в чужом кодировании и полноценно влиться в проект?
Если коротко, никак. И это как правило не нужно(выстрел в ногу).
Если менее коротко:
При трудоустройстве компания закладывает n-ное количество времени\денег для того что бы вы аккумулировали свой опыт и знания на проект, т.е постепенно влились в командную разработку путем чтения документация, настройки окружения, и тому подобного. В зависимости от проекта, может занимать от пары месяцев, до полугода(если мы говорим про крупный проект кровавого интерпрайза).
Чужой код: краткий ликбез по использованию
Что нужно знать об авторских правах на исходники, чтобы не было мучительно больно и стыдно.
Профессионалы уважают чужой труд, особенно если он облегчает им жизнь. Мы выяснили, как быть с чужим кодом студенту, сотруднику компании, бизнесмену и разработчику открытого ПО, а ещё — провели почти серьёзный мини-опрос среди программистов. Результаты в конце статьи.
Спойлер: особых открытий нет, лицензия рулит.
Самое главное: автор, правообладатель, лицензия
С точки зрения закона код — такой же объект авторского права, как книга, рисунок или музыкальное произведение. Что самое важное в авторском праве:
Кроме автора, у кода и произведения искусства могут быть правообладатели, или держатели исключительных прав, — например, издательство, киностудия или разработчик ПО. При этом программист, писатель, режиссёр и музыкант остаются авторами.
Если вы написали код в рамках трудового договора с ООО «Крутые Питоняшки», то по-прежнему остаётесь его автором. Но использовать его и получать прибыль могут только «Питоняшки». Так или почти так наверняка написано в договоре — и любой суд с этим согласится.
На практике до переговоров с авторами и правообладателями дело доходит редко. Почти у любого кода есть лицензия, которая ясно говорит: как, для чего и на каких условиях можно этот код использовать. Здесь всё в точности как с изображениями — про них написано в нашей статье о соблюдении авторских прав в дизайне.
С некоторых пор утверждает, что он data scientist. В предыдущих сезонах выдавал себя за математика, звукорежиссера, радиоведущего, переводчика, писателя. Кандидат наук, но не точных. Бесстрашно пишет о Data Science и программировании на Python.
Если вы студент
Выдавать чужой код за свой, чтобы получить нужную оценку, обычно строго запрещено. Преподаватели преследуют плагиаторов — в конце концов, они отвечают за качество диплома, который вы получите. Важен именно ваш уровень написания кода.
Тем не менее плагиат в университетах скорее жив, чем мёртв: «Нью-Йорк Таймс» пишет, что в 2015 году в Стэнфорде читили до 20% студентов, изучающих компьютерные науки.
Использовать чужие исходники — значит подставлять и добросовестных студентов под горячую руку преподов. Их тоже начнут подозревать. Если вы из таких студентов, ловите несколько лайфхаков, которые помогут укрепить репутацию.
Уважайте себя, своих наставников и свою альма матер: старайтесь кодить самостоятельно, если только в условиях задания не указано иное — например, групповая работа или парное программирование. Тем более что у преподавателей есть куча продвинутых инструментов — найти плагиат в коде довольно просто. Есть даже серьёзные научные исследования на эту тему.
Если вы работаете в компании
Чаще всего за использование чужого кода отвечает сам сотрудник, и соответствующий пункт нередко включают в договор при найме. Ведь специалист здесь вы — а значит, вы и зарплату получаете за оригинальные решения.
Иногда компании даже требуют от работников подписать сертификат подлинности — в нём вы «зуб даёте», что не только сами написали какой-то фрагмент кода, но и никогда раньше не передавали его другим работодателям. Чувствуете? Это же как раз об отношениях правообладателя и автора.
Правило простое: отслеживайте источник кода и не забывайте уточнять, по какой лицензии он распространяется. Иначе подставите шефа — а шеф такого не любит.
Даже у кода с сайта Stack Overflow есть лицензия: её полное название Creative Commons Attribution-ShareAlike 4.0 International. Вы можете делиться кодом и использовать его для любой цели (бинго! коммерческое применение разрешается) — надо только указать автора, лицензию и поставить ссылку на источник.
Например, добавить что-то подобное на экран или страницу, где конечный пользователь сможет увидеть всю информацию об авторских правах и данные компании-разработчика:
А вот классическая заставка шестого Photoshop с копирайтами: родные сердцу Томас Кнолл, Марк Гамбург и почему-то всё время попадавшийся на глаза Ситха Нарайанан, фамилия которого навевала воспоминания о треке Prodigy с легендарного Fat of The Land.
Если вы владелец бизнеса
Здесь ставки выше: нарушение лицензий, авторских прав и исключительных имущественных прав грозит судебными разбирательствами. А они не только встают в копеечку и отнимают много времени, сил, нервов, но и больно бьют по репутации обеих сторон.
Те же Google и Oracle судятся уже больше десяти лет, приковывая внимание всего IT-сообщества. Суть дела такова: Oracle владеет правами на язык Java, а его используют в экосистеме Android, принадлежащей Google, — пишут миллионы мобильных приложений. На старте корпорации не сумели договориться об условиях использования Java (точнее, его API), и Oracle подал иск почти на девять миллиардов долларов.
Интересно, что Oracle не сами разработали Java: права на язык достались им при покупке легендарной Sun Microsystems.
По мнению экспертов, возможная победа Oracle больно ударит по всей компьютерной отрасли и замедлит общий прогресс. Ведь если на API можно наложить исключительное право, то:
Но ругаются не только западные гиганты — отечественные Иван Ивановичи и Иван Никифоровичи тоже нередко встречаются в судах. Юрист Яндекса Денис Доротенко даже написал большой обзор с историями о плагиате и краже исходного кода. Самый распространённый сюжет — когда сотрудники уносят весь свой код к новому работодателю. По закону это нарушение исключительных прав, поэтому в суде обычно побеждают правообладатели.
К слову, один из популярных ответов на вопрос владельца бизнеса «Как избежать кражи кода» звучит примерно так: «Делайте своих программистов счастливыми и цените их работу». И, знаете, что-то в этом есть.
Если вы делаете open source
Разработка свободных программ с открытым исходным кодом не является волшебным «я в домике» и не защитит от обвинения в плагиате. Мол, я тут Д’Артаньян и Арамис, стараюсь на благо всего мира, а значит, имею право пользоваться любым кодом. Например, разработчикам открытой операционной системы ReactOS регулярно прилетают претензии от Microsoft — и это тормозит разработку операционки. Один из маленьких и мягких инженеров обвиняет разработчиков в краже исходного кода через университетские лицензии — или из внутренней документации компании, таких вот гроссбухов:
8 методов, которые помогают нам (по-настоящему) читать чужой код
Главное меню » Программирование » 8 методов, которые помогают нам (по-настоящему) читать чужой код
Может быть трудно перемещаться по строкам кода и при этом не сойти с ума.
Есть много случаев, когда вам нужно читать чужой код – возможно, вы новичок в работе, и вам передали кодовую базу для усвоения, прежде чем вы начнете создавать свой код. Возможно, вы должны отлаживать компонент, который был разработан не вами. Возможно, вам нужно добавить новую функцию в текущую реализацию.
Вы пытаетесь понять код, но чувствуете себя подавленным и запуганным.
Кто виноват в том, что вы ступаете в сознание другого человека?
Но все мы должны с чего-то начать, и мы хотели бы поделиться с вами методами, которые помогли нам переваривать чужой код.
1. Начните с результатов
Если этот код предназначен для компонента поиска Frontend со сложной системой фильтрации, начните с полного понимания того, как компонент работает, в первую очередь из пользовательского интерфейса. Попробуйте разные варианты, чтобы поиграть с компонентом – посмотрите, как он отреагирует.
Если этот код предназначен для Backend API, который возвращает разные форматы результатов для разных параметров, начните с поиска допустимых параметров разных типов и посмотрите, как ответ API отличается для каждого ввода.
Запишите, что вы хотите узнать о реализации, поигравшись с ней.
Это может быть список предметов, но сосредоточьтесь на чем-то одном, не отвлекайтесь – что вы хотели бы изучить в первую очередь?
Первое, что вы хотели бы изучить во внешнем интерфейсе, может быть текущее поведение, при котором первая полоса фильтра влияет на следующую полосу фильтра, которая влияет на следующую полосу фильтра.
Первое, что вы хотели бы изучить на бэкэнде, – это текущее поведение, когда, если мы помещаем элементы этой категории, он возвращает нам вложенную подкатегорию, а другие – плоскую подкатегорию.
Что бы вы ни хотели изучить в первую очередь, вы должны быть голодны, чтобы узнать, как это достигается.
2. Погрузитесь в нужные файлы, помня о цели
Теперь, когда вы понимаете, как это работает на высоком уровне, играя с конечным результатом и определили то, что вы хотели бы понять, увеличьте масштаб. Если репозиторий логически структурирован с правильным именованием папок и компонентов, вы должны быть в состоянии войти в нужный файл (ы) в кратчайшие сроки.
Григорий Петров: Как и зачем читать чужой код
Тысячи лет практика «посмотреть работу молодого специалиста, ужаснуться, подсказать что-нибудь полезное» помогает нам передавать опыт и знания. Нужно ли говорить о том, что более опытным разработчикам необходимо читать код своих начинающих коллег и помогать им советами? Это же очевидно и все об этом знают? Или нет?
В одной из первых статей я уже писал про code review, настало время рассказать подробности. Тысячи лет практика «посмотреть работу молодого специалиста, ужаснуться, подсказать что-нибудь полезное» помогает нам передавать опыт и знания. Нужно ли говорить о том, что более опытным разработчикам необходимо читать код своих начинающих коллег и помогать им советами? Это же очевидно и все об этом знают? Или нет?
Давайте вспомним проблемы разработки: Кошелек Миллера, отсутствие фундаментального образования, отсутствие выработанных методик. Написанный разработчиком код — это отражение его ментальных моделей, пропущенное через его личный опыт разработки. А опыт у него уникальный, потому что в университетах не учат разрабатывать программы. Там учат математике, алгоритмам, структурам данных. Алгоритм сортировки у всех будет одинаковый, как в университете научили. Только вот в коде никто не пишет сортировку. Пишут немного другое, а этому не учат.
Легко ли более опытному разработчику читать код, созданный не его ментальными моделями по другому опыту? Четырем из пяти моих знакомых разработчиков это невероятно трудно. Это очень трудно мне. По сути, чтобы действительно понять чужой нетривиальный код, нужно понять, как работает разум другого человека, плюс провести реверсию Кошелька Миллера — разбить картину на последовательность мазков и эскизов, иначе оно просто не влезет в фокус внимания. Странный вывод: если действительно внимательно читать чужой код, то вам для этого потребуются либо уникальные люди (я таких встречал, одного человека), либо опытный разработчик будет тратить на чтение чужого кода примерно столько же времени, сколько автор потратил на его написание.
И это только первые грабли. Есть еще вторые. Так как код является отражением ментальной модели разработчика, то чужой код разработчику в большинстве случаев не понравится! При чтении чужого кода разум будет пытаться воспринять его как свой, пропустить через собственные ментальные модели. Но код — это не книга. Естественный язык допускает множество трактовок каждого предложения, чтобы большинство читателей, пропустив текст через призму своего восприятия, увидели каждый свою картину. С языком программирования все не так: программист будет всегда видеть чужую картину, слепок работы чужого разума. И это ему не понравится. Отсюда нелюбовь разработчиков разбираться в чужом коде и инстинктивное желание «все переписать с нуля».
Что читать
Получается, читать чужой код — слишком сложно? Не совсем. Внимательно читать чужой код сложно. Но для того, чтобы чтение кода принесло пользу, не обязательно читать его внимательно! Ведь важные вещи: архитектура, уровень сложности, соблюдение стандарта кодирования — можно проверить и при быстром просмотре чужого кода. Именно в этом кроется контринтуитивный секрет code review: не нужно внимательно читать все. Опытные разработчики, делая code review, быстро просматривают код в поисках подозрительных моментов, не пытаясь понять каждую строчку и разобраться в хитросплетениях борьбы автора со сложностью. Если что-то привлекло внимание — то на это смотрят внимательнее. Если нет — специально не ищут. Действительно опасные проблемы с архитектурой и скопления сложности видны опытному разработчику сразу. Остальное покажу тесты. У вас ведь есть тесты?
Конечно, ситуации бывают разные. Для медицинского софта особо важные участки кода могут построчно ревьювить сразу несколько разработчиков — слишком высока цена ошибки. Но, в большинстве случаев, главная задача code review — избежать ситуации, когда опытный разработчик тратит все свое время на очень внимательный review кода двух-трех джуниоров, и в конце дня гордо говорит — » посмотрите, сколько я у вас нашел багов!». Нашел, молодец. Но сколько на это было потрачено времени и сил? Стоило ли оно того? Плюс не забываем о микроменеджменте — свой мозг в чужую голову не установить.
Что не читать
Половина разработчиков, с которыми я регулярно общаюсь, считают, что чтение кода — это важный и ценный навык, который можно и нужно тренировать. С одной стороны, это действительно так. Совсем не читать чужой код нельзя — начинающие разработчики не получат ценный опыт, а опытные — упустят превращение проекта в гнездо лапши с последующим приходом сложности в лице толстой полярной лисички. Другой вопрос — нужно ли тратить годы на развитие этого навыка до уровня «быстро прочитал тысячу строк чужого кода, все понял, нашел пять багов и два архитектурных косяка?». Наш мозг — это не компьютер с бесконечным жестким диском. Обучаемся мы медленно, а неиспользуемые навыки забываются быстро.
Если в команде есть спец, любящий и умеющий читать чужой код — вам повезло. Но вот специально тренировать такие навыки? Наш мозг не очень хорошо приспособлен для «проигрывания» чужого кода, поиска в нем багов и ошибок в алгоритмах. Для этого есть автоматика.
Автоматика спешит на помощь
Тим лид знает, что читать чужой код тяжело. Тим лид знает, что читать чужой код необходимо. И чтобы не расслаблялись, и чтобы вовремя отследить уползшую «не туда» архитектуру, и чтобы опыт передавался. Из всего, что я видел, хорошо зарекомендовал себя комбинированный подход. Код читается, но очень быстро, для поиска страшных, видных на первый взгляд проблем. Чтобы оценить его «читаемость» другим человеком. А все остальное: стандарт кодирования, баги, логика работы, эффективность и множество других параметров проверяет автоматика. У вас ведь не только тесты есть, но и автобилд?
Удобно следовать простому правилу: все, что может отревьювить автоматика пусть ревьювит автоматика. Человеку остается проверять то, что не может проверить автоматика: как читается код, насколько он понятен, насколько архитектура соответствует задумкам тим лида. Тогда и овцы будут сыты, и волки целы, и пушная полярная лисичка не так часто прибегать будет.