И что вы можете сделать, чтобы улучшить свою

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

«Мы постоянно читаем старый код в рамках усилий по написанию нового кода. Таким образом, облегчая чтение, легче писать ». - Роберт С. Мартин

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

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

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

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

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

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

Вы пожертвовали ремонтопригодностью.

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

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

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

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

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

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

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

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

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

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

Заключение

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

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

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

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