Исходный код: зачем и как его понимать?

Очень часто обращаясь в DST Global (dstglobal.ru) многие люди считают программирование чем-то невероятно сложным, особенно когда просматривают исходный код. Например, веб-дизайнеров, которых профессиональный долг вынуждает от случая к случаю сталкиваться программным кодом, часто бросает в дрожь при виде непонятных символов. Специалисты DST расскажут простыми словами как и зачем нужно понимать исходный код. 

Мне это не по силам

Сложность кода создает впечатление, что человек, понимающий и пишущий его, обладает незаурядными умственными способностями, а если он кодирует уже давно, значит, он ими обладал всегда. Скромность может и украшает, но не стоит занижать самооценку — все не так, как кажется.

Код действительно может быть запутанным, если изначально плохо спроектирован и не содержит пояснительных комментариев. Даже опытные программисты не всегда понимают чужой код. Профессионалы же могут писать такой код, который не нуждается в комментариях, а его структура вполне очевидна.

А зачем вообще нужно понимать чей-то код? Вот несколько причин:

- Самый лучший способ научиться программировать — понять, как работает программа, и сделать что-то подобное.

- Кому-то, например, владельцу сайта, это нужно, чтобы сэкономить бюджет на незначительных изменениях в проекте.

- Веб-дизайнер почувствует себя уверенней, когда будет понимать процессы, управляющие шаблоном сайта.

- Если изучение кода и его написание не помогут стать хорошим программистом, то на другие сферы жизни это занятие окажет положительное влияние, так как оно улучшает логическое мышление, прививает склонность упорядочивать и упрощать задачи.

Устройство кода не сложнее дерева

Главное в понимании кода — видение его структуры, где одна функция вызывает другую. Такая древовидная структура может иметь любую глубину. На самой вершине стоит функция, которая не вызывается никакой другой, с нее приложение начинает свою работу, с этой точки и нужно читать код.

Исходя из языка программирования, основных функций может быть несколько, тогда интерпретатор считывает их в том же порядке, в котором они идут в коде, либо согласно базовой логике приложения.

В ООП основной единицей является независимый класс.

У него есть своя внутренняя структура, где методы (те же функции) обмениваются данными друг с другом. Правда, методы одного класса могут вызываться методами другого класса, что порой затрудняет увидеть общую картину, но принцип понимания остается тот же.

Как уследить за работой программы

В процессе чтения кода определяют, что и как делают функции, но чаще всего достаточно знать, какие значения они возвращают, какие значения принимают переменные. Код всей программы читают редко, как правило, после понимания общей логики переходят к конкретным частям, особенно если речь идет о больших программах.

Качественное ПО хорошо документируется, разработчики в DST Global (dstglobal.ru) также могут предоставить схему приложения, чтобы облегчить понимание механизма его работы и сэкономить пользователю время на его изучение. Если схемы нет, ее можно составлять самостоятельно по мере чтения кода. Подобным образом документируют свой код и сами разработчики во время его написания.

Если программа большая, то схем может быть несколько, где одна отражает общий механизм работы, а другие — его составные части. В элементы схемы могут входить логика и всевозможные значения. Чтобы видеть, какие значения принимают переменные, используют отладчик. Он позволяет следить (пошагово) за ходом работы программы, отображая значения переменных после каждой выполненной операции.

При желании любой может изучить работу программы, главное — двигаться от малого, брать качественный исходный код и не лениться визуализировать его работу.

Исходный код: зачем и как его понимать?
Получить консультацию у специалистов DST
Напишите нам прямо сейчас, наши специалисты расскажут об услугах и ответят на все ваши вопросы.
Комментарии и отзывы экспертов
RSS
12:17 (отредактировано)
+4
В программировании говорят, что нужно постоянно учиться даже для того, чтобы просто находиться на месте
11:15
+3
Для начала определимся, что понимается под «высоким уровнем»? Традиционно языки программирования разделяются на поколения. Сам термин поколения языка достаточно редко используется в русской технической литературе, да и сам язык не всегда можно четко и категорично отнести к тому или иному поколению. Поэтому давайте разберемся, сначала с ним, а потом перейдем собственно к PHP.

