понедельник, 1 сентября 2008 г.

Багаж знаний. Часть 6.

Инженерная культура, командная работа

Два понятия объединены вместо, чтобы сильно не дробить тему. К тому же, командная работа в принципе невозможна без привитой каждому участнику команды инженерной культуры. Сначала об инженерной культуре.

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

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

  • "… А ты создавай компонент в "ран-тайме" и присваивай ему "парентом" главную форму…"
  • "…Подменяй в "квери" динамически условие "where", и прибей к нему план запроса…"
  • "…Отпиши в трекер про эту багу, ковыряю ее на днях…"
  • "…Слил код с cvs, просмотрел дифы и закоммитил…"
  • "…Сегодня в "ньюсах" пробегала "инфа" о выходе нового релиза…"

Кстати, про релизы. Система нумерации версий ПО на сегодняшний день еще не устоялась. Если раньше продавали ПО, в имени которого фигурировал номер версии, то потом перешли на наименования по году выпуска, а номер версии стал внутренним атрибутом программы. Теперь уже и год выпуска уходит в прошлое- популярность набирает именование версии ПО просто красивым именем: "Виста", "Арканоид", "Центрино" и т.д. Но внутренние версии именуются все также: до точки ставится номер версии ПО, после точки- промежуточные варианты, связанные с внесением в ПО незначительных улучшений и устранением ошибок. В скобках также указывается номер билда. Номера билдов- это сквозная нумерация всех сборок программы, номер билда не сбрасывается в нуль при переходе к другой версии, он всегда только возрастает. Строго говоря, номер билда- это более точный идентификатор ПО, чем версия, т.к. в рамках одной версии может быть собрано несколько билдов с незначительными отличиями. Тем не менее, при обнаружении ошибок наиболее достоверный способ разработчику узнать, какие изменения привели к ошибке- это посмотреть номер именно билда, а не версии программы. Примеры версий программы:

  • 1.01 (123)- версия (еще называемая мажорная версия) 1, в рамках этой версии- подверсия (минорная версия)- 01, билд- 123.
  • 3.17 (1435) - версия 3, подверсия 17, билд- 1435.

