Мы – команда, состоящая из специалистов по разработке браузерных многопользовательских игр, о чем свидетельствует популярность проектов, в которых мы принимали участие. Мы – это гейм-дизайнеры, разработчики и генераторы замечательных идей. Но напрямую это к теме не относится. Итак, осознав свою замечательность, мы ушли от «дяди» и решили делать собственный проект, лучше и успешнее предыдущего, с учетом накопленного опыта и незадействованных наработок.

И вот настало светлое будущее – удобный офис в престижном офисном центре, новенькие ноутбуки и концепт нового проекта. Где-то здесь и закралась роковая ошибка, целью поведать о которой и является данный топик.

Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.
Damian Conway, co-designer of Perl 6

Хороший программный код определяется как минимум тремя признаками: однозначность, эффективность и сопровождаемость.

Однозначность – это в первую очередь стиль кодирования. Однозначность определяется тем, какие имена переменных и функций выбирает программист, как форматирует код, как обрабатывает ошибки и формирует структуру кода.

Эффективный код — это код, состоящий из эффективных алгоритмов. Эффективный не значит хрупкий, сложный или трудно сопровождаемый. Эффективность кода достигается путем использования сильных сторон языка и в то же время избеганием его слабостей.

Сопровождаемость заключается в том, что код пишется в первую очередь для тех, кто будет его сопровождать. Сопровождаемость – легкость использования написанного кода, минимизация возможности появления ошибок при его изменении.

Сообщения о том, что «Perl устарел», появились на просторах Интернета аж в 2003 году, а может и раньше. Встречал забавное выражение «Perl устарел как моя бабушка», датированное сентябрем 2003 года. Не обращая внимание на усмешливое отношение молодого человека к своей бабушке и учитывая, что появление Perl 5.005 в 1998 году можно считать лишь началом расцвета языка, следует сделать вывод, что автор этой фразы в том далеком 2003 только-только разменял второй десяток лет.

В глубине этого кроется какое-то потаенное желание некоторых программистов выступить в роли Нострадамуса IT-сферы: сделать свой прогноз относительно популярности Linux, Windows; определить, какие языки программирования канут в лету, а какие расцветут пышным цветом через пару лет. Заявления об «устаревании» и «отмирании» я за последние лет 5 слышал и о Perl, и о PHP, о Java и Basic'e (который в своей «визуальной» инкарнации выглядит вполне живым).

Работая над крупным, постоянно развивающимся проектом, почти ежедневно имею дело с различными формами утверждения задач: от «Очень срочно, поправь тут. За час уложишься?» до «Оцени, на сколько недель потянет эта задачка». Я, как исполнитель, сам оцениваю время и сложность выполнения каждой задачи и считаю это единственным правильным подходом к оценке фронта предстоящих работ в сфере разработки ПО.

Но, наблюдая за многими проектами — сторонними, о которых пишут в статьях и блогах, а также проектами соседних отделов компании, вижу что разные руководители проектов применяют разные подходы к оценке сроков выполнения задач. И не всегда они совпадают с моим отношением к этому делу.

Принципы

Обобщив накопленную по теме оценки сроков информацию, получил следующие принципы оценки сроков выполнения работы: