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

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

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

В предыдущем абзаце я нарочно ввел термин “инженер-программист”. Как-то получается так, что программист — это не обязательно инженер. Даже из определения Википедии следует, что инженер — это в первую очередь проектировщик. Это тот, кто создает, т.е. проектирует системы. А в практике программирования проектирование нужно не всегда. Иногда достаточно кодирования: используя данный набор технологий, слепить что-то работающее. Типичный пример — стадо корпоративных или маркетинговых сайтов на джумлах, ворпрессах, друпалах и т.д. Это уровень техника, не инженера. Это уровень среднего образования. И работать техником можно даже после окончания курсов какого-либо языка программирования, крепкая теоретическая база там не нужна.

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

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

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

Первый уровень из CS (computer science) — Специальная база. Это стартовая площадка для любого программиста по четырем фронтам:

• арифметические основы ЭВМ (системы счисления и операции с числами, логические операции);

• физические основы ЭВМ (полупроводники, транзисторы, логические элементы, схемы, интегральные микросхемы);

• теория алгоритмов (алгоритмы и структуры данных; сложность, эффективность; способы представления информации в памяти);

• языки программирования (задача и понятие ЯП, уровни, типы языков, абстракция, уровни абстракции, трансляция/компиляция, шаблоны, принципы, парадигмы — обзор).

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

Уровнем выше располагаются дисциплины, которые являются базовыми именно в программировании. По-этому я назвал этот уровень Основы. В него входят:

• архитектура ЭВМ (процессоры, микроархитектура, память, шины, ввод/вывод);

• обработка информации (теория информации, статистика, модели, поиск данных, лингвистические аспекты, обработка информации средствами табличных процессоров);

• основы C/C++ (базовые свойства языка, синтаксис, указатели, ввод/вывод, массивы, основы STL).

Следом за Основами идет Уровень 1. Это первый прикладной уровень, и особо нетерпеливые могут начать коммерческую практику, овладев этим уровнем. Он включает 5 дисциплин:

• основы ASM (развитие архитектуры ЭВМ в направлении программирования, написание простейших драйверов и алгоритмов, ассемблерные вставки в C/C++);

• C/C++ (ООП, разработка прикладных приложений, библиотеки, WinAPI, make utils, параллельное программирование).

• операционные системы (архитектура ОС, процессы, межпроцессное взаимодействие, потоки, планирование, работы с памятью и переферией, POSIX-системы);

• системный анализ (предметная область, бизнес-процессы, потоки, диаграммы, принципы и теория системного анализа);

• базы данных (теория множеств, виды СУБД, реляционные СУБД, модели данных, SQL, конкретные БД).

Следующий уровень — Уровень 2 — развивает предыдущий. Кстати, компьютерные сети попали в него только по той причине, что для их изучения желательно (но не обязательно) предварительно освоить операционные системы. По развитости этот предмет ближе все-таки к первому уровню.

Уровень 2 включает:

• разработку ПО (жизненный цикл ПО, этапы разработки, основы ведения программных проектов, инструменты);

• анализ данных (Data Mining, OLAP, машинное обучение, нейронные сети, ИИ);

• компьютерные сети (по уровням стеков TCP/IP и/или ISO/OSI “от и до”, протоколы, сетевое программирование на C/C++);