Методологии программирования. С целью повышения продуктивности труда инженера и обеспечения стабильности выдаваемого им результата постоянно разрабатываются новые методики программирования. Существенного результата до сих пор не дала ни одна методика. Единственное, на чем все точно сошлись, так это на том, что каскадная разработка окончательно уступила место итерационному способу разработки ПО. Это случилось давно и нынешнее поколение молодых разработчиков уже нигде с ней (каскадной методикой разработки) не столкнется. А суть итерационного способа разработки сводится к тому, что сначала делаются крупные наброски, основной функционал, реализация которого требуется в первую очередь, и затем, круг за кругом функционал прорабатывается более детально с учетом замечаний заказчика, устраняя по пути обнаруженные ошибки. При такой методике зачастую оказывается, что проект далеко уходит от первоначальных планов, а для заказчика наиболее важным оказывается другое, чем то, что считалось в начале. Благодаря итерационному подходу подобные вещи выясняются наиболее быстро, а сама методика позволяет гибко адаптироваться к изменяющимся требованиям.

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

  1. Обсуждение функционала. Это когда собирается группа и обсуждает, как надо сделать. Рисуют на доске, на листках, обсуждают после совещания в коридорах. Распределяются обязанности.
  2. Делается первый черновой вариант, густо "нашинкованный" заглушками. Вариант обсуждается, учитывается первый опыт, замечания и разработка идет на второй круг.
  3. Когда руководитель видит, что пора уже делать релиз, дается команда чуть притормозить коммиты в CVS нового функционала, а усиленно "довести до ума" функционал, который должен войти в релиз. Если вы не успели "довести до ума", то страшного ничего не будет, но вам добавиться лишняя работа т.к. наступит следующий этап.
  4. Создается ветка в CVS. С этого момента новый функционал в ветку не добавляется, а коммитится в HEAD. В ветке с готовящимся релизом сидят разработчики, усиленно дорабатывающие ПО. В HEAD'e продолжает работать небольшая часть разработчиков. С этого момента начинают выкладываться так называемые "снап-шоты". Это ночные сборки всего ПО, которое должно войти в релиз. В эти сборки сходят изменения, сделанные разработчиками за день.
  5. По мере готовности версии продукта, руководитель принимает решение о выпуске альфа-версии. Эта версия позволяет широкому кругу пользователей предварительно ознакомиться с ПО, а разработчикам получить обратный отклик ("фид-бэк") о ПО, а также список обнаруженных пользователями ошибок ("багов").
  6. Когда функционал программы сформирован, выпускается RC1 (release candidate 1), т.е. предварительная версия. В ней уже нового функционала внедряться не будет, идет только исправление ошибок.
  7. По мере снижения количества обнаруженных ошибок и их исправления выпускаются RC2, RC3. Крайне редко делают RC4. RC3 уже означает, что ПО в данной версии достигло зрелой стадии и пригодно к эксплуатации. Количество разработчиков, работающих над данной веткой продукта, уменьшается, т.к. для исправления ошибок их уже много не надо. Многие переходят на разработку следующей версии, как говорят "работать в HEAD'e". Такая вот несколько необычная ситуация- еще текущую версию не выпустили, уже работают на следующей. Легко может в производстве находится 1-2 версии ПО одновременно, и еще плюс экспериментальные разработки (это уже только в очень крупных компаниях уровня Microsoft).
  8. И вот, наступает долгожданный момент, и объявляется о выпуске релиза (release). Именно релиз начинает массово распространяться, рекламироваться, а разработчики расходятся по другим проектам. Выпуск сопровождается банкетом для всех разработчиков, в каждой фирме есть свои традиции выпуска релизов: вручение памятных знаков, "золотых" дисков с релизом ПО и т.п.

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

Ночные сборки полезны сторонним разработчикам, которые будут использовать готовящийся продукт в своем ПО. Сторонние разработчики являются не просто опытными пользователям ПО, наиболее доверенным из них предоставляется доступ к части исходного кода программы. Имея доступ к низкоуровневым интерфейсам программы, они, что называется, видят ее изнутри, и могут свежим взглядом со стороны подсказать направления реализации тех или иных возможностей, указать на ошибки, и даже ошибки проектирования. Для общения с наиболее активными пользователями и сторонними разработчиками создаются специализированные форумы, нередко сторонние разработчики напрямую по e-mail обращаются к разработчикам выпускаемой версии ПО, встречаются на семинарах и конференциях, где неформально общаются и обсуждают готовящийся релиз. Сторонние разработчики стараются вместе с анонсом выпуска релиза вашего ПО, объявить о выпуске своего ПО, полностью поддерживающего функционал новой версии вашей программы.

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

Совершенно нормально в команде попросить о помощи, если нет мысли как лучше реализовать функцию или помощь в поиске бага. Иногда, заработавшись, просто не замечаешь правильного решения, и взгляд со стороны очень помогает. Замечено, что иногда достаточно кому-то просто слух объяснить, проговорить постановку задачи или описание бага, и решение само собою всплывает.

Немаловажную роль в понятии инженерной культуры играет умение понятно, красиво оформить код и комментарии в нем. Внутри команды вырабатываются определенные правила оформления код. Придя в команду, смотрите как другие программисты в других модулях оформляют код и комментарии и подражайте им. Если вы программируете в уже существующем модуле, то, во-первых, придерживайтесь стиля оформления кода, принятого в этом модуле, а, во-вторых, не переформатируйте строки, написанные не вами. Второе требование имеет смысл еще и в другом плане. Системы контроля версий помечают за вами все измененные вами строки. Даже, если вы там только один пробельчик м-а-а-аленький такой поставили, то автором этой строки становитесь вы. И теперь багу, связанную с этим кодом, править вам, хотя вы и понятия об этом коде на самом деле не имеете. Кроме того, внимательно изучайте используемые приемы программирования в команде. Вы должны писать программы в одном стиле с остальными разработчиками, тогда код будет легче читаться и модули друг с другом проще будет связать между собой. Единство в оформлении кода, документировании кода и выборе способа решения задач- важный элемент командной работы.

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

