Как компоновать функциональность - один из подходов

Категория: Технические советы

– Автор: Игорь (Администратор)

В рамках данной статьи я рассмотрю один из подходов к решению вопроса "как компоновать функциональность", а так же приведу некоторые ошибки, выливающиеся в потерю времени.

"А не сделать ли мне мега универсальную вещь" - обычно, именно с этих слов начинается создание сложного и кривого инструмента, который если и получает интерес пользователей, то требует, как минимум, нескольких раз практически полной переделки продукта.

Конечно, если у вас за плечами огромный опыт, то вероятность такого события существенно снижается. Однако, чаще всего это не так. Это не плохо и не хорошо. Тут, как говорится - "ковчег был сделан любителем, а Титаник до сих пор слезливый фильм".

Но, прежде всего стоит понимать, что универсального метода компоновки функциональности в природе не существует. Так или иначе переделки всегда будут (возьмите тот же PHP, любую CMS и так далее), можно лишь минимизировать их влияние.

Одной из самых больших ошибок является попытка сразу создать универсальный и мощный механизм / модуль / движок и так далее. Суть ошибки в том, что предусмотреть все возможные случаи или хотя бы большую часть из них может только тот, кто длительное время занимался проблематикой или областью знаний. Простыми словами, чем сложнее механизм и его возможности (в плане универсальности) на первых этапах, тем больше вероятность, что в нем будут существенные огрехи.

Простой пример. Допустим, Коля и Петя полные профаны в строительстве. Перед ними обоими стоит задача прорыть канал для слива воды, а затем укрепить, для надежности. Коля решает взяться за дело основательно и прокладывает бетонные перекрытия, что позволяет избавиться от дыр и предотвратить попадание воды в землю. Петя берет обычные доски, пусть для примера влагостойкие (покрыты смесями и прочее).

Проходит пара лет и оба канала становятся непригодными для использования. Дело оказывается в том, что почва слишком мягкая, отчего перекрытия проседают и с боков их засыпает землей. Таким образом, оба сталкиваются с проблемой отсутствия укреплений фундамента. Конечно, за эти пару лет они уже построили немало каналов и теперь знают "что и как" нужно делать. Однако, что имеем по факту. Коля потратил существенно больше сил и усилий, нежели Петя. При этом в добавок нужно понимать, что бетон тяжелее, отчего его теперь и дольше доставать.

Как видите, пример простой, но хорошо демонстрирует, что в случае неучтенных ситуаций "мега глобальное решение" может быть весьма менее выгодным, чем "около костыльное решение".

Примечание: В рамках статьи, под костыльным решением подразумевается неоптимальное решение с дублированием функциональности, а не "полная кривость" его исполнения.

Неопровержимо, что ситуация могла развиваться и другим путем. Однако, в большинстве случаев происходит примерно по описанному сценарию. Вы можете спросить кого угодно или даже себя "что вы чувствуете, глядя на свое творение спустя года, и что необходимо переделать". Тем не менее, не стоит опускать руки, ведь придирки будут даже к самым универсальным инструментам.

Что же с этим можно сделать, ведь без автоматизации, компоновки и упрощения функциональности сложно обойтись, особенно если речь идет о чем-то большом?

Все просто. Стоит делать компоновку по мере наличия достаточного количества похожих фрагментов и времени их использования в реальных условиях. Таким образом, у вас будет существенно больше необходимых данных для выявления того, что можно объединить в рамках универсальных решений, а что стоит оставить в виде "костыльного решения". В некотором смысле, итеративный подход.

Если рассматривать ранее приведенный пример, то выглядит это примерно следующим образом. Сделали, к примеру, 5 каналов с досками, посмотрели на общие ошибки, возможные доделки и прочее. Выявили общие вещи и скомпоновали их. Допустим, во всех случаях вода протекала, подумали над тем, как можно укрепить стыки (важно понимать, что в данной ситуации у вас есть уже 5 проверенных примеров и будет легче понимать, какие из методов стыковки не стоит использовать). Так же добавили защиту от проседания конструкции. Затем построили еще 5 каналов и так далее.

Примечание: Тем не менее, стоит помнить, что всегда важно учитывать баланс, иначе "по 5 каналов каждые пару лет" может сильно затянуться.

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