Это правило, применимое к рефакторингу кода, когда повторяющийся участок кода, должен быть заменён, новым кодом/процедурой/методом. Оно говорит нам о том, что вы можете копипастить код только один раз, но когда тот же самый код повторяется три раза, он должен быть вынесен в отдельную процедуру. Основная концепция - сделать код/процедуру/метод достаточно обобщенным, для использования в разных частях проекта. Будьте последовательны в структуре своего кода и в том, как вы его пишете. Это значительно упростит его читаемость и работу с ним. Старайтесь придерживаться набора правил, который поможет вам быть последовательным. Следует разработать хотя бы соглашение о том, как вы именуете переменные.  Другое значимое правило - это структура вашего приложения. Она должна быть очевидна для разработчика, который планирует изменять код или расширять его функционал. Оператор if внутри оператора if может быстро стать трудночитаемым. Все мы сталкивались с ситуациями, когда упростить подобную конструкцию невозможно. Но нужно стремиться к простоте. Это же относится и к else if . Избегайте if всякий раз, когда это возможно. Данный оператор увеличивает ветвление кода, а значит, усложняет его. Граничный оператор (guard clause) является действенным методом решить данную проблему. Граничный оператор - это просто проверка, которая мгновенно делает либо возврат из функции, либо вызывает исключение. Без граничного оператора: С граничным оператором: Понимание всего проекта, или хотя бы той его части, которая взаимодействует с вашим кодом - очень важно. Оно значительно упрощает работу с мелкими деталями. Если вы понимаете, как проект работает, то работа с его компонентами занимает гораздо меньше времени. Грамотное именование переменных - это одна из тяжелейших вещей, которые вы можете делать в программировании. Это может быть именование как класса, так и функции(метода) и даже переменной. Первоклассные разработчики инвестируют время в именование, потому что они знают, что в будущем эти усилия окупятся сполна. Каждый раз, когда вы увеличиваете технический долг, подумайте о том, к чему это может привести и о том, как его потом возвращать. Скорее всего, имеет смысл приложить чуть больше усилий прямо сейчас, чем потерять значительное количество времени в дальнейшем. Технический долг - это концепция в программировании, которая отражает неявную цену дополнительной работы, вызванной выбором более легкого решения, вместо использования лучшего подхода, реализация которого займёт больше времени. Совет может показаться странным и, в зависимости от того, в какой команде вы работаете, вам может не понравиться этот пункт. Правда в том, что выдающиеся разработчики всегда переоценивают сложность задач, так как они знают, что реализация всегда занимает больше времени, чем изначально предполагается, а добавление некого буфера к оценке, может помочь вам сделать вещи правильно. Этот совет может сильно помочь с вышеупомянутым пунктом. Если вы недооцениваете задачу или рассматриваете только благоприятный сценарий, то это неизбежно приводит к увеличению технического долга. У вас хватит времени только на реализацию быстрого решения, вместо правильного. Документация и комментарии помогают сохранять контекст и делиться знаниями. Опытные разработчики чаще других предлагают задокументировать какой-либо процесс. Они постоянно заставляют коллег добавлять комментарии в код. Вы будете часто видеть, как неуверенные разработчики закомменчивают огромные блоки кода и оставляют их. Для этой цели есть Git! Первоклассные программисты без малейших колебаний избавляются от кода, который они считают ненужным. Хороший разработчик всегда найдёт время на ревью кода, так как понимает всю значимость этого процесса. Ревью помогает: Находить баги как можно раньше Улучшать навыки разработчиков и следовать хорошим практикам Делиться знаниями Последовательно разрабатывать и реализовывать проект Самый лучший процесс ревью кода, который я видел: Небольшая задача с маленьким риском должна быть проверена одним разработчиком. Средняя/большая, либо сопряженная с рисками задача должна быть проверена тремя разработчиками, один из которых - сеньор. Чрезвычайно рискованная задача, либо новая часть приложения должна быть одобрена по итогам встречи трёх разработчиков, один из которых является ведущим. Они проверяют каждую строчку кода и делают заметки. Опытные разработчики тратят больше времени на написание хороших тестов. Грамотно написанные тесты позволяют вам уверенно расширять ваше приложение, снижая число багов в продакшене. До того как погрузиться в код, подумайте о его структуре. Разбейте задачу на маленькие блоки. Это поможет достичь лучшей архитектуры, взаимодействия компонентов и приведет к более чистому коду. Это очень важный пункт! Опытные разработчики предпочитают учить основы, вместо излишней сфокусированности на синтаксисе. Такой подход способствует эффективному решению проблем, а также позволяет задавать гуглу правильные вопросы. Профессиональные программисты - эксперты в гуглении. Они знают основы, вследствие чего формируют правильные запросы, таким образом, решая любые задачи, которые перед ними стоят.  Часто случается, что неопытные разработчики тратят слишком много времени на то, чтобы с самого начала сделать код красивым и правильным. А потом понимают, что решение неверно, и его нужно переписать. Профессиональные разработчики же, напротив, не думают о том, как выглядит их код. Но ровно до тех пор, пока задача не выполнена. Таким образом, они избегают временных затрат на бесполезную работу. Этот пункт вытекает из обширного практического опыта и не может быть приобретён быстро. Именно здесь сеньорство проявляет себя в большей степени. Сеньоры могут определять риски, а также решать комплексные проблемы либо с помощью применения паттернов программирования, либо пользуясь предыдущим опытом. По-настоящему крутые разработчики хотят знать всё. Они не стесняются задавать даже глупые вопросы, как технические, так и относящиеся к бизнесу. Понимание бизнеса помогает им писать лучший код. Профи будут задавать вопросы в случае неуверенности в своих компетенциях. Этот пункт зависит от типа приложения, с которым вы работаете, и применим только в том случае, когда от него не зависит производительность. Отличные разработчики держат запросы к базам данных в рамках простых операций CRUD. Затем, на уровне бизнес-логики, эти запросы собираются воедино. Таким образом, бизнес-логика находится в одном месте, избегая запутанных схем. Профи знают, что одна из ключевых задач первоклассного программиста - упрощать код настолько, насколько это только возможно. Вы можете увидеть значительное количество новичков, которые хвастаются однострочными решениями, вроде такого: И вроде бы код работает, но обслужить его очень тяжело... Все вышеизложенные практики были почерпнуты мною у самых выдающихся программистов, с которыми я работал. Как вы видите, секрет их профессионализма по большей части заключается в парадигмах и подходах, которыми они оперируют. Я уверен, что этот список можно ещё долго продолжать.  Надеюсь, что вы почерпнули для себя что-то новое! Web Developer