Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!
Следуйте правилу трёх.
Это правило, применимое к рефакторингу кода, когда повторяющийся участок кода, должен быть заменён, новым кодом/процедурой/методом.
Оно говорит нам о том, что вы можете копипастить код только один раз, но когда тот же самый код повторяется три раза, он должен быть вынесен в отдельную процедуру.
Основная концепция - сделать код/процедуру/метод достаточно обобщенным, для использования в разных частях проекта.
Последовательность в написании кода крайне важна.
Будьте последовательны в структуре своего кода и в том, как вы его пишете. Это значительно упростит его читаемость и работу с ним.
Старайтесь придерживаться набора правил, который поможет вам быть последовательным. Следует разработать хотя бы соглашение о том, как вы именуете переменные.
Другое значимое правило - это структура вашего приложения. Она должна быть очевидна для разработчика, который планирует изменять код или расширять его функционал.
Сокращайте вложенность.
Оператор if внутри оператора if может быстро стать трудночитаемым. Все мы сталкивались с ситуациями, когда упростить подобную конструкцию невозможно. Но нужно стремиться к простоте.
Это же относится и к else if . Избегайте if всякий раз, когда это возможно. Данный оператор увеличивает ветвление кода, а значит, усложняет его.
Граничный оператор(guard clause) является действенным методом решить данную проблему.
Граничный оператор - это просто проверка, которая мгновенно делает либо возврат из функции, либо вызывает исключение.
Без граничного оператора:
if (account != null)
{
if (order != null)
{
if (order.term == Term.Annually)
{
// term annually
}
else if (order.term == Term.Monthly)
{
// term monthly
}
else
{
throw new InvalidEnumArgumentException(nameof(term));
}
}
else
{
throw new ArgumentNullException(nameof(subscription));
}
}С граничным оператором:
if (account == null)
{
throw new ArgumentNullException(nameof(account));
}
if (order == null)
{
throw new ArgumentNullException(nameof(order));
}
if (order.term == Term.Annually)
{
// term annually (return here)
}
if (order.term == Term.Monthly)
{
// term monthly (return here)
}
throw new InvalidEnumArgumentException(nameof(order.term));Думайте о проекте целиком.
Понимание всего проекта, или хотя бы той его части, которая взаимодействует с вашим кодом - очень важно. Оно значительно упрощает работу с мелкими деталями. Если вы понимаете, как проект работает, то работа с его компонентами занимает гораздо меньше времени.
Прикладывайте усилие к именованию переменных.
Грамотное именование переменных - это одна из тяжелейших вещей, которые вы можете делать в программировании. Это может быть именование как класса, так и функции(метода) и даже переменной.
Первоклассные разработчики инвестируют время в именование, потому что они знают, что в будущем эти усилия окупятся сполна.
Следите за техническим долгом.
Каждый раз, когда вы увеличиваете технический долг, подумайте о том, к чему это может привести и о том, как его потом возвращать. Скорее всего, имеет смысл приложить чуть больше усилий прямо сейчас, чем потерять значительное количество времени в дальнейшем.
Технический долг - это концепция в программировании, которая отражает неявную цену дополнительной работы, вызванной выбором более легкого решения, вместо использования лучшего подхода, реализация которого займёт больше времени.
Переоценивайте сложность задачи.
Совет может показаться странным и, в зависимости от того, в какой команде вы работаете, вам может не понравиться этот пункт. Правда в том, что выдающиеся разработчики всегда переоценивают сложность задач, так как они знают, что реализация всегда занимает больше времени, чем изначально предполагается, а добавление некого буфера к оценке, может помочь вам сделать вещи правильно.
Этот совет может сильно помочь с вышеупомянутым пунктом. Если вы недооцениваете задачу или рассматриваете только благоприятный сценарий, то это неизбежно приводит к увеличению технического долга. У вас хватит времени только на реализацию быстрого решения, вместо правильного.
Документируйте и комментируйте код.
Документация и комментарии помогают сохранять контекст и делиться знаниями. Опытные разработчики чаще других предлагают задокументировать какой-либо процесс. Они постоянно заставляют коллег добавлять комментарии в код.
Удаляйте плохой код без колебаний.
Вы будете часто видеть, как неуверенные разработчики закомменчивают огромные блоки кода и оставляют их. Для этой цели есть Git! Первоклассные программисты без малейших колебаний избавляются от кода, который они считают ненужным.
Тратьте время на ревью кода.
Хороший разработчик всегда найдёт время на ревью кода, так как понимает всю значимость этого процесса.
Ревью помогает:
Находить баги как можно раньше
Улучшать навыки разработчиков и следовать хорошим практикам
Делиться знаниями
Последовательно разрабатывать и реализовывать проект
Самый лучший процесс ревью кода, который я видел:
Небольшая задача с маленьким риском должна быть проверена одним разработчиком.
Средняя/большая, либо сопряженная с рисками задача должна быть проверена тремя разработчиками, один из которых - сеньор.
Чрезвычайно рискованная задача, либо новая часть приложения должна быть одобрена по итогам встречи трёх разработчиков, один из которых является ведущим. Они проверяют каждую строчку кода и делают заметки.
Пишите хорошие тесты.
Опытные разработчики тратят больше времени на написание хороших тестов.
Грамотно написанные тесты позволяют вам уверенно расширять ваше приложение, снижая число багов в продакшене.
Уделяйте время планированию.
До того как погрузиться в код, подумайте о его структуре. Разбейте задачу на маленькие блоки. Это поможет достичь лучшей архитектуры, взаимодействия компонентов и приведет к более чистому коду.
Фокусируйтесь на базовых вещах, а не на синтаксисе.
Это очень важный пункт! Опытные разработчики предпочитают учить основы, вместо излишней сфокусированности на синтаксисе. Такой подход способствует эффективному решению проблем, а также позволяет задавать гуглу правильные вопросы.
Гугл - ваш лучший друг.
Профессиональные программисты - эксперты в гуглении. Они знают основы, вследствие чего формируют правильные запросы, таким образом, решая любые задачи, которые перед ними стоят.
Сначала сделайте работоспособный черновой прототип, а уже потом переписывайте его начисто.
Часто случается, что неопытные разработчики тратят слишком много времени на то, чтобы с самого начала сделать код красивым и правильным. А потом понимают, что решение неверно и его нужно переписать.
Профессиональные разработчики же, напротив, не думают о том, как выглядит их код. Но ровно до тех пор, пока задача не выполнена. Таким образом, они избегают временных затрат на бесполезную работу.
Управляйте рисками и решайте проблемы.
Этот пункт вытекает из обширного практического опыта и не может быть приобретён быстро. Именно здесь сеньорство проявляет себя в большей степени.
Сеньоры могут определять риски, а также решать комплексные проблемы либо с помощью применения паттернов программирования, либо пользуясь предыдущим опытом.
Задавайте вопросы.
По настоящему крутые разработчики хотят знать всё. Они не стесняются задавать даже глупые вопросы, как технические, так и относящиеся к бизнесу.
Понимание бизнеса помогает им писать лучший код. Профи будут задавать вопросы в случае неуверенности в своих компетенциях.
Выносите логику из баз данных там, где это возможно.
Этот пункт зависит от типа приложения с которым вы работаете и применим только в том случае, когда от него не зависит производительность.
Отличные разработчики держат запросы к базам данных в рамках простых операций CRUD.
Затем, на уровне бизнес логики, эти запросы собираются воедино. Таким образом, бизнес логика находится в одном месте, избегая запутанных схем.
Keep It Simple Stupid (KISS)
Профи знают, что одна из ключевых задач первоклассного программиста - упрощать код настолько, насколько это только возможно. Вы можете увидеть значительное количество новичков, которые хвастаются однострочными решениями, вроде такого:
return dir.Keys.Any(k => k >= limit) ? dir.First(x => x.Key >= limit).Value : dir[dir.Keys.Max()];И вроде бы код работает, но обслужить его очень тяжело...
Заключение.
Все вышеизложенные практики были почерпнуты мною у самых выдающихся программистов, с которыми я работал. Как вы видите, секрет их профессионализма, по большей части, заключается в парадигмах и подходах, которыми они оперируют. Я уверен, что этот список можно ещё долго продолжать.
Надеюсь, что вы почерпнули для себя что-то новое!
