"Лучшие решения, а также другие забавные мифы"
(http://www.danappleman.com/index.php?p=33)
Автор: Дан Эпплман (Dan Appleman)
Дата: 24.01.2005
Перевод: hCORe
Редко на какой конференции, связанной с компьютерами, не ведутся доклады о "лучших решениях" всевозможных проблем. Поиск на Amazon.com выдает 166 книг компьютерной тематики с обещаниями "лучших решений" прямо в названии книжки и ошеломляющие 2500 совпадений, если искать в описаниях самих книг.
Что же это такое - лучшие решения? Для большинства - это отражение степени профессионализма. Чтобы быть профессиональным разработчиком ПО, надо иметь большую базу знаний. Чтобы быть хорошим разработчиком - надо знать и того больше. Обучение программированию и изучение языка (а лучше - трёх) - простая задача, но это только начало. Нельзя забывать, что существуют многочисленные средства как для разработки программ, так и для управления ими. Это и платформа, для которой вы пишете приложения (.NET Framework, Win32 API и т.д.), и сервисы, используемые вами (web-серверы, базы данных...) Все эти средства нуждаются в настройке. Большинство имеют свои внутренние языки программирования (например, я совсем недавно завершил проект, в котором мне приходилось одновременно писать код для VB.NET, C#, Regex [регулярные выражения], JavaScript и SQL.)
А база знаний - штука изменчивая. Через год-два приоритеты меняются, а база становится все больше и сложнее (уверен, .NET 2.0 в два раза лучше чем 1.1 - но во столько же раз сложнее его изучать.)
Мы не можем знать все. Если повезет, поймешь и запомнишь то, что нужно для решения сегодняшних задач. И только эксперт в какой-либо области может научить нас тому, что нам нужно - разумеется, показывая собственные решения, проверенные на опыте. То есть - "лучшие решения".
Звучит хорошо, не так ли?
Проблема в том, что эти "лучшие решения" запросто могут причинить вам вред. Потому что фраза "лучшие решения" ошибочна. Она неполна.
Правильная же фраза звучит так: "Лучшие решения для проблем класса такого-то".
"Лучшие решения" всегда связаны с определенным набором ситуаций. И если вы не знаете этих ситуаций, может приключиться беда. Ведь наилучшее решение для одной ситуации может стать наихудшим в другой.
Для примера:
Представьте, что вы создаете ASP.NET web-приложение. Каждый знает, что хорошо снижать нагрузку на сервер. Большинство "лучших решений" для ASP.NET содержат рекомендации по уменьшению трафика и снижению нагрузку на сервер. Вроде переноса процедур проверки данных на сторону клиента. Или выключения сохранения состояния страниц там, где это возможно.
И вы точно знаете, что эти рекомендации правильны и хороши.
Однако...
Представьте себе, что это же web-приложение содержит раздел, занимающий пол-сайта, который используется ужасно редко. Например, к нему имеют доступ только администраторы. Или он вообще никому не нужен.
Программирование web-приложения, активно использующего скрипты на клиентской стороне, может быть чрезвычайно сложным. Куча проблем возникает при разработке, отладке, управлении. Да и стоит разработка и поддержка во много раз дороже. Выходит, эти "лучшие решения" часто невыгодны. Их дорого и трудно реализовывать, а выгод от использования этих техник никто и не заметит.
Я видел проекты вроде этого, в которых разработчики придерживались рекомендаций Microsoft или экспертов, а в итоге приходили к первоклассным реализациям убогих архитектур приложения. Лучшие решения не заменяют понимания основ.
Так что, в следующий раз, включаясь в разговор о лучших решениях, или читая книгу, в которой о них говорится, не забудьте остановиться на минутку и подумать: "О лучших решениях для каких видов проблем идет речь?" Если это не ваша проблема, очень вероятно, что решение не подойдет вовсе.