• языки программирования с управляемым кодом (управляемый код, виртуальные машины, сборщики мусора, юнит-тестирование, собственно практика на C# или Java);

Уровень 3 — последний уровень для среднего программиста. Он самый объемный и включает только те дисциплины, которые непосредственно связаны с разработкой ПО. Всего их получилось 6:

• разработка UI и юзабилити (принципы построения интерфейсов пользователя);

• управление командами и проектами (методологии разработки и другие вопросы управления);

• тестирование ПО (обзорно: виды тестирования, инструменты);

• веб-технологии (HTTP-протокол, веб-сервер, CGI, кэширование и проксирование, клиентское программирование);

• распределенные системы (архитектуры распределенных систем, протоколы сетевого взаимодействия компонентов, инструменты, принципы, подходы к построению распределенных систем, отказоустойчивость, большие данные, высокие нагрузки);

• интерпретируемые языки программирования (особенности, основы по двум-трем языкам, практика по одному-двум языкам: JS, PHP, Python, Ruby).

Все, что идет выше, — расширенные Экспертные знания. По большому счету этот уровень можно расширять неограниченно, добавляя в него смежные с разработкой дисциплины и наиболее сложные аспекты разработки ПО. Я привел 3 примера — разработка компиляторов, разработка операционных систем и построение архитектур больших программно-аппаратных систем, либо архитектур, рассчитанных на особо высокие нагрузки. Зависимости к нижним уровням на графе не рисовал, т.к. получится слишком много стрелок, идущих через все уровни, вплоть до Общей базы. Наверное, широкие зависимости — это один из признаков вопросов экспертного характера. Здесь как раз подтверждается то, что экспертный уровень требует самых широких знаний и хорошего опыта.

Интересно в графе то, что он не только показывает предпочтительный порядок изучения предметов, но также:

• дает возможность понять, какие дисциплины нужны больше, какие меньше для работы в определенной специализации (просто выбрать основной предмет специализации и смотреть по связям и удаленности до других);

• дает понимание, как изучать компьютерные науки, если начинать не с фундаментальных основ, а с прикладных знаний (например, PHP) — можно двигаться по связям в стороны и вниз — собственно именно таким был мой личный путь развития (и я никак не могу назвать его самым легким, эффективным и оптимальным).

Граф — это модель. А хорошая модель как правило дает ответы сразу на множество вопросов. Я поставил перед собой задачу сделать хороший граф, близкий к реальности. Естественно, он основан на моем личном опыте и не претендует на идеал. Я старался сделать его наиболее объективным. И еще раз напоминаю, что это граф для программиста. Т.е. для тестировщика, сисадмина и других близких к программированию профессий он будет более или менее близким, но явно другим.

А вот таблица по количеству поисковых запросан на Яндексе за месяц:

Выводы (кратко). Не забывайте, что статистика рабочих мест касается только Беларуси, а поиска — только рунета.

1. PHP все еще актуален и в лидерах. В то же врмемя, раз много ищут в яндексе, значит много новичков и чайников им интерисуются.
2. C# жжот.
3. HTML ищут много. Профессионалам по HTML искать почти нечего, вывод — студенты, новички все еще атакуют :)
4. Java-программеры давно поняли, что помощь надо просить у гугла. Тех, кто еще не понял, осталось мало :)
5. JavaScript солидно отстает по популярности от того же PHP.

Теперь выводы из поиска вакансий/резюме.

1. Ищут в основном Java-девелоперов. Причем, как спрос, так и предложение (относительно других языков) велики. Специалисты могут выбирать, имеют возможность менять работу в поиске лучших условий и з/п.
2. С#: спрос в 3 раза превышает предложение. Ищут много, большенство уже нашли себе теплые места и сидят там :) Ждем лета-осени, когда работу начнут искать выпущенные студенты… (тут сказали, что нихера не ждем, потому что распределение и все дела. Ну и ладно, значит не ждем :)
3. Delphi: мест мало, резюме много. Дельфи знают многие, это популярный язык у чайников. Но серьезные конторы не работают с этой средой.
4. C++: все хорошо, все на своих местах…
5. PHP-программистов не хватает. Всех хороших разобрали, плохие никому не нужны. Однако, и спрос, и предложение, меньше традиционных системных языков. Сайт-бум прошел.
6. Python и Ruby: есть мизерный спрос, предложение нулевое. Эти языки у нас не популярны. Больше как хобби расматриваются.
7. SQL жив. Правда программировать на нем довольно грустно и сложно (имеется в виду программирование бизнес-логики в хранимых процедурах), потому предложение в 3 раза меньше спроса. Но при этом, в большенстве вакансий ищут не SQL-разработчика, а c++, php, c#, а SQL только прилагается. Это объясняет второе место после Java. А вообще, банки атакуют :)
8. JavaScript и HTML получили 3-е и 4-е места только потому, что они вечно к чему то прилагаются. В основном к PHP и C#.