Поколение языка к его возрасту имеет косвенное отношение. Словом «поколение» выражается лишь общие тендении и абстрактность языковых терминов. Даже в наши дни до сих пор создаются языки «младших» поколений, для решения каких либо конкретных задач, если для этого есть предпосылки.

Языком первого поколения является машинный код. Он и сейчас используется, в него в конечном итоге транслируют все другие языки программировния. Молодежь может быть не в курсе, но еще лет 30-40 тому назад на нем писали живые люди. Кроме шуток. Не хакеры, а прикладные программисты. Прямо так байтик по байтику составляли прикладные программы, например расчет зарплаты сотрудникам завода.

Наиболее известный представитель второго поколения — Ассемблер (ASM). С помощью него повысилась скорость написания программ и совместимость при переносе на родственное оборудование. Ассемблер не просто привел в соответствие машинным кодам какие-то мнемонические команды, а позволил абстрагироваться от многих технических деталей, позволив больше сосредоточится на решении прикладной задачи. Собственно этот последний тезис является главным признаком индукции при переходе от одного поколения языка к другому.

Третье поколение языков позволило практически полностю абстрагироваться от «железа». Их уже столько много, что перечислить затруднительно. Одни из пионеров — Фортран, Паскаль, Бейсик. Языки третьего поколения до сих пор самые используемые и кажется, что покрывают все необходимые потребности современного программирования. Однако прогресс не стоит на месте. Теория программирования сделала следующий шаг и породила четвертое поколение языков (4GL).

Не каждый язык имеет ярлык конкретного поколения и свое четкое место на шкале. Примером такого является Си. Хотя Си появился, когда эра третьего поколения была уже в разгаре, но родился он с явними признаками языка второго поколения. Это нисколько не аттавизм и не деградация. Он именно таким и задумывался – язык для написания операционных систем. Взяв все необходимые новшества и синтаксические удобства языков третьего поколения, он позволяет писать программы, практически оптимизировануми также, как на Ассемблере. Можно сказать, что он находится на отметке 2 ½ поколения.

Не меннее интересна картина с С++. Синтаксически это тот же Си с дополнительными прибамбасами. Но из-за них С++ перестал быть языком. Сам по себе он не представляет бОлшей ценности, чем Си. Интересным он становится тогда, в нем создана та или иная объектная иерархия, переопределены операторы и т.п. Когда мы получаем новую концепцию работы с данными. Практически это новый язык с Си синтаксисом, который может соответствовать любому поколению. То есть по сути С++ не язык, а инструмент для создания языков. К сожалению большинство програмистов звезд с неба не хватают. Какая бы не была навороченная иерархия объектов, созданная в С++, она будет соответствовать банальному третьему поколению языков. ООП находится в полном перпендикуляре к линии повышения абстракций.

Мы сейчас живем на стыке эпох третьего и четвертого поколения. Многие просто недопонимают самого смысла появления нового поколения, при том, что старые языки так прекрасно решают все вопросы. Суть индукции следующего шага все та же — абстракция от технических деталей с целью более быстрого решения прикладной задачи.

Здесь следовало бы привести примеры языков четвертого поколения. Перед этим необходимо сделать оговорку, что упомянутые далее языки могут обладать в той или иной мере свойствами четвертого поколения. Синтаксически это может быть не выражено явно. 4GL — это новая концепция, а не новый синтаксис. Синтаксически язык может быть похож на язык третьего поколения, но подход при работе с ним будет другим.

Формально к языкам четвертого поколения можно отнести SQL. Это наиболее известный представитель, но посколько он используется в очень узкой специфической задаче, то наглядно не демонстрирует все аспекты 4GL. Одну из ранних попыток предпринял Informix. Вместе со своей базой данных и набором стандартных библиотек для других популярных языков третьего поколения, они предлагают свой собственный язык Informix-4GL. В качестве синтаксической модели они взяли SQL и дополнив другими языковыми конструкциями сделали из него полноценную среду разработки, в котором SQL команды явлются не чем-то инородным, заключенным в кавычки, а нативной частью языка. В этом смысле к языкам четвертого поколения можно отнести семейство dBase, FoxBase, Clipper и им подобные.

