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