[767] 19 января 2011; 1:15

В конце августа 2008 года, перед началом нового семестра, я за пару ночей написал простенькую софтину с веб-интерфейсом для учёта студенческих успехов: сданные задачи, посещаемость и всё такое. Все таблички на моих студенческих сайтах (например, здесь) с тех пор генерируются этой самой софтиной. Штука получилась реально удобной (для меня), я очень рад, что запинал себя и наконец-то её написал: раньше я отмечал всё в Excel и это было дико неудобно, а про бумажечные времена даже и вспоминать неохота.

Но, как обычно, есть небольшое «но».

Сейчас мне кажется, что система 2008 года себя исчерпала. Конечно, мне как автору не составляет никакого труда допиливать некоторые фичи и я это регулярно делаю: если бы система была настоящим продуктом, сейчас бы она имела какую-нибудь версию 1.16 или, возможно, даже 1.17. Проблема в другом: после пяти семестров использования я наконец-то понял, какую функциональность на самом деле мне хочется иметь, как действительно правильно спроектировать такую штуковину и как приятно будет работать с настоящей, правильной, идеальной системой учёта студенческих оценок версии 2.0.

Почему же нельзя было сделать всё правильно с самого начала? Глупый вопрос: в августе 2008 года я и сам не знал, как сделать всё правильно, и даже если бы я посидел день или два, прикидывая use cases будущей софтины, я вряд ли смог бы продумать всё. Есть и другой момент: если бы даже я тогда каким-то волшебным образом сразу придумал правильные use cases, я бы посмотрел на объём проектируемой системы и не стал бы ничего писать, испугавшись долгого кодирования: всё равно не успел бы к первому сентября закончить. Да и сейчас, обдумывая все модификации, я не могу заставить себя взяться за глобальную правку кода, потому что менять придётся, кажется, всё или почти всё (в умных книгах описан «эффект второй системы», и здесь мы, кажется, видим именно его), а в феврале надо начинать новый семестр с новыми группами. Да и денег мне за эту работу никто не платит, так что...

Получаем проблему номер один. Сразу и правильно не бывает. А позже, к сожалению, зачастую проще всё переписать (но это нечасто возможно сделать).

Идём дальше. Посмотрите ещё раз на табличку по ссылке выше. Она раскрашена в несколько цветов по простому правилу: несданные задачи выделены красным, если текущего количества сданных задач не хватает для получения зачёта; жёлтым, если их хватит только на «троечку», и так далее. Хуже того: двоим студентам, формально претендующим лишь на «четвёрку», я нарисовал «пятёрку» авансом. Теперь только представьте возможный GUI или конфигурационный файл для настройки этого поведения. А если система оценок не пятибалльная? А если хочется чуть-чуть изменить правила? А если... А ведь это только одна маленькая фича.

Естественно, у меня нет никакого GUI для настройки этого раскрашивания. Я автор системы; меня не заломает написать несколько строчек кода, которые раскрасят именно эту табличку именно для этой группы. Для другой группы будут другие правила и другой код. Я автор и я умею программировать. К сожалению, считается, что «простой пользователь» имеет право программировать не уметь.

Проблема номер два. Система, претендующая на универсальность, либо имеет огромное количество «галочек» в настройках, либо позволяет пользователю программировать. Либо (вспомним Microsoft Word) и то, и то.

Казалось бы, ничего нового я тут не придумал. Но это я рассказал про свою на коленке сделанную систему учёта успеваемости. Почему же эти проблемы я регулярно вижу и во вполне промышленном коде, и в опенсорсе, и вообще везде?

P.S. Менеджмент проектов — совершенно не моя тема, но вот что-то захотелось написать.