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

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

Умей пользоваться утилитами командной строки Кэрролл Робинсон

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

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

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

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

Минуточку. Разве IDE существуют не для того, чтобы облегчить разработку и повысить продуктивность программиста? Что ж, все так. Я вовсе не предлагаю прекратить пользоваться IDE. Просто вам следует заглянуть «под капот» и понять, какие задачи IDE выполняет за вас. И наилучший способ это сделать — научиться применять инструменты командной строки. После этого, вернувшись к своей IDE, вы гораздо лучше будете понимать, что она за вас делает и как можно управлять процессом сборки. С другой стороны, освоив работу с инструментами командной строки и познав их мощь и гибкость, вы, возможно, предпочтете пользоваться командной строкой вместо IDE.

Как следует изучи более двух языков программирования Рассел Уиндер

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

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