Я думаю, у каждого разработчика рано или поздно в голове возникают мысли о том, что код нужно писать определённым образом.
Почему фреймворк этого автора так прост в использовании и так быстро освоится? Почему этот кусок кода кажется мне ужасным? В этот момент происходит важная веха в развитии разработчика как профессионала.
Он не только начинает думать о том, как реализовать конкретную задачу, но и о том, как дизайн ваше решение.
В голове начинают возникать мысли об определенной структуризации кода и его красивом дизайне.
Кто-то начинает создавать для себя некий эмпирический свод правил проектирования кода, кто-то приходит на помощь литературе или советам более опытных товарищей.
В любом из этих сценариев код начинает рассматриваться как нечто большее, чем просто абсолютное решение проблемы.
Появляются мысли, что какая-то часть кода сделана уродливый , а тут получилось круто и элегантно .
Но кто определяет эти критерии красоты применительно к кодексу и что в них входит? Все ли понятно, когда речь идет о кодексе этикета и красоте? Отказ от ответственности: Цель этой статьи — поделиться мыслями, которые возникли в процессе попыток постичь концепцию красивого кода.
Вышеизложенные мысли не претендуют на истину в последней инстанции.
Я только надеюсь, что эти мысли, размышления и аргументы помогут кому-то взглянуть на процесс написания кода с несколько иной точки зрения.
Далее следует не одно формальное правило типа «Пиши код так и будет тебе счастье».
На эту тему уже написано большое количество литературы гораздо более авторитетными авторами.
Всем, кого интересуют дискуссии на тему того, что такое кодовая красота, как она может выражаться, почему всем известным практикам не удается закрыть этот вопрос раз и навсегда, прошу под кат.
Хорошие и плохие практики
«.И мы часто задаемся вопросом, как правильно отформатировать наш код. Для ответа на этот вопрос в мире уже написано большое количество профессиональной литературы.и маленький спросил: «Что такое хорошо и что такое плохоЭ» — Маяковский В.
В.
Возьмем, к примеру, самые популярные работы на эту тему, о которых слышало большинство людей:
- Чистый код - Роберт К.
Мартин
- Идеальный код. Мастер-класс - Стив МакКоннелл
- Техники объектно-ориентированного программирования.
Шаблоны проектирования — банда четырех
- Программист-прагматик.
От мастера к мастеру - Эндрю Хант, Дэвид Томас
Но история не о необходимости применять тот или иной подход. Дело не в том, насколько хороша или плоха та или иная книга.
Поразмыслив, вы можете прийти к выводу, что даже использование всех передовых практик, описанных в этих книгах, не гарантирует вам красивый код. И что все это может быть как вредно, так и хорошо.
Получается, что если не существует конкретной «формулы успеха», то, возможно, стоит начать хотя бы с наброска мыслей о том, чего именно вы хотите достичь, пытаясь написать красивый код. Мы знаем, что такое код, но никто из нас не может сказать, что такое красивый код.
Предпосылки для мыслей
Как бы кому ни хотелось выделить программирование в отдельную самостоятельную дисциплину, все сводится к инженерии.Соответственно, общие мысли и идеи в области техники применимы как для автомобилестроения и строительства, так и для программирования.
Все это о применении научных знаний для создания чего-то практического, в какой-то степени материального (если речь идет о разработке программного обеспечения, то о материальности могут возникнуть чисто философские споры).
С практической точки зрения, чем проще система (конструкция, идея), тем удобнее, проще с ней работать и обслуживать, тем более более красивый она выглядит. Иллюстрация этой идеи на примере автомобильной промышленности.
Возьмем пример из автомобильной промышленности.
На данный момент у нас большой выбор автомобилей различной ценовой категории и характеристик, а также внутреннего устройства агрегатов.
Давайте отбросим все мысли об экономической составляющей (стоимость, пиар, маркетинг и т. д.), и попробуем оценить текущую ситуацию на авторынке с точки зрения надежности.
Сужая рамки рассуждений, ограничимся оценкой силового агрегата.
Это касается, например, автомобильных двигателей.
На данный момент люди изобрели уже множество различных типов двигателей, каждый из которых хорош в своей области.
Принципы их работы основаны на простых мыслях о расположении поршней, цилиндров, их количестве и объеме.
Все это в той или иной степени влияет только на 2 показателя – надежность и мощность.
Нынешние реалии таковы, что наиболее надежным решением является использование крупного атмосферного агрегата.
Двигатели с турбонаддувом меньше по размеру по сравнению с безнаддувными решениями, но требуют отдельной установки подачи воздуха (турбины), что усложняет всю систему.
Кроме того, поскольку сам двигатель меньше по размеру, в сочетании с турбиной он может производить столько же или больше мощности, чем безнаддувный двигатель, в 2 или 3 раза большей.
Это достигается за счет того, что двигатель, выдавая большую мощность, работает на пределе своих возможностей.
При этом большой атмосферный двигатель выдает примерно такую же мощность, но проще по конструкции и гораздо долговечнее.
То есть более простое решение является одновременно и самым прагматичным.
Иллюстрация этой идеи примером из природы.
Еще один простой пример можно взять из природы.
С момента своего появления на планете пчелы строят ульи.
Ульи считаются наиболее совершенными конструкциями насекомых.
Все дело в том, как пчелы строят соты.
Для строительства сот используется минимум материала – воск, который выкладывается самым оптимальным образом – в виде шестиугольников.
И здесь мы снова можем наблюдать торжество простоты.
Вместо использования более прочных материалов или более сложных конструкций (которые непременно потребуют каких-то вспомогательных колонн, опор и т. д.) используется простой материал и простая, но наиболее совершенная форма для достижения наиболее прагматичного и изящный решения.
Существует множество доказательств того, что такое решение красиво.
Возьмем, к примеру, 3D-печать.
Любой человек, хоть немного интересующийся 3D-принтерами, знает, что принтеры печатают модели, содержащие сотовую структуру, которую мы заметили у пчел.
Объяснение этой идеи на примере из математики.
В этом примере простота может быть не столь очевидной.
Многие люди, в основном нетехнические, находят математику сложной и по большей части бесполезной.
Основная идея, положившая в основу всей математики, — это идея о том, что все жизненные ситуации можно смоделировать.
Стоит учитывать, что зачастую получаемая модель гораздо проще и менее детальна, чем реальный процесс.
Самый простой пример: скажем, у пастуха есть стадо овец.
Но день был тяжелый, и он уснул на работе, а проснувшись, подумал, что нужно убедиться, что все овцы на месте.
В этот момент ему на помощь может прийти древнейший математический аппарат – числа.
Сами по себе цифры ничего не значат. Абстрактное число, оторванное от реальности, имеет не больше смысла, чем попытка надеть штаны через голову.
А вот в ситуации определения количества предметов им нет равных.
Позвольте мне привести более сложный пример.
В моей университетской программе был чрезвычайно полезный предмет под названием «Комбинаторные алгоритмы».
Большая часть этого курса была посвящена изучению теории графов и различных графовых алгоритмов.
Дискуссии о теории графов и по другим предметам уже велись, но лишь поверхностно.
То есть все мои одноклассники уже имели представление о том, что это такое и с чем это связано.
Кто-то даже проводил лабораторные работы по реализации какого-то алгоритма на графах.
Но именно на одной из пар по комбинаторным алгоритмам преподаватель вдруг спросил: «Кто может сказать, зачем вообще нужны эти графыЭ» Как ни странно, никто из группы не смог ответить; стояла гробовая тишина.
Ответ был очевиден и прост – для моделирования нужны графики.
Никому не нужны сами графы, и никому не нужна возможность реализовать обход в ширину или в глубину.
Но применительно ко многим жизненным ситуациям бывает крайне удобно отказаться от кучи ненужных подробностей и оставить только абстрактную суть.
Можно привести еще много подобных примеров из жизни человека и природы, которые будут объединены общей мыслью: зачастую простое решение оказывается самым прекрасным.
Именно в тот момент, когда я узнаю, как просто устроен тот или иной предмет, который кажется таким необходимым в жизни, в мою голову закрадывается мысль о том, что он был сделан.
Красивый .
Пока речь не идет об эстетике, только об «подкапотном» устройстве.
Однажды я наткнулся на книгу Кевлин Хенни — 97 вещей, которые должен знать каждый программист: коллективная мудрость экспертов .
Эта книга состоит из 97 небольших глав, написанных разными людьми и связанных только тем, что все они посвящены программированию.
Своего рода житейская мудрость от людей с большим опытом программирования.
Сразу оговорюсь, столь подробное описание ни в коем случае не является рекламой.
Но не могу не упомянуть эту книгу, потому что одна из ее глав побуждает задуматься о том, что красивый код – простой код .
В общем, она называется «Красота в простоте» (Красота заключается в простоте).
Автор начинает главу с цитаты Платона о том, что все прекрасное просто:
Красота стиля, гармония, изящество и хороший ритм зависят от простоты (Платон).Именно этот афоризм еще больше подогрел мой интерес к области красивого кода и применимости к коду понятия «красивое решение» и, как следствие, эквивалентности красивого кода простому коду.
Что такое красота?
Итак, мы подошли к самому вопросу о красоте кода.Чтобы максимально объективно понять, является ли красота в нашем деле синонимом простоты, следует начать с основного понятия.
Обратимся к Википедии за определением:
Красота – эстетическая категория, обозначающая совершенство, гармоничное сочетание сторон предмета, при котором последний вызывает у наблюдателя эстетическое удовольствие.Говоря о коде, мы не можем говорить исключительно с эстетической точки зрения.
Красивый (идеальный, хороший) код сочетает в себе и эстетику, и семантику.
Семантика кода также должна попасть в категорию «красивого решения».
Думаю, многие согласятся, что помимо практической ценности код (точнее, результат его работы и процесса создания) носит творческий характер.
Ближайшей творческой аналогией разработки программного обеспечения является создание литературного произведения.
Эти отрасли творчества, несомненно, имеют много общего.
Для простоты программный код можно сравнить с книгой.
Оба симулякр мысли.
Разница лишь в том, что, грубо говоря, результат кода — это некий результат на экране устройства, а результат чтения книги — это галлюцинация визуальных образов, ассоциаций и впечатлений, возникающих в нашем сознании.
При написании книг учитывается большое количество правил, позволяющих правильно оформить текст. Этот момент аналогичен правилам конкретного языка программирования и схеме работы компилятора/транслятора/интерпретатора.
Исходный текст книги проходит тщательное итеративное редактирование, прежде чем предстать перед глазами читателя.
Но важнее содержание.
С другой стороны, мало кто сможет дочитать самую интересную и увлекательную книгу или правильно ее понять, если мысли не будут правильно (читай: красиво) оформлены в связный текст.
Почему важен красивый код?
При выражении мыслей на бумаге, несомненно, стоит ориентироваться на правила языка, а также на структуру и простоту выражения.От этого напрямую зависят те впечатления и мысли, которые передадутся читателю, и какие образы возникнут в его голове.
С кодом дела обстоят немного сложнее.
Конечного пользователя нашего ПО не волнует, насколько красиво оно написано и какие ощущения получает разработчик от работы с этим кодом.
Конечного пользователя интересует только качество выпущенного продукта, то, как он работает и насколько удобно им пользоваться.
В отличие от литературы, качество кода — это характеристика, важная для разработчика или команды, работающей над ним.
Это не обязательно должны быть разработчики.
Вся команда (например, менеджеры проектов, менеджмент и инвесторы) может пострадать от обилия ошибок во время разработки.
Однако, что касается специалистов из других областей, красота кода касается их лишь косвенно.
Разработчики становятся первыми жертвами уродливого кода.
Почему для них это так важно? Разрабатывая продукт, мы большую часть времени тратим на парсинг кода, навигацию по нему, поиск места, где нужно написать или исправить нужные строки.
Все было бы намного проще, если бы разработкой определенного продукта занимался один человек.
Весь исходный код будет для него единым и понятным.
Но чтобы это самое программное обеспечение можно было разрабатывать в реальном времени, а не десятилетиями, разработку одного программного обеспечения часто осуществляет команда из нескольких разработчиков.
Это вносит свои коррективы.
Например, у каждого разработчика может быть свое понятие красоты (в частности, красоты кода).
Но поскольку работа происходит в команде, стандарты установлены для того, чтобы заставить команду думать.
более-менее то же самое.
Это позволяет убедиться, что читая код, разработчик не всегда может понять, он или кто-то другой написал код и кто именно, и дает ощущение общности и целостности команды.
Мы говорим «код нашего приложения», а не «мой фрагмент кода» или «мой скрипт».
Грубо говоря, мы пытаемся получить общее представление о красоте группы людей, связанных одним программным обеспечением и, чаще всего, ничем иным.
Получается, что в понятии красоты кода есть субъективизм, но мы стараемся его минимизировать внутри команды.
Но можно ли сделать понятие красоты кода полностью объективным? К чему мы прибегаем, пытаясь добиться объективной красоты и как это работает? Чтобы прийти к ответу на эти вопросы, стоит рассмотреть те немногие вещи, которые объединяют абсолютно всех людей.
А именно: мозг и то, как он обрабатывает информацию.
С какой задачей мозг справляется лучше всего?
В Интернете можно найти бесчисленное множество статей о том, как работает мозг при распознавании информации.Например, вы можете связаться этот статья.
Наш мозг обрабатывает огромное количество информации и для оптимизации своей деятельности использует закономерности.
Эти закономерности формируются в течение нашей жизни.
Отличным примером является процесс чтения.
Чем больше литературы человек прочитал на одном языке, тем выше его скорость чтения.
Чем больше книг вы читаете, тем больше слов вы читаете и тем чаще вы с ними встречаетесь.
Визуальное распознавание часто встречающихся слов происходит во много раз быстрее, чем чтение новой терминологии (особенно в незнакомой вам предметной области).
Чем больше книг одного автора прочитал человек, тем быстрее он сможет читать другие произведения этого автора.
Это правда, потому что у каждого автора ограниченный словарный запас и стиль письма.
Если посмотреть глубже, мы учимся читать, изучая алфавит. Точнее, мы учимся распознавать письменные буквы и только потом начинаем узнавать слова.
С распознаванием букв связан еще один интересный факт – скорость распознавания букв мозгом также зависит от шрифта, если мы говорим о печатном тексте, или от руки – для рукописных текстов.
Более того, когда речь идет о рукописных текстах, ситуация может доходить до абсурда – почерк может быть настолько плохим, что мы просто не сможем разобрать написанное (привет, врачи).
Процесс обучения ребенка чтению, скорее всего, является именно тем жизненным явлением, которое вдохновило людей на изобретение нейронных сетей.
Интересующиеся этой темой могут посмотреть материалы о том, как распознается текст с помощью алгоритмов нейросетей.
Когда мы читаем слова, мы обращаем внимание на все буквы только на начальных этапах.
И читать нас учат соответственно – сначала по буквам, потом по слогам и только потом по словам.
Есть интересное исследование, диссертация которого может ответить сама на себя:
Согласно рзелулаттам илссеовадний одонго анлигысокго унвиертисет, не иемт занчнея, в кокам пряде рсапожелены бкувы в решить.И это еще одно доказательство того, что мозг работает по шаблонам.Гальвоне, чтобы ты преавья и пслоэндя бквуй блый на мсете.
Осатлыне бкувы мгоут селдовт в плоонм бсепордяк, все рвется ткесть чтаицей без блуждания.
Главное, что мы читаем не каждую книгу по отдельности, а все вместе.
Мозг также пытается передать всю новую информацию, которую мы получаем, через существующие шаблоны, прибегая к 3 основным принципам:
- удаление - удаляем из памяти неиспользуемую уникальную (наименьшую шаблонную) информацию
- искажение означает преувеличение или преуменьшение чего-либо.
Например, в нашей повседневной жизни очень часто используются слова «никогда», «всегда», «ничего», «все», «все».
Если вдуматься, каждое употребление такого слова – это ложь или искажение фактов.
- генерализация – мозг пытается всю новую информацию свести к чему-то, с чем он уже работал.
Аналогии облегчают запоминание и припоминание.
Таким шаблоном может служить общий стиль кода команды разработчиков.
Если отступ в коде для каждого исходного файла или строки в нем разный, то ориентироваться в нем будет достаточно сложно.
Еще одним шаблоном может быть общий совет — кодируйте с точки зрения предметной области.
Это правда, потому что некоторые слова могут иметь разные значения в зависимости от контекста (отличный пример — лук или замок).
Напротив
Подумав о шаблонах, я задумался над тем, с каким кодом будет труднее всего работать.В моей голове промелькнула мысль об обфускации кода.
В конце концов, это сделано исключительно для того, чтобы затруднить понимание внутренней работы вашей системы другими программистами.
Кроме того, обфусцированный код наиболее ярко показывает важность визуального восприятия кода.
Можно выделить следующий набор методов обфускации:
- Длинные и бессмысленные имена переменных, классов, методов и функций.
Мало того, что длинные слова труднее читать, так еще и таких сочетаний букв и цифр вы явно никогда в жизни не видели.
- Пробелы, отступы и переносы строк полностью удалены.
В данном случае мы, видимо, просто набор букв, цифр и символов.
В худшем случае это может быть целый экран без единого свободного места.
Дальше вам придется разбирать этот текст посимвольно, что отнимет уйму времени.
К тому же, в конце дня работы с таким кодом вы будете чувствовать себя измотанным и уставшим.
Кто-то скажет, что у него «мозг взорвался».
- Возможно, вызовы некоторых методов или функций будут заменены их исходным текстом.
Немного странный момент. По сути, это огромные изуродованные шаблоны, но с условием их бессмысленного повторения.
Делает текст крайне избыточным.
К тому времени, как вы осознаете огромную закономерность, мысли о предыдущем контексте уже покинули ваш мозг.
Есть даже известная аббревиатура для этой темы: СУХОЙ — Не повторяйся.
Однако всегда ли это так, если смотреть на мир шире? Отличный пример – музыка.
Она не может обойтись без повторений.
Здесь стоит отметить, что из этого утверждения есть исключения.
Простейший пример такого исключения — виртуозные соло.
Они запоминаются поклонникам, несмотря на то, что часто не содержат повторов.
Но в целом правило работает. Если вы посмотрите на музыку, которая набирает все больше оборотов – Рэп/Хип-хоп – то вы сможете увидеть это наиболее отчетливо.
Структура минуса почти целиком состоит из простых, коротких, повторяющихся фрагментов, что не всегда характеризует его красоту.
В качестве вырожденного примера можно вспомнить метроном — никто не станет спорить, что его равномерное и монотонное тиканье — красивая музыкальная композиция.
Можно ли считать увеличение количества повторов в музыке ее оптимизацией или улучшением? Первое, на что можно посмотреть, — это классическая музыка, полная неожиданных ходов, уникальных партий и небольшого количества повторов.
Современная тенденция такова, что практически независимо от жанра произведения стали короче.
Их теперь называют песнями и они совершенно шаблонны по структуре - есть вступление, припев, простой лейтмотив.
Берем эти компоненты в различных вариациях и сочетаниях и получаем более-менее универсальную формулу.
Такие произведения слушателям легче найти.
Вот почему ценителей популярной музыки гораздо больше, чем ценителей классической музыки.
Еще одним примером феномена постоянного повторения и упрощения является игровая индустрия.
Жанр казуальных игр становится все более популярным, плавно перетекая в жанр гиперказуальных.
Это игры, направленные на повторение простой цепочки быстрых действий, строго ограниченной небольшим промежутком времени.
В то время как сложные вариативные игры и игры с малым повторением, такие как стратегии, в настоящее время переживают не лучшие времена.
Если есть пример того, как подход с простыми неизбыточными шаблонами не работает, должен ли такой подход всегда работать для кода?
Как добиться простого ООП-кода и что может в этом помочь?
С момента погружения в профессию нас окружают сложные и замысловатые, на первый взгляд, принципы и подходы.Старшие люди, под руководством которых мы обучаемся, рассказывают о различных подходах, шаблонах и книгах, которые следует прочитать, чтобы добиться успеха в ООП.
Я думаю, что наиболее часто употребляемые слова — это шаблоны проектирования и ТВЕРДЫЙ .
Не все сразу понимают, зачем это все нужно.
Но общий смысл — писать красивый и правильный код. Как это нам помогает и всегда ли это помогает? Все магические паттерны и аббревиатуры направлены на то, чтобы научить нас думать о программировании по тем же шаблонам, что и при чтении и анализе обычного текста.
Всегда ли шаблоны проектирования хороши?
С самого начала карьеры разработчиков обучают шаблонам.Попробуем разобраться, почему.
Любой шаблон проектирования направлен на то, чтобы сущность была максимально компактной по описанию и простой.
Она не делала того, чего не следовало, и делала то, что от нее требовалось, в максимально сжатой форме.
Речь идет не только о том, чтобы решение было архитектурно обоснованным, но и о том, чтобы его было легко понять.
От проекта к проекту вы используете примерно один и тот же набор паттернов.
Частое повторение этих шаблонов ускоряет процесс проектирования и процесс обработки существующего кода в мозгу, сокращая время, необходимое для поиска того или иного фрагмента кода.
Сама по себе разработка ПО ради разработки ПО никого не интересует, разве что в образовательных целях, которые можно оставить за рамками обсуждения.
Разработка программного обеспечения всегда преследует какую-то бизнес-цель.
Здесь стоит отметить, что, говоря о целях бизнеса, мы не всегда говорим о деньгах.
Возможно, цель — заработать репутацию, помочь кому-то или просто похвастаться перед семьей/товарищами («Смотрите, я написал игру!») и так далее.
По большей части бизнес-цель является фундаментальным фактором при выборе архитектуры приложения.
Сначала анализируются требования, на основании чего можно сделать вывод о том, будет ли поддерживаться программное обеспечение и каков будет цикл разработки.
На все эти факторы накладывается информация о ресурсах — знания команды или собственные знания.
Все эти факторы явно или неявно (если вы только начинаете заниматься разработкой программного обеспечения, вы можете и не думать об архитектуре, но скоро обязательно начнете) влияют на то, какие подходы и шаблоны вы будете использовать при разработке.
На основе выбранной архитектуры, подходов и шаблонов формируется кодовая база программного обеспечения.
До того, как разговор зашел о шаблонах проектирования, красоту кода можно было рассматривать в абстрактных терминах.
То есть можно гипотетически представить себе какой-то файл с исходным кодом, вырванный из контекста.
Руководствуясь исключительно визуальной составляющей кода, не обращая внимания на его семантику, можно сделать вывод, красив код или нет. Когда в какой-то момент абстрактный исходный код становится частью базы кода (частью чего-то большего, частью программного обеспечения), в уравнение красоты кода начинают вводить новые переменные.
Допустим, в проект приходит новый разработчик, который никогда не видел кода этого проекта.
Прежде всего ему необходимо войти в проект, то есть изучить кодовую базу.
В ходе исследования у разработчика сформируется свое мнение о проекте, а точнее о том, из чего он состоит. И в этот момент у разработчика могут возникнуть такие мысли: «Это решение некрасивое» или, наоборот, «Ух ты! Какое элегантное (красивое) решение.
» В данном случае красота относится к архитектуре, которая выражается посредством кода.
То есть в понятие красоты кода также может вмешиваться понятие семантической красоты – в какой степени Решение архитектурно правильное.
Правильно ли выбран подход или шаблон и поддерживается ли он? Именно здесь все становится сложнее всего:
- Если вы не знакомы с тем или иным подходом, то его идея может быть неочевидной, непонятной и восприниматься в негативном или позитивном контексте.
Это самый непредсказуемый случай.
- Вы можете быть знакомы с каким-то подходом и воспринимать его негативно, например, как антишаблоны.
- Возможно, вы знакомы с этим подходом и воспринимаете его положительно.
Оказывается, именно поэтому мы все вынуждены изучать шаблоны проектирования — чтобы мы все говорили на одном языке, стандартизированным образом.
Кроме того, шаблон – это то, с чем любит работать наш мозг.
Однако мы достигли точки, когда все может быть не так просто, как кажется.
Любой файл исходного кода может сочетать в себе реализацию нескольких шаблонов.
Оставим в стороне вопрос о правильности такого решения; это очень сильно зависит от ситуации и может быть как правильным, так и неправильным решением.
Разбавление реализации одного паттерна реализацией другого может усложнить восприятие кода, сделав его некрасивым в наших глазах.
Неправильно реализованный шаблон еще больше усугубляет ситуацию.
До самого конца вы можете думать, что понимаете код, поскольку он подчиняется закономерности, а потом оказывается, что все это время вы воспринимали его неправильно.
В этот момент красивый код теряет все свое очарование и становится не таким красивым, а скорее вонючим.
В этом случае отсутствие узора может выглядеть красивее, чем неправильно реализованный узор.
Другой аспект касается неправильных подходов или антипаттернов.
По сути, антишаблон — это шаблон, который не следует использовать.
Но тем не менее, это паттерн, который определенным образом придает коду читабельность и понятность, то есть простоту и красоту.
Оказывается, использование шаблонов в коде проекта — палка о двух концах.
стиль написания API
Когда речь идет о красивом дизайне API, чаще всего на ум приходит либо сервис, либо библиотека (или фреймворк).Сервис чаще всего рассматривается как нечто внешнее по отношению к коду, поэтому в нашем контексте лучше рассматривать библиотеку.
Выбор того или иного типа API повлияет не только на структуру кода библиотеки, но и на внешний вид клиентского кода, использующего библиотеку.
Я могу сразу вспомнить два стиля.
Классический стиль заключается в том, что мы помещаем библиотеку в одну конкретную сущность (класс) и все методы, которые есть в этом классе, выполняют определенное действие, возвращая конкретный результат, не зависящий от состояния основной сущности библиотеки.
Большинство различных плагинов выполнены в классическом стиле, поэтому проблем с пониманием этого стиля возникнуть не должно.
Второй стиль – жидкостные интерфейсы .
Этот подход заключается в том, что на выходе библиотеки мы получаем тот же объект, который вызвал действие, только теперь настроенный немного по-другому.
Примером является реализация LINQ на C#.
В нем цепочки действий выполняются над одной и той же коллекцией (IEnumerable).
На каждом шаге запроса мы каким-либо образом модифицируем коллекцию, пока не получим требуемый результат. Другой пример из C# — контейнер внедрения зависимостей под названием Зенжект .
В нем привязки зависимостей написаны в гибком стиле:
Очень известный пример гибкого интерфейса от Swift — популярного фреймворка.Container.Bind<Foo>().AsSingle().
NonLazy().
FromInstance(FooInstance");
Часто можно увидеть следующие конструкции: Alamofire.request(
.
GET, "http:foo.com", parameters: ["include_docs": "true"],encoding: .
URL).
validate().
responseJSON { (response) -> Void in. }
В большинстве случаев подходящий стиль можно выбрать исходя из текущей ситуации.
Но никто не мешает вам переписать API библиотеки из одного стиля в другой без изменения функционала, а дальше это становится делом вкуса или красоты.
В целом гибкие интерфейсы встречаются не так часто, как классический стиль, но в зависимости от большого количества факторов они могут сделать код красивее или уродливее.
Здесь также невозможно вывести универсальную формулу.
Косметические средства по уходу за языком
Мы уже пришли к выводу, что для красоты нужны шаблоны, без них никуда.Шаблоны должны быть узнаваемыми, простыми и короткими.
С паттернами проектирования всё оказалось неоднозначно.
Но помимо архитектурных закономерностей на помощь приходят и конструкции самого языка, на котором вы пишете.
Один и тот же шаблон проектирования, реализованный на одном языке, может выглядеть красиво или некрасиво в зависимости от конкретных языковых инструментов.
Общей для большинства, если не для всех языков программирования, то для большинства особенностью языка, которая не влияет на семантику кода, но влияет на его красоту, является комментирование.
Добавление хорошего комментария в нужном месте может улучшить внешний вид вашего кода.
Но как только вы пишете комментарий в отрыве от общего стиля (например, Си-подобные языки позволяют описывать комментарии тремя разными способами), это сразу портит общую картину и визуально отвлекает от восприятия кода.
сам.
В качестве жертвы давайте посмотрим на некоторые возможности, которые предоставляет нам язык C#.
Одной из простейших особенностей этого языка является ключевое слово вар .
Это позволяет мне избежать Теги: #программирование #дизайн и рефакторинг #мозг #Идеальный код #продуктивность #активность мозга #идеальный код #красивый код #философия программирования #мысли вслух #длинный пост #длинный пост
-
Что Такое Медленные Протоколы
19 Oct, 24 -
Эскизное Литье
19 Oct, 24 -
Профилирование Сборки Проекта
19 Oct, 24 -
Lizard Squad Пытался Атаковать Тор
19 Oct, 24