Заключение

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

(Конец)

Багаж знаний. Часть 5.

Специализированные знания в определенной предметной области

Если главы про книги, ОС, форумы и телеконференции актуальны для любой специализации, глава про инструментарий актуальна не всем, то про технологии и языки программировании главы интересны далеко не всем. Это такие специализации, как программист банковского ПО, программист бухгалтерского ПО, тестировщик, системный администратор и т.д.

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

Знания и опыт

Вы думаете что, например, программисту 1С не надо читать Страуструпа и Кнута? Вы пренебрежительно фыркали, читая главу про технологии или инструментарий? Ну тогда может вас убедят несколько случаев из моей жизни. Это не взято с других сайтов, все случаи произошли с моим участием.

История первая. У гордости российской IT-отрасли, фирмы 1С, у ее хорошо развитого ПО, есть "ахиллесова пята": огромная армия низкопрофессиональных программистов, чей уровень подготовки зачастую граничит с профанацией. На мой взгляд, это произошло из-за низкого уровня вхождения в рынок: продукт настолько прост в изучении, что многие не программисты (экономисты, кадровики и пр.) становятся программистами 1С. Так вот, был в фирме, где я работал, программист 1С Толик. Экономист по образованию. Однажды мое внимание привлекло оживленное бегание бухгалтеров к нему, и Толика к бухгалтерам. Они носили кипы бумаг, оживленно что-то обсуждали, засиживались до поздна. Это продолжалось дня два. На третий день взлохмаченный и задуренный он оглянулся вокруг в поисках ЛЮБОЙ помощи. Тут я и спросил его:
- Толик, что за "запарка" у вас? Отчетность очередная?
- Неее, 1С глючит, третий день бьюсь, не могу обойти.
- ?!
- НДС считает не правильно, суммы с НДС и без НДС не сходятся в копейках.
В общем, тут уже можно смеяться, продолжать историю нет смысла. Далее я ему провел ликбез по программе первого курса технического ВУЗа, и объяснил, что такое погрешность округления. В следующие полчаса задача, занимавшая умы всех бухгалтеров предприятия и Толика, была успешно решена.

Вторая история. Костя, сертифицированный программист по финансовым системам. Сидим в кафе, говорим о разном. Зашла речь о его работе. Он расхваливает свою систему и предлагает ее внедрить на моем предприятии. На что я говорю, что она такие объемы не потянет. Далее Костя говорит:
- Ну почему же не потянет, вот мы заканчиваем крупный проект и там все нормально с производительностью.
- А что будет через год, когда там будет много данных? - спрашиваю я.
- Купят сервер помощнее.
- Да, у вас система мощная, но почему бы вам ее не оптимизировать, чтобы не требовалось наращивать железо?
- А это умная программа: она сама себя оптимизирует.
- Такого не может быть! Что будет, если я добавлю в таблицу БД еще одно поле и буду вести по нему поиск? Если я ручками не проиндексирую поле, то поиск будет вестись медленно, перебором! Тут сама программа ни при чем.
- Неее, программа умная, там все очень хорошо продумано. Будет работать быстро.
- Но как?!
- Я точно не знаю, но думаю, что она сама будет автоматически все поля индексировать!

