суббота, 17 апреля 2010, Александр Краковецкий

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

Относительные и абсолютные пути

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

Типичным является код:

string path = "D://work/projects/my_cool_project/bin/debug/file.txt";
// do something

Здесь есть две ошибки:

• сам проект у вас может не находиться по адресу "D://..."
• вы можете скомпилировать проект не в debug режиме (об этом позже)

Вместо этого необходимо использовать относительные пути:

• для Windows Forms приложения это Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "file.txt");
• для Web Forms это Server.MapPath("~/file.txt");

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

Debug или Release?

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

Кстати, иногда поведение приложения в debug и release режимах может отличаться. Поэтому рекомендуется тестировать приложения во всех конфигурациях.

Для веб-приложений, которые отправляются в production, в web.config необходимо запрещать debug:

<compilation defaultLanguage="c#" debug="false" />

Использование дублирующегося кода

Очень часто можно увидеть, что один и тот же код используется в разных частях приложения.

Выделение куска кода, что повторяется, могло бы:

• сократить количество строк кода
• упростить "чтение" кода другими людьми
• позволить легче и быстрее изменять функциональность (при необходимости) этого кода 

Комментарии

Я лично всегда выступал против большего количества комментариев.

Здесь есть два варианта:

• называть методы и переменные, чтобы было понятно (не a1, b1, c1, а numberOfRows, sumOfItems, tablesCount и т.д.)
  
• писать комментарии в ключевых местах - не везде, а именно в ключевых, без понимания которых сложно разобраться в приложении.
  

Разделение функционального кода и кода приложения

Да, очень часто приходится видеть в одном месте смесь из функционального кода (business logic) и кода приложения (GUI, Console.WriteLine() и т.д.). Таким образом, если вы захотите переделать, например из Windows Forms application в Console application, то вы можете потратить куда больше времени, чем написать все с нуля.

Для избежания подобных проблем придумали MVC, code-behind и OOP, но все же.

В качестве дополнения можно упомянуть плохую структурированность приложения, большое количество строк в методах (2-3 метода на 1000 строк кода), множество вложенных условий if... else... (хотя можно было бы использовать switch или разбить на несколько методов).

Это небольшой перечень проблем, с которыми я сталкивался при рассмотрении проектов, написанных НП. Для кого-то это прописные истины, а для кого-то - отсутствие опыта. Надеюсь, кому-то этот материал пригодится и подобных проблем станет немного меньше. А с какими проблемами сталкивались вы?

---