Чтобы быть хорошим программистом, мы должны следовать некоторым легко усваиваемым привычкам, чтобы наша карьера программиста оставалась долгой.
В этой статье мы рассмотрим, как сохранить ортогональность в нашем программном обеспечении.
Ортогональная система
Ортогональность в программном обеспечении заключается в том, что у нас есть части, которые не влияют на другие, если мы изменяем одну часть.
Таким образом, если мы изменим что-то одно в нашем приложении, тогда нам не придется беспокоиться о том, что одно изменение нарушит другое.
Это хороший способ снизить риски изменений и упростить их.
Устранение эффектов между несвязанными вещами
Эффекты между несвязанными вещами должны быть минимизированы.
Каждая часть нашего программного кода должна быть автономной, независимой и иметь единственную четко определенную цель.
Таким образом, мы можем изменить одну часть, не беспокоясь об остальных.
Повышайте производительность
Благодаря локализации изменений мы повышаем производительность, не беспокоясь о других частях, которые могут быть затронуты.
Это связано с тем, что снижается риск изменения одной части и поломки другой части нашего программного обеспечения.
Это сокращает время разработки и тестирования. Легче написать относительно небольшие автономные компоненты, чем один большой блок кода.
Можно спроектировать, написать и протестировать простые компоненты, а затем отложить их в сторону.
Нам не нужно беспокоиться о каких-либо дополнениях или изменениях, нарушающих существующий код.
Кроме того, ортогональные компоненты способствуют повторному использованию. Если детали не связаны плотно, то мы можем легко использовать их повторно в разных местах.
Чем слабее соединены детали, тем легче их настраивать и изменять.
Снизить риск
Снижение риска - еще одно преимущество наличия ортогональных компонентов.
Если в нашем коде есть плохие части, то они изолированы, поскольку ортогональные компоненты не влияют друг на друга.
Если один модуль неисправен, тогда проблемы ограничиваются этим модулем, а не распространяются повсюду.
Эту деталь также легче исправить, заменив ее чем-то новым.
Полученная система также будет менее хрупкой, если у нас будут ортогональные части, поскольку изменение одной части не нарушает другую.
Любые плохие изменения относятся к той части, которая была изменена, а не к нескольким компонентам, которые от нее зависят.
Кроме того, вероятно, лучше протестировать, поскольку проще добавлять тесты для независимых компонентов.
Мы также не будем так привязаны к какой-либо библиотеке, поставщику или платформе, поскольку мы можем легко удалить их и заменить на то, что мы хотим выбрать.
Команды проекта
Ортогональность применяется не только к коду, но и к командам.
Мы можем создавать более эффективные команды, если у каждого есть четко определенные обязанности и минимальное дублирование.
Отделение инфраструктуры от приложения - это один из способов разделить нашу систему на более мелкие ортогональные части, которые или более управляемы, чем если бы все это было утомительно.
Каждая часть системы получает свою команду, поэтому каждая команда делает что-то более управляемое.
Поскольку каждая команда работает над меньшим, команды становятся меньше, и накладные расходы на общение ниже.
Однако каждая команда также должна общаться друг с другом.
Дизайн
Системы должны состоять из взаимодействующих модулей, независимых друг от друга.
Их можно изменять по отдельности, и каждый слой и каждый слой отделены друг от друга.
Существует множество шаблонов проектирования, которые служат для отделения компонентов друг от друга.
Например, есть архитектура модель-представление-контроллер (MVC), которая служит для отделения уровня представления (представления) от уровня данных (модели), при этом контроллер является мостом между двумя.
Разделение задач и независимость каждого компонента делает эту архитектуру желательной для веб-приложений.
Их также можно протестировать независимо, чтобы мы могли легко писать для них модульные тесты.
Кроме того, мы не должны использовать свойства вещей, которые мы не можем контролировать. Например, мы должны сгенерировать собственный идентификатор вместо того, чтобы использовать, например, чье-то имя в качестве уникального идентификатора.
Заключение
Ортогональность - это идея, при которой изменение одной части системы не влияет на другую.
Это важно для обеспечения надежности и простоты изменения систем. Это также упрощает тестирование изолированно.
Идея ортогональности также должна применяться к другим вещам, таким как дизайн и структурирование команд, чтобы каждая из них могла быть максимально независимой друг от друга.