Следующая история. Маленький диалог:
- Я буду переписывать твою программу с нуля.
- Для чего? Там будет другой функционал?
- Нет.
- Там будет использоваться другая БД?
- Нет.
- Я потратил месяц чтобы ее написать. Зачем ты будешь еще минимум месяц тратить, на то, чтобы ее переписать?
- Я не хочу разбираться как работает твой код.

Еще одна история. Напротив меня одно время было рабочее место программиста Жени, с очень большой зарплатой, т.к. он считается очень хорошим специалистом. Он упорно работает над протоколом обмена данными между программами. У Жени в его работе возник затык. Он прогулялся, поймав меня в коридоре и, немного стесняясь, спрашивает: "А сколько бит в числе?". Так и спросил: бит в числе.

Несколько лет назад я разбирался с мистической историей. Функционал у клиента в принципе не работал. Вообще. Как будто его и вовсе не было. "Ларчик" открылся быстро- достаточно было взглянуть на исходный код. Код, который был помещен программистом в... модуль с Unit-тестами! Т.е. на тестировании все работало великолепно, но когда собирался релиз, этого кода там просто не оказывалось.

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


(Продолжение следует...)

Багаж знаний. Часть 4.

Рабочий инструментарий программиста

Как я уже писал ранее, рабочее место современного программиста оснащается, как "космический корабль", кучей различного ПО: см. "Инструменты программиста": http://www.alvosoft.com/itlife/2007/05/blog-post_30.html. По этому вопросу даю еще ссылку: http://alenacpp.blogspot.com/2008/01/wiki.html. Теперь, как и с технологиями, список с небольшими комментариями от себя (сразу извиняюсь, что в списке я не всегда корректно "на одну доску" ставлю в качестве примера два сильно разных инструментария- для кратких пояснений различия между ними можно не учитывать, общей картины это не ухудшит):

  • Система контроля версий (представители: CVS, SVN)- данные системы ведут учет версий файлов, хранят все версии и информацию о том, кто изменил файл, какие именно строчки в файле изменил и когда. Это позволяет восстановить состояние файлов на любой версии, а также организовать коллективную работу на проектом. Работа над проектом нескольких человек практически невозможна без использования какой-либо системы контроля версий. Поэтому научиться работать с CVS или SVN начинающему специалисту надо обязательно.
  • BugTracker (представители: Jira, BugZilla)- системы отслеживания ошибок. Позволяют пользователям вести учет найденных в ПО ошибок и отслеживать этапы их устранения. Это тоже обязательный элемент изучения для начинающего. В командах разработчиков багтрекеры используются незначительно реже, чем системы контроля версий.
  • Документирование (представители: Wiki, Doxygen)- эти системы позволяют документировать исходный код программы (Doxygen), а также документировать процесс разработки (wiki): обмен мнениями, идеи, планы. Системы просты в изучении, поэтому даже обсуждать не стоит, надо их изучать или нет- даю полчаса на изучение. Время пошло!
  • Profiler- позволяет замерить время выполнения отдельных функций программы с целью выявления узких мест для последующей оптимизации кода программы. Этим пользуются нечасто, чаще предпочитают купить железо помощнее. Для начинающего достаточно просто знать что есть такие штуки как "профайлеры".
  • Debugger- отладчики программ. Ну, без них отладка ПО мучение сплошное. Обязательно надо уметь не только ими пользоваться, но и великолепно владеть методами отладки. Тут учебники не помогут: практика, практика и, еще раз, практика.
  • Сборщик (представители: make, cmake, ant)- программа, которая по заданному сценарию вызывает компиляцию отдельных файлов исходного кода ПО в нужной последовательности. Конечный результат работы сборщика: собранная и готовая к запуску программа. Обычно у сборщиков бывает несколько целей работы: сборка отладочной версии ПО, сборка с тестированием, сборка релиза, сборка инсталляционного пакета. В правильно организованном процессе сборки подготовка инсталляционного пакета должна выполняться в два этапа: выгрузка из системы контроля версий нужной версии программы и запуск сборщика- все, после этого в заданном каталоге должен оказаться инсталляционный пакет. Обычно в командах программистов от 5 человек, как правило, есть отдельный человек, который занимается исключительно сборщиком. От начинающего программиста требуются общие знания о сборщиках.
  • Тестирование (например: UnitTest)- видов тестирования много, это отдельная от программирования область деятельности. В серьезных проектах обязательно есть тесты, есть люди, занимающиеся тестированием. Программисту достаточно понимать, что тестируется и как, не вникая в тонкости построения систем тестирования.
  • Написание справки (представители: Tex, Chm)- часто программистам самим приходится писать справки для пользователей. Это не любимое дело большинства из программистской братии. В серьезных организациях для этого есть отдельные люди, и даже отделы. Техническая сторона дела- формат записей, сборка справки несложна, однако косноязычность- непреодолимый барьер для большинства IT-специалистов. В общем, бегло просмотрите что это такое, чтобы знать, кто такие "течрайтеры" и как с ними общаться.
  • Инсталляторы (представители: Inno Setup, MSI)- этими программами, отвечающими за корректную установку или удаление ПО, как правило, занимаются отдельные специалисты. Программист сталкивается с ними в основном когда пробует сам продавать свое ПО (shareware). Поэтому от начинающего программиста достаточно, чтобы он знал, используемые им технологии: какие dll надо включить к инсталляционный пакет, какие значения задать в реестре и т.п., чтобы сообщить это специалисту, занимающемуся сборкой инсталляционного пакета.
  • Защита ПО (представители: Execryptor, Hasp)- в этим программист уж вряд столкнется в начале карьеры. Установкой системы защиты ПО от нелегального копирования редко занимаются в самих организациях, предпочитая отдавать эту работу на аутсорсинг. Это связано с тем, что защита обычно пересматривается перед релизом и держать на постоянной основе своего специалиста по защите большинству фирм не выгодно.
  • Проектирование (представитель: UML)- в этой области знаний больше "воды", чем реально полезной информации. UML- хорошо пропиаренный способ описания проекта. Я работал и был связан с очень крупными IT-предприятиями, имена которых у всех на слуху. Их штат сотрудников насчитывает более 1000 человек. И что характерно, они не используют ни UML, ни каких-либо других способов описания проекта. Прекрасно обходятся доской с фломастерами и живым общением. Поэтому моя рекомендация начинающим: "на первых порах" держитесь подальше от слов UML, методики проектирования- это точно не первоочередные вещи, которые надо изучать.
  • Управление разработкой (представители: MS Project, электронные таблицы)- волей-неволей, но вы все же придете к понимаю необходимости управлять процессом разработки. Даже, хотя бы лично для себя составить кратенький план: "1). написать класс…; 2). не забыть его подключить туда-то…; 3). изменить то-то…". Например, я делаю такие пометки в обычном notepad.exe. Рекомендую этот стиль работы: вы ничего не забудете сделать, что повысит качество вашей работы, а вашему начальнику вы в любой момент сможете предоставить отчет о том, что сделали, и о том, что вам еще предстоит сделать.
  • Протоколированное общение (представители: телеконференции, IM-клиенты, e-mail)- я указал именно протоколированное общение. В работе важно, чтобы общение записывалось, чтобы можно было потом что-то важное по записям вспомнить. Личный совет: никогда не удаляйте протоколы- пройдет 3-4 года и обязательно что-то всплывет, что потребует вспомнить, что же вообще-то было.
  • Обмен файлами (представители: SMB, FTP)- ну куда уж без этого! В ходе работы файлам обмениваются постоянно, начиная с внутренней документации, заканчивая личными фотками с отпуска. Я предпочитаю FTP- неприхотливый протокол. FTP-сервера у меня запущены и дома, и на работе.

