Продолжаю цикл статей, связанных с правилами Эрика Реймонда из «Искусства программирования под Unix».
В прошлом посте я писал о правиле модульности. Напомню, он был о том, что простые блоки должны соединяться ясными и понятными интерфейсами.
Сегодня речь пойдет о следующем правиле —
Правило ясности: Ясность лучше заумности (или ясность лучше, чем мастерство)
Rule of Clarity: Clarity is better than cleverness.
Наверное, вы не раз слышали о принципе и процессе проектирования, известного как KISS. Эта аббревиатура расшифровывается как «Keep it short and simple» («делай это просто») или «Keep it simple, stupid» (что-то типа «не усложняй, тупица!»). На практике, оно выражается в том, что если вам известно два решения задачи — простое и сложное, то стоит два раза подумать, прежде чем останавливать выбор на втором.
Очень часто программисты сами себе ставят задачи, не адекватные поставленной им цели. Придумывают для себя проблему, чтобы героически ее преодолеть. Сюда относится написание всевозможных «движков», позволяющих решить не только поставленную задачу, а целый класс задач. Например, вместо того, чтобы взять готовый поисковый механизм, пишут его сами. Конечно, задача становится интереснее, но риски получить нестабильное решение оказываются выше, а поддержка — гораздо затратнее.
Маленькое отступление в сторону: Здесь очень распространена ситуация, что, возможно, вы додумали себе требования, которых не было в исходной задаче. Они действительно могут быть не лишними, но их ни в коем случае нельзя прятать в себе. Если у задачи заказчик внешний, то очень правильно эти требования фиксировать и утверждать, показывая альтернативы, риски, преимущства и недостатки.
Стоит вспомнить известные выражения Альберта Эйнштейна, относящиеся к этому правилу: «Всё следует упрощать до тех пор, пока это возможно, но не более того» и «Вы не можете утверждать, что понимаете что-либо, до тех пор, пока вы не сможете объяснить это своей бабушке». Не уверен, что логику системы подбора аксессуаров или обработки прайс-листов я смогу объяснить бабушке. Но объяснить кратко и емко человеку от бизнеса — должен. Если это не удается, вы придумали слишком сложную систему. Упрощайте, иначе она — не жилец…
Есть близкое к теме философское понятие, «бритва Оккама». Суть его в том, что если существует несколько определений или объяснений какого-то явления, то следует считать правильным самое простое из них. Но чаще «Бритву Оккама» вспоминают в другом контексте, «Не умножай сущности без надобности» (что не совсем верно по отношению к философу, но правильно само по себе). Это правило пригождается практически на каждом шагу в программировании.
Итак, резюмирую:
В прошлом посте я писал о правиле модульности. Напомню, он был о том, что простые блоки должны соединяться ясными и понятными интерфейсами.
Сегодня речь пойдет о следующем правиле —
Правило ясности: Ясность лучше заумности (или ясность лучше, чем мастерство)
Rule of Clarity: Clarity is better than cleverness.
Наверное, вы не раз слышали о принципе и процессе проектирования, известного как KISS. Эта аббревиатура расшифровывается как «Keep it short and simple» («делай это просто») или «Keep it simple, stupid» (что-то типа «не усложняй, тупица!»). На практике, оно выражается в том, что если вам известно два решения задачи — простое и сложное, то стоит два раза подумать, прежде чем останавливать выбор на втором.
Очень часто программисты сами себе ставят задачи, не адекватные поставленной им цели. Придумывают для себя проблему, чтобы героически ее преодолеть. Сюда относится написание всевозможных «движков», позволяющих решить не только поставленную задачу, а целый класс задач. Например, вместо того, чтобы взять готовый поисковый механизм, пишут его сами. Конечно, задача становится интереснее, но риски получить нестабильное решение оказываются выше, а поддержка — гораздо затратнее.
Маленькое отступление в сторону: Здесь очень распространена ситуация, что, возможно, вы додумали себе требования, которых не было в исходной задаче. Они действительно могут быть не лишними, но их ни в коем случае нельзя прятать в себе. Если у задачи заказчик внешний, то очень правильно эти требования фиксировать и утверждать, показывая альтернативы, риски, преимущства и недостатки.
Стоит вспомнить известные выражения Альберта Эйнштейна, относящиеся к этому правилу: «Всё следует упрощать до тех пор, пока это возможно, но не более того» и «Вы не можете утверждать, что понимаете что-либо, до тех пор, пока вы не сможете объяснить это своей бабушке». Не уверен, что логику системы подбора аксессуаров или обработки прайс-листов я смогу объяснить бабушке. Но объяснить кратко и емко человеку от бизнеса — должен. Если это не удается, вы придумали слишком сложную систему. Упрощайте, иначе она — не жилец…
Есть близкое к теме философское понятие, «бритва Оккама». Суть его в том, что если существует несколько определений или объяснений какого-то явления, то следует считать правильным самое простое из них. Но чаще «Бритву Оккама» вспоминают в другом контексте, «Не умножай сущности без надобности» (что не совсем верно по отношению к философу, но правильно само по себе). Это правило пригождается практически на каждом шагу в программировании.
Итак, резюмирую:
- Давайте ход в первую очередь простым и понятным решениям;
- Все сложные решения подвергайте критическому анализу, желательно на самом раннем этапе, пока не убедитесь, что упрощать себе дороже;
- Любое усложнение должно иметь основание, в идеале согласованное и утвержденное с заказчиком
| « Начало: правило модульности | Продолжение: правило композиции » |
