Как научиться читать код сайта и зачем это нужно, если вы не программист
Кажется, что программирование — это сложно, особенно если никогда не приходилось с ним сталкиваться. На самом деле всё зависит от задачи. Чтобы вносить небольшие изменения на сайт, хватит и азов, а их может освоить даже человек без технического образования. Об этих азах и пойдет речь в статье. Расскажем об устройстве исходного кода, о том, как начать в нём немного разбираться, и ответим на вопрос, зачем всё это вам нужно.
Примечание: мы не будем лезть в дебри и подробно описывать процесс программирования. Расскажем о том минимуме, что пригодится в работе над вашим сайтом.
Зачем понимать исходный код
Сначала поговорим о том, зачем вам нужно что-то знать о коде, если вы не программист. Да, здорово расширять свои границы. Но главное, что вы можете получить из этого знания — пользу для бизнеса.
Зная, как устроен исходный код, вы сможете:
Если просто смотреть на страницу сайта, вы не сможете проанализировать, правильно ли настроено SEO-продвижение, а инструменты для анализа не всегда могут быть под рукой. Только в коде проверяют, на месте ли метаданные и обязательные элементы — основная информация для успешного SEO. Поэтому заглядывать в исходный код становится обычной практикой маркетологов или владельцев бизнеса, которые сами занимаются продвижением.
Плюс вам больше не будет казаться магией работа SEO-специалиста. Вы будете говорить на одном языке и понимать, как поисковики видят ваш сайт и что можно улучшить.
Если вы решите проанализировать сайты конкурентов, немного разбираясь в коде, вы сможете оценить не только визуальную и контентную стороны страниц. У вас получится определить, с помощью каких ключевых слов продвигается сайт, на какой CMS работает и немного больше понять стратегию продвижения конкурентов.
Вам будет легче представить и объяснить разработчику, как вы видите свою задумку. А значит, на финальной стадии работ не окажется, что всё сделано не так, а деньги и время уже потрачены.
Когда программист будет объяснять вам, в каких правках нуждается сайт компании, вы всё поймёте и сможете на равных обсудить это с сотрудником. Вам будет проще нанимать человека на IT-должность и разбираться в сметах на обслуживание сайта.
Экономнее изучить азы программирования и быстро устранять проблемы самостоятельно вместо того, чтобы нанимать программиста для выполнения небольших, но частых задач. Например, менять размеры баннеров или цвет текста на странице.
Что такое исходный код сайта
Национальная библиотека им. Н. Э. Баумана говорит, что исходный код — это текст компьютерной программы, который может прочитать человек, на языке программирования или языке разметки.
Именно код скрывается за внешней стороной любой интернет-страницы. Он выглядит как список пронумерованных строк с информацией о том или ином элементе страницы.
Как посмотреть код любого сайта
Расскажем, как посмотреть исходный код страницы в браузере Google Chrome. В остальных браузерах этот процесс примерно такой же.
Код вызывается одной из комбинаций:
Панель с кодом откроется на этой же странице, а не в другом окне. При наведении мышки на код будет подсвечиваться соответствующая ему область на текущей странице.
Дальше в статье мы будем пользоваться именно этим инструментом — он нагляднее.
Чтобы не утонуть в огромном количестве новых символов, нужно разобраться, что такое HTML, CSS и JavaScript.
Что такое HTML
HTML — язык гипертекстовой разметки. На нём написано большинство сайтов в интернете.
Что можно узнать о сайте из исходного кода
Код сайта предназначен в первую очередь для браузера и поисковых систем. Браузеру он говорит, что и в каком порядке выводить на странице. Поисковые системы берут из исходного кода всю информацию о странице: заголовок, описание, метаданные — всё то, что потребуется, чтобы показать страницу в выдаче поисковика. Обычный пользователь тоже может прочитать этот специальный текст — достаточно знать, как он устроен.
Все элементы кода нужны для правильного расположения разделов и деталей страницы. Всё это вы сможете найти и проанализировать, внимательно изучив исходный код сайта:
Чтобы лучше понять теорию, разберёмся в коде страниц блога RU-CENTER: найдём теги, картинки и другую информацию.
Для начала открываем страницу и вызываем интерактивный код (Ctrl + Shift + I). Откроется интерактивная панель с кодом, поделённая на две области. Слева — HTML-код (вкладка Elements), справа — CSS (вкладка Styles). Нам пока нужна левая часть с HTML.
Основные теги
HTML-страница состоит из набора тегов, которые вместе с содержимым называются элементами — это строительный материал веб-страницы. Другими словами, теги — команды для браузера, чтобы он понял, как нужно показывать сайт пользователю. Указывая в коде определенные теги, вы говорите браузеру: «Это текст, а это картинка, это ссылка, а это кнопка или форма». И браузер показывает все элементы интерфейса так, как вы их разместили.
Теги обычно открываются и закрываются так: — открытие тега, — закрытие.
Теги делятся на два вида: блочные и строчные.
Как читать код: 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. Оригинал здесь.
Ломаем хаКс полностью. Читаем машинные коды как открытую книгу
Если haXe оттранслирован в C++, а из него — в машинные коды, это может показаться безнадёжным, тем более, на первый взгляд этот код пестрит вызовами виртуальных методов, которые, не запуская отладчик, трудно соотнести с адресами тел методов.
Но всё не так уж плохо. Даже при отключенной поддержке сценариев (HXCPP_SCRIPTABLE) в файле можно обнаружить строки с названиями методов и полей. Разбираем, как можно размотать этот клубок, сопоставить имена методов с их адресами и смещениями в таблице виртуальных методов.
Немного теории
После трансляции в C++ все классы haXe наследуются от hx.Object (определён в hxcpp/include/hx/Object.h). Особый интерес представляют следующие методы:
Эти методы переопределяются в классах, оттранслированных в C++, и реализация их везде выглядит примерно так:
Как можно видеть, полями в понимании транслятора хаКс оказывается не только то, что обычно считается полями, но и методы тоже, правда, в динамических обёртках, из которых их ещё предстоит вытащить.
Подготовка
Соответственно, начинать стоит с того, чтобы найти метод __Field. Например, в него можно попасть по обратной ссылке на строку с именем метода. Если почитать, какие в файле есть строки, то по обратным ссылкам можно попасть, например, в __ToString или RTTI. Из них по обратной ссылке надо перейти в VMT. Если строка является именем поля, то вместо __Field можно попасть в похожий метод __SetField, который хуже подходит, так как там нет ссылок на динамические обёртки для методов. Находясь в VMT, открываем переопределённые методы (выделяются по адресам) и ищем, какие из них похожи на __Field (видно большой switch в начале):
__Field в таблице виртуальных методов идёт раньше, чем __SetField, и вариантов там обычно меньше. В данном примере 13 против 28.
Первый этап: ищем динамические обёртки
Когда найдены оба метода, нужно зайти в __Field, смотреть, куда идёт ветвление после 0 == memcmp и давать имена обёрткам. Попадаться при этом могут как обычные поля, так и обёртки. Научиться отличать их несложно, вот пример сначала обычного поля, потом динамической обёртки для метода:
Встречалась, но не в этом файле, такая проблема, что указатели на обёртки не распознаются. Выглядит это как аномально большой целочисленный операнд оранжевого цвета. Через Ctrl+R его надо в IDA сделать смещением.
Второй этап: самые простые случаи
Для начала посмотрим, как вообще после трансляции в C++ расположены методы и обёртки для них:
Видно, что идёт сначала тело метода, потом макросом конструируется динамическая обёртка, потом следующий метод, потом динамическая обёртка для него и так далее. Поскольку обёрткам имена на первом этапе дали, а собственно методам — ещё нет, в списке подпрограмм IDA должна получиться «полосатая» картина, когда именованные подпрограммы перемежаются с именованными.
Это не вполне так, но на этом этапе нужно обработать только самые очевидные случаи — когда между динамическими обёртками ровно одна подпрограмма, и, скорее всего, это и есть метод. Ему даётся имя по обёртке, которая ниже него.
Осторожно: попадались случаи, но не в этом файле, когда IDA не распознавала тело метода как подпрограмму, зато распознавала что-то вспомогательное, идущее после метода. На настоящий метод идёт обратная ссылка из VMT.
Третий этап: когда между обёртками две подпрограммы
Как можно видеть, обёрток здесь создаётся сразу две, типизированная и нетипизированная, но типизированная обычно выбрасывается транслятором C++ за ненадобностью. Если между динамическими обёртками сразу две безымянных подпрограммы, то, скорее всего, первая из них — это нужный метод, а вторая — типизированная обёртка.
К началу третьего этапа большая часть методов уже должна быть проименована, так что если смотреть из VMT, то это будут одиночные пробелы, и на данном этапе они устраняются.
Четвёртый этап: закрываем большие пробелы в VMT
Бывает, остаются большие пробелы в VMT, по два и более метода. В очередной раз можно отметить удобство взгляда из VMT. Так, если при обходе __Field упустить один метод, он будет выглядеть в списке подпрограмм IDA как три безымянные подпрограммы между динамическими обёртками, но хаКс может генерировать дополнительные подпрограммы и для других нужд, и тогда тоже может получаться три безымянные подпрограммы между динамическими обёртками.
Из VMT же видно: если пробел из двух элементов, значит, это упущенная динамическая обёртка в __Field. Находим в списке подпрограмм, где этот пробел, переходим к средней подпрограмме, это должна быть обёртка. С помощью X открываем список обратных ссылок, среди них должен быть __Field. Переходим туда, выясняем имя обёртки, пробел в списке подпрограмм «затягивается» полосой, и дальше по описанному алгоритму проставляем имена методов.
Методы hx.Object
Для полноты можно открыть hxcpp/include/hx/Object.h, выписать оттуда все виртуальные методы по порядку, и так идентифицировать методы в начале VMT.
Определение типов данных полей и аргументов
Когда у полей и аргументов вызываются методы (как и все, виртуальные), надо понять, в какой VMT их искать, а для этого надо понять, каких вообще они типов. Если не запускать отладчик, помогают это сделать динамические обёртки. На вход они получают аргументы формальных типов (Dynamic, Dynamic, Dynamic, … ) и, чтобы сделать вызов, они сначала приводят Dynamic к реальному ожидаемому методом типу. Во время этого преобразования как раз можно и узнать эти самые типы.
Например, если в теле обёртки видим:
…то видно, что делается приведение из hx.Object во что-то другое. Если hx_Obejct_ci у вас ещё не идентифицирован, то оба класса будут неизвестные, но это решаемо. Смотрим, в чей RTTI ведут указатели (в данном примере off_22D9DE0), проставляем имена, делаем выводы.
Аналогично для полей пригождается __SetField, который вынужден приводить тип от Dynamic к реальному типу поля, тем самым давая подсказку.
Статические поля и методы
Если у класса есть статические элементы, у него переопределяются статические методы __GetStatic и/или __SetStatic. В VMT их по понятным причинам не видно, но если в классе есть одновременно и статические, и обычные элементы, то в транслированном коде идут по порядку __Field, __GetStatic, __SetField, __SetStatic, так что, зная, где __Field и __SetField, можно вычислить __GetStatic и __SetStatic рядом с ними. Там так же в начале switch по длине строки, и затем операции сравнения.
Один из простых способов улучшить свои навыки программирования — читать чужой код
Примечание: первоначально эта статья была написана для сайта Fuel Your Coding back в мае 2010 года. К сожалению, этот сайт сейчас не работает, поэтому я публикую статью здесь, чтобы сохранить её для потомков. Я собирался обновить её, учитывая последние веяния, но решил оставить так, как она была написана. Те части, что подустарели, могут показаться немного смешными, но да ладно. Получайте удовольствие…
Наиболее очевидным способом повысить качество своего программирования является писать больше программ. Каждый знает это. Однако другой способ, который, я уверен, улучшит ваше программирование, — совершенно противоположный. Изложу это так ясно, как смогу.
Если вы желаете резко поднять ваше умение программировать, необходимо… читать код, написанный другими программистами.
Вы можете верить в это, можете не верить. Ваше право. Но если вы готовы рискнуть, то, уверен, вы будете вознаграждены за потраченное время.
В этой статье я хотел бы помочь вам в выборе того, что именно читать, и дать практические советы по такому чтению. Если вы уже и так читаете другие программы, то, может быть, вы найдёте здесь что-нибудь, что позволит получить больше от ваших усилий. Если же вы не читаете коды других разработчиков, то вы просто обязаны заняться этим.
Что читать
Это — важное решение, и то, в котором трудно советовать. Я не хотел бы просто указать вам на какой-то код, который, как я думаю, вы должны прочитать, потому что на самом деле надо рассматривать то, чем вы занимаетесь. Однако я дам несколько направляющих указаний, чтобы помочь вам в выборе программ для чтения.
Читайте программы, имеющие к вам отношение
Отличным местом для старта являются какие-либо плагины или библиотеки, которые вы уже используете.
• Плагин WordPress, который вам действительно нравится;
• Ruby gem, который вы считаете полезным;
• Плагин jQuery, к которому вы продолжаете возвращаться.
Все они — первые кандидаты на изучение. Вы уже знаете их общедоступные интерфейсы, поэтому барьер для понимания их внутренней работы ниже. Кроме того, у вас — как пользователя этой программы — есть возможность добавить документацию, внедрить новую функцию или вообще внести свой вклад в этот проект в каком-то виде.
Читайте программы, впечатлившие вас
Помню, что, когда я первый раз просматривал сервис создания презентаций 280 Slides, я подумал: «Да! Круто!». Я быстро выяснил, что программа, управляющая этим сайтом, является проектом Cappuccino с открытым кодом. Это знание вошло глубоко в моё сознание, и когда я как-то наткнулся на ещё одно впечатляющее приложение, работавшее на Cappuccino, я уже знал, что на этом проекте я смогу многому научиться. Что произвело сильное впечатление на вас в последнее время? Эта программа имеет открытый исходный код? Если так, то она — отличный выбор для чтения: код, скорее всего, впечатлит вас так же, как и само приложение.
Читайте программы, написанные теми, кого вы уважаете
Программисты, достойные уважения
Если вы уже занимаетесь программированием с открытым исходным кодом какое-то время, то, вероятно, у вас уже есть на примете программисты, заслужившие ваше уважение. Я мог бы с ходу назвать несколько разработчиков, программы которых вызывают у меня просто «белую зависть».
Если у вас пока нет такого разработчика, то найти его несложно. Он(а), вероятно, является автором какой-нибудь программы в одном из предыдущих двух разделов (программы, имеющие к вам отношение, или программы, впечатлившие вас).
Читайте программы, которые вы сможете, действительно, достаточно глубоко понять
Если вы склонны рисковать, то можете рассмотреть погружение в большой проект, как, например, Ruby на Rails, Drupal или jQuery. Но я предложил бы вам не использовать пока такие проекты, если вы, конечно, не являетесь опытным читателем программ.
Крупные проекты имеют чрезвычайно много взаимодействующих частей, и вы, в конечном итоге, потратите немало времени и сил на освоение общих представлений, чтобы узнать что-то конкретное. Запутанность предмета изучения расхолаживает, и большие проекты, более вероятно, приведут к вашему разочарованию при чтении. Преимуществом выбора небольшого проекта для чтения является то, что вы можете держать всю логику работы программы в вашей голове целиком. Это позволяет работать только с деталями, чтобы извлечь какие-то уроки.
Как читать
Теперь, когда код для чтения выбран, как наилучшим способом читать его? Я прочитал на сегодня множество программ и могу предложить несколько способов максимизации вашего КПД.
Изучите общую картину
Структура каталога twitter gem
Я предполагаю, что вы, по крайней мере, знаете на макроуровне, что делает код, который вы читаете. Если нет, то предлагаю прочитать веб-сайт проекта, учебные пособия, документацию и всё остальное, что вы можете достать помимо кода.
После того как надлежащая ясность внесена, вашим первым шагом должно быть рассмотрение структуры проекта. Объём этой работы зависит от размера выбранной базы исходного кода, но даже если она занимает больше одного файла, это потребует лишь ненамного больше времени.
Прежде всего, зафиксируйте для себя структуру файлов. Этот шаг легче выполнить с помощью редактора, который имеет вид иерархии папок, как, например, TextMate. Здесь, как пример, показан прекрасный вид Twitter Ruby gem.
Цель этого шага состоит просто в ознакомлении с источником. Разберитесь, какие файлы включают в себя / вызывают / загружают другие файлы, где находится основная часть кода, какие пространства имён используются (если таковые имеются) и прочее такого рода. Получив общее представление, можно погружаться в детали.
Документируйте ваши результаты
Чтение кода не должно быть каким-то пассивным действием. Рекомендую добавлять комментарии по мере продвижения, документировать ваши предположения и ваши выводы, когда вы начнёте понимать ход выполнения программы. Когда вы начнёте впервые, ваши комментарии будут выглядеть, вероятно, так:
По мере понимания процессов вы можете удалить небольшие иерархические комментарии, которые вы оставляли для себя, и, возможно, написать более значимые и авторитетные комментарии, которые могли бы быть переданы обратно в проект.
Используй тесты, Люк
(Прим. переводчика: автор вспомнил «Используй силу, Люк» из «Звёздных войн»)
Будем надеяться, что проект, который вы выбрали, имеет набор тестов. Если нет, то можете пропустить этот раздел вообще (или найти проект, имеющий такой набор).
Тесты являются отличным местом для начала чтения чужого кода, потому что они документируют то, что программа должна выполнить. Одни тесты являются более информативными, чем другие, но независимо от того, насколько хорошо они написаны, часто найти намерения программиста в тестах намного легче, чем в реализации. При чтении попытайтесь получить успешный результат при прогоне всего набора тестов. Это позволит убедиться, что ваша среда разработки сконфигурирована правильно, и сделает вас более уверенным при внесении изменений.
Измените код, скомпилируйте
Кто сказал, что чтение кода должно быть пассивным? Вы начнёте, действительно, понимать код, только после того, как сломаете всё и снова соберёте вместе. Вспомните пройденные тесты? Сделайте так, чтобы они завершились неудачно, добавьте кое-что или попытайтесь изменить реализацию так, чтобы они прошли нормально. Попробуйте добавить какую-нибудь небольшую «фичу», которая вам кажется «крутой», или настройте регистрацию по всему проекту так, чтобы можно было распечатать вывод на различных этапах выполнения программы. Это по-прежнему чтение? Абсолютно, но такой подход является больше собственным приключением, чем чтением детективного романа. И это — именно то, что надо!
Смыть и повторить
(Прим. переводчика: из анекдота про айтишника, моющегося шампунем строго по инструкции — бесконечно)
Закончив с чтением одной кодовой базы, возьмите другую и начните процесс снова. Чем больше кодов вы читаете, тем лучше идёт это чтение и тем больше вы получаете из него за меньшее время. Я думаю, вы обнаружите, что ваш КПД растёт довольно быстро и что это действительно очень приятный способ обучения.
Где начать
Единственным, самым важным источником для чтения кода является для меня GitHub. Этот сайт позволяет так легко найти новые проекты и действительно великих программистов, что вы действуете себе во вред, если не используете его. Я предлагаю начать на GitHub и читать код прямо на сайте, пока не найдёте проект, из которого по вашему мнению вы сможете извлечь какие-то уроки. Затем склонируйте его и читайте!
А вы используете чтение кода как обучающий инструмент? Какие проекты вы порекомендовали бы коллегам? Прочитали какую-нибудь хорошую программу в последнее время?
