Мы всегда должны содержать наш код в чистоте и упростить его обслуживание. За последние несколько лет я прочитал много книг и сообщений в блогах, которые учат чистому программированию. Поэтому я подумал о том, чтобы объединить свой опыт кодирования с моими знаниями в области UX-дизайна. В результате я обнаружил, что когнитивно-психологические теории, которые используют дизайнеры UX, можно применять и для кодирования.
Когда я начал самостоятельно разрабатывать свой собственный продукт NoCodeXpress, не требующий написания кода, и чтобы быть более продуктивным как индивидуальный разработчик, сочетание когнитивно-психологических принципов с кодированием помогло мне стать более продуктивным как индивидуальному разработчику.
Тем не менее, очень меньшее количество проектов разрабатывается отдельными лицами. Когда разработчик пишет код, другим разработчикам в команде должно быть легче его понимать и вносить в него изменения. Работая техническим руководителем, эти практики помогли мне обеспечить качественный код для всей команды.
Практика чистого кодирования повышает производительность
Когда код продолжает давать сбои, поскольку разработчики продолжают вносить изменения в течение длительного периода времени, производительность всей команды падает. Эта ситуация хорошо объяснена в знаменитой книге «Чистое кодирование» Роберта Мартина. Когда производительность команды падает, это влияет на бизнес (например, несвоевременный выход на рынок, увеличение затрат на разработку и т. д.). В результате это имеет неприятные последствия для всей команды разработчиков, поскольку они выпускают программное обеспечение в сжатые сроки, что еще хуже для уродливой/неподдающейся сопровождению кодовой базы. В конце концов, разработчики будут недовольны своим работодателем, а предприятия будут страдать от проблем с производительностью.
Напротив, методы чистого кодирования помогут продуктивно работать всей команде разработчиков. Продуктивные команды могут предоставить программное обеспечение без ошибок в установленные сроки. В результате предприятия также могут получить максимальную выгоду от своей работы.
Практики чистого кодирования дополняют когнитивную психологию
Когда я прочитал и применил лучшие практики из книг Clean Coding и Code Complete 2, я обнаружил, что эти практики работают как по волшебству.
Точно так же опытный UX-дизайнер может порадовать пользователя, разработав приложение, которое вызовет у него вау-фактор. Поработав с несколькими моими коллегами, они научили меня, что делают это, используя принципы когнитивной психологии.
Изучив концепции чистого кодирования и когнитивной психологии, я обнаружил взаимосвязь между ними. Применив эти концепции в различных проектах и получив положительные результаты, я решил поделиться своими знаниями.
Конечно, когнитивная психология — очень широкая и глубокая тема. Я смог применить теории восприятия в своем кодировании. Восприятие в когнитивной психологии связано с тем, как наши пять чувств усваивают и понимают внешнюю информацию. Когда дело касается кодирования, все зависит от того, как его воспринимают наши глаза и мозг.
Чтобы немного больше рассказать о восприятии, позвольте мне показать изображение треугольника Канижи. Он показывает оптическую иллюзию, которая привела к лучшему пониманию того, как мозг и глаза воспринимают визуальную информацию.
Точно так же и в кодировании существуют теории, объясняющие, как его воспринимают наши глаза и мозг. Следовательно, плохие методы кодирования очень вредны для мозга, тогда как чистые методы кодирования благоприятны для мозга. Поэтому, когда разработчик понимает, как очистить код, чтобы сделать его более удобным для мозга, он может писать код, чтобы сделать других разработчиков продуктивнее.
В следующем примере, какой код более удобен для мозга и глаз? Я объясню почему в оставшихся разделах.
Пример неправильного кода
Хороший пример кода
Как принципы гештальта применяются для кодирования
Принципы гештальта определяют, как люди воспринимают группы элементов. Применить эти принципы в визуальном дизайне и дизайне пользовательского интерфейса довольно просто; это совсем другое в кодировании.
Гештальт-принцип близости
Чтобы наилучшим образом использовать закон близости в нашем коде, мы можем организовать код так, чтобы нашему глазу и мозгу было легче воспринимать и разделять логически связанные сегменты и легко понимать детали каждого раздела.
Во-первых, позвольте мне объяснить, что такое закон близости. Когда элементы расположены близко друг к другу, они выглядят как более связанная группа, чем элементы, которые расположены дальше друг от друга. Следующий пример иллюстрирует этот принцип.
Однако кодирование — это не только шаблоны. Это больше о том, как он организован в логически связанные группы или разделы. Когда разработчик создает логически связанные группы понятий (логика, которая работает с одними и теми же данными или выполняет схожие задачи), код становится более понятным.
Согласно Code Complete 2, если операторы правильно упорядочены, вы получите что-то вроде этого.
Если операторы плохо организованы, вы получите такую картину;
В книге «Чистое кодирование» автор объяснил следующие методы создания более логически разделенных групп, что упрощает применение этого принципа для кодирования;
Открытость и расстояние по вертикали: пустые строки между двумя последовательными блоками или концепциями создают вертикальное разделение, которое легче уловить глазу. Кроме того, поддержание соответствующего расстояния (или количества пустых строк) показывает, насколько один блок относится к следующему блоку. Иногда, когда у вас есть код в нескольких файлах, становится сложно перемещаться между ними. Сохранение соответствующего расстояния является альтернативным способом.
Вертикальная плотность. Вертикальная плотность противоположна открытости, подразумевая, что линии, находящиеся ближе друг к другу, тесно связаны с одной и той же логикой.
Объявления переменных. Переменные должны быть объявлены как можно ближе к их использованию
.
Держите зависимые функции ближе. Когда функция вызывает другую функцию, всегда полезно держать зависимые функции ближе друг к другу, чтобы поддерживать естественный поток. Например, когда у вас есть одна функция в верхней части исходного файла и зависимая функция в нижней части, вам придется продолжать прокручивать вперед и назад.
Гештальт-закон хорошего продолжения
Этот принцип гласит, что когда элементы расположены на линии или кривой, они воспринимаются как более связанные, чем элементы, не расположенные на линии или кривой. Это показано в следующем примере;
В мире кодирования мы можем использовать такие тактики, как объединение методов, чтобы наилучшим образом использовать этот принцип, как показано в следующем примере;
Кроме того, вы можете реорганизовать свой код, чтобы сделать его более понятным. Как видно из следующего примера, плохой пример относительно сложно читать. Мы можем упростить чтение с помощью рефакторинга, применив закон продолжения.
Неверный код
Хороший код (рефакторинг плохого кода)
Гештальт-законы фигуры / фона и подобия
Принцип подобия гласит, что когда вещи кажутся похожими друг на друга, мы группируем их вместе. И мы также склонны думать, что у них одна и та же функция. Это показано в следующем примере;
Другой принцип — фигура/фон, также известный как принцип переднего плана или фона. Этот принцип объясняет, как мозг и глаз выделяют фигуру на фоне, как показано в следующем примере;
Хотя эти два принципа не относятся к организации кода, разработчики могут использовать эти принципы для настройки своей темы IDE для повышения своей производительности. В мире кодирования всегда ведутся споры о том, что лучше темная или светлая тема. Тем не менее, я предпочитаю темный режим из-за его преимуществ, таких как снижение нагрузки на глаза и снижение энергопотребления. Кроме того, когда речь идет о фигуре/фоне, темная тема создает лучший контраст, чтобы текст выделялся на черном фоне.
Кроме того, при выборе темы разработчики должны убедиться, что тема различает ключевые слова, переменные, строки и т. д., используя различимые цвета, чтобы облегчить точную идентификацию вещей. Именно так закон подобия применяется к кодированию.
Как видно из следующих примеров, в темной теме лучше контраст и дифференциация ключевых слов с разными цветами, а в светлой теме этого нет.
Улучшите понятность с помощью репрезентативных моделей
В конце концов, наивысшим приоритетом команды разработчиков является предоставление функций, которые удовлетворят клиента, а не решение технических проблем. Более того, для предоставления функций в соответствии с их запросом, если код организован таким образом, чтобы он напоминал реальную бизнес-сферу, всей команде легче поддерживать исходный код.
Во-первых, позвольте мне объяснить ментальную модель, модель реализации и репрезентативную модель с точки зрения UI/UX;
Модель реализации. Это пользовательские интерфейсы, управляющие функциями операционной системы или сервера базы данных. Примерами таких пользовательских интерфейсов модели реализации являются bash и SQL Server Management Studio.
Ментальные модели: такие пользовательские интерфейсы разрабатываются на основе реальных ожиданий, убеждений и эмоций конечных пользователей путем их тщательного изучения. Конечные пользователи считают пользовательские интерфейсы, соответствующие их ментальным моделям, более привлекательными и простыми в использовании. Примерами таких интерфейсов являются Facebook, Uber и Airbnb.
Репрезентативная модель: такие пользовательские интерфейсы находятся между моделями реализации и ментальной моделью. Такие интерфейсы создаются путем компромиссов в пользовательских интерфейсах ментальной модели, которые трудно реализовать.
Когда эти принципы применяются к кодированию, исходный код с моделью реализации способен лучше обрабатывать основные технические детали. Лучший пример — приложение hello world, написанное на Win32/C. Как видите, в нем много строк для обработки простого сценария, который занимается всеми системными вызовами windows.
Напротив, Tkinter в Python использует всего несколько строк для выполнения той же задачи. Так, например, если разработчик хочет создать окно, ему достаточно вызвать несколько методов для создания окна, добавить заголовок и установить его размер. Это пример того, как используются репрезентативные модели. Это не позволяет разработчикам иметь дело с ненужными техническими деталями, предоставляя им методы для достижения того, что им нужно.
Однако модели реализации обеспечивают превосходный контроль над базовой технологией, что очень важно при разработке приложений, требующих высокой производительности. Когда дело доходит до производительности, очень высока вероятность того, что разработчику потребуется дополнительное время для доставки программного обеспечения и внесения ошибок, если он слишком много внимания уделяет техническим деталям.
Чтобы этого избежать, лучше всего использовать хорошую инкапсуляцию и абстракцию. Таким образом, разработчики могут инкапсулировать техническую логику в классы нижнего уровня и использовать эти классы в классах доменной логики верхнего уровня.
Чтобы соответствовать ментальной модели команды разработчиков, разработчики также могут использовать в своем коде хорошие соглашения об именах. В книге «Чистый код» объясняется множество тактик, позволяющих осмысленно называть их. Несколько примеров перечислены ниже;
Используйте проблемные доменные имена: благодаря этому код становится легче поддерживать, а также, если разработчик где-то застрял, он может обратиться за разъяснениями к специалисту по предметной области.
Используйте имена доменов решений. Использование терминов информатики (CS), названий алгоритмов, названий шаблонов, математических терминов и т. д. является хорошей идеей для именования, поскольку разработчики хорошо понимают эти термины.
Используйте имена, раскрывающие намерения. Имена должны раскрывать намерения или то, что они делают.
Используйте описательные имена. При именовании функций всегда полезно описать, что они делают (например, createInvoiceForCustomer()). Именование переменных должно соответствовать тому же соглашению (например, elapsedMinutes вместо минут). Иметь длинное описательное имя намного лучше, чем иметь короткое нечитаемое имя. Кроме того, длинное описательное имя лучше, чем длинный описательный комментарий.
Избегайте когнитивного диссонанса, избегайте стресса
Когнитивный диссонанс означает психический дискомфорт, возникающий в результате наличия двух противоречивых убеждений, ценностей или взглядов. Именно такое чувство вы испытываете, когда читаете плохо организованный исходный код. В результате вы расстраиваетесь, испытываете стресс и гнев.
Антипаттерны, такие как Big Ball of Mud, спагетти-код, разработчики должны любой ценой избегать кода лазаньи. Ниже показано, как выглядит спагетти-код в формате блок-схемы.
Другая ситуация, с которой вы сталкиваетесь с когнитивным диссонансом, — это когда вы имеете дело с плохо структурированными сложными джунглями кода. Это обычно наблюдается в устаревших или старых системах, где модули системы со временем поддерживались многими разработчиками, добавляя и изменяя их.
На следующей диаграмме показана архитектурная схема организации кодирования.
Чтобы преодолеть эту проблему, разработчики должны организовать кодовую базу в хорошо структурированные слои. Будь то микросервис или монолит, разработчики должны хорошо организовать код, чтобы избежать когнитивного диссонанса.
Еще один способ избежать когнитивного диссонанса — использовать принципы SOLID, особенно принцип единой ответственности, наилучшим образом использовать шаблоны проектирования и постоянно рефакторить код.
Уменьшите когнитивную нагрузку, повысьте эффективность
Я уверен, что в какой-то момент, когда вы работали с каким-то уродливым кодом, вы, возможно, чувствовали себя истощенными. Это из-за когнитивной нагрузки, то есть количества информации, которое рабочая память может удерживать за раз. В результате рабочая память имеет ограниченный объем, как показано на следующей диаграмме. Когда мы пытаемся учиться на коде другого разработчика, мы можем столкнуться с этим, если его код плохо структурирован. Когда у вас есть исходный файл с большим количеством строк (скажем, 1400), становится очевидным, что его становится трудно читать или работать с ним.
Чтобы решить эту проблему, рекомендуется реорганизовать код в файлы меньшего размера, потому что маленькие файлы обычно легче понять, чем большие файлы. Также применение принципов SOLID с самого начала поможет предотвратить проблему. Кроме того, рекомендуется уменьшить размер класса, уменьшив максимальное количество строк.
Наконец, продолжайте практиковать чистый код
Вы можете найти много других книг и сообщений в блогах в разделе ссылок, которые помогут вам стать лучшим программистом. Всегда хорошо постоянно оттачивать свои чистые навыки кодирования, изучая, применяя и помогая другим кодировать лучше. Удачного чистого кодирования :)