Короче говоря, лучше всех живется джаверам: огромный спрос, относительно спроса малое предложение :)

Рейтинг основан на количестве разработчиков на данных языках по всему миру, количеству различных курсов и производителей, использующих те или иные языки. Для рассчета рейтинга используются популярные западные поисковики Google, MSN, Yahoo!, и YouTube. По-этому, не стоит понимать данный рейтинг, как выбор лучшего языка программирования, или показателя количетсва написанных строк кода на предствеленных языках.

Итак, предствим 20-ку лучших. Позиции с 21 по 50 представлены на сайте-источнике.

Status обозначает принадлежность языка программирования к группе основных используемых (A) или второстевенных (B). A- означает сдвиг в сторону второстепенных.

Как видно, Java лидирует и за год набрал 2,6% пользователей. За ним идет Си, который не поменял позиции. А вдвоем они держат 35% рынка (если так можно выразиться).

Не совсем понятно поднятие на 2 позиции Visual Basic. Он обогнал PHP, который сумел удержаться. Зато 2 позиции сдал C++. Это падение как раз объеснимо: +1 позиция C# и +3 позиции Delphi немного потеснили C++. Эти 3 языка можно включить в одну группу взаимозаменяемости.

JavaScript, который сейчас, казалось бы, на пике популярности, сдал 3 позиции. Почему? Рискну предположить, что пользователи стали меньше искать по JS в поисковиках за счет появления фрейморков. Программировать на нем стало проще, он стал меньше обсуждаться.

6-ю и 7-ю позиции Perl’а и Python’а мне честно говоря вообще сложно объяснить. Казалось, что первый давно забыт, а второй используется довольно редко. Возможно Python удерживается и за счет того, что до сих под активно используется в Google.

Интересно так же то, что в 20-ку нагло ворвались Pascal и Lua (+5 позиций). Неужели на Pascal еще пишут софт?

Вообще, рейтинг довольно спорный, но интересный :)

Источник: http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

Если история развития ОПП в PHP вам неинтересна, можно сразу перейти к части «Проблемы в ООП PHP».

Эту статью удобнее читать в формате PDF (493 Кб). 

История развития PHP и ООП в PHP.

Когда-то давно, на заре развития Интернета вовсе не было ни PHP, ни «динамичных» веб-страниц. Сайты были похожи на простые книги, их суть заключалась в банальной передаче информации пользователю. Главным отличием сайтов той эпохи от книг был гипертекст. Возможность делать ссылки с одного документа на другой оказалась невероятно удобной и в то время потрясла мир.

Кстати. Для общего развития автор рекомендует прочитать статьи «Краткий экскурс в историю гипертекста» и «Секреты хорошего гипертекста».

Гипертекст определил сильный толчок в развитии Интернета, и буквально за несколько лет появилась необходимость в динамичных веб-страниц. Сайты начали развиваться в динамичном и интерактивном направлениях: появились поиски по каталогам, формы обратной связи, гостевые книги и т.д. Вместе с этим появилась необходимость в написании программ для сайтов.

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

Наиболее продвинутым и любимым языком среди системных администраторов Unix в то время был Perl. А так как подавляющее большинство серверов работало на Unix, его и стали широко использовать при программировании сайтов.

Многие программисты помнят нашумевший в свое время каталог cgi-bin на сайте. В него складывали все скрипты, и только на нем было разрешение на запуск (выполнение) программного кода (как скриптов, так и бинарников) в целях безопасности.

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

Таким образом, в 1994 году появился новый скриптовый язык программирования, созданный специально для генерации HTML-страниц на веб-сервере и работы с базами данных. Это был PHP. Во многом он был схож с Perl, синтаксис заимствовался из языка C++. Так как язык разрабатывался специально для веб и невероятно прост, он оказался очень удобным при программировании сайтов, и стал невероятно популярным. В конце 90-х – начале 00-х годов был бум развития PHP.

По сей день PHP – один из популярнейших скриптовых языков (наряду с JSP, Ruby и языками, используемыми в ASP.NET) благодаря своей простоте, скорости выполнения, богатой функциональности и распространению исходных кодов на основе лицензии PHP. Сейчас для него разработано огромное количество расширений, библиотек, написано большое количество книг и статей.

