Вы познакомились с синтаксисом языка? Вы знаете, что такое переменная, класс, условные операторы и циклы? Теперь нужно учиться программировать, нужно начать использовать знания для написания реальных приложений.
Почти все, что касается стиля и оформления кода может вызывать серьезные споры среди программистов, потому что все это дело вкуса – один программист любит один стиль, другой любит что-то другое и очень часто существует два лагеря, которые поддерживают какой-то стиль.
В этом разделе мы поговорим о именовании переменных, методов и классов. Правила тут менялись и даже сейчас в разных языках принято использовать немного разные подходы, ярким примером являются Objective-C со своим реально уникальным подходом. В этой же главе я подведу итоги того, что я считаю правильным.
Отношение к комментариям со временем менялось. В старые времена рекомендовалось писать как можно больше комментариев и давать пояснение коду. Перед каждым методом писали подробную информацию о том, что делает метод, какие параметры он получает и что возвращает. В Java и других языках даже появилась возможность создания документации на базе кода.
Эта глава может вызвать халивар, потому что тут будет много вещей, которые каждый программист может принять по-разному. Для кого-то эталоном красоты является Анжелина Джоли, а для кого-то Шарлиз Терон, это дело вкуса каждого, на кого молится. Я же расскажу свои мысли по поводу оформления кода и что работает в моем случае.
В этом части мы поговорим о различных небольших вопросах, которые не вписались в предыдущие главы. Ради каждой из этой тем создавать целую главу нет смысла, а вот объединить их все под одним заглавием будет удобно для меня и вас.
Я очень часто вижу разговоры в интернете о том, что тесты необходимы. Но когда дело доходит до реальных проектов все почему-то если и пишут что-то, то только реальные тесты методов и абстрагируются от всех зависимостей. Плюс тесты, которые тестируют конечный продукт.
С появлением интерфейсов и популяризацией инъекции зависимостей Dependency Injection все больше и все чаще вижу тех, кто программирует интерфейсами, когда нет прямого доступа к классам, а на каждый кашель запускается инъекция.
Далеко не всегда получается написать идеальный код сразу же с первого шага. Даже после стольких лет работы программистом мне достаточно часто приходиться запускать редактор кода и начинать что-то набрасывать как черновик. Как и художники или писатели программистам очень часто приходиться делать какие-то наброски, прежде чем переходить к чистовой работе.
Когда я попал в Канаде в консалтинговую компанию и впервые столкнулся с git то совершенно не понял его. В документации каждый брэнч называли экспериментом и совершенно непонятно было, зачем это нужно. Чтобы реально ощутить весь кайф от брэнчей git мне понадобилось около месяца, нужно было на практике увидеть весь кайф.
Чтобы этот пример был максимально реальным к жизни, когда я работал над PHP Symfony я сначала написал код в процедурном стиле, когда вся логика была реализована прямо в основном контроллере. Потом мы стали переносить код в отдельную бизнес логику и контроллер стал лучше, но все же не идеален и сегодня мы посмотрим, что именно указывает на проблему в коде.
Еще одна проблема примера из мануала по Symfony – наличие метода getCategories у класса CategoryModel, который выглядит так:
Во время выполнения кода могут возникать ошибки, что-то может пойти не так и нужно быть готовым корректно отреагировать на внештатную ситуацию. Мы не можем гарантировать, что всегда будет интернет, что всегда будет достаточно места на диске и что пользователь будет вводить то, что мы ожидаем.
Если честно, то меня бесят заголовки типа «делаем что-то как профессионалы» или «советы профессионалов». Это кликбейтные названия, за которыми нередко спрятаны советы далеко не профессионалов, а. . . ну не будем вешать ярлыков, потому что я сам намеренно взял и сделал такое кликбейтное название.