avl (avl) wrote,
avl
avl

Categories:

51. Проверяйте предположения, особенно собственные.

(В оригинале - Challenge assumptions - especially your own)

"Предположение – причина большинства неудач", или более популярно: "Don’t assume – it makes an 'ass' of 'u' and 'me', что в дословном переводе звучит как «Предположения делают из нас ослов», увы, не передавая замечательную игру слов оригинала. И когда речь заходит о предположениях, за которыми стоят тысячи или даже миллионы долларов, то вышеприведенная фраза – уже не просто смешная шутка.

Одна из хороших практик разработки ПО – документировать причины того или иного решения, особенно когда за решением стоит компромисс (производительность или сопровождаемость, стоимость или время выхода на рынок и т.п.). Также можно записывать и контекст того или иного решения, включая факторы, повлиявшие на окончательное решение. Факторы могут быть функциональными или нефункциональными требованиями, а также могут быть просто «фактами», важными для принимающих решение (ограничение технологии, доступный уровень знаний, политическая ситуация и прочее).

Эта практика хороша тем, что когда эти факторы перечислены, то это может помочь выделить те предположения, которые были у архитектора, ответственного за разработку ПО. И часто эти предположения основаны лишь на «исторических причинах», традициях разработки, FUD-е или же даже на «Я где-то что-то об этом слышал»:

  • Open source проекты недостаточно надежны
  • Bitmap индексы приносят больше проблем, чем пользы
  • Заказчик никогда не согласится, что страница грузится пять секунд
  • Директор согласится только на продукцию крупного вендора

Важно сделать эти предположения видимыми ради потомков и для будущего анализа. Однако еще более важно убедиться, что все предположения, не имеющие адекватного эмпирического подтверждения, проверяются перед тем, как решение окончательно принято. Что, если заказчик не будет возражать против пятисекундной загрузки страницы, если добавить на нее прогресс-бар? Какой именно open-source проект ненадежен и как именно ненадежен? Тестировали вы bitmap-индекс на ваших данных?

И не игнорируйте слово «релевантный». Иногда то, что было истинным в предыдущих версиях, не является таковым сейчас. Производительность bitmap-индексов в одной версии Oracle может отличаться от производительности в другой версии. Старая версия библиотеки могла иметь дыры в безопасности, исправленные в новой версии. Ваш поставщик надежного ПО может быть на грани банкротства. Технологии меняются каждый день, и с ними меняются и люди. Возможно, ваш шеф завтра станет фанатом Linux.

Факты и предположения – основа, на которой строится ваше ПО. Какими бы они ни были, будьте уверены в том, что они согласованные.

Автор оригинала - Timothy High

Перевод мой. Если вы решите использовать его полностью или частично, не забудьте указать ссылку на мой живой журнал!
Tags: 97_things_architect_should_know
Subscribe

  • Один день на яхте

    Давно, очень давно хотелось оказаться на яхте. И вот наконец удалось реализовать мечту, пока что на 1 день. Главное — что оказалось, что никого из…

  • Подарок на 8 марта :)

    Фирма удивила, подарив 8 марта ВСЕМ сотрудникам смарт-часы от неизвестного производителя с нанесенным своим логотипом :) Да, в Словении 8 марта -…

  • Подводная лодка

    Давно не писал сюда, т.к. несмотря на отвратительный интерфейс, все переходят в фейсбук... Но все же возможность вставлять несколько фото и управлять…

  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

  • 0 comments