Кстати, PHP 3.0 был официально выпущен в июне 1998 года после 9 месяцев публичного тестирования. Это была первая открытая официальная версия PHP. Многие задаются вопросом, куда делись PHP 1 и PHP 2? А никуда. Их просто не было. Были версии PHP/FI и PHP/FI 2.0. PHP 3 был переписан с нуля, поэтому прямой связи с PHP/FI не имел. Однако нумерацию версий решили продолжить с 3-й.

Проблемы в ООП PHP.

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

Одним из самых очевидных промахов была передача объектов не по ссылке, а копированием. Запись $a = $b вела к созданию новой копии объекта, на который указывала $a. Эту ошибку исправили в PHP 5, но огромное количестве скриптов, написанных на PHP 4, содержат «костыли» для решения этой проблемы (повальное использование &).

В PHP 3 и PHP 4 не было возможности объявлять тип доступа к объектам класса. Это важный недостаток при разработке больших классов и больших систем. Это так же было исправлено в PHP 5, но не достаточно полно. Так как не был введен модификатор доступа при наследовании, остались большие проблемы с доступом к свойствам и методам класса.

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

Введение в PHP 5 интерфейсов так же не сыграло большой роли из-за отсутствия жесткой типизации в PHP.

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

Perl давно перестал конкурировать и значительно отстал от PHP. Писать сайты на Perl в наше время могут только фанаты, энтузиасты и студенты в вузах. Объективных поводов программировать сайты на Perl нет. Однако с начала 00-х годов появилась и активно развивается другая конкурирующая с PHP технология – Microsoft .NET. В настоящее время она составляет очень серьезную конкуренцию PHP и большое число компаний (в т.ч. и многие гиганты) отказались от PHP и перешли на ASP.NET.

Основным языком в ASP.NET стал C#. Этот язык, по мнению автора, – одна из лучших разработок Microsoft. C-подобный синтаксис по-прежнему является одним из самых гибких и удобных. Важным преимуществом перед C++ является организация автоматической сборки мусора и простота написания кода.

Одно из главных преимуществ PHP – отсутствие жесткой типизации – стало одним из главных его недостатков в борьбе с C#. Вторым серьезным недостатком стало ООП. В C# ООП развито на уровне C++. Для крупных проектов этот недостаток PHP крайне серьезен.

Частью технологии .NET является мощный и удобный фреймворк – .NET Framework. В споре с ныне существующими фрэймворками PHP (CakePHP, Symfony, Zend Framework) .NET Framework однозначно выигрывает.

Кстати. Одно из главных достоинств ASP.NET тоже сыграло против него самого. Программирование сайтов на ASP.NET сделано похожим на программирование программ для Windows. В случае простых сайтов это действительно очень удобно. Разработка страниц ведется значительно быстрее, чем на PHP. Но для крупных сайтов такой подход, напротив, создает ряд неудобств. Поэтому, PHP пока держит серьезные позиции и сдавать их не собирается.

Теперь вернемся к ООП в PHP. Так как текущая версия PHP 5, о ней и будем говорить.

Проблема 1. Одна из серьезных проблем ООП в PHP 5 уже была озвучена. Это отсутствие модификатора наследования. Об этом подробнее.

Допустим, создан класс, в котором часть методов объявлена как public. При создании нового класса, базовым для которого служит первый созданный класс, эти методы нужно скрыть. Это нужно, когда интерфейс класса-наследника «перекрывает» функционал открытых методов базового класса. Естественно, что при использовании базового класса отдельно возникает необходимость оставить эти методы открытыми, а при использовании его в качестве базового для нового класса, методы должны быть закрыты. В PHP этого механизма нет.

Проблема 2. Отсутствие возможности множественного наследования. Это свойственна не только PHP, но и C# (и некоторым другим языкам). Присутствует оно в C++. От множественного наследования отказались потому, что оно сложно и якобы «непонятно» для программиста. По мнению автора это глупо. Это все равно, что отказаться от полетов в космос, потому что это сложно.

