Отправляет email-рассылки с помощью сервиса Sendsay

Статьи по Visual C++

  Все выпуски  

Почему разваливаются крупные проекты


Домашняя страница www.devdoc.ru

DevDoc - это новые статьи по программированию каждую неделю.

Заходи и читай!

Домашняя страница Письмо автору Архив рассылки Публикация статьи

Выпуск №60

Здравствуйте уважаемые подписчики!

Cегодня в номере:

  • Результаты опроса
  • Статья "Почему разваливаются крупные проекты"
  • Анонс

Результаты опроса

Опросы постоянно проводятся на сайте www.devdoc.ru.

Результаты опроса
У вас автоматизировано тестирование?

1Да
13% ( 13 )
 
2Нет
53% ( 51 )
 
3Не знаю
4% ( 4 )
 
4А что это такое?
30% ( 29 )
 

Всего голосов: 97
Последний голос отдан: Понедельник - 6 Апреля 2009 - 17:47:45

Постоянная ссылка на статью (с картинками): http://www.devdoc.ru/index.php/content/view/project_crash.html

Автор: Кудинов Александр
Последняя модификация: 2009-04-07 00:06:36

Почему разваливаются крупные проекты

Команды которые понимают принципы работы над большими проектами через пару месяцев оставляют далеко позади своих конкурентов. Те кто не понимает и осознает - учатся. Те кто думает, что все знает, но мало что понимают в работе над крупными проектами, расстраиваются из-за очередной неудачи и списывают все на руководство и плохую методологию разработки. Рецепт удачи между тем достаточно прост.

Часто можно видеть что первые 3-4 месяца работа продвигается по плану, а потом вдруг проект начинает разваливаться на глазах. Проблемы с руководством, методологией, ресурсами, планированием и финансированием могут быть, а могут и не быть. Но те вещи о которых сегодня пойдет речь есть всегда. Они очевидны и банальны, но почему то многие программисты и целые компании их игнорируют.

Есть две базовые причины неудачи:
1.Низкая квалификация программистов и отсутствие обучения
2.Отсутствует контроль за сложностью кода

Низкую квалификацию можно устранить только за счет обучения или увольнения и найма других сотрудников. Другого пути нет, что бы не говорили сами такие программисты. По аналогии со строительством - если у каменщика руки кривые, то никакой прораб не сможет "мотивировать" его возвести ровную стену. Думаю не трудно догадаться, кто попадет под сокращение в первую очередь в условиях кризиса. Все предельно просто и думаю, что комментарии излишни.

С контролем сложности кода все не так очевидно. Например, опытный программист глядя на код может сказать красивое решение или нет. Это интуитивное понимание и мало кто сможет объяснить в чем заключаться "красота". Ответ прост. Чем меньше сложность кода, тем он "красивее". Впервые мне попалось формализованное описание сложности в книге "Совершенный код: практическое руководство по разработке программного обеспечения", Макконнелл С.

Я настоятельно рекомендую прочитать эту книгу всем. На сложность влияют множество факторов. Например, это количество связей между разными модулями, атомарность операций и т.п.

Пожалуй сложность кода это основной фактор, которые приводит к развалу проекта, даже если все остальные аспекты работы отлично налажены. Фактически вся разработка это борьба со сложностью. По мере разработки программы, сложность кода постоянно растет. В итоге она может превысить некий предел и программист будет просто не в состоянии добавлять новые функции без внесения ошибок. Причем количество ошибок начинает расти лавинообразно. Т.е. исправление одной ошибки может порождать еще две.

В команде из 3-6 человек проблемы со сложностью начинают вылазить на 3-4 месяце разработки. Как правило на этом этапе затраты на переработку программы и уменьшение сложности могут составлять до 30% от бюджета предыдущих месяцев.

Поэтому на каждом этапе разработки надо выбирать те решения, которые уменьшают сложность системы. Или по крайней мере не увеличивают ее. Самым простым и эффективным способом является деление программы на модули (классы для ООП). Каждый модуль разрабатывается так, чтобы он был слабо связан с другими. Кроме того он должен выполнять как можно более простые операции.

Вот пример функции на 10 страниц... шучу. Я дам просто пример в псевдокоде. Программа ищет в неком списке кадр, а затем выполняет его масштабирование и фильтрацию.

{
 int iStride = w * h * sizeof(RGB);
 for(int f = 0; f < nFrames; f++)
 {
  for(it = s.begin(); it != s.end(); it++)
  {
   if(it->frame_n == f && it->name = "left")
   {
    frame = it;
    break;
   }
  }
  pixel = frame->pixels;
  for(int y = 0; y < h; y++)
  {
   for(int i = 0; i < iStride; i++)
   {
    //масштабирование и фильтрация кадра.
    for(.........) for(......)
     pixel[y][i] = expression;
   }
  }
 }
}

Я выкинул все нужные детали, которые будут в настоящей реализации. И тем не менее код выглядит корявым. С первого взгляда трудно понять, что он делает. Давайте разобьем его на атомарные операции.

{
 int iStride = GetStride();
 for(int f = 0; f < nFrames; f++)
 {
  frame = FindFrame(s, f "left");
  pixel = frame->pixels;
  pixel = ScaleAndFilterImage(pixel, iStride)
 }
}

Этот вариант выглядит более элегантно и понятно. Все "кирпичики" хорошо отлажены и программисту нет нужны задумываться о их реализации, когда он пишет высокоуровневый код. Сложность кода это главное о чем стоит заботится в больших проектах. За сложность в первую очередь отвечают программисты.

Есть очень хорошее практическое руководство по уменьшению сложности кода: "Refactoring: Improving the Design of Existing Code" by Martin Fowler.

Эта книга переведена на русский язык. Несмотря на то, что она написана для Java, все техники могут успешно использоваться и в других языках программирования.


Анонс

Вы хотите грамотно научиться работать на компьютере!? Хотите уметь работать с различными полезными приложениями и программами, а также свободно ориентироваться в компьютерном мире!? Тогда подписывайтесь на бесплатную рассылку Артёма Ющенко Эффективная работа на компьютере, компьютер для начинающих - http://artomu.com. Постоянные бонусы подписчикам!

Copyright (C) Kudinov Alexander, 2006-2007

Перепечатка и использование материалов запрещена без писменного разрешения автора.


В избранное