Заметки непосредственного специалиста из мира программирования о профессии

Самодостаточность шаблона

Конечно, код пишется в первую очередь для машины, а потом уже для людей. Тем не менее, принимать кого-то нового и постороннего в свою среду, уж тем более ощущать его присутствие – бывает довольно-таки непросто. Например, вот проект, над которым я работаю. Вот тут у меня были функции: getUserHandler, createUserHandler, getUsersListHandler. А вот кто-то создал рядом ещё одну, назвав её loadSettingOfUser – это как это так?

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

Задача самого шаблона тоже довольно нехитрая – чтобы его существование было ясно, и лишний раз никому в голову не приходило бы его нарушать – это должно ощущаться чем-то вроде испачканной белой рубашки, выбрасыванию окурка посреди чистого тротуара и т. п. Впрочем, переделать сам шаблон – почему нет, если никто не против, если хватит сил и энтузиазма. И на этом моменте про шаблоны, пожалуй, всё – либо понятно, либо нет: можно обосновывать дальше и дальше, но опыт подсказывает, что это бессмысленно. Человек даже может согласиться со всеми аргументами, но если трёх абзацев не хватило – вероятно, ему не хватит и целой книги на эту тему. Что впрочем вовсе не свидетельствует о его профнепригодности.

«Пишем комментарии»

// Получаем имя пользователя username := getUserName()

Часто встречал комментарии, написанные подобным образом. Может даже и сам когда-то писал такие – уж наверняка, «шаблоны», все дела. Однако, одумался. И, нет – мы ничего здесь не получаем, получает машина, а человек, пожалуй, пишет код. Нет, ну, можно, конечно, представлять, что вот он – компьютер, а я вместе с ним как некая «мамочка» – и вот, мы что-то там получаем.

 // Получение имени пользователя  username := getUserName()

Ну, согласитесь, стало же лучше?

Стандартизация глубинная

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

В этом плане мне довольно близка идеология языка Golang. Однако, не смотря на его строгость, в нём тоже есть моменты, когда можно сделать совершенно одно и то же, но разными способами. Пример:

len(val) == 0 // или val == ""

Круто, когда одна задача – одно решение. Но здесь сам язык вынудил фанатов стандартизации допустить такую ситуацию, ничего не поделаешь — вроде как можно и длину строки получить, а вроде как можно и сверять её с константой. Спойлер: если речь идёт о проверке на пустую строку, то, конечно же второй вариант предпочтительнее – сразу ясно, что val – строка, а не slice или map. В таких ситуациях достаточно определиться один раз и дальше делать аналогично – на этот случай встречаются всяческие сборники рекомендаций и соглашения (наподобие «Go Code Review Comments»).

Чем проще, тем лучше

Это одна из немногих аксиом программирования. Хотя, возможность трактовать слово «проще» на свой лад всё равно остаётся за человеком: проще для восприятия программистом? Проще в абстрактом смысле? Проще для исполнения машиной?

Гляжу очередную вакансию, такс, такс, такс, что тут у нас? Docker, Kubernetes, Helm, Prometheus, Grafana и Kafka… Так, вы что, хвастаетесь? Это звучит примерно как если бы я сказал – «за свою жизнь я переболел триппером, сифилисом, гепатитом, плотно сижу на стимуляторах и имею за плечами судимость» – ну, то есть, нечего стыдиться, окей, допустим. Но только и радоваться тоже нечему. Если пытаться меня заманить подобным списком, подумайте – может что-то всё-таки вы добавили для так, для красного словца, и ещё не поздно вычеркнуть? В идеале – для таких случаев существует некая локальная документация / набор неких ссылок, и новому работнику нет необходимости быть знатоком подобных технологий – он просто разбирается в них на ходу.

Документация и отношение к ней бывают разными, где-то прям фанатеют и чуть ли не дублируют то, что вполне ясно, например, из кода – уж не знаю, может иногда это и верно. Где-то полностью забивают на неё, спустя долгое время работа над проектом превращается в некую «археологию». Вообще, я считаю, полезно во время работы в компании заранее готовиться к своему увольнению – делать всё, чтобы проект было легко принять следующим разработчикам. Нынче я, впрочем, делаю это только, что называется, «по-любви» – если у компании аналогичная политика. В противном случае, например, уровня «получше чем было» может оказаться достаточно.

Я наблюдал разные экосистемы, видел, например, монолитный проект на Golang’е, где не использовались не то что модули, но и вообще никакие менеджеры зависимостей – какой версии библиотеки туда попадали, такой они там и оставались до конца, распространяясь zip-архивом почти на гиг. И это, конечно же, обратная крайность – когда проект варится исключительно в собственном соку.