Зачем нужен план
Самый известный план на планете
Сначала я хотел назвать этот текст «Зачем нужен бизнес-план», но к чему себя ограничивать? План — он и в Африке план, не важно для чего. Тот, что для бизнеса, называется бизнес-планом. Тот, что для эвакуации, называется, как ни странно, планом эвакуации. И так далее.
Но идея текста таки пришла из области, где актуальны бизнес-планы. Часто стал встречаться с высказываниями о том, что «бизнес-план, конечно, нужен, но вот конкретно в нашем случае он пользу не принесёт потому, что»:
- у нас слишком большая неопределённость, будет гадание на кофейной гуще;
- и так всё предельно ясно, план — лишняя трата сил.
Сам я тоже страдал этими тараканами, но так получилось, что периодически разного рода планы составлять всё-таки приходилось. И хочу вам сказать — планы делать полезно и нужно.
Но сначала…
Почему разработчики не сделают эту простую штуку?
Животрепещущий вопрос, не правда ли?
Меня уже 3 года как им пытают персонально, поэтому я решил попытаться рассказать всё-таки почему. Рассказывать, конечно, буду со стороны разработчика-одиночки. В командах побольше есть некоторые нюансы, но суть та же.
Для затравки приведу небольшую иллюстрацию, смысл её, думаю, понятен.
Взгляд на проект со стороны пользователя и разработчика.
Тестирование семантики кода
Одной из практик тестирования является написание тестов по уже найденным ошибкам, чтобы исключить их в будущем. Но что делать, если ошибка не специфична для конкретной логической сущности, а может встретиться в любом месте?
Писать для каждого модуля одинаковые тесты — не самая вдохновляющая идея, тем более, о них ещё помнить надо. В некоторых случаях тест можно написать не для проверки поведения программы, а для проверки непосредственно её кода. Этакий семантический pep-8, если хотите.
В коде «Сказки» уже давно прописалось несколько таких тестов, собранных в файле test_code.py . О них и расскажу, для иллюстрации идеи.
Тесты, которые тестируют тесты
Или почему в них нет необходимости.
Часто, когда рассказываешь новичкам про автоматическое тестирование, всплывает один и тот же вопрос: «А кто будет проверять сами тесты? Придётся писать тесты для тестов, потом тесты для тестов для тестов…» Все любят рекурсию и ещё больше любят уесть ей собеседника.
Странно, ни разу не попадался вопрос: «Кто тестирует тестировщиков?» — по сути, та же проблема вид сбоку.
Но действительно, почему нет необходимости тестировать тесты? (и тестировщиков)
О создании названий
Первое, что видит игрок, знакомясь с контентом — это его название (конечно, кроме красивой картинки). Будь то название мира, территории, поселения, способности, предмета, монстра или ещё чего-то. Часто кроме названия игрок ни с чем и не знакомится — проходит мимо по каким-то своим делам. Название — это подарочная упаковка для контента, во многом от него зависит обратит ли игрок внимание на то, что скрывается за парой слов, или нет.
По сути, мир средней игры для среднего игрока — это много-много названий и немного контента, с которым он познакомился. Игроков, целеноправленно изучающих весь игровой мир обычно меньшинство.