В некоторых ситуациях возникает острая необходимость множественного наследования. Например, когда есть некий условный класс получения (getter) некого X и класс установки (setter) этого же самого X. На более высоком уровне может иметь смысл объединить их в один класс работы с X. Для этого надо написать класс, базовыми для которого будут сразу два класса – getter и setter. Но сделать этого технически мы не можем.

Проблема 3. Конструктор базового класса не вызывается по умолчанию из конструктора наследника. Но если конструктор наследника вовсе не определен, конструктор базового класса все же будет вызван. Это вносит некоторую путаницу и чревато ошибками.

Проблема 4. Следствием отсутствия строгой типизации является отсутствие возможности перегрузки функций. Да, в случае с обычными функциями или методами класса это легко обойти и серьезных затруднений не вызывает. Проблема возникает при необходимости перегрузки конструктора. Тогда приходится выкручиваться и делать «костыли». Это неприятно.

Проблема 5. В PHP 5 есть возможность указать тип аргумента функции (только для классов и массивов). Если переданный аргумент не будет соответствовать требуемому типу, возникнет ошибка и функция вызвана не будет. Это удобно: избавляет от необходимости повально писать лишние проверки.

Но разработчики забыли один важный нюанс, который проявляется серьезными неудобствами в некоторых случаях. Если указан тип объекта, нельзя передать в качестве объекта NULL. NULL – это по сути обозначение отсутствия объекта. В C++ NULL повально используется в местах передачи объекта в функции. В PHP программисты лишены такой возможности. В результате возник казус. Если написать function f(MyClass $class = null), то такая конструкция будет замечательно работать. Но вызов f(null) выдаст ошибку. В результате, при наследовании, когда из метода, где есть параметры-объекты со значением по умолчанию NULL, вызывается метод класса-родителя с теми же параметрами-объектами со значением по умолчанию NULL, программист вынужден писать костыли в виде блоковIF.По мнению автора, такая недоработка лишает метод указания типа параметра половины преимуществ.

Кстати, эта проблема возникла из-за отсутствия строгой типизации в PHP. Из плюса в начале развития PHP сейчас этот вопрос перерос в минус.

Проблема 6. Отсутствие нормального определения виртуальных свойств и методов класса (свойств, которые имеют геттеры и сеттеры).

Кстати. По сути, невиртуальные свойства – это вовсе не «свойства» класса, а «поля». Свойством же, как раз, называется поле, определенное не в виде переменной, но в виде геттера и/или сеттера. Это в языках с нормальной реализацией ООП. В PHP любое поле класса называется свойством. А виртуальные свойства входят в понятие перегрузки свойств.

Из-за неудобного способа перегрузки свойств и методов класса, интерпретатор не может точно определить, существует ли свойство или метод в классе, пока непосредственно его не вызовет. Как следствие – отсутствие виртуальных (перегруженных) свойств и методов в выпадающем списке членов класса в PHP-редакторах и IDE. Именно по это причине автор избегает перегрузки во всех случаях, когда это возможно. Использование методов перегрузки (__get, __set, __call) – отличный способ запутать программиста, использующего ваш класс.

Создание перегрузки свойств и методов в таком виде – это ужасный поступок со стороны разработчиков PHP. Ведь нельзя заставлять программиста помнить все методы и свойства класса наизусть. Это просто невозможно. Именно для этого во всех современных средах программирования (IDE) используются выпадающие списки членов класса. Использование методов перегрузки ломает механизм выпадающих списков.

Проблема 7. Открытость классов. Даже защищенные и приватные свойства класса в runtime легко просмотреть и подменить, используя сериализацию. Это открытый путь ко взлому скриптов.

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

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

Заключение.

ООП в PHP по-прежнему нуждается в серьезной переработке. И коррективы, которые будут внесены в PHP 6, не спасут ситуацию.

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

Автор уверен, что наследником PHP в недалеком будущем (2012-2015 года) станет язык со строгой типизацией. Возможно, это будет даже C#.

P.S. При перепечатке статьи обязательно указание этого абзаца в полном объеме и со ссылками. Автор статьи – Валерий Леонтьев aka feedbee. Источник – Персональный блог автора.