97 этюдов для программистов. Опыт ведущих экспертов - Пит Гудлиф

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

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

Программист, изучающий второй язык, встретится с трудностями, особенно если вычислительная модель второго языка отличается от первого. C, Pascal, Fortran — все они основаны на одной вычислительной модели. Переход с Fortran на C вызывает некоторые трудности, но их не так много. Переход с C или Fortran на C++ или Ada сопровождается фундаментальными трудностями с пониманием поведения программ. Переход с C++ на Haskell означает существенные изменения, а потому существенные трудности. Переход с языка C на Prolog станет весьма существенным испытанием.

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

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

Взаимное обогащение при использовании разных языков программирования дает мощнейшие эффекты. Пожалуй, наиболее очевидным из них является все растущее применение декларативных режимов описания в системах, реализованных посредством императивных языков. Любой знаток функционального программирования может легко применить декларативный подход, даже при работе с таким языком, как C. Применение декларативных методов обычно приводит к созданию более коротких и понятных программ. Скажем, C++ определенно выступает за такой подход, обеспечивая всестороннюю поддержку обобщенного (generic) программирования, в котором декларативный режим описания является почти обязательным.

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

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

Знай свою IDE

Хейнц Кабуц

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

В девяностые годы компании начали осознавать потенциал прибыли от более удобных и полезных инструментов разработки. Интегрированная среда разработки (Integrated Development Environment, IDE) объединила уже предлагавшиеся ранее функции редактирования с компилятором, отладчиком, средствами форматирования и другими инструментами. Как раз в это время стали популярны меню и мышь, а значит, отпала надобность заучивать разработчикам сложные комбинации клавиш для работы со своим редактором. Достаточно было выбрать команду из меню.

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

Другая замечательная возможность современных IDE — способность принуждать к соблюдению стиля, принятого в компании. Например, в Java некоторые программисты стали объявлять все параметры final (на мой взгляд, это пустая трата времени). Тем не менее раз такое правило установлено, мне достаточно задать его в настройках IDE, и я стану получать предупреждения для всех параметров, которые не объявлены как final. С помощью правил стиля можно также искать возможные ошибки, такие как проверка равенства автоматически упакованных (autoboxed) объектов посредством ссылочной семантики, как в случае использования оператора == для примитивов, упакованных в соответствующие объекты.

К сожалению, современные IDE не требуют, чтобы мы прилагали усилия к освоению этих самых IDE. Когда я начал программировать на C под UNIX, мне пришлось потратить немало времени, чтобы научиться работать в редакторе vi, что обусловлено его кривой обучения. Но потраченное на старте время сторицей окупилось с годами. Даже черновик этой статьи набран в vi. У современных IDE кривая обучения такая, что мы никогда не выходим за пределы базовых приемов работы с ними.

Первое, что я делаю при изучении IDE, — запоминаю управляющие сочетания клавиш. Когда я набираю код, пальцы лежат на клавиатуре, и нажатие Ctrl+Shift+I позволяет встроить переменную (операция рефакторинга Inline Variable), не нарушая рабочего потока, тогда как навигация по меню указателем мыши отвлекла бы меня. Такие отвлечения создают ненужные переключения контекста и значительно снижают мою продуктивность, если я пытаюсь делать все «ленивым» образом. То же справедливо в отношении владения клавиатурой: освойте печать вслепую, и вы не пожалеете о потраченном времени.

Наконец, у программистов есть проверенные временем конвейерные UNIX-утилиты, позволяющие манипулировать кодом различными способами. Например, если при рецензировании кода я замечаю, что программисты назвали многие классы одинаково, я легко могу обнаружить эти повторения с помощью утилит find, sed, sort, uniq и grep, например:

find. -name ”*.java” | sed ’s/.*///’ | sort | uniq — c | grep — v ”~ *1 " | sort —