Страсть к программированию. Глава 15. Практика, практика, практика

О переводе

Это перевод 15 главы книги The Passionate Programmer: Creating a Remarkable Career in Software Development. Её автор — Chad Fowler — талантливый Ruby-разработчик, известный докладчик на конференциях, посвящённых Ruby и IT в целом. Бывший саксофонист, а сейчас — CTO 6Wunderkinder.

Краудсорсинговый перевод книги ведётся на github, присоединяйтесь.

Глава 15. Практика, практика, практика

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

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

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

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

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

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

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

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

— физика/координация
— чтение с листа
— импровизация

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

Физика/координация:

Музыканты должны практиковаться в технических аспектах своих музыкальных инструментов: извлечение звука, физическая координация (заставляя пальцы двигаться легко например), скорость и точность — все это важно при практике. Какой эквивалент есть у разработчиков программного обеспечения по сравнению этими основными положениями для музыки? Что есть такого в пыльных уголках вашего языка программирования, на что вы редко обращаете внимание? Например, поддерживает ли выбранный вами язык программирования регулярные выражения? Регулярные выражения это очень мощный и печально недостаточно используемый инструмент многих сред разработки. Очень часто разработчики не используют их, тогда когда есть такая возможность, из-за недостаточного уровня знаний для эффективного использования регулярных выражений. Как результат, создается множество ненужного кода по структурному анализу строк (needless string-parsing code), который в дальнейшем должен сопровождаться.

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

Чтение с листа:

Что касается музыкантов, возможность читать и исполнять музыку почти идеально с первого раза отличает профессионала. Я однажды играл на саксофоне для Blockbuster (компания видеопроката). Я играл и ведущую и вторую партию одновременно в быстром темпе. Я видел ноты первый раз, буквально как только лента начала вращаться. Мы играли попеременно ведущую и вторую партию. Любые ошибки, и вся группа должна была начинать сначала — и цена этого — студийное время.

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

После выбора скачайте исходный код ПО и начните исследование. Как знать куда смотреть? Какие уловки вы используете для нахождения своего пути в значительной части кода? Где ваша точка отсчета?

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

Импровизация:

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

Замечательный способ повысить навыки импровизации при написании кода это справляться с самостоятельно поставленными ограничениями. Выберите простую программу и попытайтесь написать ее с этими ограничениями. Мое любимое упражнение это писать программу, которая выводит текст старой песни «99 бутылок пива на стене» //Прим. перев.: cсылки на youtube — тут пива нет, а тут есть;). Как бы вы смогли написать эту программу без присваивания переменных? Или насколько маленькую программу вы можете написать, которая выводит правильный текст? Добавим ограничение — как быстро вы можете написать такую программу? Как насчет того, чтобы решать небольшие, сложные задачи с таймером?

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

Действуйте!

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

2. Code Kata — Дэйв Томас, один из Прагматичных Программистов (Pragmatic Programmers) (наш любимый издатель), взял идею практики написания кода и сделал что-то… ну, прагматичное из этого. Он создал серию того, что называется Code Kata, маленькие провокационные упражнения, которые программисты решают на выбранном ими языке программирования. Каждая ката представляет собой особую технику или мыслительный процесс, заставляющий шевелить мозгами. Во время написания книги, Дэйв создал 21 такую ката и выложил их в свободном доступе на сайте (http://codecata.pragprog.com/ //Прим. перев. ссылка почему-то ведет на tumbler). На сайте вы найдете ссылки на список адресатов, а также решения других пользователей во время обсуждения того как была решена задача. Ваша задача: проработать все 21 упражнение. Ведите дневник (или блог?) вашего опыта работы с катами. Когда вы закончите, напишите собственную ката и поделитесь ею с остальными.

Автор: urticazoku

Источник