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