Информация по перечисленному инструментарию можно найти в http://ru.wikipedia.org/. В каждом пункте я привел по паре примеров, но подобного ПО существенно больше- освойте, хотя бы перечисленное для начала. Приведенные примеры- наиболее популярные программы, зная их, на собеседовании вы будете чувствовать себя гораздо увереннее.

(Продолжение следует...)

Багаж знаний. Часть 3.

Операционные системы

На протяжении всего блога я ориентирую начинающих специалистов на мэйнстрим. Явно указываю язык программирования, который надо изучать, критерии для оценки фирм, в которых стоит работать и т.п. Да! И еще я по-прежнему утверждаю, что не надо поступать учится в ВУЗ: http://www.alvosoft.com/itlife/2007/04/blog-post_5372.html. А по операционными системами я еще "наводок" не давал.

На сегодняшний день ситуация такова, что Linux получает все более широкое распространение. Даже на дешевые ноутбуки стали ставить эту ОС, чего ранее не было вообще. Так стоит ли оставаться на Windows или надо уже потихоньку перекочевывать на Linux? Вне сомнений, что на текущий момент Windows кормит минимум 80% IT-специалистов. Я не буду проводить никаких исследований, и скажу на основании своего опыта: лучше изучать программирование под Windows. Как ни крути, а "винда"- это мэйнстрим, то, где крутятся основные деньги, выделяемые на IT. Ситуация в будущем коренным образом не изменится, т.к. любая попытка более широкого продвижения Linux за счет доли Windows упрется в сопротивление уже не только Microsoft, но и многочисленной армии программистов, откормленной на сытном рабочем столе Windows.

