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