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