Тут написал правила кодирования, организации работы, взгляды на какие-то вещи – все вместе. Не знаю, как это разделить – думаю, что и не нужно это разделять.
Идеи не претендуют на оригинальность. "Алан Голуб. Веревка ...", "Совершенный код", "Программист прагматик" и другое прочитаны давно, возможно, что-то оттуда продублировано (надо еще раз пролистать, освежить память).
Этот список не претендует на полноту.
Порядок идей в списке хаотичный.
Я не пытаюсь этим кого-то чему-то научить, а, написал это для себя. Впрочем, возможно, вы посчитаете какую-то из этих идей интересной, нет ничего плохого в том, чтобы подчетпнуть ее для себя – я буду этому рад.
Старайтесь использовать понятные имена переменных
- Достаточно уникальные
- Достаточно длинные и понятные
- Имена переменных ссылок – это будет неплохо, если они будут содержать уникатьные слова из изначальных термов
Конечно, тут речь идет о переменных, общих для большого объема кода. Если код вмещается в один или пусть даже несколько экранов, то конечно можно называть проще переменные. Вот несколько примеров
- в локальной области видимости
conn,connection; в глобальной –bookingDbConnection,mainDbConn,mainMongoDbConn - в локальной области видимости
options,opts,config; в глобальной –socks5ProxyOptions,redisLocksConfig
Избегайте необоснованного желания сделать красиво
for await – вы долго будете искать в 12 часов ночи какого черта у вас дублируются запросы, а потом долго будете материть того человека, который все это написал, и вообще, того, кто придумал async/await.
Сделайте это решение, даже если это сложный выбор
Просто, блин, сделайте это и все. Если у вас появляются мысли как это сделать и вы самостоятельно не можете на них ответить (в результате внутреннего диалога не можете выбрать один из нескольких вариантов), то лучше сначала спросить у кого-то аргументы в пользу того или иного варианта. Если нет такого человека поблизости, выберите самый простой для понимания вариант и вариант наименее воздействующий на окружающий код без вреда функционалу.
Обязательно оставьте комментарий в сложных ситуациях
В сложных ситуациях, например, когда вы до конца не уверены, как данный код заафектит все вокруг, вы просто обязаны, я считаю, рассказать о вашем выборе в коментариях к этому коду, поскольку этот код может быть неочевиден и даже противоречить другому коду в проекте (все мы не идеальны). Таким образом:
- Вы сами будете помнить, что и зачем вы написали – вы просто не будете себе и другим казаться сумасшедшим чуваком, который все ломает вокруг
- Когда вы сами или кто-то другой придёт и скажет, что этот код сломал ту фичу, то по комментариям можно будет понять зачем этот код нужен и принять правильное решение – или поменять этот код или поменять код в "той фиче" или что-то третье
- Если проект большой, это поможет не ходить по кругу исправляя одно и ломая другое
Не торопитесь
Когда вы начинаете торопиться, ваш мозг переходит в состояние цейтнота и начитает работать довольно специфически (бей или беги). При этом это частая ошибка (по крайней мере и я был этому привержен когда-то давно и у других замечал). Видимо, это связано с невысказанной атмосферой соревновательности, которая присутствует в компаниях, а так же с чувством профессионального достоинства, когда программист думает, что чем быстрее он это сделает, тем лучше. На практике получается код "на отъебись" – крайне неоптимальный, без какой-то идеи, с кучей багов и неточностей – почти всегда его проще переписать (что, впрочем, редко удается убедить сделать). И он потом выливается или в многочасовые диалоги или в баги в продакшене. Лучше не стесняйтесь, возьмите лишние 3 часа если не уверены или лишний рабочий день и сделайте спокойно.
Берите время на исследование задачи/проблемы
Если вы ни разу не настраивали nginx, не писали mongodb запросов, не настраивали rabbitmq очередь, то не стесняйтесь выделить время на исследование того, как это работает, какие есть подводные камни. Попробуйте сделать тестовый проект и поиграться с этой технологией, сделайте ее своей. При этом явно скажите об этом окружающим, так всем будет все понятно и это честно.
Поспите, перед тем, как городить сомнительный код
Часто, когда вы не понимаете как писать, на самом деле, вы не понимаете, что именно вам нужно сделать и естественное желание начинающих программистов огорадить себя от этой проблемы милионами слоев абстракций (ведь не зря же вы все это читали?). Я не буду говорить очевидного совета, что не нужно так делать и все такое. Я бы посоветовал сделать самое правильное на мой взгляд в такой ситуации – пойти поспать.
На самом деле, это поможет вам по 2-м причинам:
- Когда вы устали, вам сложно принимать решения, кроме того, ваш взгляд на вещи зашорен вашим текущим опытом, поэтому вам сложно отказаться от текущей идеи-фикс
- Во время засыпания и сна (фазы быстрого сна) ваш мозг вырабатывает решения. Он (мозг) уже не находится в состоянии цейтнота (если конечно во сне за вами не гонится кто-то кровожадный) поэтому с высокой долей вероятности вы несколько разочаруетесь в том, что вы делали 10 минут назад. Вместе с этим вы увидите другие варианты, посмотрите на картину под другим ракурсом.
Гордись тем, что делаешь
Не знаю, что тут еще добавить... не скажу, что это самая важная мотивация, но, я считаю, что необходимо испытывать гордость за то, что делаешь. Это делает тебя значимым в своих же глазах как специалиста, побуждает не опускать уровень качества своего кода и своей работы, зачастую, несмотря на внешние обстоятельства, дает тебе спокойствие и внутреннюю уверенность, делает тебя сильнее как личность, позволяя развиваться дальше.
Не старайся казаться умным
Не пишите, так, как будто вы хотите кого-то запутать. Не думайте, что ваш код будет кто-то досконально изучать – его прочтут по диагонали быстренько поняв, что тут происходит (точно так же, как и вы поспупаете). Поэтому, лучше использовать стандартные языковые конструкции. Ситуация, когда одна какая-то загогулина меняет все поведение программы, крайне неприятна, тк. человек, который будет читать ваш код может просто не увидеть ее и это будет причиной многочасовой отладки и когнитивного диссонанса для него. Впрочем, это можно исправить, написав комментарий рядом, о том как работает этот кусок кода (и будет вообще прекрасно, если вы "подсветите" в комментарии ту неочевидную загогулину). В общем, сконцентрируйтесь на решении задачи, а не на том, как красиво этот код выглядит – всем правда плевать.
Не давайте общих советов
Или по другому можно сформулировать – не учите других, как им нужно работать.
Во-первых, это бессмысленно. На что вы рассчитываете, когда даете общие советы? Если вывести людей из себя, то это тоже не самый лучший способ, тк. как правило человек, которому вы их даете уже много раз их слышал и он просто по другому со временем к вам начнет относиться.
Во-вторых, это бесит.
В-третьих, смотрите кому вы даете совет. Не ставьте себя в идиотское положение.
Если человек у вас спрашивает совет, то или скажите, что не знаете или скажите, что он может справится сам или таки напишите ясно, четко и по делу. Не нужно при общении с другими цитировать книги о хорошем программировании.
Постоянно исследуйте готовые решения и применяйте их
Я думаю, что это одно из отличий прикладного специалиста – знание инструментов, лучших практик, готовых решений. Это нужно по вполне понятной причине – не писать все с нуля каждый раз и выбирать именно то, что нужно в данном случае. Есть множество различных источников информации – подкасты, hackernews, различные публичные специалисты в twitter (mastodon, telegram), онлайн курсы, github с различными рейтингами репозиториев. Да просто интересно все это читать.
Не бойтесь изобретать велосипед
Велосипеды полезны – они позволяют быстро и с комфортом добраться на небольшие расстояния, в пределах 5-10 км. Если бы они не были изобретены, это бы стоило сделать. Кроме того, их есть огромное множество конструкций и модификаций под разные нужды. Поэтому не стесняйтесь изобретать велосипеды – новые или необычные способы решить существующую задачу. Но при этом вы должны четко понимать, что и зачем вы делаете.
На первый взгляд кажется, что этот пункт противоречит предыдущему, однако на самом деле если вы хорошо знаете существующие технические решения в предметной области, это даст вам понимание в нужности (или ненужности) того, что вы делаете.
Старайтесь минимизировать диффы в мр
Если вы увидели в коде неправильное выравнивание строк или неправильное форматирование, если вы увидели неточность, даже если вы увидели явный баг – не трогайте его прямо сейчас. Особенно это касается форматирования строк – возникает желание исправить это форматирование и все тут и в мр появляется куча лишних строк, что сильно ухудшает читаемость.
Если у вас стоит проблема неконсистентного форматирования кода, то она решается с помощью линтеров, которые 1. внедрены в IDE, 2. валидируются на этапе коммита 3. валидируется на удаленном сервере на этапе пуша и мержа в мастер.
Если вы увидели, что что-то нужно исправить напишите об этом в отдельный R&D чат или члену команды, который понимает этот код – задайте вопрос нужно ли это исправлять и как другие видят способы исправить это, какие есть преимущества, недостатки у разных способов исправления. Затем, вы можете описать к чему приводит наличие этого бага, который вы нашли и высказать мнение относительно срочности его исправления.
Делайте сразу и просто
Ты не можешь остановить время, чтобы переделать или оставить на потом. За тебя никто не допишет этот код. Всем плевать, насколько мудрено и "как в книжке" ты можешь написать. Старайся минимализировать усилия, направленные на написание и поддержку кода (пиши меньше кода, короче).
Часто нужно просто приложить над собой усилие, чтобы завершить работу. Часто нужно приложить над собой усилие, чтобы остановиться и еще раз подумать, возможно, есть способ сделать проще. Если вы не уверены как именно сделать ту или иную фичу, то проведите исследование перед тем, как делать. Не бойтесь, что вас поругает злой начальник за то, что вы не пишите код – это плохая мотивация. Попробуйте в этом случае сформулировать вашу исследовательскую деятельность. Если это не получается, то возможно, вы находитесь в расфокусе и вы не до конца понимаете, что именно вам нужно сделать. Поговорите с кем-то, кто понимает предметную область. Если ситуация не стала проще, возможно, стоит перенести задачу или ничтоже сумявшись переназначить на другого человека с комментариями конечно, какие именно проблемы мешают ее сделать.
Don't repeat* yourself
Тут я бы подумал, что такое repeat. Это неочевидно, что тот код, который вы физически скопировали, является его логической копией. Иначе все конфигурации nginx, форки на гитхабе, все вызовы функций и методов, у которых совпадают передаваемые пераметры, противоречили бы этому принципу.
В целом, с практической точки зрения, я бы этот принцип немного перефразировал: если вы видите, что некоторые куски кода делают примерно одно и то же, то вероятно, их стоит вынести в отдельную функцию/метод/класс/библиотеку, чтобы упростить поддержку этого кода в случае изменения (не нужно будет менять в нескольких местах, достаточно будет поменять в одном месте). Впрочем, и обратное тоже верно – если вы видите, что у вас появилась куча настроек в общем куске кода, то можно рассмотреть рефакторинг этого кода на несколько методов или вынести этот код в некоторых случаях использования наверх.
Я бы применял этот принцип и на уровне продукта – если появляется много настроек, которые друг с другом находятся в суперпозиции (влияют друг на друга), то имеет смысл редуцировать эти настройки до некоторого множества, которое было бы непротиворечиво и умещалось бы в голове, составляло единое целое. Так же, можно попробовать выделить несколько основных сценариев использования этих настроек и сделать режимы/суперсеты настроек (wrapping, скрытие сложности суперпозиции).
P.S.
Тут можно, если подумать, вспомнить еще много чего. Думаю, что этого будет достаточно, иначе будет слишком душно (скорее всего уже душно).
Часть правил нацелена на то, чтобы избежать ловушки выбора (когда вы не можете выбрать один из нескольких вариантов). Некоторые правила не относятся к коду вообще, но сильно влияют на него. Некоторые правила вполне конкретны, некоторые довольно абстрактны. Так или иначе, они являются сублимацией моего опыта. У каждого он свой, поэтому вполне нормально, если вы не согласитесь с тем или иным пунктом.
