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

Почему я это делаю

Я думаю, что важно изучить мою мотивацию. Во-первых, я не буду здесь ничего кричать. По общему признанию, я испытываю любовь / ненависть к Го. Каждый день, работая с Go, я обязательно испытываю множество взлетов и падений. В некоторые моменты я восхищаюсь элегантной простотой языка или просто рад быстро решить проблему параллелизма. Я всегда удивляюсь легкости, с которой я могу кросс-компилировать код для альтернативных операционных систем и архитектур ЦП, на самом деле это часто моя самая большая мотивация для использования Go - это и тот факт, что это, несомненно, lingua franca распределенных вычислений. Но есть вещи, которые сводят меня с ума ...

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

Сущность против Церемонии

Много лет назад я был так же глубоко укоренен в экосистеме Java / Spring, как и сейчас в экосистеме Go. Неоднократно мне доводилось слышать, как Венкат Субраманиам говорит о том, что он назвал «сущностью против церемонии». В то время это было представлено в контексте Java vs Groovy, но это понятие применимо в более широком смысле, чем это. Я перефразирую, но Венкат определил «сущность» как определенное je ne sais quoi, которое делает язык полезным. Он определил «церемонию» как всю нелепую работу, которую вы выполняете вручную (или с помощью инструментов) в качестве рутинной процедуры для устранения недостатков языка или просто потому, что кто-то сказал вам, что это лучшая практика. Венкат утверждал, что Java - это «церемония», в то время как Groovy содержит больше «сущности».

Я не хочу, чтобы этот пост превратился в пост, посвященный Java, но я думаю, что было бы полезно изучить простой пример на основе Java.

В Java видимость атрибутов класса и функций-членов может быть указана с помощью таких ключевых слов, как public, private и protected. Если кто-то хочет, чтобы какой-то атрибут одного класса был видимым для других классов, может возникнуть соблазн сделать атрибут public, но во многих случаях это нарушит инкапсуляцию. Возможно, например, допустимо, чтобы значение атрибута читалось другими классами, но не изменялось. Обозначая такой атрибут как public, желаемый характер атрибута только для чтения не применяется, и внутренняя работа класса потенциально начинает просачиваться в остальную часть вашего кода. Это не буэно. На протяжении всего времени существования Java разработчики работали над этим, создавая public функции-члены, называемые аксессорами и мутаторами ( или, проще говоря, «геттеры» и «сеттеры»), которые управляют доступом к private атрибутам. Это улучшает соблюдение основных принципов объектно-ориентированного проектирования. Хотите, чтобы атрибут был доступен только для чтения? Без проблем. Предоставьте только "получатель".

Плохой:

Лучше:

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

Groovy (который компилируется в байт-код Java и выполняется в JVM точно так же, как Java) решает эту конкретную проблему, при отсутствии каких-либо модификаторов доступа для атрибута генерируя соответствующие «геттеры» и «сеттеры». для вас во время компиляции.

Тот же пример в Groovy:

Этот пример логически идентичен лучшему из наших двух примеров на Java, но идет без «церемониального» налога. В этом суть.

Ах да ... мы говорили о Go ...

Что ж, друзья мои. С сожалением сообщаю вам, что, хотя Go обладает большой сущностью в отношении определенных проблем - например, я считаю, что его подход к параллелизму соответствует требованиям, - тем не менее, в отношении многих других проблем он чрезвычайно высок. на церемонии - возможно, больше, чем на любом другом языке, с которым я работал. Это значит, что объем лучших практик, с которыми вы должны быть ознакомлены, чтобы писать (что я считаю) хорошим кодом Go, ошеломляет.

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

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

Что ожидать

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

Следите за новостями о первом (реальном) взносе, который выпадет на следующей неделе!