Если вы сделали самостоятельный выбор в пользу программирования под Linux, то переубеждать вас не буду- и там вы свой хлеб найдете, а не определившимся однозначно советую освоить программирование под Windows. Именно эта ОС на сегодняшний день лучшая в смысле перспектив развития, карьеры и заработка.

Языки программирования

Про языки программирования я уже писал: http://www.alvosoft.com/itlife/2007/04/blog-post_24.html, предлагая осваивать Java и БД Oracle. Вот моя небольшая характеристика языков:

  • Java. Синтаксис языка изящен. Программировать на нем приятно. Создан, что называется, "по уму". Для него существует огромное количество библиотек, хорошо организованно сообщество программистов, этот язык поддерживают крупные корпорации, такие как IBM, Sun, Oracle. Язык нашел широкое применение в области разработки крупных корпоративных систем.
  • С++. Лично мне он нравится за то, что его многие критикуют: за отсутствие сборки мусора. У данного языка программирования весьма широкие возможности, что позволяет с его помощью решать широчайший круг задач, которые, зачастую, трудно решаемы в рамках других языков программирования. Однако его высокая гибкость, запутанный и трудночитаемый синтаксис, сложность задают высокий барьер "вхождения", т.е. надо приложить гораздо большие усилия, чем в других языках, чтобы освоить его.
  • C#. Часто о нем говорят, как об майкрософтовской альтернативе Java. Т.е., фактически, признавая только одну причину его появления- попытка Microsoft захватить лидерство и в области инструментария для программистов. В общем-то, язык не имеет ничего выдающего по отношению к другим языкам, и, наверное, для использующих его программистов, главное- это целостная, единая поддержка его со стороны компании. Что весьма важно при разработке крупных проектов, где C# и нашел свое применение. Но, боюсь, что этот вечный ярлык его, как подражателя, оппонента Java сыграет с ним свою злую шутку, и он пойдет по пути Visual Basic, которого мало кто всерьез воспринимает.
  • Python, Ruby и др. Их стоит воспринимать как эксперимент. Основные "мэйнстримовые" языки уже сформированы и серьезные изменения в них недопустимы, т.к. это может поломать многие крупные проекты. Однако жизнь не стоит на месте, появляются новые технологии, новые идеи, которые надо где-то обкатывать. Вот и появляются новые языки программирования, реализующие некий новый функционал, который в них обкатывается. По прошествии нескольких лет успешной эксплуатации этот новый функционал появляется в основных языках программирования: C++, Java, C#. Если идея, новый функционал на деле показал себя "не очень", то язык с этим функционалом тихонько займет свою узкую нишу, где спокойно и будет доживать свои дни.
  • Узко специализированные языки программирования. Яркий и широко известный пример: встроенный язык программирования в системе 1С или, например, web-программирование. Такие языки отлично адаптированы для решения узких задач в своей области. В них во главу угла ставится не программирования как таковое, а решение бизнес-задач. Программирование здесь вторично. Благодаря своей легкости осваивания, порог "вхождения" в эту область деятельности низок. Как правило, это приводит к тому, что в данной области скапливается разношерстный народец с весьма низким уровнем познаний в области программирования. Данное "сборище" формирует высококонкурентное сообщество, что приводит в более низким зарплатам в этих областях.
  • Мало распространенные языки программирования или уже потерявшие былую славу. Это языки типа (тут сейчас будут возмущенные вопли): C, Delphi, Basic. Армия программистов на этих языках еще весьма велика, но эти языки уже явно не являются основными в целом по отрасли, и ушли в узкую нишу. Существует огромное количество ПО, написанного на них, которое надо поддерживать. Учитывая, что пополнения рядов программистов в этих языках идет крайне низкими темпами, то "старые" программисты на этих языках с каждым годом становятся все ценнее и ценнее.