Внимательный читатель может заметить из нескольких перечисленных примеров, что здесь говорится даже больше не о языке, а о среде разработки. Это будет правильное замечание, поскольку современые прикладные задачи требуют баз данных, не просто как нечто, где можно сохранить кое-какие конфигурационные данные. База данных (в широком смысле этого слова) становится ядром, вокруг которого строится приложение. Поэтому не удивительно, что она уже не хочет довольствоваться правами сторонней библиотеки (бедного родственника). Из-за естественных ограничений мы получаем ситуацию, когда не к языку привязывается база данных, а вокруг какой-то конкретной реализации базы возводится язык. Универсальные решения мне пока не известны.
11:16
+2
«База данных (в широком смысле этого слова) становится ядром, вокруг которого строится приложение.»
Я для себя как-то давно определил, что веб-программирование — по сути создание удобного интерфейса к базе данных.
11:18
+1
Было интересно почитать. Жду продолжения
02:35
«Ненавижу читать чужой код», — такую фразу можно часто услышать от программистов. Причина их ненависти в том, чужой код пишут не они. Это не значит, что каждый разработчик страдает манией величия, все гораздо проще: читатель никогда не испытает того потокового состояния, в котором находился программист, когда создавал свой код. Поэтому пассивное чтение иногда бывает скучным.

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

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

Как правильно читать код

Научитесь проводить «раскопки» в коде

При первом знакомстве с серьезной кодовой базой вы будете ощущать себя не разработчиком, а археологом, частным сыщиком или исследователем религиозных книг. Вам придется проводить «раскопки» в чужом коде, чтобы понять, как он создавался.

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

git blame

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

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

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

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

git log и git grep

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

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

Переключайтесь между коммитами и изучайте историю кода

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

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

Читайте спецификации

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

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

Воспринимайте комментарии как подсказки

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

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

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

Если вы хорошо провели «раскопки», то нашли момент, когда один из разработчиков решил абстрагировать часть кода. Вспомните, как код выглядел до этого изменения и задумайтесь, что с ним стало после выноса на новый уровень абстракции.

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

Избавляйтесь от «мусора» в коде

Пока вы читаете код, вам могут встретиться функции и целые файлы, которые разработчики никогда не используют, и комментарии, на которые никто не отвечал несколько лет. Не тратьте на разбор всего этого много времени — избавьтесь от «мусора». Если этот код все еще нужен, кто-нибудь отметит это на код-ревью. Удалив ненужное, вы сбережете силы и время того, кто будет читать этот код после вас.
Вам может быть интересно
Мастерство, необходимое для создания производительных, масштабируемых и удобных в обслуживании программных архитектур и API, часто остается незамеченным и недооцененным. Эта статья от разработчиков ко...
Разработчики играют решающую роль в современных компаниях. Узнайте от специалист...
В мире есть много способов программирования. Но од...
Название PHP расшифровывается как гипертекстовый п...
Прежде чем мы узнаем для чего и как придумали объе...
Что такое программное обеспечение для разработки п...
В этой статье от разработчиков компании DST Global...
В этой статье разработчики компании DST Global опи...
В программировании существует такое понятие, как «...
REST API (Representational State Transfer Applicat...
Frontend- и backend-разработка тесно связаны между...

Новые комментарии

Работаем в DST CRM уже несколько лет, отличная и очень удобная система
Для приоритетного размещения и его брендированного подвида необходимо создать пр...
Спасибо за ответ, а как тогда лучше подключить рекламу на Яндекс Картах?

Заявка на услуги DST

Наш специалист свяжется с вами, обсудит оптимальную стратегию сотрудничества,
поможет сформировать бизнес требования и рассчитает стоимость услуг.

Адрес

Ижевск, ул. Воткинское шоссе, д. 170 Е, Технопарк Нобель, офис 1117

8 495 1985800
Заказать звонок

Режим работы: Пн-Пт 10:00-19:00

info@dstglobal.ru

Задать вопрос по почте

Укажите ваше имя
Укажите ваше email
Укажите ваше телефон