Почему большая часть кодов — полный отстой

06.05.2020
Posted in blog-article
06.05.2020 admin

Почему большая часть кодов — полный отстой

Проверьте, попадает ли ваш код под это определение 😉

Звучит довольно грубо, не так ли? Но дело в том, что в этом есть доля истины. Вы, вероятно, заглянули в какие-нибудь библиотеки кода и подумали, что они в полном порядке.

Ни один разработчик не совершенен. Все они, какими бы хорошими вы их ни считали, совершали ошибки, как большие, так и маленькие.

Плохое наименование, слишком большие функции, плохие архитектурные решения, дублирование кода. Я мог бы продолжить этот список, но вы, вероятно, сталкивались с этими ошибками и без меня.

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

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

Причина, по которой большая часть кода плоха

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

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

Вы можете сделать многое для улучшения читабельности вашего кода. Один из них — дать значимые имена переменным, методам и классам. Да, elapsedTime — это достойное имя для переменной, но как насчет elapsedTimeInSeconds? Это просто гораздо более значимо.

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

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

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

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

Имейте в виду, что код читается гораздо чаще, чем пишется. Роберт К. Мартин сказал следующее о читабельности:

“Мы постоянно читаем старый код в рамках усилий по написанию нового кода. Поэтому, облегчая чтение, вы облегчаете и написание.— Роберт К. Мартин

“Вам нужно написать код, который минимизирует время, необходимое кому-то другому, чтобы понять его, даже если этот кто-то другой — вы. — Дастин Босуэлл И Тревор Фуше

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

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

Комментарии, которые объясняют, почему это может быть чрезвычайно полезно, как только ваш проект вступает в фазу обслуживания. Что подводит нас к следующей причине, почему большинство кодов — отстой. Он не обслуживаем.

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

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

Вы пожертвовали обслуживаемостью.

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

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

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

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

Последняя причина, по которой большинство кодов отстой — это то, что они не поддаются тестированию. Этому есть довольно простое объяснение. Большинство программистов вообще не любят тестирование.

Добавьте тот факт, что слишком многим программистам не хватает навыков, чтобы написать правильные тесты, или вообще не этого делать.

Если вы не знаете, как писать тесты для вашего кода, Вы, вероятно, также не знаете, как писать тестируемый код. И, как мы все знаем, в лучшем случае наивно не проверять свой код.

Но как сделать ваш код тестируемым?

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

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

Заключение

Хорошо написанный код отвечает определенным критериям: он читаем, понятен, доступен для обслуживания и тестирования. Если код не соответствует этим критериям, скорее всего, это отстой.

Существует множество способов улучшить качество вашего кода. Один из них легче реализовать, чем другие. Например, сделать ваш код тестируемым может быть намного сложнее, чем удалить дубликат кода.

Просто знайте, что каждый разработчик делает ошибки и что никогда не поздно исправить их!

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Contact

Давайте работать вместе!

Пишите нам и найдем точки соприкосновения, может станем партнерами, а может поможем вам зайти в нашу чудесную нишу

Вы разработчик?

Пишите! Нам постоянно нужны новые кадры, либо можем помочь в продвижении вашего приложения

Новичок?

Поможем быстро войти в нишу, не тратя годы на понимание

Давно в нише?

Рады будем пообщаться как на темы whitehat, так и blackhat тематики ^_^ + всегда есть что обсудить по поводу рекламных сетей

ПИШИ В TELEGRAM!

Contact