По ту сторону кодинга

Алексей Башкеев

Спецвыпуск: Хакер, номер #053, стр. 053-068-5

Средства постановки задач

Постановка задач в любом проекте - это одно из необходимых условий успеха. Есть поговорка: если задача поставлена некорректно, то в результате может получиться вообще все что угодно. Безусловно, можно составить техническое задание на листике за пять минут. Возможно, вы с заказчиком настолько хорошо понимаете друг друга, что тебе и этот листик не нужен – все и так будет сделано в лучшем виде. Если все не так радостно, имей в виду, что серьезные задачи могут потребовать мощных средств постановки задач.

UML (Unified Modeling Language)

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

Существуют и другие средства. Для некоторых областей программирования есть специальные средства и наборы стандартов. Большинство из них специально затачиваются под ту или иную область. Для проектирования баз данных, банковских процессов, Java-программ такие средства уже существуют практически для всех видов программирования. Если все же говорить о "простых" и "средних" средствах, то Word Excel и Visio – то, что доктор прописал.

И еще один маленький совет. Уж лучше заставить человека написать подробное техническое задание, чем переписывать несколько раз "то, что поняли не так".

CVS (Concurrent Version System)

Система контроля версий, если по-русски. Чтобы ты понял, что это такое и для чего это предназначается, опишу несколько "классических ситуаций". Ты разрабатываешь какую-то программу. Выпустил релиз и продолжаешь работу над следующей версией, и вдруг в выпущенном релизе обнаруживается серьезный баг, а выпуска нового в ближайшем будущем не предвидится. Надо вернуться к выпущенной версии, исправить баг, затем вернуться к разработке новой. А в новой версии придется исправлять этот же баг уже во второй раз... Если над одними и теме же файлами работают несколько человек, конфликты между участниками этого коллективного труда неизбежны. Казалось бы, это можно решать криками "Вась, ты это файл трогаешь? Нет? Ну тогда и не трогай, я сейчас его править буду!" Звучит смешно, но, например, я говорил это тысячи раз, а слышал еще чаще. Каждый релиз можно складывать в отдельную папочку, исправления багов вносить сначала в выпущенную версию, а потом в разрабатываемую. А если разработчики не сидят в одном помещении, вообще разделены часовыми поясами и, соответственно, могут работать в разное время? При всем этом на "исправление бага" ты уже потратил много времени, неужели для его исправления в следующей версии придется начинать все сначала? Можно и дальше продолжать изобретения велосипеда. Однако такие проблемы решают уже давно, значит, должны существовать их решения.

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