Rivalry2

HTML Diff

0 added 0 removed

Original 2026-01-01

Modified 2026-02-26

1 <p><strong>Каждому программисту рано или поздно предстоит разобраться в чужом коде, однако не все это делают правильно. Мы перевели<a>статью</a>разработчика Уильяма Шона и узнали, как читать чужой код так, чтобы понимать его и выносить из этой практики что-то новое.</strong></p>

2 <blockquote><p>Вы читаете обновленную и улучшенную версию нашей старой статьи</p>

3 </blockquote><h2>Содержание</h2>

4 <ul><li><a>Почему разработчики не любят разбираться в чужом коде</a></li>

5 <li><a>Как правильно читать код</a></li>

6 <li><a>Итог</a></li>

7 </ul><h2>Почему разработчики не любят разбираться в чужом коде</h2>

8 <p>"Ненавижу читать чужой код", - такую фразу можно часто услышать от программистов. Причина их ненависти в том, чужой код пишут не они. Это не значит, что каждый разработчик страдает манией величия, все гораздо проще: читатель никогда не испытает того потокового состояния, в котором находился программист, когда создавал свой код. Поэтому пассивное чтение иногда бывает скучным.</p>

9 <p>Читатель может не осознавать, что видит на экране труд нескольких разработчиков. Возможно, они спорили во время кодинга, и он дался им нелегко. Возможно, разработчикам потребовались недели, чтобы выдать код, который обходит недокументированные ограничения. Читатель имеет дело с законченным продуктом и даже не догадывается, что стоит за многократно выверенными строками кода.</p>

10 <p>Рано или поздно у разработчика наступает момент, когда ему предстоит читать чужой код. Например, когда программисту нужно изменить или обновить существующий код, провести код-ревью, разобраться в работе программного интерфейса. Для этого нужно знать, как читать и понимать чужой код. Это умение полезно и тем, кому только предстоит освоиться в кодовой базе. Разберемся, на что обратить внимание при чтении чужого кода, чтобы понять его и, возможно, чему-то научиться.</p>

11 <h2>Как правильно читать код</h2>

12 <h3>Научитесь проводить "раскопки" в коде</h3>

13 <p>При первом знакомстве с серьезной кодовой базой вы будете ощущать себя не разработчиком, а археологом, частным сыщиком или исследователем религиозных книг. Вам придется проводить "раскопки" в чужом коде, чтобы понять, как он создавался.</p>

14 <p>Если вы работаете над кодовой базой, в которой разработчики использовали контроль версий, то у вас есть доступ к метаданным. Изучите следующие команды для Git, чтобы узнать, как изменялся код (они подойдут и для SVN):</p>

15 <h3>git blame</h3>

16 <p>С помощью этой команды вы узнаете имя автора кода, дату последних изменений и хэш коммита (зафиксированного изменения в коде) для каждой строки. Так можно найти историю кода и понять, какой именно код был внесен в репозиторий, как это было сделано и по какой причине. Если это возможно, познакомьтесь с авторами кода: они постараются ответить на ваши вопросы.</p>

17 <p>Читая код, убедитесь, что вы понимаете, где он начинает выполняться и что происходит в процессе его запуска. Посмотрите, какие файлы подключаются, какие классы используются, какие опции конфига устанавливаются. Скорее всего, вы будете постоянно сталкиваться с ними во всей кодовой базе.</p>

18 <p>Некоторые модули могут выделяться из остального кода и иметь очень общее назначение. Выполните git blame и посмотрите, какие части основного файла недавно изменяли. Так вы узнаете проблемы, которые решала команда в последнее время. Возможно, разработчики долго пытались наладить библиотеку, которая не слишком хорошо работала. Может, там просто шаблонный код, который нужно регулярно обновлять.</p>

19 <p>Попробуйте найти примеры таких выделяющихся модулей в других частях кода, чтобы узнать, как и когда они используются. Это поможет вам понять место и роль модулей в основном приложении.</p>

20 <h3>git log и git grep</h3>

21 <p>Используйте команду git log, чтобы увидеть историю коммитов по всему репозиторию. Команда git grep поможет вам найти в коммитах конкретный текст, например, название функции someFunction: git log | grep someFunction -C 3. Последние флаги покажут вам найденные выражения с тремя строками окружающего контекста.</p>

