После такого наглядного примера, не должно быть вопросов о пользе применения принципов программирования. Осталось только понять, что это за принципы такие.
Сопение. Пыхтение. Пауза. Щелчок затвора. Ура! – Как-то так я сделал свою первую фотографию. Приблизительно так же я написал свою первую программу. Разве что вместо звука затвора случилось нажатие на клавишу компиляции.
Сначала все сделанные фотографии кажутся шедеврами. По крайней мере, до тех пор, пока их не увидят мало-мальски сведущие в фотографии люди. И сразу получите – горизонт завален, пересвет, ужасная композиция и т.п. Что делать? Плюнуть критику в лицо и продолжить штамповать говнофото! Вариант, но если хочется получать выразительные, интересные, сбалансированные снимки – желательно следовать определённым правилам. Таким, например, как правило третей:
Воображаемыми линиями кадр делится на три равные части по вертикали и горизонтали. Изображение выглядит естественнее и интереснее, когда важные объекты располагаются либо вдоль этих линий, либо в точках их пересечения.Это простое правило позволяет существенно улучшить композицию фотографий. И оно действительно работает! Вот, например, обычный снимок:
Когда корабль располагается по центру, фотография кажется статичной и скучной.
Применяем правило третей. Фотография заиграла! У корабля появилось пространство для движения. А дополнительное пространство вверху создаёт акцент на красивом небе.Почему я говорю о фотографии? Потому что так проще визуально показать, на сколько просты и полезны правила, исторически сложившиеся в какой-либо области знаний. Конечно, само по себе применение этих правил не гарантирует, что снимок будет шедеврален, однако шансы получить хорошую фотографию значительно возрастают.
В общем, с программированием та же история - код всегда хорош, если его не надо сопровождать. А того, кто говорит, что ваш говнокод проще переписать, можно больно ударить. Да и вообще - не для каждого приложения высокое качество кода критично. Но качество кода явно выходит на первые позиции при работе в команде и дальнейшей поддержке приложения (или если у вас недостаточно сил побить коллегу).
Что такое качественный код? Можно ли считать хорошим код, где каждый метод содержит 17 слогов, разделённых на три строки в пропорции 5-7-5? Определённо такой код можно считать хайку. Но качественным - едва ли. Вот действительно важные характеристики кода:
- readability (понятность)
- maintainability (лёгкость сопровождения)
- extensibility (расширяемость)
- testability (тестируемость с помощью xUnit тестов)
- simplicity (простота)
Как их достичь? Как и в фотографии, здесь нет рецепта создания шедевра. Но в объектно-ориентированном программировании также существует набор базовых принципов, применение которых значительно увеличит шанс получения системы, которую легко сопровождать и расширять.
Собственно вот они:
- DRY (Don't repeat yourself)
- YAGNI (You ain't gonna need it)
- KISS (Keep it simple, stupid)
И набор принципов проектирования классов от дяди Боба:
- SRP (Single responsibility principle)
- OCP (Open/closed principle)
- LSP (Liskov substitution principle)
- ISP (Interface segregation principle)
- DIP (Dependency inversion principle)
Есть ещё много непонятных аббревиатур, но даже применения этих вполне достаточно для того, чтобы значительно улучшить качество кода. В следущих постах я постараюсь расшифровать их все, и объяснить каким образом эти принципы помогают создавать хороший код.
P.S. Применение принципов в абсолютном большинстве случаев улучшит качество вашего кода или фотографий. Но принципы это не законы, поэтому иногда их можно (и нужно) нарушать :)
Комментариев нет:
Отправить комментарий