Существует множество рекомендаций о том, как прокачать свои скиллы и стать более хорошим разработчиком. Да даже я регулярно пишу на эту тему. Но на самом деле, есть одно золотое правило, которое является основополагающим для всего и именно им нужно руководствоваться в первую очередь, и это – здравый смысл.
Казалось бы, что может быть проще, но именно про это чаще всего забывают, когда начинают жестко придерживаться какой-либо методологии или регламентов. Запомни, из любого правила бывают исключения и невозможно добиться сто процентного соответствия всем параметрам. Но нарушать их нужно с умом и только тогда, когда это действительно нужно. Давай рассмотрим несколько примеров.
Существуют два крайних противоположных мнения, одно говорит, что код обязан быть самодокументируемым и комментариев быть не должно. Другое – в коде обязательно должны быть комментарии, они просто необходимы обязательно. И оба этих подхода абсолютно не верны, первое чем должен руководствоваться идеальный разработчик – логикой и здравым смыслом. Да, если код написан хорошо, то комментарии в большинстве своем могут быть излишни, но полностью от них отказываться нет никакого смысла. Кроме того, что они могут содержать вспомогательные метаданные, так и иногда просто необходимы для объяснения нетривиальных вопросов (например, используется нестандартный алгоритм обработки, потому что он дает лучшую производительность). В таких случаях отказ от комментариев ничем кроме глупости назвать нельзя.
Рассмотрим другой вариант – переменные должны быть подробно описаны в своих именах, однобуквенные переменные и аббревиатуры использовать запрещено. А теперь представь, что тебе придется работать допустим в банковской сфере, и одно из полей будет содержать индивидуальный номер налогоплательщика. Разве будет правильным решением использовать полное именование для этого? Конечно же нет! Общепринятое и широко используемое сокращение ИНН подойдет намного лучше. А то, что в качестве итераторов для циклов уже устоялись имена i и j я даже говорить не буду. В любой предметной области существуют объективно часто используемые сокращения, которые будут куда более информативны, чем полные имена. Но нужно ли везде использовать аббревиатуры? Ни в коем случае, иначе ты рискуешь сделать свой код нечитаемым. Какой выход? Включать свою логику и начинать думать.
Какой язык программирования выбрать? Какая операционная система лучше? Какой алгоритм использовать? Как назвать переменную и метод? На все эти вопросы не существует универсального ответа, который был бы идеальным на каждый случай. Но для того нам и дан мозг, чтобы подключать его и постараться поразмыслить логически. И именно это качество способно выделить программиста на фоне тех, кто будет просто слепо следовать инструкциям. Нет таких правил, которые бы были всегда верны и закрывали все возможные варианты, наш мир слишком изменчив. Поэтому нужно просто быть готовым найти аргументы и обосновано убедить окружающих, что в данном, конкретном случае нужно зайти с другой стороны. Нужно ли нарушать правила постоянно? Конечно нет. Опять же здравый смысл и анализ в помощь.
Большое спасибо за прочтение! Пожалуйста, поставь лайк и подпишись на канал, чтобы не пропустить свежие статьи. Этим ты очень поможешь развитию блога!
Также рекомендую прочитать статью Преждевременная оптимизация