Если мне не интересно предупреждение и оно совсем несущественное, я советуюсь с командой, не изменить ли нам политику выдачи предупреждений. Например, я считаю, что документирование параметров и возвращаемого значения метода во многих случаях не приносит никакой пользы, и нет нужды выводить предупреждение об их отсутствии. Или вот еще: при переходе на новую версию языка программирования могут появиться предупреждения в коде — там, где их раньше не было. Например, когда в Java 5 появились обобщения (generics), старый код, не обозначавший типы параметров обобщений, запестрил предупреждениями. Мне не нужны такие назойливые предупреждения (пока, во всяком случае). Предупреждения, не согласованные с реальностью, бесполезны.
Обеспечив неизменно чистую сборку, я уже не должен при рассмотрении каждого предупреждения решать, существенно оно или нет. Проигнорировать что-либо — это тоже работа мысли, а я стараюсь избавляться от всей лишней мыслительной работы. Благодаря чистой сборке мне легче передать свою работу другому человеку. Если я оставлю все эти предупреждения, кому-то другому придется разбираться с ними и решать, какие из них важны, а какие нет. А еще вероятнее, что этот новый человек просто проигнорирует все предупреждения, включая существенные.
Предупреждения во время сборки полезны. Нужно лишь избавиться от бесполезного шума, чтобы начать извлекать пользу. Не откладывайте это до «генеральной уборки» кода. Если что-то начинает мозолить глаза, разберитесь с этим сразу же. Нужно либо исправить источник предупреждения, либо подавить его вывод, либо изменить политику вывода предупреждений вашей среды разработки. Чистая сборка нужна не только для проверки ошибок компиляции и «упавших» тестов. Предупреждения — важная и неизбежная часть поддержания гигиены кода.
Умей пользоваться утилитами командной строкиКэрролл Робинсон
Сегодня многие средства разработки программного обеспечения поставляются в виде интегрированных сред разработки (IDE). Помимо двух популярных примеров — Visual Studio от Microsoft и Eclipse от сообщества открытых проектов — существует и множество других. В пользу IDE можно сказать многое. Ими легко пользоваться и они избавляют программиста от необходимости вникать во множество мелких деталей, включая процесс сборки.
Однако легкость использования имеет свой недостаток. Обычно инструментом легко пользоваться, когда он принимает решения за программиста и автоматически проделывает большой объем работы за кулисами. Поэтому если в качестве среды программирования вы используете только IDE, вполне возможно, вы никогда до конца не поймете, что фактически делают ваши инструменты. Жмете на кнопку, творится волшебство, и в папке вашего проекта появляется исполняемый файл.
Работая с инструментами в командной строке, вы гораздо больше узнаете о том, что делают ваши инструменты во время сборки проекта. Составление собственных make-файлов поможет осмыслить все этапы сборки исполняемого файла (компиляция, ассемблирование, компоновка и т. д.). Эксперименты с многочисленными ключами командных строк этих инструментов — ценная и познавательная практика. Начать работу с инструментами командной строки для сборки можно со средств командной строки с открытым исходным кодом, таких как GCC, или тех, что поставляются в составе вашей коммерческой IDE. В конце концов, правильно спроектированная IDE — это всего лишь графический интерфейс к набору инструментов командной строки.
Так вы обретете лучшее понимание процедуры сборки. Кроме того, определенные задачи в командной строке выполняются проще и эффективнее, чем в IDE. Например, возможности поиска и замены таких утилит, как grep и sed, зачастую превышают аналогичные функции IDE. Инструменты командной строки ориентированы на сценарное выполнение задач, что позволяет автоматизировать, например, выполнение ежедневной сборки в заданное время, создание нескольких версий проекта и прогон наборов тестов. В IDE автоматизация такого рода может быть затруднена (или вообще невозможна), потому что параметры сборки обычно указываются через диалоговые окна GUI, а процедура сборки запускается щелчком мыши. Если вы никогда не выходили за рамки IDE, то, возможно, не догадываетесь о возможности автоматизации таких задач.
Минуточку. Разве IDE существуют не для того, чтобы облегчить разработку и повысить продуктивность программиста? Что ж, все так. Я вовсе не предлагаю прекратить пользоваться IDE. Просто вам следует заглянуть «под капот» и понять, какие задачи IDE выполняет за вас. И наилучший способ это сделать — научиться применять инструменты командной строки. После этого, вернувшись к своей IDE, вы гораздо лучше будете понимать, что она за вас делает и как можно управлять процессом сборки. С другой стороны, освоив работу с инструментами командной строки и познав их мощь и гибкость, вы, возможно, предпочтете пользоваться командной строкой вместо IDE.
Как следует изучи более двух языков программированияРассел Уиндер
Психология программирования: давно уже известно, что профессионализм программиста непосредственно зависит от количества различных парадигм программирования, которыми он владеет — не просто что-то слышал и знает о них, но умеет реально использовать их в работе.
Каждый программист начинает с какого-то одного языка. Этот язык оказывает преобладающее влияние на то, как программист видит программное обеспечение. Но каким бы долгим ни был опыт работы программиста с этим языком, если он работает только с ним одним, то и будет знать только этот язык. Мышление программиста, знающего лишь один язык, ограничено возможностями этого языка.
Программист, изучающий второй язык, встретится с трудностями, особенно если вычислительная модель второго языка отличается от первого. C, Pascal, Fortran — все они основаны на одной вычислительной модели. Переход с Fortran на C вызывает некоторые трудности, но их не так много. Переход с C или Fortran на C++ или Ada сопровождается фундаментальными трудностями с пониманием поведения программ. Переход с C++ на Haskell означает существенные изменения, а потому существенные трудности. Переход с языка C на Prolog станет весьма существенным испытанием.
Можно перечислить некоторые парадигмы вычислений: процедурная, объектно-ориентированная, функциональная, логическая, парадигма потоков данных и т. д. Переход между этими парадигмами создает наибольшие трудности.
Чем полезны такие трудности? Здесь играют роль наши представления о реализациях алгоритмов, а также идиомах и шаблонах этих реализаций. В частности, взаимное обогащение идеями лежит в основе достижения мастерства. Идиомы решения задач, применимые в одном языке, могут оказаться недоступны в другом. Пытаясь перенести идиомы из одного языка в другой, мы начинаем лучше понимать оба эти языка и задачу, которую решаем.
Взаимное обогащение при использовании разных языков программирования дает мощнейшие эффекты. Пожалуй, наиболее очевидным из них является все растущее применение декларативных режимов описания в системах, реализованных посредством императивных языков. Любой знаток функционального программирования может легко применить декларативный подход, даже при работе с таким языком, как C. Применение декларативных методов обычно приводит к созданию более коротких и понятных программ. Скажем, C++ определенно выступает за такой подход, обеспечивая всестороннюю поддержку обобщенного (generic) программирования, в котором декларативный режим описания является почти обязательным.
Как следствие всего сказанного выше каждому программисту надлежит уметь хорошо программировать хотя бы в двух разных парадигмах, а в идеале хотя бы в перечисленных пяти. Программист всегда должен стремиться к освоению новых языков, предпочтительно с незнакомыми ему парадигмами. Даже если в своей повседневной работе он неизменно использует один и тот же язык программирования, нельзя недооценивать то более искусное применение этого языка, которое станет возможным благодаря идеям из других парадигм. Работодателям следует это учесть и закладывать в бюджет обучение сотрудников языкам, которые в данное время на проектах не используются, как средство научить работников более искусно применять те языки, которые реально используются.
Неделя начального курса — это хорошо, но не достаточно для изучения нового языка. Чтобы приобрести рабочие навыки применения языка, обычно нужно потратить несколько месяцев хотя бы факультативно. Важно практическое освоение идиом, а не просто изучение синтаксиса и вычислительной модели.
Знай свою IDEХейнц Кабуц
В восьмидесятые годы среда программирования, как правило, не сильно отличалась от текстового редактора с наворотами — в лучшем случае. Это сегодня мы воспринимаем подсветку синтаксиса как нечто само собой разумеющееся, а в то время она была роскошью, доступной далеко не каждому. Средства форматирования кода существовали в виде внешних инструментов, применение которых корректировало расстановку пробелов. Отладчики тоже «жили» отдельно как программы для пошагового выполнения кода, и для работы с ними требовалось знать массу загадочных сочетаний клавиш.
В девяностые годы компании начали осознавать потенциал прибыли от более удобных и полезных инструментов разработки. Интегрированная среда разработки (Integrated Development Environment, IDE) объединила уже предлагавшиеся ранее функции редактирования с компилятором, отладчиком, средствами форматирования и другими инструментами. Как раз в это время стали популярны меню и мышь, а значит, отпала надобность заучивать разработчикам сложные комбинации клавиш для работы со своим редактором. Достаточно было выбрать команду из меню.
В двадцать первом веке IDE настолько распространились, что некоторые компании, нацеленные на доли рынка в других областях, раздают их бесплатно. Современная IDE предлагает множество восхитительных функций. Мне особенно нравится автоматический рефакторинг, в частности функция