Содержание
Что-то удавалось посчитать на пальцах, что-то было отложено до лучших времен. Например боевой товарищ Ломоносовавесьма практически положил жизнь на алтарь теории электричества. Или семья Кюри развлекавшаяся с полонием до того как это стало международным мейнстримом. Techrocks.ru – это качественный контент, созданный инженерами для инженеров. Во-вторых, все эти зависимости не должны быть прямыми.
Если только создатель проекта не забрасывает свою идею вообще (и при этом даже не передает ее кому-то еще), проект, по сути, постоянно развивается. Но при этом нет никакой точки, где можно было бы признать проект «достаточно хорошим» и остановиться. Принцип Don’t Repeat Yourself («Не повторяйся», аббревиатура DRYв качестве отдельного слова означает «сухой») по своей природе очень похож на принцип KISS. Он тоже имеет довольно простое, но широкое значение. Как не сложно догадаться, этот принцип велит вам следить за тем, чтобы код оставался как можно более простым.
Тогда разработчик начинает знакомиться с этими методологиями в рамках выбранного фреймворка, работая с уже реализованными абстракциями, порой не понимая даже, зачем они нужны. Очень простой принцип о том, что надо стараться избегать копипаста. Не потому, что этот участок кода работал плохо, а только лишь потому, что он не соответствует принципам, по которым мы решили писать код. И это действительно происходит в реальных проектах.
OCP требует, чтобы код был открыт для новых, будущих дополнений, и чтобы при их добавлении не приходилось изменять уже написанный код. Этот принцип в большей степени затрагивает вопросы архитектуры, чем кода как такового. Многим разработчикам случается делать копипаст и дублирование фрагментов собственного кода. У всех порой возникает необходимость быстро проверить что-нибудь (ожидаемое поведение или что другое), чтобы определить, стоит ли это писать (т. е., писать правильно).
Вторая важная категория «поехавших», которую хотелось бы разобрать — это люди, утверждающие, что применяют принципы SOLID, но на самом деле этого не делающие. Их аргументация обычно сводится к тому, что солид следует применять не по всему проекту, а лишь в тех местах, где он подходит. Но тут налицо непонимание разницы между паттерном и принципом. Ты либо стараешься следовать ему везде, либо это уже не солид. Пять принципов, которые мы уже обсудили — SRP, OCP, LSP, ISP, DIP — вместе составляют набор принципов SOLID, описанный Робертом Мартином.
Но если это противоречит вашим убеждениям, давайте разберем подробнее. YAGNI это определенно самая длинная аббревиатура в нашем списке. ПринципYou Aren’t Gonna Need It («Тебе это не понадобится», YAGNI) может противоречить точке зрения некоторых программистов.
Написание производительного, эффективного и простого кода – это прекрасно. Дублирование кода – пустая трата времени и ресурсов. Вам придется поддерживать одну и ту же логику и тестировать код сразу в двух местах, причем если вы измените код в одном месте, его нужно будет изменить и в другом. Их использование поможет вам в развитии и позволит стать лучшим программистом. А все эти “торможения из-за классов” – исчезают в компилируемых языках.
Я не разглядывал все близко, возможно они все и Data-oriented. Однако, не думаю, что это достаточное основание приравнивать ECS к DO. Пока она умеет немного, но вы всегда можете помочь автору своими пул-реквестами. Я не претендую на лавры доктора Курпатова, а просто описал то, чему следую сам.
Все дело в прагматизме и навыке выбора лучшего решения для вашей проблемы. Когда вы сталкиваетесь с проблемой при разработке ПО, вы можете воспользоваться базовыми принципами, которые помогут в выборе самого правильного подхода. Думаю, многие из вас применяют эти принципы при разработке ПО как с применением сознания так и без него. Если кто-то по какой-то причине, вдруг, не в курсе про них – срочно покаяться и бежать изучать. А остальным я предлагаю пойти в другую сторону – от программных конструкций к реальной жизни и посмотреть как эти принципы могут помочь сделать её проще. Но как именно следует организовывать эти более мелкие функции?
В этом тексте приводится набор принципов, которые должен знать любой разработчик, и которые следует периодически освежать в памяти. Считайте их своим секретным оружием при программировании. Повторного использования кода, которое, по сути приравнивается к ложным целям. Когда ты работаешь в большой экосистеме разработчиков, тебя развивает окружение и более опытные наставники.
Просто постарайтесь работать осознанно и пробуйте постепенно включать эти принципы в свой рабочий процесс. Этот принцип гласит, что объекты старших классов должны быть заменимы объектами подклассов, и приложение при такой замене должно работать так, как ожидается. Программные объекты должны быть открыты для расширения, но закрыты для модификации. Речь о том, что нельзя переопределять методы или классы, просто добавляя дополнительные функции по мере необходимости. А любители простыней и понатыкать ифов горите в аду.
Как насчет того, чтобы создать несколько классов вместо того чтобы хранить все напрямую в одном классе? Так у нас появляются DevicesController, DiskSpaceController и т. А после мы можем использовать все эти классы, чтобы составить высокоуровневый класс Controller, который теперь будет куда проще поддерживать.
Например, можно начать с простых декомпозиций монолитного кода на отдельные, независимые друг от друга компоненты, обладающие единой ответственностью. Важно соблюдать принцип необходимости — избегать переабстрагирования и неверного применения тех или иных паттернов дизайна архитектуры. Начинающему разработчику всегда сложно разобраться в паттернах проектирования, методологиях и концептуальных подходах, таких как, например, MVC, MVVM или MVP. Многочисленные материалы и статьи по темам не дают конкретики по реализации, а главное, по применению обозначенных подходов на практике.
Не в последнюю очередь чтобы уложить у себя в голове. Поэтому, не стоит тут искать каких-то чересчур глубоких материй. Но есть общие, фундаментальные, принципы, которыми руководствуется большинство причастных к написанию компьютерных программ граждан, вне зависимости от расы и вероисповедания. Готовность к будущему обычно считается делом хорошим, но не в программировании. Оставлять любой код, предназначенный только для расширяемости программы в будущем, это неправильно.
Это часто приводит к рассинхронизации и прочим багам, не говоря уже о том, что от этого увеличивается размер программы. На самом деле, именно простота делает их красивыми. Если вы сбиты с толку, не пытайтесь применять все их сразу.
Liskov Substitution Principle («Принцип подстановки Барбары Лисков», LSP) назван в честь его автора, Барбары Лисков. Это принцип объектно-ориентированного программирования, касающийся классов, интерфейсов, типов и подтипов. как стать программистом с нуля Он должен контролировать температуру CPU, скорость вентилятора, дисковое пространство, внешние устройства и т. Имейте в виду, что это означает не только свойства, но и методы, с которыми мы взаимодействуем.
Будьте прагматичны — подумайте, нужны ли они, поскольку они могут в конечном итоге усложнить вашу кодовую базу. Поймите правильно, предвидеть, что что должен знать фронтенд разработчик произойдет что-то плохое – это хорошо. Но прежде чем вы погрузитесь в детали реализации, убедитесь, что эти оптимизации действительно полезны.
Какое именно «одно действие» должна выполнять каждая из них? Ну, когда вы приобретете больше опыта в программировании, вы начнете чувствовать, где и что следует располагать, а SLAP поможет вам в этом. Пытаться спрогнозировать будущее и представлять, как должен выглядеть ваш код, это не плохо. Но нежелательно оставлять YAGNI принцип в продакшене «точки расширения» (места, предназначенные только для того, чтобы позволить вам в будущем легко добавить новый функционал). Конечно, мы не говорим о случаях, когда речь идет об уже заказанном функционале. Такие точки расширения вносят ненужную сложность и увеличивают размер вашей кодовой базы.
Правильное их написание и организация дают прекрасную возможность улучшить поддерживаемость вашего кода без потерь производительности. Interface Segregation Principle («Принцип разделения интерфейса», ISP) это еще один принцип, затрагивающий тему организации кода. Он главным образом касается интерфейсов и статически типизированных языков программирования. Т.е., люди, пишущие код на JavaScript, не часто будут сталкиваться с применением этого принципа на практике. Тем не менее, знание этого принципа в любом случае способствует улучшению кода.
Писать плохой, но рабочий код, при этом расходуя огромное количество времени на его сопровождение и частичное переписывание для расширения функционала. Курс по основам React в одном видео на примерах и практике от Владилена Минина. SOLID (принцип единственной ответственности, принцип открытости/закрытости, принцип подстановки Барбары Лисков, принцип разделения интерфейса, принцип инверсии зависимостей). С тех пор мне пришлось пару раз подискутировать на эту тему в разных уголках интернета, и я решил, что стоит уже это оформить в отдельный пост. Но беглый гугол выводит много ECS решений для Unity.
Иногда добавление этого уровня абстракции требует усилий, но в конечном итоге они окупаются. У этого принципа много общего с переизобретением колеса, которым занимались в 1970-х. Тогда он звучал как деловая и рекламная метафора. Последовательное применение этих принципов упростит ваш переход от миддла к сеньору. Вы можете обнаружить, что некоторые (вероятно) вы применяете интуитивно.
Их сложность для понимания и применения тоже варьируется. Поэтому я постараюсь поподробнее объяснить теорию, стоящую за каждым из этих принципов. А самую интересную часть — их реализацию — я оставляю вам. Одна из самых распространенных ошибок нашего времени – использование новых инструментов исключительно из-за того, что они блестят. Разработчиков следует мотивировать использовать новейшие технологии не потому, что они новые, а потому что они подходят для работы. Хорошему программисту необходимо уметь совмещать свои навыки со здравым смыслом.
Если ты лишен такой экосистемы, например ты фрилансер, то старайся посещать релевантные конференции, митапы и тусовки своего города и доступных тебе локаций. Старайся общаться, принимать и передавать опыт. Поставь себе цель дорасти до спикера, а не оставаться в слушателях. Начни с классической и концептуальной литературы, не останавливайся на понимании каких-то гайдов к инструментам и библиотекам.
Автор: Olha Bahaieva