Используемые методы
Когда программист самостоятельно разрабатывает программу целиком, он имеет почти полную свободу в выборе используемых методов. (Фактически именно эта свобода нередко является причиной низкого качества конечного продукта.) Однако, когда программист работает в группе, он не так свободен и должен научиться работать в условиях определенных ограничений. Эти ограничения должны быть вызваны необходимостью, а не навязываться неоправданно, они должны обеспечивать большую свободу для разработки высококачественного продукта. Такие ограничения можно представить как необходимость для каждого уяснить требования:
а) других членов группы;
б) руководителя проекта;
в) пользователя, который будет эксплуатировать конечный продукт.
Если программист может выполнить требования трех указанных категорий людей, он сумеет успешно справиться со своей работой в рамках проекта. -
Первое и, возможно, самое важное ограничение касается документации. Документирование и именно по отношению к этой части работы можно отличить любителя от профессионального программиста. Любитель избегает разработки документации, обычно аргументируя это так: Я разбираюсь в программе, поэтому я знаю, как ее изменять, а кроме меня никто документацию читать не будет. Профессиональный программист, напротив, понимает, что документирование так же необходимо, как написание и сопровождение программы. Он знает, что и другие люди могут захотеть разобраться в программе и, возможно, усовершенствовать ее, а также то, что документация сделает программу проще для понимания. Не восприняв такой точки зрения, невозможно работать в группе.
Для каждого проекта имеется стандарт на документацию. В процессе, разработки проекта роли отдельных ее участников могут изменяться из-за болезни, продвижения по службе или увольнения кого-то из них, поэтому вполне возможно, что заняться разработкой программы отсутствующего сотрудника придется другому программисту. Кроме того, руководителю проекта может понадобиться оценить состояние работ или будущий пользователь может захотеть ознакомиться с отдельными программами на предмет их последующего внедрения и сопровождения. Из всего сказанного следует, что все программы должны разрабатываться в согласии с общим стандартом. Какой конкретно стандарт будет принят — не столь важно, Главное, чтобы он был информативен и не вносил слишком много ограничений.
Одна из основных частей такого стандарта должна быть посвящена использованию комментариев в распечатках программ, поскольку эти комментарии представляют собой полезный источник информации для того, кто захочет проследить за ходом разработки программы. Участникам работы над проектом почти наверняка понадобится на некотором этапе ознакомиться с программами, написанными другими сотрудниками — либо для проверки программ, либо для того, чтобы установить причину сложной ошибки, возникшей во время стыковки системы. Каждый программист обязан придерживаться соответствующего стандарта на документацию и, если потребуется, обновлять ее.
Второе ограничение связано с использованием машинного времени. Когда несколько человек пытаются одновременно запустить программу на одной ЭВМ, это приводит к превышению суммарным запросом времени отведенного количества машинного времени. Если для научной среды эти ограничения не так характерны, то в коммерческой они всегда имеют место. Именно поэтому каждому сотруднику важно научиться тестировать программу в условиях ограниченности отводимого на это машинного времени.