Как реализовать ТВЕРДЫЕ принципы в существующий проект
Вот мои мысли - прежде чем углубляться в детали, я должен сказать, что я ненормальный, когда дело доходит до поддержки браузера.
До тех пор, пока пару лет назад я не пытался поддерживать IE8 и выше. Причиной этой логики было то, что люди, которые «оказались в ловушке» с Windows XP и IE8, были последней версией, поддерживаемой Windows XP. Под ловушкой я подразумеваю, что это были случаи, подобные правительственным, которые были слишком дорогостоящими для модернизации.
После того, как Windows 7 достаточно повзрослела и использование Windows XP упало, я попытался поддерживать IE9 и выше. По сути это означало, что даже после того, как появились полезные свойства (например, flexbox), у меня ушло много времени на миграцию - поэтому я строил макеты с таблицами для лучшей поддержки браузера и т. Д.
Однако, Javascript Frameworks начал отказываться от поддержки старых браузеров (включая IE9), затем CSS-структуры начали отказываться от поддержки. Если вы подумаете об этом некоторое время назад, сама MS уже давно отказалась от поддержки. Крупные мобильные компании отказываются от поддержки своих двухлетних устройств, так почему мы должны поддерживать старые браузеры? Как указано в других ответах, это зависит от аудитории - представьте, что генеральный директор вашей лучшей компании-клиента имеет ноутбук с Windows XP или другим устаревшим устройством - не будет иметь значения, если кто-то еще использует современные браузеры ...
Итак, пару лет назад пришло время выбирать, следовать ли за потоком, быть современным или поддерживать старые устройства. Я полностью поддерживаю последовательность и единообразие контента, поэтому поддержка современных функций для некоторых избранных браузеров и отбрасывание их для других была бы бесполезной для меня. Flexbox был одним из тех свойств, которые подтолкнули меня к отказу от поддержки старых браузеров - это значительно помогло мне уменьшить разметку - тем самым упростив обслуживание. В то же время, даже Bootstrap решил отказаться от поддержки старых браузеров, поэтому должен обновиться, чтобы идти в ногу с конкурентами.
Излишне говорить, что проблема не только в IE, но и в Android, который поднялся до версии 4.4, чтобы стандартный браузер поддерживал определенные свойства - vh, flexbox wrapping и т. Д.
сказал: позвольте мне дать вам прямой ответ:
-
Не беспокойтесь о поддержке IE9 - даже 10. IE10 может быть обновлен до 11 на той же ОС, так что должно быть обновлен в любом случае по соображениям безопасности. IE9 не поддерживается фреймворками JS (например, Ember), в нем отсутствуют переходы CSS3 и другие полезные свойства, такие как flexbox. Без этого ваши проекты должны были бы сделать много шагов назад, если бы вы стремились к согласованности дизайна.
-
Как sidenote, IE10 начал поддерживать свою собственную интерпретацию flexbox (извините за все это постоянство с flexbox, но это одно из самых полезных свойств). Это означает, что для правильной его поддержки вам придется написать много CSS. Представьте себе добавление 30 КБ минимизированного CSS для поддержки только одного браузера, который является довольно редким. Стоит ли это того?
-
Некоторым браузерам веб-пакетов (например, Opera) все еще могут требоваться специфичные для поставщика префиксы для версий браузера, выпущенных 4 года назад, например, для преобразований CSS3. Более важные вещи ломаются в таких браузерах (включая Opera), что я бы больше беспокоился о других вещах. Лично я использую префикс
-webkit-только в некоторых случаях (например, свойства flexbox, которые появились в последнее время). -
В некоторых случаях префиксы, специфичные для браузера, могут оказаться полезными даже в современных браузерах, например, для стилизации ввода диапазона или полосы прокрутки, где вам нужно связываться со свойствами, специфичными для браузера, для достижения согласованности. В таких случаях могут потребоваться специальные CSS-хаки с префиксами вендоров.
В качестве последнего замечания, я бы избегал любых передовых свойств, например, сетки; узнайте, что он делает и как он работает, но пока не используйте его. Вы должны взглянуть на https://caniuse.com/ , чтобы иметь представление о свойствах CSS и поддержке браузера.
Тем не менее, вам решать, и вы должны сделать свой выбор на основе требований вашего проекта. Два года назад я бы посоветовал вам поддерживать столько, сколько вы можете ... тогда вы могли бы достичь одних и тех же целей с разными усилиями, но это уже не так. С самого начала ... старые браузеры не могут идти в ногу.
4 ответа
Принцип единой ответственности - У класса должна быть только одна причина для изменения. Если у вас есть монолитный класс, то у него, вероятно, есть несколько причин для изменения. Просто определите свою единственную причину для изменения и будьте настолько детализированы , насколько разумны . Я бы предложил начать «большой». Переведите одну треть кода в другой класс. Как только вы это получите, начните все сначала с вашего нового класса. Переход от одного класса к 20 слишком сложен.
Принцип открытия / закрытия - Класс должен быть открыт для расширения, но закрыт для изменения. Там, где это целесообразно, отметьте своих членов и методы как виртуальные или абстрактные. Каждый элемент должен быть относительно небольшим по своей природе и давать вам базовую функциональность или определение поведения. Тем не мение, если вам понадобится изменить функциональность позже, вы сможете добавить код вместо изменить код , чтобы ввести новые / другие функции.
Принцип подстановки Лискова - Класс должен быть заменяем для своего базового класса. Ключевым моментом здесь, на мой взгляд, является правильное наследование. Если у вас огромный оператор case или две страницы операторов if, которые проверяют производный тип объекта, то вы нарушаете этот принцип и вам необходимо переосмыслить свой подход.
Принцип разделения интерфейса - На мой взгляд, это принцип очень похож на принцип единой ответственности. Это относится только к высокоуровневому (или зрелому) классу / интерфейсу. Один из способов использовать этот принцип в большом классе - заставить ваш класс реализовать пустой интерфейс . Следующий, измените все типы, которые используют ваш класс, чтобы быть типом интерфейса. Это сломает ваш код. Тем не менее, он укажет, как именно вы потребляете свой класс. Если у вас есть три экземпляра, каждый из которых использует свое собственное подмножество методов и свойств, то теперь вы знаете, что вам нужно три разных интерфейса. Каждый интерфейс представляет собой совокупный набор функций и одну причину для изменения.
Принцип обращения зависимостей - Аллегория родителей / детей позволила мне понять это. Подумайте о родительском классе. Это определяет поведение, но не касается грязных деталей. Это надежно. Дочерний класс, однако, все о деталях, и на него нельзя положиться, потому что он часто меняется. Вы всегда хотите зависеть от родителей, ответственных классов, и никогда не наоборот. Если у вас есть родительский класс, зависящий от дочернего класса, вы получите неожиданное поведение при изменении чего-либо. На мой взгляд, это то же самое мышление SOA. Контракт на обслуживание определяет входные данные, выходные данные и поведение без каких-либо подробностей.
Конечно, мое мнение и понимание могут быть неполными или неправильными. Я бы предложил учиться у людей, которые освоили эти принципы, таких как дядя Боб. Хорошей отправной точкой для меня была его книга Agile Принципы, Шаблоны и Практики в C # . Другим хорошим ресурсом был Дядя Боб на Hanselminutes .
Конечно, как Джоэл и Джефф указали , это принципы, а не правила. Они должны быть инструментами, которые помогут вам вести, а не закон страны.
РЕДАКТИРОВАТЬ:
Я только что нашел эти ТВЕРДЫЕ скринкасты , которые выглядят действительно интересными.
Существует классическая книга Мартина Фаулера - Рефакторинг: улучшение дизайна существующего кода.
Там он предоставляет набор методов проектирования и пример решений для создания существующей кодовой базы. более управляемым и обслуживаемым (и в этом суть принципов SOLID). Несмотря на то, что в рефакторинге есть несколько стандартных процедур, это очень нестандартный процесс, и одно решение не может быть применено ко всем проектам.
Модульное тестирование является одним из краеугольных камней успеха этого процесса. Вам действительно необходимо покрыть существующую кодовую базу достаточным покрытием кода, чтобы вы могли быть уверены, что ничего не сломаете при его изменении. На самом деле использование современных фреймворков для модульного тестирования с поддержкой насмешек приведет вас к лучшему дизайну.
Существуют такие инструменты, как ReSharper (мой любимый) и CodeRush, чтобы помочь с утомительными изменениями кода. Но это, как правило, тривиальные механические вещи, принятие проектных решений - гораздо более сложный процесс, и инструментальной поддержки не так уж много. Использование диаграмм классов и UML помогает. Это то, с чего я бы начал, на самом деле. Постарайтесь понять, что уже есть, и привнести в него некоторую структуру. Затем вы можете принимать решения о декомпозиции и отношениях между различными компонентами и соответствующим образом изменять свой код.
Надеюсь, это поможет и удачного рефакторинга!
Постарайтесь понять, что уже есть, и привнести в него некоторую структуру. Затем вы можете принимать решения о декомпозиции и отношениях между различными компонентами и соответствующим образом изменять свой код.Надеюсь, это поможет и удачного рефакторинга!
Постарайтесь понять, что уже есть, и привнести в него некоторую структуру. Затем вы можете принимать решения о декомпозиции и отношениях между различными компонентами и соответствующим образом изменять свой код.Надеюсь, это поможет и удачного рефакторинга!
It will be a time consuming process. You need to read the code and identify parts that do not meet the SOLID principles and refactor into new classes. Using a VS add-in like Resharper (http://www.jetbrains.com) will assist with the refactoring process.
Ideally you will have good coverage of automated unit tests so that you can ensure your changes do not introduce problems with the code.
More Information
In the main API class, you need to identify methods that relate to each other and create a class that more specifically represents what actions the method performs.
e.g.
Let's say I had an Address class with separate variables containing street number, name, etc. This class is responsible for inserting, updating, deleting, etc. If I also needed to format an address a specific way for a postal address, I could have a method called GetFormattedPostalAddress() that returned the formatted address.
Alternatively, I could refactor this method into a class called AddressFormatter that takes an Address in it constructor and has a Get property called PostalAddress that returns the formatted address.
The idea is to separate different responsibilities into separate classes.
Что я сделал, когда мне представили подобные вещи (и я с готовностью признаю, что раньше я не использовал принципы SOLID, но из того, что я мало о них знаю, они звучат хорошо) это посмотреть на существующую кодовую базу с точки зрения подключения. По сути, глядя на систему, вы сможете найти некоторое подмножество функциональных возможностей, которые внутренне сильно связаны (много частых взаимодействий), но внешне слабо связаны (мало редких взаимодействий). Обычно в любой большой кодовой базе есть несколько таких частей; они кандидаты на удаление. По сути, после того, как вы определили своих кандидатов, вы должны перечислить точки, в которых они внешне связаны с системой в целом. Это должно дать вам хорошее представление об уровне взаимозависимости. Обычно в этом есть небольшая взаимозависимость. Оценить подмножества и их точки подключения для рефакторинга; часто (но не всегда) в конечном итоге возникает пара четких структурных рефакторингов, которые могут увеличить разделение. Принимая во внимание эти рефакторинги, используйте существующие связи для определения минимального интерфейса, необходимого для работы подсистемы с остальной частью системы. Ищите общие черты в этих интерфейсах (часто вы найдете больше, чем ожидаете!). И наконец, внедрите те изменения, которые вы определили.
Процесс звучит ужасно, но на практике он довольно прост. Имейте в виду, это не дорожная карта к достижению полностью идеально разработанной системы (для этого вам нужно начать с нуля),