|
Как убедить людей
Нельзя убедить людей быть профессионалами. Нельзя убедить их
принять
профессиональное
отношение
к
делу.
Аргументы
неэффективны.
Данные
непоследовательны.
Ситуационные
исследования не значат ничего. Принятие профессионального
отношения
является
не
столько
рациональным,
сколько
эмоциональным решением. Это очень человеческое решение.
Как же подвести людей к переходу на профессиональное
отношение? Да, оно заразительно, но только в том случае, если вы
можете наблюдать за его проявлением. Следовательно, вы должны
демонстрировать его. Станьте образцом для подражания. Вы
становитесь
профессионалом
сами
и
показываете
свой
профессионализм другим. А затем пусть концепция сама сделает всю
работу.
Заключение
Учебное заведение может научить теории программирования. Но
оно не учит и не может научить практике, методам и
профессионализму. Все это приобретается годами личной практики –
как в роли обучаемого, так и в роли наставника. Пришло время всем
нам, работникам отрасли программирования, признать, что задачу
воспитания следующего поколения разработчиков придется решать
нам, а не университетам. Пришло время принять программу
наставничества, интернатуры и долгосрочной опеки.
Приложение
Инструментарий
В 1978 году я работал в Teradyne над телефонной тестовой
системой, о которой упоминал ранее. Система состояла примерно из
80 тысяч строк кода ассемблера M365. Исходный код хранился на
магнитных лентах.
Ленты напоминали 8-дорожечные стереокассеты, которые были
так популярны в 1970-е годы. Лента была склеена, а накопитель мог
перематывать только в одном направлении. Ленты в кассетах имели
длину 10, 25, 50 и 100 футов. Чем длиннее была лента, тем больше
времени занимала «перемотка», так как накопителю приходилось
просто перематывать ее вперед до «точки загрузки». Перемотка 100-
футовой ленты до точки загрузки занимала около 5 минут, поэтому мы
осмотрительно подходили к выбору длины лент.
[54]
На логическом уровне ленты делились на файлы. На одну ленту
можно было записать столько файлов, сколько на ней помещалось.
Чтобы найти нужный файл, приходилось загружать ленту, а затем
последовательно читать файлы, пока не будет найден нужный. На
стене висела распечатка каталога с исходным кодом; по ней мы
определяли, сколько файлов нужно пропустить, чтобы найти нужный.
На полке в лаборатории лежала эталонная 100-футовая копия
ленты с исходным кодом. Чтобы отредактировать файл, мы ставили в
один накопитель эталонный экземпляр, а в другой – 10-футовую
пустую (рабочую) ленту. Эталонная лента проматывалась до нужного
файла, после чего файл копировался на рабочую ленту. Тогда мы
«перематывали» обе ленты в начало, и эталонная лента ставилась
обратно на полку.
На доске в лаборатории была прикреплена специальная распечатка
эталонной ленты. Когда мы создавали копии файлов, которые
требовалось отредактировать, мы прикрепляли цветную булавку рядом
с именем этого файла. Так производился контроль изменений!
Редактирование производилось в экранном режиме. Мы
пользовались очень хорошим текстовым редактором ED-402 –
близким аналогом
vi
. Страница читалась с ленты, мы редактировали
ее содержимое, записывали ее обратно и читали следующую.
Страница обычно состояла примерно из 50 строк кода. Мы не могли
«заглянуть вперед» на ленту и увидеть предстоящие страницы и не
могли вернуться назад к уже отредактированным страницам. Поэтому
мы использовали листинги.
В листингах отмечались все предстоящие изменения,
после чего
файлы редактировались в соответствии с пометкой.
Никто
не писал и
не изменял код спонтанно! Это было бы самоубийством.
После внесения изменений во все файлы, которые требовалось
отредактировать, мы объединяли их с содержимым эталонного
экземпляра. Полученная лента использовалась для проведения
компиляции и тестирования.
Когда мы завершали тестирование и убеждались в том, что
изменения работают, мы смотрели на распечатку. Если на ней не было
новых кнопок, то рабочая лента просто переименовывалась в
эталонную, а наши кнопки снимались с доски. Если на доске
появлялись новые кнопки, то мы снимали свои и передавали рабочую
ленту их владельцу для слияния результатов.
В группе было трое разработчиков. У каждого были кнопки своего
цвета, поэтому мы могли легко определить, кто взял на
редактирование те или иные файлы. А поскольку мы все работали в
одной лаборатории и постоянно говорили друг с другом, текущее
состояние кодовой базы постоянно хранилось в наших головах. Так
что распечатка часто оказывалась излишней, и часто мы обходились
без нее.
Do'stlaringiz bilan baham: |