По вышеуказанной вначале списка ссылке вы можете пройти простой алгоритм по которому вы можете сориентироваться, куда вам лучше всего податься. Став хорошим специалистом, вы в любой нише найдете себе высокооплачиваемую работу. Но я лично рекомендую держаться мэйнстрима, и выбирать между C++, Java, C#, 1С, web-программированием. А Python и прочие оставьте для экспериментов.

(Продолжение следует...)

Багаж знаний. Часть 2.

Технологии

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

  • Run-Time, Design-Time, Compile-Time. Эти термины означают момент, когда происходит то или иное действие: во время исполнения программы, во время разработки, во время компиляции. Эти понятия не должны вызывать ни малейших трудностей при использовании их в дискуссии.
  • RTTI- возможность во время выполнения программы (Run-Time) исследовать тот или иной объект в программе: определить список его свойств, узнать тип каждого свойства. Эта технология требуется не часто, допустимо знать про нее в общих чертах.
  • ООП- парадигма программирования, в основе которой лежит понятие объекта заданного класса. На сегодняшний день- это мэйнстрим, основной способ написания программ у подавляющего числа программистов.
  • Шаблоны- генерация кода по заданному шаблону. В принципе, общих знаний про шаблоны будет достаточно.
  • Перегрузка операторов- возможность задать свои функции для выполнения таких операций, как сложение, умножение и т.п. Используется не часто- общих знаний будет достаточно.
  • Исключения- один из способов обработки ошибок в программе. Это лучше знать- мощнейший механизм, значительно облегчающий обработку ошибок, хотя многие его избегают, в основном из-за недостаточных знаний об исключениях.
  • Call-back вызовы- когда какой-либо внешней функции передается адрес определенной функции в нашей программе, чтобы та внешняя функция могла вызвать от себя нашу функцию (типа того, как мы пишем SMS кому-то: "Перезвони мне на такой-то номер"). Знать обязательно- встречается часто, можно сказать- постоянно.
  • Лямбда-функции- смотри про лямбда-исчисление. "Зверь" относительно новый, ради эрудиции почитать стоит.
  • Компонентная модель- говоря про это емкое понятие, обычно имеют ввиду способ построения программы с помощью компонент- функционально полных программных блоков, которые являются как бы "кирпичиками" программы. Простота разработки программ с помощью компонент породила класс программистов, называемый "кнопочкокидатели на формочки".
  • Обмен сообщениями- тема очень широкая. Тут и RPC, и очереди, и посылки сообщений, сигналы. Знать обязательно. Ключевые слова для поиска информации к изучению: RPC, events, signal, queue.
  • Приемы оптимизации. Это когда что-то тормозит или "кушает" много каких-либо ресурсов, то надо улучшить показатели программы по этому "тормозному" параметру. Например, если низкая скорость работы программы, то повысить ее можно предварительным кэшированием данных. Обычно улучшение одного показателя ухудшает другой. Например, увеличение быстродействия часто требует повышенного расхода используемой памяти. Хороших книг по оптимизации я не знаю- только практика.
  • Многопоточность- это когда внутри программы может выполняться одновременно несколько функций. В наш век многоядерности и многопроцессорности про это надо знать.
  • Синхронный/асинхронный режим работы- в синхронном мы посылаем запрос и дальше не работаем пока не придет ответ, а в асинхронном- послали запрос и занимаемся "своими делами", по приходу ответа выполняем его обработку. Асинхронный в реализации сложнее. Это тему знать надо хорошо.
  • Каналы, потоки- это некоторые из способов обмена информацией. При этом технология каналов имитирует канал, трубу (pipes), по которой как бы течет информация, а потоки (stream) имитируют что-то типа потоков, рек информации из которых мы как бы черпаем нужные нам данные. Эти вещи знать надо железно.
  • Блокировки (мьютексы, критические секции)- это способ сообщить другим частям программы или другим программам, чтоб они "не лезли сюда" (к определенным данным, к "железу"), т.к. вы в своей функции уже приступили к работе с блокируемыми ресурсами и пока не закончите, никто не должен их трогать. Про блокировки надо знать, эта тема идет "рука об руку" с темой многопоточности.
  • Регулярные выражения- поиск текстовых данных по заданному образцу. Ну без этого совсем никуда.
  • XML- замечательный язык для структурирования информации. Получил широкое распространение, легок в изучении. Знать обязательно.
  • Библиотеки подпрограмм, классов. У каждого языка программирования есть свои библиотеки. Есть такая фраза, часто цитируемая в форумах: "В языке главное не знание его синтаксиса, а знание его библиотек". Говорить, что это знать обязательно, даже не имеет смысла- мимо изучения библиотек не пройти на пути повышения своей квалификации.

