Как программисты, мы сталкиваемся с десятками различных типов сценариев при принятии решений. Я работаю в отрасли почти десять лет и видел множество решений, которые могут чрезмерно усложнить программы или даже процессы. Разработчики часто попадают в ловушку проектирования кода или инфраструктуры, которые намного сложнее, чем необходимо. Я определенно виноват и здесь, пытаясь произвести впечатление на коллег или клиентов сложными и перепроектированными решениями до такой степени, что через несколько лет их становится сложно поддерживать мне, моей команде или моим клиентам.

Здесь вступает в игру очень простой принцип, который, как мне кажется, забывают большинство программистов, в том числе и я, KISS. Принцип KISS для читателей, которые не знают, что он означает, Keep It Simple, S глупый. Это звучит немного грубо, поэтому вы часто будете видеть разные варианты, такие как Keep It Super Simple. В целом, это просто означает, что это просто, если вы не можете сказать. Я бы сказал, что это один из самых важных принципов, которого следует придерживаться на любом уровне развития. Я часто напоминаю себе об этом принципе всякий раз, когда мне нужно принять какое-либо инженерное решение.

Почему ПОЦЕЛУЙ?

Вся идея этого принципа состоит в том, чтобы упростить ваш код. Этот принцип может применяться к другим областям, таким как инфраструктура и другие конвейеры между проектами, но, вообще говоря, это больше всего относится к коду. Чем проще ваш код, тем проще будет поддерживать его в будущем.

Вы когда-нибудь так глубоко думали о кодировании решения проблемы, и вы написали удивительный алгоритм, которым вы гордитесь, с временной сложностью, которую вы ищете? Затем вы идете вперед, чтобы объединить этот код, а затем через неделю вы снова посещаете код, потому что была обнаружена ошибка, а затем вы оказываетесь в ситуации, когда вы полностью потеряны, потому что вам нужно напомнить себе об этом решении. вы собрали? Да, это случалось со мной бесчисленное количество раз, и каждый раз я ненавидел это.

Очевидно, что при кодировании решения вы хотите быть эффективным, когда речь идет о вычислительных и пространственно-временных сложностях, но я часто вижу, как многие разработчики, в том числе и я, усложняют решение чрезмерными структурами данных или излишними средствами, когда дело доходит до к используемым библиотекам. Это часто случалось со мной на ранних этапах моей карьеры, когда я обычно хотел произвести впечатление на других или использовать новейшие технологии. Теперь я обычно делаю шаг назад всякий раз, когда заканчиваю реализацию решения или обдумываю решение проблемы, и спрашиваю себя: «Как я могу сделать это проще?»

Просто задав себе этот вопрос, я принял бессчетное количество лучших решений, чем если бы я этого не делал. Я часто вижу, как разработчики коммитят свой код в ту же минуту, когда он заработает, и очень доволен тем фактом, что их код работает так, как ожидалось, после трех дней работы над ним. Очевидно, вы знаете все входы и выходы решения, но никто другой не знает, поэтому я бы сказал, что именно здесь начинается более важная часть, упрощение кода до такой степени, что любой может прочитать и понять его, не тратя слишком много денег. большую часть своего времени на нем. Это, на мой взгляд, важнее самой реализации и того, что действительно отличает разработчиков друг от друга.

Большинство разработчиков могут получить работающее решение, но может ли большинство разработчиков предоставить вам простое и удобное в сопровождении рабочее решение?

Как применять принцип KISS

Как упоминалось ранее, этот принцип действительно может быть применен к большинству частей разработки и даже вне разработки. Тем не менее, вот несколько быстрых советов о том, как вы можете сохранить свою кодовую базу в соответствии с этим принципом:

  • Каждая программа или служба должны делать что-то одно и хорошо. Не перегружайте свою программу функциями, так как со временем это только сбивает с толку как разработчиков, так и пользователей. Это основная причина, по которой микросервисы так популярны. Микросервисы сосредоточены исключительно на одной проблеме, и они очень хорошо решают эту проблему. Имейте такой настрой, когда пытаетесь все упрощать.
  • Создавайте функции для любого фрагмента кода, который кажется вам сложным. Это кажется довольно простой концепцией, но вы будете удивлены, сколько раз я видел монстра, всеохватывающую функцию, которую просто считали «волшебной коробкой». Потратьте время на то, чтобы разделить код на небольшие функции, даже если они используются только в одном месте во всей кодовой базе. Это поможет разработчикам и вам самим быстрее понять код, так как его будет легче читать.
  • Держитесь подальше от причудливых функций или библиотек там, где они не нужны. Библиотеки существуют не просто так, они помогают ускорить разработку, и я полностью понимаю, почему вы должны их использовать. Однако некоторые библиотеки настолько перегружены функциональностью, что это может навредить проекту. Иногда они даже перестают поддерживаться, что вредит вашему проекту, тем более, что вы вкладываете в него уйму времени. Поэтому просто помните об этом, когда будете искать внешние решения. Не проще ли построить самому? Было бы проще изучить эту библиотеку? Вопросы для размышления.
  • Комментирование. Некоторые реализации будут иметь встроенную сложность. Этого нельзя избежать. Чтобы упростить код, прокомментируйте его. Опять же, за свою карьеру я видел много разных типов кодовых баз. Некоторые с фантастической документацией и комментариями, а другие вообще ничего. У меня даже было несколько случаев, когда «код, который вы пишете, должен быть самодокументируемым». Это полная БС. Меня не волнует, насколько чистым может быть код или насколько он самодокументирован, добавление комментариев поможет гораздо больше, чем навредит.

Можно легко заблудиться, когда вы находитесь в глубоком фокусе, и у вас в голове есть только решение. Всегда спрашивайте себя: «Как я могу сделать это проще?» Это отличный вопрос для размышлений. Черт возьми, я мог бы упомянуть и кое-что еще, например, о применении этого принципа к инфраструктурным решениям, но это общие правила, которых я придерживаюсь, когда дело доходит до кодирования.

Вывод

Программирование с таким мышлением может быть не только эффективным, но и сделает вас лучшим разработчиком. Может быть легко забыть о KISS, когда вы погружены в работу, но просто старайтесь время от времени делать шаг назад, чтобы проанализировать то, что вы сделали.

Потратьте некоторое время на то, чтобы инвестировать в свою кодовую базу и упростить ее. Интересный способ, которым я включил это в существующие кодовые базы, заключается в том, что я обычно провожу пятницу, рефакторинг кодовой базы и упрощение кода, с которым я работаю. Это помогает сбить технический долг, который накапливается в вашем портфеле, и может стать забавным занятием в медленную пятницу.

Как всегда, если у вас есть какие-либо вопросы, не стесняйтесь начать обсуждение со мной ниже! Я читаю каждый комментарий, который приходит.

Увидимся, ребята, в следующем!