<rmcreative>

RSS

Все заметки с тегами «сложность, Паттерны»

Можно уточнить:

  1. Архитектурные паттерны

    21 сентября

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

    Архитектурные паттерны вроде clean architecture или hexagonal architecture мало чем отличаются от привычных паттернов проектирования в плане их применения. Как и с паттернами с свойственной им стадией «паттернизма», с архитектурными паттернами случается ровно то же. Практически все в определённый момент читают про очередной модный паттерн и начинают его бездумно применять. Не потому что он решает их конкретные проблемы, а потому что модно и «правильно».

    Применять любой паттерн без должного анализа решаемой проблемы вредно.

    В идеале должен происходить следующий процесс:

    • Анализ решаемой проблемы.
    • Выделение мест, которые должны быть гибкими.
    • Выделение болей. Поиск паттернов, которые могут их решить или изобретение решений (это часто не хуже).
    • Повторный анализ решения, которое получится. Можно ли проще?
    3 комментария
  2. Хорошие программисты и сложность

    27 октября 2014

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

    Чаще всего мешают им фанатичность, нетерпимость к альтернативам и полное отсутствие прагматичного подхода. От них часто можно услышать что-то вроде:

    • Код надо обязательно покрыть юнит-тестами на 100%. В тестах надо делать моки через мок-фреймворк.
    • Ни в коем случае нельзя писать связанный код.
    • Всегда без исключений надо следовать SOLID, DRY, GRASP и т.д.
    • Абсолютно все приложения надо строить по DDD.
    • Для доступа к данным обязательно нужен крутой ORM.
    • Писать документацию нет смысла, потому как она всегда отстаёт от кода. Код — лучшая документация.
    • Если в коде есть комментарии, код недостаточно отрефакторен. Всегда можно разделить код и назвать методы так, чтобы отразить предметную область.
    • Невозможно построить хорошую архитектуру без ООП.
    • И так далее.

    Знакомо? Всё это выливается в непрактичные решения, реальной целью которых является доказать собственную правоту и крутость сделав «как учат в умных книгах». Реальность при этом частенько не учитывается.

    Не следует забывать, для чего на самом деле мы пишем код. А именно:

    1. Чтобы он работал и решал поставленные задачи.
    2. Чтобы его могли прочитать, осознать и изменить другие программисты.

    Для пункта номер два следует вносить в код как можно меньше сложности. Оправдана она только в том случае, когда другого выхода нет.

    Это не означает, что не надо изучать шаблоны проектирования, читать Фаулера и т.д. Надо. Просто во всём надо знать меру и не бросаться применять прочитанное с особым энтузиазмом и уж, тем более, не стоит это делать, если вы не понимаете, для чего это и как оно упростит вам жизнь (и упростит ли вообще).

    39 комментариев