Ларри Константин - Человеческий фактор в программировании

Какая-то информация запоминается легче и на более длительное время. Запахи могут оставлять в памяти очень долговременные следы даже после однократного вдыхания. Пространственно-моторное запоминание, то есть память о выполненных движениях и действиях, не просто долговечна — она может способствовать вспоминанию мыслей и ощущений, связанных с движениями. Физическое обращение с предметами, манипулирование материалами, которые ясно представляют некоторые идеи, помогает закрепить понятия — при условии, что физические манипуляции непосредственно с ними связаны.

Мультимодальная коммуникация не обязательно должна вовлекать сложные мультимедийные презентации. Например, во время дискуссии, проходившей на конференции в Лондоне, на вопрос о связи между повторным использованием и объектной технологией я не раздумывая ответил с помощью удерживания двух карандашей в виде буквы «L». Таким способом я хотел показать, что эти концепции — ортогональные, то есть не зависят друг от друга. Позже, уступая под градом острых вопросов, я признал взаимосвязь этих концепций. Объектная технология может способствовать более эффективному повторному использованию. Я составил из карандашей широкую букву «V», чтобы показать, что эти концепции связаны друг с другом. Два дня спустя участники конференции все еще обсуждали эту мини-демонстрацию.

Взаимосвязь между повторным использованием и объектной технологией продемонстрировать легко. Хорошая презентация, прежде всего, должна делать простые вещи простыми в изучении. Трудные вещи всегда будут трудными. Сколько бы систем восприятия вы не применяли, вы не сможете изучить объектно-ориентированное проектирование за один час так же, как не сможете изучить за час программирование. За это время вы сможете узнать только упрощенные — некоторые сказали бы «разбавленные» — варианты основных понятий.

Из журнала Software Development, том 1, № 11, ноябрь 1993 г.

Может ли роботам сниться электрическая овца? Преследуют ли менеджеров программных проектов кошмары о прыжках с водопада?

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

Конечно, на самом деле так обычно не происходит. Так называемая «водопадная» модель разработки программного обеспечения все еще подвергается жарким обсуждениям. Порой она кажется кошмарной частью нашей коллективной мифологии. Бросаясь вниз с водопада, вы теряете контроль над своим движением и направлением. Вы просто летите вниз, хотите вы того или нет. Самое большее, на что вы можете надеяться — не утонуть. Я могу взять часть вины на себя за то, что когда-то давно ввел такие чрезмерно упрощенные понятия. Однако в сравнении с неуправляемым хаосом, который царил в то время, даже такие примитивные модели последовательного цикла работы были прогрессом. С тех пор мало что изменилось.

Разработчики программного обеспечения и другие представители индустрии программирования отличаются тем, что они всегда бегут впереди себя. Едва увидев титульный лист спецификации, они тут же начинают придумывать код или дизайн интерфейса. Анализируя абстрактные сценарии использования, они уже представляют иконки для панели инструментов. При планировании связей между основными модулями они начинают придумывать оригинальные способы применения программного интерфейса.

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

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