Привет Хабр

Всегда интересовался программной архитектурой. Читал много статей и примеров. Подходов много, и лучшего конечно же нету.

Данная статья будет показывает мой взгляд на проектирование архитектуры в Unity в компонентно-ориентированном подходе (КОП). Кода в статье не будет!

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

Что такое имя? Имя — это ярлык, дескриптор, указатель в вашей памяти. Это краткое изложение сложной идеи. Оно позволяет ссылаться на «экономику» или «догфудинг» в середине предложения, избегая развернутого на три абзаца объяснения термина.

Если представить, что разработка программного обеспечения — это просто распределение данных по ячейкам и их маркировка, то становится понятно, почему именование объектов является одной из двух сложных задач в информатике. Объем рабочей памяти мозга ограничен, и хорошее имя позволяет использовать его максимально эффективно. Хорошее имя — всегда лаконичное, вызывающее ассоциации и подходящее по контексту. Оно снижает когнитивную нагрузку и лучше отпечатывается в сознании. Плохое имя — это неясное, вводящее в заблуждение, расплывчатое или явно содержащее недостоверную информацию.

Под катом разработчик Джозеф Гласс* делится правилами эффективного нейминга и разбирает их на практических примерах.

*Обращаем ваше внимание, что позиция автора может не всегда совпадать с мнением МойОфис.

От автора поста: ниже представлен Kotlin Code Style на 2 мая 2023 года. Конвенция постоянно меняется, но основные принципы уже заложены и неизменны. Перевод предоставлен без комментариев, как есть.

Привет! Продолжаем цикл постов про чистый код по мотивам видеолекций Дяди Боба, первая часть тут. В этом посте поговорим про структуру функций и не только.

Передача булевых аргументов

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

Как многие разработчики, я прекрасно понимаю, насколько важно создавать приложения, которые будет легко поддерживать, расширять и развивать в долгосрочной перспективе. Именно поэтому принципы Clean Architecture (Чистая архитектура) стали неотъемлемой частью моей работы. В этой статье я расскажу о том, почему следование принципам Clean Architecture так важно и какие преимущества эти принципы могут дать.

Сначала я хотел назвать эту заметку «Редактор связей? Это очень просто». Именно так называл свои прекрасные книжки Евгений Айсберг: «Радио? Это очень просто!», «Телевидение? Это очень просто!» Но поскольку я уже использовал эту шутку в статье о планировщике Windows, чтобы не повторяться, теперь использую любимую формулу многих журналистов: «Вся правда о…».

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

Другое дело я, который сопровождает и даже по мере сил развивает средства программирования. Приходится разбираться и с работой редактора связей, а, значит, как говорится, мне и карты в руки. Попробую кратко и на пальцах объяснить назначение и работу этого программного инструмента. И не просто объяснить, а привести примеры из конкретной реализации. Иначе абстрактные рассуждения плохо воспринимаются. Сам не люблю лекторов, которым кажется, что им достаточно поводить пальцем в воздухе, чтобы аудитория все поняла с полуслова. Так не бывает.

«Жизни многих людей в современном мире зависят от программного обеспечения, например, оно контролирует системы управления большими коммерческими авиалайнерами. Тем не менее, сфера разработки ПО практически никак не регулируется. Любой может стать разработчиком-самоучкой, при этом нет никаких сертификаций или правил, как в других профессиях с высокими ставками, например, в архитектуре или нейрохирургии. Это угрожающе нерегулируемая сфера, хотя несколько строк плохого кода могут привести к смерти».

Так как же объяснить концепцию «плохого кода» обывателю?

Вот уже 10 лет прошло, как я переводил свои средства программирования в среду x86-64 для Windows 7. А как будто вчера было! Поскольку тогда многие особенности этой среды были для меня внове, они вызывали недоумение. Вот типичный пример.

Программирование является необходимым навыком для инженеров по автоматизации тестирования. Однако важно писать чистый код, который понятен и удобен в обслуживании. В этом посте я расскажу, что такое чистый код и зачем он нужен, а также поделюсь 5 практическими советами по написанию чистого кода. 

Что такое чистый код? 

Чистый код — это код на языке программирования, который легко понять и легко поддерживать. Это означает, что код легко использовать и он не имеет непредвиденных последствий при обновлении. Кроме того, чистый код позволяет нескольким людям работать над проектом и следовать согласованным рекомендациям. 

С чистым кодом задачи легко решаются. Каждое решение проблемы начинается с алгоритма. Алгоритм — это план, переведенный в шаблон проектирования. Эффективным шаблоном является Page Object Model, который определяет каждую веб-страницу как файл класса.

Зачем нужен чистый код? 

Одним из преимуществ написания чистого кода является читаемость. Читаемость кода очень важна, так как она может сделать понятным процесс расширения и модификации программы. Кроме того, читабельность кода снижает вероятность путаницы между командой по автоматизации тестирования. 

Это помогает, потому что вся жизнь проекта редко поддерживается его первоначальными авторами.

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

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

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

Что получится, если попытаться описать составной объект? Как ни старайся, ничего другого, кроме древовидной структуры у вас не получится. Отсюда первый принцип:

Привет! В этом посте я хочу обсудить, что такое чистый код и почему я считаю его очень важной практикой. Если у вас всё руки не доходили до того, чтобы сесть и подробно почитать книги Дяди Боба, я подготовил небольшой конспект по его видеолекциям со своими примерами с самым главным.

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

Дядя Боб считает, что единственный способ быстро двигаться в разработке — делать хорошо, поэтому чистота кода очень важна. 

• Отдавайте предпочтение полиморфизму, а не «if/else» и «switch»
• Код не должен знать о внутреннем устройстве объектов, с которыми он работает
• Функции должны быть маленькими
• Каждая функция должна выполнять одну задачу
• Принцип «DRY» — Don’t Repeat Yourself («не повторяйся»)

Речь пойдет о безымянных константах в программе, которые часто называют литералами. Если такой литерал нельзя использовать как непосредственный операнд в машинной команде, компилятору приходится выделять – а куда деваться! – этому литералу собственную память и далее оперировать адресом этой памяти.

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

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

В статье много практики. Сначала я покажу, как с помощью Decompose и Jetpack Compose создавать отдельные флоу приложения. Далее обсудим реализацию bottom-навигации. И, наконец, объединим несколько флоу воедино, чтоб получить навигацию по всему приложению.

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

Вы когда-нибудь задумывались о том, как оценить качество архитектуры вашего кода? В этой статье мы погрузимся в мир метрик устойчивости, абстрактности и главной последовательности. Эти метрики помогут вам выявить слабые места и оптимизировать свои проекты.

О код-ревью уже сказано очень много, но все равно остаются моменты, о которых можно поспорить. Именно их мы не так давно обсуждали на одной из внутренних ИТ-посиделок.

Код-ревью сам по себе - не панацея. Его можно построить так, чтобы помочь проекту. Но эта польза не гарантирована - полно примеров, которым код-ревью идет во вред. Поговорим о том, где здесь скрываются подводные грабли и как провести код-ревью лучше.