litceysel.ru
добавить свой файл
  1 2 3 ... 7 8

43. Умейте пользоваться утилитами командной строки

Кэррол Робинсон (Carroll Robinson)

Сегодня многие средства разработки программного обеспечения имеют вид интегрированных сред разработки (IDE). Два популярных примера – Visual Studio разработки Microsoft и Eclipse, имеющая статус open source, но есть и много других. В пользу IDE можно сказать многое. Ими не только легко пользоваться, но они также избавляют программиста от необходимости заниматься многими мелкими деталями, включая процесс сборки.

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

При работе с инструментами, вызываемыми в командной строке, вы гораздо больше узнаете о том, что делают ваши инструменты во время сборки проекта. Составление собственных make-файлов поможет понять вам все этапы (компиляция, ассемблирование, компоновка и т. д), из которых состоит сборка исполняемого файла. Эксперименты с многочисленными опциями командной строки этих инструментов также представляют собой ценное образовательное упражнение. Начать работу с инструментами командной строки для сборки можно со средств командной строки open source, таких как GCC, или тех, которые поставляются с вашей коммерческой IDE. В конце концов, правильно спроектированная IDE – это всего лишь графический интерфейс к набору инструментов командной строки.

Помимо того, что вы улучшите свое понимание процедуры сборки, есть ряд задач, которые в командной строке выполняются легче и эффективнее, чем в IDE. Например, возможности поиска и замены, предоставляемые утилитами grep и sed, часто мощнее имеющихся в IDE. Инструменты командной строки поддерживают скрипты, поэтому можно автоматизировать такие задачи, как ежедневные сборки по расписанию, создание нескольких версий проекта и прогон наборов тестов. В IDE такого рода автоматизация может быть затруднена (или вообще невозможна), потому что опции сборки обычно указываются через диалоговые окна GUI, а процедура сборки запускается щелчком мыши. Если вы никогда не выходили за рамки IDE, то, возможно, не догадываетесь о возможности автоматизации таких задач.


Но, постойте. Разве IDE существуют не для того, чтобы облегчить разработку и повысить продуктивность программиста? Да, конечно. Вам не предлагают здесь прекратить пользоваться IDE. Предлагается только заглянуть «внутрь» и понять, чем в действительности занимается IDE. Лучше всего это сделать, научившись пользоваться инструментами командной строки. После этого, вернувшись к своей IDE, вы гораздо лучше будете понимать, что она для вас делает и как можно управлять процессом сборки. С другой стороны, освоив работу с инструментами командной строки и оценив предлагаемые ими мощь и гибкость, вы, возможно, предпочтете пользоваться командной строкой вместо IDE.

44. Нужно хорошо знать не менее двух языков программирования


Рассел Уиндер (Russel Winder)

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

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

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

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


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

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

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

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

45. Знай свою IDE


Хейнц Кабуц (Heinz Kabutz)

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

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

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

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


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

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

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

find . -name "*.java" | sed 's/.*\///' | sort | uniq -c | grep -v "^ *1 " | sort -r

Мы рассчитываем, что сантехник, который приходит к нам в дом, в состоянии пользоваться паяльной лампой. Давайте же потратим немного времени и поучимся более эффективно работать со своей IDE.



<< предыдущая страница   следующая страница >>