В этом перечне краткие пояснения мои. Я упрощал пояснения в ущерб точности определения. По большинству терминов определения можно найти в википедии: http://ru.wikipedia.org/. От программиста ожидается, что он ориентируется в большинстве из перечисленных терминов. Исключением является большая группа программистов 1С, SAP и других, им подобных. В их областях программирования первично умение решать бизнес-задачи, а не сугубо технические задачи программирования, поэтому и требуемый круг знаний там другой. НО! Другой список терминов вовсе не означает, что не надо читать Страуструпа и Кнута. Перечисленные книги надо прочесть всем- это фундаментальная подготовка. К чему может привести ее недостаток- в конце статьи.

Форумы и телеконференции

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

  • http://www.rsdn.ru/ - наиболее предпочитаемый мною. Тут есть и бдительные модераторы, и опытные специалисты, а особенно мне нравится наличие удобного оффлайного клиента для чтения форумов на сайте.
  • http://www.sql.ru/ - более "чайниковского" уровня форумы. Для начинающих может быть и ничего, но лично меня форумы этого сайта раздражают: слишком мало полезной информации, в основном вопросы начального уровня. Но зато можно подключиться к форумам по протоколу NNTP и просматривать их в том же Outlook'e.
  • http://groups.google.ru/ - хорошие форумы есть, но их надо поискать среди кучи практически мертвых форумов. К плюсам можно отнести возможность подключения к форумам по протоколу NNTP.

Если вы еще не были на этих форумах, то обязательно зайдите- наверняка найдете там интересное для себя.

(Продолжение следует...)