четверг, 14 апреля 2011 г.

Из чего складывается работа профессионального программиста

Бывает такое, что клиент не понимает, почему за разработку необходимо так дорого платить. Иногда это бывает из-за технической некомпетентности, как описано здесь: http://wiki4tech.ru/Проблема_понимания_клиентом_сложности_проекта. Но последнее время как правило бывают технически подготовленные клиенты, имеющие специальное профильное образование, но не ставшие на путь разработки и занимающиеся менеджментом. В этом случае сталкиваемся с непониманием другого рода. Будучи студентом решая различные лабораторные работы создается впечатление о том, что программирование - это достаточно легкое занятие. Довольно сложные задачи могут решаться быстро и впечатлять нас.
Дело в том, что лабораторная работа в сравнении со зрелым продуктом - это картонный автомобиль в сравнении с настоящим автомобилем. Смотрите, это же работает, какая красивая картинка. Но откуда берутся дополнительные часы и дни на разработку? Попробую перечислить, что же нам вставляет палки в колеса.
  • Программа должна быть легко сопровождаема, необходимо писать красивый понятный код
  • Программа должна быть протестирована самим программистом (а не только тестировщиком)
  • В вузах как правило не преподают как эффективно проектировать интерфейс взаимодействия с пользователем. Интерфейс пользователя - это та неуловимая для многих вещь, которая заставляет писать дифирамбы программе, а иногда отбивает желание пользоваться.
  • Программирование - это не спринт, а марафонский бег. Нужно достаточно хорошо подумать, чтобы что-то сделать.
  • Иногда бывает, что время днями тратится на решение какой-то технической проблемы. При этом проблема не имеет какого-то понятного пользователю описания.
  • Когда программисты работают в команде, необходимо тратить время на взаимодействие внутри команды.
  • Любой проект с первого дня разработки начинает меняться и дополняться новыми требованиями. Если вы не меняете проект, то готовьтесь выкинуть его на помойку.
Как же решить эти проблемы с обоих сторон? Думаю, нам поможет модель Agile разработки ПО, которая учитывает непостоянство окружающего мира и в том числе процесса разработки. Эта модель построена на взаимном доверии, когда бюджет заранее не фиксируется, либо имеет ограничение сверху с запасом, позволяющее развивать проект. При подходе Agile программный продукт выпускается очень часто. Может быть каждую неделю, а может быть каждый день. Для больших проектов - это единственный путь, способствующий созданию успешного продукта. Подход Agile может существенно сэкономить средства на разработку и в короткие сроки создать работающий продукт. Старый подход, когда сначала пишется огромное ТЗ, а потом долго-долго реализуется часто приводит к провалу. А иногда даже к провалу до начала работы программиста.

1 комментарий:

  1. Очень правильно и хорошо заметно на всяких протатипах. Когда за месяц на коленки делаешь POC. Показываешь, все довольны и надеяться, что завтра уже можно это использовать.
    Мой любимый пример логирования. В большинстве лабораторных, если и есть, то вывод в консоль.
    В более менее готовом проекте, это кончено будет какой-нибудь серьёзны логгер, который пишет и в файл и в базу.
    Но когда нужен production ready продукт, оказывается например за пару месяцев накапливается слишком много логов и их надо архивировать, а очень старые ещё и удалять.
    И как показывает практика, даже опытные программисты на начальных этапах разработки не задумываются о таких вроде мелких вещах, но с другой стороны, это то, что отличает картонку, от качественного автомобиля с климат контролем :)

    ОтветитьУдалить