как читать программный код
Как научиться читать чужой код
Предположим, от такого занятия Ваши веки постепенно тяжелеют, и… Приходится пробудиться от необходимости понять чужой код и привести его в порядок. На мой взгляд, визуально сканировать иероглифы не так сложно как может показаться сначала. Как бы то ни было, необходимо уметь читать чужой код и редактировать, и один процесс не существует без второго.
Понимание этого приходит во время изнурительных тренировок. Особенно хорошо мы запоминаем, когда много раз сталкиваемся со своими ошибками из-за отсутствия навыков правильного чтения чужого кода.
Говоря о вероятности наличия ошибок, заметим, что в старых, тысячу раз проработанных файлах их меньше. Обычно массу ошибок мы встречаем в файлах, который никогда не меняли.
Перед реконструкцией кода иногда проще привести его в удобный для Вас порядок и потом вносить небольшие изменения, нежели сначала написать стили или события, а потом изменять верстку, например.
Лучше не оставлять черновых вариантов в рабочих файлах, поскольку Вы обязательно про что-нибудь забудете.
Когда над проектом работает команда, становится необходимостью сначала позаботиться о понимании концепции будущего сервиса. Вы обязательно вспомните этот совет, когда заметите, что продуктивно работали не возвращаясь к вопросам о том как это должно быть. Каждый специалист знает свою работу, и не стоит заблуждаться в том, что кто-то имеет такое же представление о том как будет реализована задача и что оно будет совпадать с Вашим. Поэтому не бойтесь советоваться с коллегами по цеху, чтобы последствия не вышли из области Вашего контроля и не стали неожиданностью.
Если Вы совершаете повторный поиск чего-то, на что вновь потребовалось приличное количество времени – необходимо обратить на это внимание.
Проведите анализ – с чем чаще всего пришлось повторно столкнуться; какого рода элементы вы ищите долго и почему. Возможно, это происходит из-за того, что Вы бы написали определенный фрагмент кода иначе, или не до конца ясна логика. В любом случае, надо действовать исходя из осознания того, что работа с кодом — уже Ваша задача, а не того, кто первым его написал.
Работая с чужими файлами, мы начинаем понимать, что хотел человек, каким он видел будущий сервис. Ход закодированных мыслей становится для нас все более логичным, а иногда и самым верным для реализации конкретной задачи.
Решения многих задач ждут Вас в сетях интернета, и поиск их занимает не так много времени, как кажется может показаться на первых порах.
Приятно воспользоваться благами обычных блокнотов. Например, CTRL + G (поиск по номеру строки) и прочие удобности, что значительно экономит время.
Работая с кодом желательно оставлять комментарии. Со временем они приобретут лаконичную форму и будут размещены в нужном месте. Это облегчает работу не только Вам, но и другим коллегам.
Приблизительно в середине работы над изменением кода для небольшой разгрузки можно просмотреть его на содержание синтаксических ошибок.
Рекомендуется так же редактировать файлы по маленьким частям, а начинать с самого сложного. Если Вы надолго застряли на каком-то моменте — переключитесь на что-нибудь другое. Вернитесь к трудности завтра, с утра, чтобы не тратить много времени на восстановление в памяти последних мыслей.
Не сомневаюсь, что частенько у Вас бывает поток мыслей о том, что необходимо исправить в разных участках кода. Для этого лучше все записывать. В конце рабочего дня это будет хорошим подспорьем. Так проще рассчитать время, необходимое на выполнение поставленной задачи, а так же, пригодится для отчетности.
Когда уходите на перерыв или домой, просмотрите что необходимо еще сделать. Когда перед Вами не будет кода и в памяти будет «висеть» задача, Вы заметите появление свежих оригинальных мыслей, даже если не будете намеренно думать о способе решения. Особенно такой прием подходит для сложных задач. Не говоря о пустяковых, конечно.
Как читать код: 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. Оригинал здесь.
Как научиться читать код сайта и зачем это нужно, если вы не программист
Кажется, что программирование — это сложно, особенно если никогда не приходилось с ним сталкиваться. На самом деле всё зависит от задачи. Чтобы вносить небольшие изменения на сайт, хватит и азов, а их может освоить даже человек без технического образования. Об этих азах и пойдет речь в статье. Расскажем об устройстве исходного кода, о том, как начать в нём немного разбираться, и ответим на вопрос, зачем всё это вам нужно.
Примечание: мы не будем лезть в дебри и подробно описывать процесс программирования. Расскажем о том минимуме, что пригодится в работе над вашим сайтом.
Зачем понимать исходный код
Сначала поговорим о том, зачем вам нужно что-то знать о коде, если вы не программист. Да, здорово расширять свои границы. Но главное, что вы можете получить из этого знания — пользу для бизнеса.
Зная, как устроен исходный код, вы сможете:
Если просто смотреть на страницу сайта, вы не сможете проанализировать, правильно ли настроено SEO-продвижение, а инструменты для анализа не всегда могут быть под рукой. Только в коде проверяют, на месте ли метаданные и обязательные элементы — основная информация для успешного SEO. Поэтому заглядывать в исходный код становится обычной практикой маркетологов или владельцев бизнеса, которые сами занимаются продвижением.
Плюс вам больше не будет казаться магией работа SEO-специалиста. Вы будете говорить на одном языке и понимать, как поисковики видят ваш сайт и что можно улучшить.
Если вы решите проанализировать сайты конкурентов, немного разбираясь в коде, вы сможете оценить не только визуальную и контентную стороны страниц. У вас получится определить, с помощью каких ключевых слов продвигается сайт, на какой CMS работает и немного больше понять стратегию продвижения конкурентов.
Вам будет легче представить и объяснить разработчику, как вы видите свою задумку. А значит, на финальной стадии работ не окажется, что всё сделано не так, а деньги и время уже потрачены.
Когда программист будет объяснять вам, в каких правках нуждается сайт компании, вы всё поймёте и сможете на равных обсудить это с сотрудником. Вам будет проще нанимать человека на IT-должность и разбираться в сметах на обслуживание сайта.
Экономнее изучить азы программирования и быстро устранять проблемы самостоятельно вместо того, чтобы нанимать программиста для выполнения небольших, но частых задач. Например, менять размеры баннеров или цвет текста на странице.
Что такое исходный код сайта
Национальная библиотека им. Н. Э. Баумана говорит, что исходный код — это текст компьютерной программы, который может прочитать человек, на языке программирования или языке разметки.
Именно код скрывается за внешней стороной любой интернет-страницы. Он выглядит как список пронумерованных строк с информацией о том или ином элементе страницы.
Как посмотреть код любого сайта
Расскажем, как посмотреть исходный код страницы в браузере Google Chrome. В остальных браузерах этот процесс примерно такой же.
Код вызывается одной из комбинаций:
Панель с кодом откроется на этой же странице, а не в другом окне. При наведении мышки на код будет подсвечиваться соответствующая ему область на текущей странице.
Дальше в статье мы будем пользоваться именно этим инструментом — он нагляднее.
Чтобы не утонуть в огромном количестве новых символов, нужно разобраться, что такое HTML, CSS и JavaScript.
Что такое HTML
HTML — язык гипертекстовой разметки. На нём написано большинство сайтов в интернете.
Что можно узнать о сайте из исходного кода
Код сайта предназначен в первую очередь для браузера и поисковых систем. Браузеру он говорит, что и в каком порядке выводить на странице. Поисковые системы берут из исходного кода всю информацию о странице: заголовок, описание, метаданные — всё то, что потребуется, чтобы показать страницу в выдаче поисковика. Обычный пользователь тоже может прочитать этот специальный текст — достаточно знать, как он устроен.
Все элементы кода нужны для правильного расположения разделов и деталей страницы. Всё это вы сможете найти и проанализировать, внимательно изучив исходный код сайта:
Чтобы лучше понять теорию, разберёмся в коде страниц блога RU-CENTER: найдём теги, картинки и другую информацию.
Для начала открываем страницу и вызываем интерактивный код (Ctrl + Shift + I). Откроется интерактивная панель с кодом, поделённая на две области. Слева — HTML-код (вкладка Elements), справа — CSS (вкладка Styles). Нам пока нужна левая часть с HTML.
Основные теги
HTML-страница состоит из набора тегов, которые вместе с содержимым называются элементами — это строительный материал веб-страницы. Другими словами, теги — команды для браузера, чтобы он понял, как нужно показывать сайт пользователю. Указывая в коде определенные теги, вы говорите браузеру: «Это текст, а это картинка, это ссылка, а это кнопка или форма». И браузер показывает все элементы интерфейса так, как вы их разместили.
Теги обычно открываются и закрываются так: — открытие тега, — закрытие.
Теги делятся на два вида: блочные и строчные.
Приемы чтения кода
Для начинающих программистов хорошим тоном всегда было – «учиться программированию у мастеров». А кто может быть лучшими мастерами, чем разработчики типовых решений?! Поэтому совершенно неудивительны попытки новичков открывать модули типовых решений и просто начинать читать код, следя за развитием логики алгоритма, подмечая ньюансы и приемы программирования.
В такие моменты начинающий программист подобен литературному переводчику с неродного языка: что знал – перевел, что не знал – домыслил, что не понял – перевел так, как написал бы сам в данной ситуации.
И не беда, что поначалу половина кода кажется туманной и загадочной. Главное понимать его цель, отмечать основные вехи и как можно больше – читать, осознавать и брать на вооружение. По мере «набивания руки» в чтении кода – тумана и загадок будет оставаться все меньше.
А что бы этот процесс приносил еще больше пользы – в данной статье предлагаем определенную методику и ряд приемов, минимизирующих усилия по чтению программного кода.
Но кому в наше время нужна голая теория, не подкрепленная практикой?! Что бы доказать действенность методики – давайте сразу попробуем ее применять в конкретном примере.
Допустим, мы хотим разобраться, как в типовых решениях устроен механизм пересчета цен при изменении значения валюты документа.
Выход на нужный программный код
Ну что открываем «конфигуратор»?
Первым делом в любой ситуации полезно посмотреть на действие изучаемого механизма… в пользовательском режиме программы!
Поясню: Понимая, к чему это действие приводит, впоследствии гораздо легче делать выводы о важности тех или иных фрагментов программного кода. А это в свою очередь, позволит сэкономить время на игнорировании «очень мутных, но, похоже, не важных» для нашего механизма фрагментах.
Итак, правило первое: Перед началом анализа программного механизма, посмотрите на его действие «глазами пользователя».
Далее желательно определиться с точкой старта изучаемого механизма. Ну, в самом деле, не будем же мы читать сверху-донизу все строчки кода всех модулей программы. Их миллионы. А задействована в работе нашего мехнизма – только малая часть. Как бы на нее выйти побыстрее?
Итак: Если хотим быстро выйти на фрагмент кода механизма – достаточно определить «провоцирующее» действие пользователя и обработчики событий, возникающих после этого действия.
Как видите, найти обработчики событий, связанных с изменением элементов формы, достаточно легко. Надо лишь в эскизе формы задействовать контекстное меню на самом элементе, и в подменю «События» посмотреть – напротив каких обработчиков проставлена пиктограмма «Р()«. Если проставлена – значит этому обработчику назначена процедура. А если обработчик подходит по смыслу нашей задачи – то именно эту процедуру надо прочитать, изучить.
Серфинг по коду
Но одним из принципов структурного программирования является следующий: «повторяющиеся фрагменты программы нужно оформлять в виде процедур и функций, вызываемых из программы». То есть надо быть готовым к тому, что очередная строчка кода в изучаемой процедуре будет не исполняемой командой, а именем «вызываемой из программы процедуры или функции». А вызываемая процедура или функция уже в свою очередь может включать в себя вызовы других процедур или функций, а те – других…
Фактически чтение «сверху-вниз» в типовых конфигурациях зачастую превращается в «серфинг» по вызывающим друг-друга процедурам и функциям. Как не «утонуть», не запутаться при этом серфинге – смотрим в следующем ролике:.
Шаг назад: комбинация клавиш (причем «минус» надо нажимать на верхнем ряду клавиатуры, а не на отдельной боковой).
Кроме этих двух основных приемов «серфинга» есть еще один вспомогательный:
— найти использование процедуры или функции. Эта комбинация клавиш позволит оценить «популярность» очередной процедуры или функции:
Анализ вызываемых процедур и функций
Ну что ж, теперь можно подступаться к анализу вызываемой функции «НеобходимПересчетВВалюту».
Что бы чтение функции (процедуры) сопровождалось еще и пониманием прочитанного – желательно придерживаться следующего плана:
1) Контекст
2) Комментарий
3) Параметры
4) Текст
То есть – текст в последнюю очередь.
Почему? Потому что «дешевле и быстрее» выводить умозаключения «от общего к частному», а не наоборот. Потому что легче читать код функции, когда Вы уже четко осознаете:
1) Где она расположена, и какое окружение ей доступно просто из-за того, что она расположена именно там?
2) Что мне хотел посоветовать/пояснить автор этой функции?
3) Какие данные (недоступные из контекста) автор бы вынужден передать со стороны вызывающей процедуры(функции)?
В следующем ролике показано – как именно это осознание можно выполнять:
Вот теперь можно приступать к чтению:
Синтакс-помощник, помогай!
— входной для «черного ящика» информации;
— планируемого действия черного ящика;
— выходной из «черного ящика» информации;
— особенностей поведения «черного ящика».
Так вот, все это описание содержится в инструменте платформы «Синтакс- помощник«:
Приведенный в этом ролике пример работы с синтакс-помощником – это не какое-то особенное и самобытное действие в процессе чтения чужого кода. Это обычная рутинная, рефлекторная повседневность. Это как во время ходьбы размахивать руками. Не задумываемся, просто машем и все тут.
Ну, вот смотрите сами, как идет дальнейший анализ нашей функции:
А вот так освоенные нами «F12«, и «Поиск в Синтакс-помощнике» помогают осознать следующую часть алгоритма:
Изучение привлекаемых объектов
В процессе чтения кода кроме вызываемых или системных процедур и функций мы можем еще наткнуться на привлечение других объектов. Вот сейчас мы в рамках контекста формы документа с алгоритмом разбираемся. Но в самом алгоритме прописано получение данных из совсем другого объекта. Смотрите, как можно и в этом случае воспользоваться теми правилами чтения кода, что мы уже изучили:
Отладчик, показывай!
Хорошо когда Вам абсолютно прозрачны преобразования данных, выполняемые в коде алгоритма. То есть читаете код и понимаете: «ага, сюда, значит, у них заходит проволока, вот этот барабан крутится, вот эти насадки загибают, а вот эта – обрезает. «
Но иногда понимание сводится к следующей схеме:
Наглядность! Вот что требуется при чтении сложных фрагментов кода.
Наглядность преобразований данных на каждом этапе.
Так вот, платформа «1С:Предприятие» имеет шикарный инструмент для обеспечения наглядности. Называется он – «Отладчик».
Итак, отладчик позволяет посмотреть результат любой переменной, метода или функции, выполнимых в рамках текущего кода (текущего контекста).
За работу, товарищи!
Ну, правда, попробуйте.
Убедитесь, что это не сложно и по-своему приятно.
Ведь что может быть приятнее для начинающего программиста, чем полностью разобраться в сложном, запутанном деле алгоритме.
Ужасы чужого кода: как найти смысл и не умереть
Даже самым крутым программистам трудно читать чужой код. Узнайте, почему это так страшно и как с этим справиться.
В жизни каждого разработчика наступает момент, когда нужно взяться за код, написанный другим человеком. Это может быть связано с поддержкой старого проекта, оптимизацией legacy-кода, переделыванием приложения, которое не доделал другой программист.
Хорошо, если этот код написан по архитектурному паттерну, у него есть документация, комментарии или хотя бы понятные названия переменных. Однако чаще всего приходится работать с говнокодом (это термин, если что).
В этой статье я опишу личный опыт чтения ужасного кода. Поэтому приготовьтесь сначала лицезреть моё страдание и только потом получить какие-то полезные советы.
Пишет о программировании, в свободное время создает игры. Мечтает открыть свою студию и выпускать ламповые RPG.
Виновник торжества
Мне и раньше приходилось сталкиваться с плохим кодом (например, своим), но недавно попался настолько ужасный, что я решил написать об этом статью.
Для начала попробуйте понять, что делает этот цикл, зная только, что приложение работает с 3D-графикой:
Первое, что бросается в глаза, — нарушение традиций в выборе имени счётчика.
Чтобы разобраться, что тут происходит, нужно понять, что такое msh, object и gm. С последним всё предельно просто:
Теперь остаётся только понять, что такое oo. Это очень хороший вопрос, потому что oo — это глобальная переменная, объявление которой нужно ещё поискать.
Вот другой фрагмент:
Название метода не вносит никакой ясности. Не говоря уже о том, что разработчик игнорирует соглашение об идентификаторах. Он даже единого стиля не придерживается, потому что в этом же файле можно встретить метод, который называется getPointOfIntersection ().
Складывается ощущение, что разработчик не знает главного правила программирования:
«Пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где вы живёте».
Как с этим жить
Очевидно, что невозможно заставить всех писать чистый и понятный код. Поэтому единственный выход — научиться читать всё, что попадается под руки. Это умение можно разделить на два навыка: чтение и расшифровка (эти названия условные).
Расшифровка может пригодиться, когда нужно срочно понять, как работает код. Особенно если он настолько ужасный, что просто пытаться вникнуть в проект — глупо. Рассмотрим на примере:
Это достаточно небольшой метод, который, однако, записан таким образом, что невозможно понять, что он делает. В этом случае не стоит тратить силы, чтобы вникнуть, — лучше сразу привести его в человеческий вид.
Для начала можно расставить пробелы и переносы строк:
Сделать это можно с помощью специальных инструментов, но лучше попробовать вручную. Возможно, в процессе получится что-то понять. Попутно можно добавить комментарии:
Становится понятно, что метод проверяет коллизию двух двумерных объектов. Поэтому можно поменять названия переменных и самого метода:
Когда весь код приобретёт более-менее человеческий вид, можно будет провести рефакторинг:
Например, можно вместо координат принимать объекты:
Всё это должно помочь разобраться в коде здесь и сейчас. Если же нужно постоянно работать с чужими проектами, то есть смысл попрактиковаться в чтении. Есть несколько простых советов, которые помогут в этом нелёгком деле.
1. Пробуйте писать в разных стилях
Обычно я пишу вот так:
Даже если нужно выполнить одну инструкцию, я всё равно использую фигурные скобки. Мне кажется, так легче понять, что является частью ветвления, а что — нет.
Но иногда стоит посмотреть, как пишут другие, и попробовать так же. Например, вот так:
Если часто практиковаться, можно привыкнуть, и тогда читать такие конструкции будет проще.
2. Читайте чужой код
Попробуйте зайти в случайный репозиторий на GitHub и разобраться, как там всё устроено и как оно работает. Изучите несколько проектов, чтобы научиться понимать разные стили.
Подумайте, почему разработчик пишет так, а не иначе, как он составляет документацию и так далее. Так вы не только научитесь читать чужой код, но и, возможно, найдёте пару интересных приёмов, которые захотите использовать сами.
3. Давайте другим читать ваш код
Дайте другому разработчику посмотреть ваш проект. Сразу будьте готовы к тому, что ваш код тоже так себе. Обратная связь поможет понять, что вы делаете не так, а если повезёт, получите несколько рекомендаций, как улучшить свой код.
В процессе вы можете понаблюдать, что делают более опытные коллеги, чтобы вникнуть в ваш проект.
4. Попробуйте прочесть код, который писали давно
Скорее всего, сначала вы ничего не поймёте, а потом почувствуете сильный стыд. Это нормально и случается со всеми программистами.
Сейчас вы уже лучше, чем были когда-то давно, поэтому сможете увидеть, что делали не так. Возможно, вы заметите, что до сих пор используете те же самые приёмы, и исправите это.
5. Больше рефакторинга
Иногда код необходимо переделать, даже если он работает. Конечно, это касается в первую очередь проектов, которые нужно поддерживать. Если не прибегать к рефакторингу, то придётся постоянно держать в голове весь плохой код, чтобы не приходилось каждый раз вникать заново. Кроме того, вы вряд ли заметите баги и уязвимости, потому что весь код выглядит как одна большая уязвимость.
Заключение
Последний совет: не обманывайте себя. Вы, я и любые другие разработчики пишут ужасно. Просто потому, что так устроено программирование — приложения не могут быть безупречными и совсем понятными.
Однако это не значит, что можно окончательно забить на чистоту и читаемость кода. Просто нужно понимать, что мастерство в программировании, как и в любом другом деле, это не пункт назначения — это сам путь.
Нужно стремиться к тому, чтобы писать совершенный код, но помнить, что не нужно зацикливаться на этом. Именно так мы подходим к обучению на курсе «Профессия C#-разработчик». Студенты учатся писать чистый, поддерживаемый код с документацией, который не стыдно показать коллегам.
Профессия C#-разработчик
130 часов — и вы научитесь писать программы на языке, созданном Microsoft. Вы создадите 5 проектов для портфолио, даже если до этого никогда не программировали. После обучения — гарантированное трудоустройство.