Это занятие в рамках «Курсов повышения ИТ-компетенций» было 10.12.2010. Понимаю, что пишу с опозданием… Но что это такое для истории! :) К тому же, материал для меня там был освещен интересный и, главное, неизвестный мне.

А началось все с описания финальной версии аттестационного задания (именно его выполнение и задержало написание поста). Его я скорее всего опишу отдельно. А пока перейду к тому, что было после озвучивания того, что должна уметь наша аттестационная программа.

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

Прежде, чем перейти к описанию систем и примерам, нам сказали о результатах исследования, проводившегося давно, в «бородатые» годы, и направленного на изучение эффективности работы программистов. Так вот, получилось, что в среднем программист пишет 7-8 строк кода/день! Имеются в виду те стоки программы, которые после этого остаются в финальной версии программы. Сейчас этот показатель, конечно, вырос, но не на порядки.

После такого приятного начала (еще бы, можно писать всего 7-8 строк, а остальное время плевать в потолок и болтать в аське :)), было упомянуто профилирование. Или профайлеры, если говорить о типе программ.

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

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

Следующее рассмотренное понятие – «покрытие кода».

Покрытие кода – мера, которая говорит о том, какой процент кода был протестирован в программе, т.е. все ли участки программы были так или иначе задействованы при тестировании.

Естественно, следует стремиться к максимальному покрытию, чтобы быть уверенным, что все функции работают правильно и не «мешают» друг другу.

Следующий вопрос – системы контроля версий (или системы управления версиями). Главное назначение таких систем – упростить коллективную разработку, когда есть несколько версий различных библиотек. Она позволяет при необходимости загрузить старую версию кода, если выяснилось, что новая оказалась неудачной и/или испорченной. Также, системы контроля версий позволяют осуществлять поддержку сразу нескольких версий одного и того же ПО, ведя при этом историю изменений.

Пример такой системы – Subversion (или SVN). Это бесплатная и, хорошая и очень популярная система контроля версий.

Существует также CVS, распространяемая по лицензии GNU GPL, но её активная разработка уже давно прекращена, и она имеет некоторые недостатки, исправленные в Subversion.

Также облегчают жизнь системы отслеживания ошибок. Они нужны уже на этапе тестирования. Суть такой системы в следующем: тестер обнаруживает ошибку и создает в системе запись о ней с описанием того, что привело к ней, её важности, и прочей подобной информацией. Далее, разработчик видит, что появилась новая ошибка, «открывает» её, пытается воспроизвести. Если это у него не получилось, то «закрывает» ошибку с пометкой «не воспроизводится». Если же вызвать ошибку удалось, то он её исправляет, отсылает новую исправленную версию и «закрывает» ошибку с пометкой «исправлено». Тестер получает уведомление об исправлении ошибки, проверяет, действительно ли она исправлена и, если да, то подтверждает исправление, если нет – все повторяется по кругу.

Следует отметить, что все ошибки в системе, как правило, и не пытаются исправить. На это просто нет времени и денег. Исправляют в первую очередь критические ошибки и «замечания» заказчика.

Пример системы отслеживания ошибок – Mantis – свободно распространяемая система, написанная на PHP.

Последним из инструментариев были рассмотрены юнит-тесты. В Википедии о них написано:

Модульное тестирование или юнит-тестирование (англ. unit testing) — процесс в программировании, позволяющий проверить на корректность отдельные модули исходного кода программы.

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

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

Пример среды для юнит-тестирования – NUnit.

Закончилось занятие дополнительными вопросами, о возможностях и требованиях к программистам в Ульяновске. Вот что мы узнали из ответов Власенко:

Средний программист в Ульяновске запросто может рассчитывать на зарплату в 20-30 тыс. рублей. Уже «матерые» — на ~40 тыс. А самые сливки имеют возможность получать и 60-80 тыс.

Самыми оплачиваемыми языками программирования Власенко считает: JS, PHP, Java и далее по списку все остальные. Для меня, если честно, удивительно, что в списке высокооплачиваемых языков нет C++… Но он так считает, а может это средние цифры по всем вакансиям.

Далее, период полураспада знаний программиста составляет 2.5 года. Т.е. если ничего не делать и не развиваться, то через этот срок ваши знания уменьшатся в 2 раза.

И последнее, о чем нам поведали: у хорошего программиста при приеме на работу должен быть опыт работы по специальности в 3000 часов за последние 3 года. Это сделано как раз, чтобы брать человека с «нераспавшимися», актуальными знаниями.

После этого нас отпустили домой, делать аттестационное задание…