Это интересный простой вопрос, не правда ли, хотя, возможно, и не так однозначно ответить. Код достойного качества, или, если на то пошло, хорошего качества - вопрос довольно субъективный. Он может быть разным в зависимости от языка программирования, человека, просматривающего код, или проекта, для которого он используется. И, конечно, стандарты кодирования со временем тоже развиваются. Короче говоря, не существует единой меры, которая могла бы помочь вам в любом случае. Или, может быть, просто может быть.
Если вы посмотрите на все прекрасные парадигмы кодирования, с которыми вы сталкиваетесь в жизни программирования; DRY, SOLID, KISS, YAGNI и многие другие, может быть одна общая характеристика, которая может помочь лучше всего. Заменяемость.
О заменяемости
Я почти уверен, что это не оригинальная мысль, и многие блестящие программисты со знаниями, намного превосходящими мои собственные, уже писали об этом. Но меня всегда поражает, насколько элегантно это понятие заменяемости может сочетать вышеприведенные парадигмы кодирования.
Если вы сохраняете свой код СУХИМ, вы следите за тем, чтобы одна и та же часть логики не повторялась несколько раз по всей кодовой базе. Он находится в одном месте, что упрощает замену. Если вы придерживаетесь знаменитых ТВЕРДЫХ принципов (аббревиатура аббревиатуры, джекпот!), Вы в основном пытаетесь сосредоточить свой код на единой цели и, следовательно, его легче реализовать и заменить. KISS утверждает, что код должен быть достаточно простым для понимания. Что, как вы уже догадались, упрощает замену. А YAGNI способствует тому, чтобы не добавлять код, который вообще не используется. Это код, который вы даже не сможете заменить, если захотите, великолепно.
Но кто на самом деле сознательно думает об этих могучих акронимах каждый день при кодировании? Я не знаю, просто слишком много заглавных букв. Однако возможность замены может стать хорошей и практичной заменой. Например, всякий раз, когда я делаю обзоры кода, я часто задаю себе вопрос: достаточно ли я понимаю этот фрагмент кода, чтобы я мог изменить его сам или даже заменить, если необходимо? Отсюда возникают другие вопросы и предложения, в том числе передовой опыт и ошибки, с которыми вы сталкиваетесь, пытаясь понять, что происходит.
Нельзя сказать, что мой код всегда является светочем понятной логики, не совсем так. Одна из моих личных ловушек заключалась в том, чтобы надолго погрузиться в какую-то проблему с кодированием и создать код, который для меня довольно понятен ... сделать шаг назад и спросить, действительно ли эта функция может быть понятна и легко заменена кем-то другим - это часто хорошее начало для улучшения вещей.
В более широком смысле можно даже утверждать, что возможность замены - хорошая черта для любого приложения или службы, над которыми вы работаете. По крайней мере, это означает, что он достаточно мал для понимания, поэтому вы действительно можете начать думать о его замене (привет, микросервис / микро-интерфейс). Это, безусловно, плюс в современном быстро развивающемся технологическом ландшафте. А как насчет вас как программиста, вас могут заменить в короткие сроки? Если да, то ваш код понятен и может быть адаптирован вашими коллегами, отлично. Если нет, то даже лучше! (просто шучу)
Но это, вероятно, заходит слишком далеко, и кто на самом деле заменяет их код? Я не знаю, в любом случае это хорошее наблюдение, которое довольно часто всплывало за мои 25 лет программирования, так что, возможно, стоит подумать.
