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