Я серьезно, и я не вижу достаточного количества людей, которые это делают!

Да, вы меня правильно поняли, и я полностью осознаю, что если вы инженер, который никогда раньше не слышал выражения «KISS», вы можете неловко смотреть на свой ноутбук/ПК, но не волнуйтесь, это просто означает Будь проще, глупец. Есть несколько вариаций этой аббревиатуры, но я думаю, что это основная, и она сводится к простой концепции: не переборщите с разработкой решения и сделайте мир более легким местом для себя и других.

Ну и что это вообще тогда?

Это очень просто (что в некотором роде важно), я нахожу много случаев, когда инженеры чрезмерно усложняют простую задачу во имя «х-стандарта», «Y-практики» или чего-то, что кажется угрозой ненадежности, как говорится. известное изречение:

«Программисты часто прибегают к понятной, но пагубной склонности к сложности и изобретательности в своей работе». Майкл А. Джексон, Принципы разработки программ

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

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

Почему я должен помнить об этом?

Это полезно помнить, когда это поощряет привычку использовать небольшие изолированные функции, которые можно использовать повторно, которые имеют простую цель и являются ЧИТАЕМЫМИ. Вы всегда должны комментировать свой код таким образом, чтобы прояснить что-то странное или нюанс, но базовая функциональность функции должна быть очевидна из имен функций, имен переменных и логики единой ответственности, она должна стоять сама по себе, не нуждаясь в комментариях.

«Лучше иметь и не нуждаться, чем нуждаться, но не иметь». Джордж Эллис

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

Если мы посмотрим на пример, это одна из основных координирующих функций из моей статьи о чистом сервисе Go, без комментариев то, что она делает, довольно очевидно, даже если вы не Go-разработчик.

Даже без комментариев, без знаний Go, на которые я бы поставил деньги, вы можете мне точно сказать, что это может сделать, потому что это просто и понятно!

Сноска к этой части, важно помнить, что «читабельный» означает разные вещи для разных людей, в языках есть общие шаблоны, которые поощряют называть вещи определенным образом, например, имена переменных r, w и err не очень ясны, пока это не в этом:

func MyHttpHandler(w http.ResponseWriter, r *http.Request)

Почти каждая HTTP-библиотека на земле, поддерживающая базовый обработчик net/http, будет реализовывать этот шаблон в примерах и документации, поэтому, хотя вы обычно не называете переменные одной буквой, здесь это имеет смысл, как и ожидает почти каждый разработчик Go. это то же самое, когда err является именем вашей ошибки, это распространенный и ожидаемый шаблон.

Значит, целуйтесь все время?

Ну в основном да, но иногда нет. Бывают ситуации, когда принуждение к простоте подводит вас и в конечном итоге приводит к усложнению позже, плюс простота, как и зло, всегда зависит только от точки зрения, поскольку то, что может быть простым для вас, усложняет жизнь другим.

Например, я создам свой микросервис для использования пакета журнала по умолчанию в Go, это выведет мои ошибки на stdout и stderr, красиво и просто, независимо от того, где я запускаю эти вещи, они всегда короткие и приятные и выполняют свою работу. , потрясающий!

Теперь, когда я перенесу это в кластер Kubernetes, у меня будет инженер DevOps, которому нужно будет внедрить демон ведения журналов для переноса этих журналов на любую платформу, которую я использую, включая дополнительные развертывания, которые необходимо отслеживать, а затем анализировать то, что я Я вывожу в структурированный формат журнала и экспортирую его туда, куда я его отправляю, не так уж здорово.

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

Заключение

Короче говоря, делайте вещи настолько короткими и простыми, насколько можете, никто не будет думать, что вы лучший инженер, когда вы набираете 10 строк кода вместо 1000, особенно когда они делают одно и то же (лично я бы выглядел добрее к 10-строчному решению, поскольку оно более эффективно), вы сделаете себе одолжение, когда вам придется вернуться и поддерживать его. И не забывайте о более широкой картине, что может быть просто для вас, может быть не так для других, стоит сделать шаг назад, чтобы потом всей командой бежать вперед!