22 <p>Также git log может показать вам историю отдельного файла. Чтобы ее посмотреть, используйте флаг -p: git log -p index.js. Обращайте внимание на имена авторов коммитов, чтобы знать, кому в будущем адресовать вопросы.</p>

23 <blockquote><h3>Читайте также:</h3>

24 <p>Фильтр Блума: зачем нужен и<a>как работает</a></p>

25 </blockquote><h3>Переключайтесь между коммитами и изучайте историю кода</h3>

26 <p>Вы можете переключиться на любой коммит и запустить проект так, будто этот коммит был последним. Как правило, это делают для того, чтобы выявить сложно отслеживаемую проблему. Также коммиты переключают, чтобы увидеть историю кода.</p>

27 <p>Если проект хранится на GitHub или подобном сервисе, вы можете узнать много нового, читая пулл-реквесты и код-ревью. Обращайте внимание на тикеты - карточки-задачи для отслеживания работы над багами, внедрения функций. Читайте обсуждения в тикетах: там могут быть "болевые точки", с которыми вы можете столкнуться в будущем, поэтому лучше иметь представление о них заранее.</p>

28 <h3>Читайте спецификации</h3>

29 <p>Specs или спецификации - это новые комментарии к коду. Читайте unit specs, чтобы выяснить предназначение функций, модулей и возможные пограничные случаи (edge-cases), которые они обрабатывают.</p>

30 <p>Также читайте интеграционные спецификации, чтобы понять, как пользователи будут взаимодействовать с вашим приложением и какие процессы оно поддерживает.</p>

31 <h3>Воспринимайте комментарии как подсказки</h3>

32 <p>Если в процессе изучения кода вы наткнулись на непонятную функцию и прочли комментарий к ней, который еще больше вас запутал - возможно, он просто устарел. Держите это в голове: если комментарий к функции давно не обновлялся, вероятно, она исчезла уже много месяцев назад, и кроме вас это никто не заметил.</p>

33 <h3>Обращайте внимание на стиль написания кода</h3>

34 <p>Читая чужой код, посмотрите, соблюдены ли стандарты его оформления, есть ли именования, пробелы, скобки. Обратите внимание на общий уровень абстракции кода. Если у него много уровней абстракции, то вам следует их использовать и в своем коде.</p>

35 <p>Если вы хорошо провели "раскопки", то нашли момент, когда один из разработчиков решил абстрагировать часть кода. Вспомните, как код выглядел до этого изменения и задумайтесь, что с ним стало после выноса на новый уровень абстракции.</p>

36 <p>Работая над проектом, посмотрите, какие конструкции используют разработчики из вашей команды. Если они отдают предпочтение циклам, а не функции map, то и вам следует их использовать. Если вам не нравится стиль оформления кода в проекте, обсудите это с командой - это лучше, чем смешивать разные стили в одном файле. Хороший код выглядит так, будто он написан одним человеком.</p>

37 <h3>Избавляйтесь от "мусора" в коде</h3>

38 <p>Пока вы читаете код, вам могут встретиться функции и целые файлы, которые разработчики никогда не используют, и комментарии, на которые никто не отвечал несколько лет. Не тратьте на разбор всего этого много времени - избавьтесь от "мусора". Если этот код все еще нужен, кто-нибудь отметит это на код-ревью. Удалив ненужное, вы сбережете силы и время того, кто будет читать этот код после вас.</p>

39 <h2>Итог</h2>

40 <p>Не падайте духом, если чувствуете, что вы совсем запутались в чужом коде. Изучение кода - это не линейный процесс. Не ждите, что сразу поймете все на 100%. Обращайте внимание на важные детали, проводите "раскопки", чтобы найти ответы на вопросы, и, надеемся, все станет понятнее.</p>

41 <blockquote><h3>Никогда не останавливайтесь:</h3>

42 <p>В программировании говорят, что нужно постоянно учиться даже для того, чтобы просто находиться на месте. Развивайтесь с нами - на Хекслете есть<a>сотни курсов по разработке на разных языках и технологиях</a></p>

43 </blockquote>