Совет 15 Практика, практика и еще раз практика

Совет 15

Практика, практика и еще раз практика

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

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

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

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

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

Я не работал спустя рукава, но был страшно разочарован тем, что многие из приходящих мне в голову идей оказались неэффективны. Хотя я старался сделать свою работу как можно более качественно, проектное решение и код то и дело получались совсем не такими элегантными, как мне хотелось.

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

Тренируйся на пределе своих способностей.

Но как понять, что именно следует отрабатывать? Что расширяет твои границы? Тема наработки навыков, необходимых разработчику программного обеспечения, потянет на отдельную книгу. Я первым делом прибегаю к моему опыту джазового музыканта. Тренировки имеет смысл поделить на три категории (я специально упрощаю для читателей, не имеющих отношения к музыке):

? физические упражнения/координация;

? игра с листа;

? импровизация.

Этот список может послужить основой одного из вариантов тренировки для разработчиков программного обеспечения.

Физические упражнения/координация. Музыканты должны нарабатывать технику обращения с инструментом: генерация звука, координация движений (например, легкость перемещения пальцев), скорость и точность — все это крайне важно наработать.

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

Эти же правила применимы к API или к библиотекам функций выбранного тобой языка. Не научившись работать с многочисленными инструментами окружения, ты вряд ли сможешь применить их в ситуации, когда они действительно потребуются. Попробуй, к примеру, разобраться, как функционирует в выбранной среде разработки многопоточное программирование. А как у тебя обстоят дела с библиотеками потоков ввода-вывода, API сетевого программирования или наборами служебных программ для работы с коллекциями или списками? Большинство современных языков программирования предлагает богатые и мощные библиотеки для всех упомянутых областей, но разработчики предпочитают освоить только небольшую часть из них, что негативно влияет на эффективность написания кода.

Чтение с листа. Для профессиональных музыкантов, записывающихся в студии, способность играть с листа имеет первостепенное значение. Однажды пришлось принять участие в записи рекламного ролика для Blockbuster (она специализируется на прокате видеокассет). Большой оркестр играл быструю мелодию, а я не только солировал на саксофоне, но и исполнял партию второго альта. В первый раз я увидел ноты в момент начала записи. Сначала мы сыграли солирующую партию, потом — сопровождающую. При малейшей ошибке все музыканты были бы вынуждены начать с начала, и не забывайте про стоимость аренды студии.

Что для разработчика программного обеспечения означает умение читать с листа код? Или технические требования? Или проектное решение? Искать код для подобных упражнений лучше всего в сообществах разработчиков ПО с открытым исходным кодом. У тебя есть любимые фрагменты таких программ? Не хочешь попробовать добавить в них какую-нибудь функцию? Прочитай список задач для программы, с которой ты хотел бы поработать, и определи конкретную дату реализации новой функциональной возможности (или хотя бы прикинь, сколько времени может занять эта реализация).

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

Такое упражнение можно делать на время. При этом ты вовсе не обязан реально реализовывать выбранную функциональную возможность. Используй это как отправную точку. На самом деле ты учишься с максимальной скоростью распознавать, что делает код, на который ты смотришь. Для каждого следующего упражнения выбирай новую программу. Попробуй выполнить его с разными типами программы, написанными в разных стилях и на разных языках. Отмечай моменты, которые облегчают или затрудняют понимание происходящего. Какие стандартные действия помогают тебе в работе с кодом? Какие виртуальные «хлебные крошки» ты оставляешь себе, чтобы упростить ориентирование при перемещении вверх и вниз по стеку вызовов сложной функции?

Импровизация. Импровизацией называется взятие некой структуры или ограничения и мгновенное создание на его основе чего-то нового. Как программист, я обнаружил, что чаще всего импровизирую в моменты стресса. Ох, нет! Сервер приложений в беспроводной сети перестал работать, и мы теряем заказы! Именно в такие моменты у меня возникают самые творческие экспромты. Я делаю сумасшедшие вещи, такие как восстановление потерянных данных вручную путем повторной передачи по беспроводной сети пакетов из бинарного файла системного журнала. Никто не рассчитывает, что ты способен на подобные вещи, особенно под горячую руку. Такая способность к резким и быстрым решениям напоминает приходящую на помощь в нужный момент магическую силу.

Отличным способом заострить свой ум и улучшить способности к импровизации при написании кода является практика с самостоятельно наложенными ограничениями. Выбери простую программу и попытайся переписать с учетом ограничений. Моим любимым упражнением является написание программы, выводящей на экран строки старой песни «99 бутылок пива». Ты можешь это сделать, обходясь без присвоения переменных? Или попробуй минимизировать размер этой программы. В качестве дополнительного ограничителя может выступить время. Насколько быстро ты в состоянии написать код? Как насчет решения небольших сложных задач с таймером в руках?

Это всего лишь один из вариантов практики. Примеры можно добыть в любой области, от изобразительного искусства до религиозных практик монахов. Важно понять, в каких именно вещах тебе требуется тренировка, и, разумеется, никогда не тренироваться во время выступлений (на работе). Для практики нужно выделить отдельное время. Это только твоя ответственность.

Действуй!

1. TopCoder. TopCoder.com — это сайт корпорации, проводящей соревнования по спортивному программированию. Ты можешь зарегистрироваться там и участвовать в соревнованиях с призами. Для тех, кто не любит соревноваться с другими, на сайте есть раздел с набором задач, которые послужат прекрасной основой для отработки практических навыков. Регистрируйся и начинай заниматься.

2. Code Kata. Один из самых прагматичных программистов, наш любимый издатель Дэйв Томас (Dave Thomas), превратил идею наработки программистских навыков в… кое-что прагматичное. Его кодовая ката (code kata) — набор небольших, но провокационных упражнений. Программисты могут выполнять их на любом языке. Каждая ката делает упор на определенную технику или мыслительный процесс, нагружая один из твоих ментальных мускулов.

На момент написания этой книги Дэйвом была создана двадцать одна ката. Все они доступны в его блоге (http://codekata.pragprog.com/). Там же можно найти список рассылки и чужие решения этих упражнений, а также обсуждения способов решения.

Твоя задача — выполнить всё. Записывай результаты в дневник или веди блог. Закончив дело, напиши собственную кату и поделись ею с широкой публикой