В мире PHP-программирования существует набор трендов. Некоторые люди активно продвигают их (в книгах и на сайтах) как «современный PHP», а другие подходы выставляют как устаревшие, глупые или просто неверные.
Похоже, все эти люди без устали стараются заставить каждого программировать так, как они считают нужным. Эта статья написана, чтобы поделиться прагматичным взглядом на PHP-программирование. Взглядом, продиктованным опытом и практическими последствиями, а не популярными тенденциями, теориями или академическими догмами. Материалы, представленные на сайте PHP — The Wrong Way, будут обновляться по мере появления новой информации. Приглашаем всех поучаствовать в этом.
Опасность экстремизма
С правилами и руководствами по программированию есть одна проблема: они часто имеют смысл только в конкретных условиях. Если выйти за рамки этих условий, то хорошее правило превращается в ужасное. По сути, любое хорошее правило, доведенное до крайности, становится плохим.
Важно понимать это, потому что экстремисты от программирования часто неверно использовали многие принципы и правила разработки ПО, которые появлялись время от времени и предлагались разными людьми.
Опыт подсказывает, что неверное использование основных руководств и правил всегда усложняет проекты, снижает их безопасность и приводит к ошибочным, а иногда и к катастрофическим результатам.
Принцип KISS, который некоторые расшифровывают как «Keep It Simple, Stupid», — чрезвычайно мудрый и правильный, опытные люди призывают следовать ему. Но даже KISS может стать угрозой для проекта, если довести его до абсурда. Есть такое понятие, как излишняя простота, что в нашем случае приводит к недостатку функциональности.
Неправильный путь: религиозное следование правилам и руководствам. 
Постоянное использование фреймворков
Все PHP-фреймворки общего назначения — отстой!
Расмус Лердорф
В PHP-сообществе по-настоящему плохая тенденция превратилась в де-факто стандарт при разработке веб-приложений. Речь идёт об использовании популярных фреймворков общего назначения.
Это явление широко распространилось. Причина тому — не улучшение результатов разработки и не правильность выполнения каких-то операций с точки зрения технологий и архитектуры. Просто некоторые авторы фреймворков увлекли за собой сообщество разработчиков с помощью полемики, направленной против создания приложений с нуля. Характерными лозунгами стали «Не изобретайте колесо!» и «Не надо всё делать самостоятельно, об этом уже позаботились более опытные».
Многие из современных программистов полностью игнорируют фундаментальные принципы нормального программирования и тратят кучу времени, фантазируя о новых слоях и уровнях сложности, чтобы стать умнее и круче тех, кого они считают своими сверстниками.
Этим людям настолько нравится увлекать других за собой, становиться своеобразными лидерами мнений в PHP-сообществе, убеждать всех использовать свежие и «модные» open source инструменты, что они забывают удостовериться в осмысленности и толковости своих советов. Фреймворк общего назначения можно сравнить с собранным на фабрике домом. Строительство приложения с помощью такого фреймворка сделает вас кодером или программистом в той же степени, как возведение заранее собранных домов превратит вас в плотника.
В этой статье мы различаем фреймворки и библиотеки по следующим признакам:
- Библиотека — это набор многократно используемого кода. Например, стандартные библиотеки С или Go. Код библиотеки можно легко и без ограничений внедрить в проект. Она состоит из маленьких фрагментов, у каждого из них есть конкретная функциональность.
- Фреймворк — это не просто набор многократно используемого кода: вы не сможете вырезать кусок из фреймворка и вставить его в проект. Эта система помогает создавать ПО, но в то же время накладывает на вас ограничения, присущие самому фреймворку. Кроме того, во фреймворке немало взаимозависимой функциональности: одна часть не сможет работать без других.
В мире Python и Ruby создание веб-сайтов с нуля — занятие довольно утомительное, поскольку эти языки для создания веб-сайтов не предназначались. В результате фреймворки общего назначения, такие как Django и Ruby on Rails, быстро стали популярны именно для сайтостроительства на Python и Ruby.
А PHP Расмус Лердорф изначально создавал как набор инструментов, написанных на С, позволяющих легко и быстро разрабатывать динамический HTML. PHP таким задумывался и таким остался, он сам и есть фреймворк.
Всё время своего существования PHP активно развивался, и сегодня он может использоваться для гораздо более разнообразных задач, нежели строительство HTML и веб-сайтов. Но неправильно относиться к PHP как к фреймворку. По своей природе он является уровнем абстракции для разработки веб-приложений, который целиком написан на процедурном С.
Использовать библиотеки в проектах совершенно естественно. В комплекте поставки PHP идёт набор библиотек, которые могут расширить ваш код. Например, PDO — маленькая библиотека, предоставляющая согласованный интерфейс для обращения к базам данных в PHP.
А вот использование фреймворка поверх PHP — совсем другое дело.
В этом случае вы добавляете уровень абстракции поверх другого уровня абстракции, который изначально создавался как базовая точка отсчёта. Добавочный уровень, обеспечиваемый фреймворком, может просто организовывать ваш код в заранее заготовленные наборы шаблонов. Или может увеличивать сложность с помощью переплетения сотен или тысяч классов и методов в адскую кашу зависимостей. Но в любом случае вы добавляете в код новый уровень сложности, который совершенно не нужен!
Обретение опыта начинается с интерфейса. Интерфейс — это результат базовых технологий и определённого количества уровней абстракции. Чем больше абстракции вы используете, тем менее эффективным становится интерфейс, тем больше ошибок вы закладываете в приложение. Чем выше абстракция, тем больше деталей и эффективности вы теряете.
Чётко уясните: строк кода в любом проекте должно быть как можно меньше, чтобы код стал как можно чище и читабельнее!
Людям не нужны фреймворки общего назначения. Ни у кого нет общих проблем, каждый пытается решать очень специфические проблемы.
Расмус Лердорф
Некоторые компании тоже проникаются суетой вокруг PHP-фреймворков и начинают использовать их в своих проектах, что в результате приводит к катастрофе. Компании сталкиваются с тем, что фреймворки общего назначения плохо помогают решать конкретные задачи, к тому же очень медленно работают. Фреймворки невозможно масштабировать, и многие компании пытаются выдрать из них куски в отчаянной надежде заставить работать то, что изначально не требовалось.
Всегда используйте прагматичный подход, при котором:
Действие или политика продиктованы рассмотрением прямых практических последствий, а не теорией или догмой.
Словарь английского языка Collins, полная версия, 12-е издание, 2014
Неправильный путь: всегда использовать фреймворк поверх PHP. 
Постоянное использование шаблонов проектирования
У меня сильная аллергия на оторванные от жизни проекты и шаблоны проектирования. Питер Норвиг написал хорошую статью о том, что шаблоны проектирования — это лишь недостатки вашего языка программирования. Перейдите на язык получше. И он абсолютно прав. Все поклоняются шаблонам и только и думают: «Ага, я воспользуюсь шаблоном Х».
Брендан Айх. Coders at work — Reflections on the Craft of Programming
Шаблоны проектирования — это многократно используемые решения часто возникающих проблем в архитектуре приложения. Шаблоны — это не законченный проект, который может быть напрямую преобразован в код. Это лишь описание, идея того, как решить проблему, для использования во многих разных ситуациях. Объектно ориентированные шаблоны обычно демонстрируют связи и взаимодействия между классами или объектами без определения финальных классов или объектов приложения.
PHP поддерживает императивные, объектно ориентированные, процедурные и рефлективные парадигмы. PHP — это огромный ящик с инструментами, позволяющий решать самые разные задачи самыми разными способами, а не только одним. PHP — это свобода, быстрые и масштабируемые решения.
Пытаясь улучшить себя и в особенности свой код, мы иногда зацикливаемся на философии конкретных шаблонов или идей, при этом забывая мыслить практично.
Когда я вижу в своей программе шаблоны, для меня это сигнал о неприятностях. Структура программы должна отражать только решаемую проблему. Любые другие закономерности в коде говорят (по крайней мере, мне) о том, что я использую недостаточно сильные абстракции. Например, что я вручную генерирую расширения макросов, которые нужно написать.
Пол Грэм
Нельзя попадать в ловушку философии или идеи, стоящей за конкретным шаблоном или решением. Наша главная задача — сделать код как можно более лёгким для понимания, а значит, безопасным и простым в сопровождении.
Также нельзя забывать о существовании антишаблонов. Эти шаблоны могут часто использоваться, но они неэффективны или даже контрпродуктивны.
Я думаю, изначально шаблоны были некими узнаваемыми лучшими решениями частых проблем. Но спустя некоторое время мы обнаружили, что приложения стали в десять раз сложнее, чем нужно, потому что люди пытаются запихнуть туда все шаблоны, о которых они читали («Моё приложение хорошо продумано, потому что по горло нагружено шаблонами»). Так что моё представление о ценности шаблонов изменилось.
Пол Уитон. Evil Design Patterns
Всегда используйте прагматичный подход, при котором:
Действие или политика продиктованы рассмотрением прямых практических последствий, а не теорией или догмой.
Словарь английского языка Collins, полная версия, 12-е издание, 2014
Неправильный путь: искать шаблон для решения проблемы. 
Постоянное использование объектно ориентированного программирования
Проблема ОО-языков в том, что они тащат за собой всё своё неявное окружение. Вы хотели банан, но при этом получили гориллу, которая держит банан, и все джунгли в придачу.
Джо Армстронг. Coders at work. Reflections on the Craft of Programming
Абстракция — это сила. А что меня действительно отвращает и о чём я говорил ещё в 1990-е, так это CORBA, COM, DCOM, объектно ориентированная чушь. В то время каждый стартап предлагал какую-нибудь безумную вещь, которая при запуске вызывала 200 тысяч методов и выводила «Hello world». Это же пародия! Вам, как программистам, не нужно ассоциировать себя с такими вещами.
Брендан Айх. Coders at work. Reflections on the Craft of Programming
Многие разработчики и компании сегодня считают, что ООП — единственный оправданный способ разработки. А те, кто с этим спорят, немедленно осознают, что идут против «общепринятого мнения» индустрии.
Блоги и форумы, посвящённые программированию, полны защитников ООП, уверенных в том, что они понимают, о чём говорят, хотя какого-либо стандартного определения не существует.
Но дело в том, что так называемое объектно ориентированное программирование очень часто бывает излишне сложным!
Мы, специалисты по информатике и программисты, должны оставлять предрассудки в стороне и искать лучшее решение для конкретной проблемы.
Сегодня одно из главных преимуществ PHP — поддержка императивной, функциональной, объектно ориентированной, процедурной и рефлективной парадигм. PHP — это огромный ящик с инструментами, позволяющий решать самые разные задачи самыми разными способами, а не только одним.
Когда мы пытаемся решать разные проблемы в рамках приложения с помощью одной конкретной парадигмы программирования, мы перестаём творчески мыслить и эффективно работать.
Маленький исторический урок
Один из лучших способов понять парадигму программирования — посмотреть, как она возникла. В чём причина? Из-за каких проблем в других парадигмах понадобился новый подход? Была ли проблема практическая или академическая? И сколько времени прошло с момента создания парадигмы?
Неважно, что говорит человек Х или какое определение даёт человек Y. Важны исторические предпосылки возникновения парадигм.
Есть два пути разработки архитектуры приложения. Первый — сделать её настолько простой, чтобы, очевидно, недостатков не было. Второй — сделать её настолько сложной, чтобы очевидных недостатков не было.
Чарльз Энтони Ричард Хоар
Раньше, ещё до пришествия ООП, примерно в конце 1950-х, для создания многих программ использовали языки с упором на неструктурированное программирование. Их иногда называют языками первого и второго поколений. Неструктурированное программирование исторически стало первой парадигмой. Её активно критиковали за спагетти-код.
Есть и высоко-, и низкоуровневые языки, использующие неструктурированное программирование. Например, BASIC, COBOL, MUMPS, JOSS, FOCAL, TELCOMP, машинный код, ранние системы ассемблера (без процедурных метаоператоров), ряд скриптовых языков. Программа на неструктурированном языке обычно состоит из последовательно расположенных команд или выражений, обычно по одной на строку. Строки либо нумеруются, либо могут содержать метки, позволяющие потоку выполнения переходить к любой из строк (вроде непопулярного выражения GOTO). В 1960-х появилось структурное программирование, во многом благодаря известному письму Эдсгера Дейкстра Go To statements considered harmful.
Структурное программирование — это парадигма, улучшающая чистоту, качество и процесс разработки с помощью подпрограмм, блочных структур и циклов. Это в противовес простому перепрыгиванию выражения GOTO.
Затем из структурированного программирования возникло процедурное. В его основе лежит концепция «вызова процедуры». Это ещё одно название для «вызова функции». Процедуры также известны вам как подпрограммы или методы. По сути, это серия вычислений, которые необходимо выполнить. Любая процедура может быть вызвана другими процедурами или самостоятельно в любое время в ходе исполнения программы.
Сначала все процедуры были доступны в любой части программы как глобальные данные. В маленьких программах это не проблема, но по мере усложнения и увеличения программ небольшие изменения в одной части начинали сильно влиять на многие другие части. Одно маленькое изменение процедуры могло привести к каскаду ошибок в куче других процедур, зависящих от неё.
Возникла новая методика, позволяющая разделять данные на разные области видимости: «объекты». К одним и тем же данным могли обратиться только конкретные процедуры, принадлежащие к той же области видимости. Это называется скрытием данных, или инкапсуляцией. В результате удалось гораздо лучше организовать коды.
Вначале объекты не назывались объектами, они просто рассматривались как отдельные области. Позднее, когда уменьшились зависимости и связи между переменными внутри этих областей, их стали рассматривать как изолированные сегменты, и в конце концов возникли концепции «объектов» и «объектно ориентированного программирования».
Затем, в основном из-за появления Java, появились новые модные термины, а «процедуру», или «функцию», переименовали в «метод», когда он принадлежит отдельной области видимости. Переменные переименовали в «атрибуты», когда они принадлежат отдельной области видимости.
Так что объект, по сути, — это просто набор функций и переменных, которые теперь называют методами и атрибутами.
Методы и атрибуты изолируются внутри отдельной области видимости с помощью «класса». А когда создаётся экземпляр класса, он называется объектом.
Объекты могут ссылаться друг на друга, и благодаря этому методы (функции) внутри них тоже «взаимодействуют» друг с другом. Также объекты могут «наследовать» методы от других объектов, тем самым расширяя их, это называется «наследование». Это способ многократного использования кода, позволяющий создавать независимые расширения приложений через публичные классы и интерфейсы. Взаимосвязи между объектами породили иерархию. Наследование было создано в 1967 году для языка Simula 67.
Объекты также могут наследовать методы от других объектов и «переопределять» их с помощью дополнительной или изменённой функциональности, это называется «полиморфизм».
В разных языках эти идеи реализованы очень по-разному.
Объектно ориентированное программирование — это иной способ организации кода. Это расширение процедурного программирования, связанное с сокрытием данных (инкапсуляцией) и избеганием глобальных областей видимости. Это расширение функций посредством «заимствования» их чертежей без влияния на оригинальный код (наследование). И это переопределение функций без влияния на оригинальный код (полиморфизм).
Модель ООП позволяет легко создавать программы путём аккреции (наращивания). На практике это зачастую означает, что это структурированный способ написания спагетти-кода.
Пол Грэм. Ansi Common Lisp
Неправильный путь: всегда использовать объектно ориентированное программирование. 
Бояться чужого кода
Один из частых аргументов, оправдывающих применение фреймворков, — нежелание людей иметь дело с кодовыми базами, сделанными из фрагментов кода, написанного другими.
Это довольно странное , в основном характерное для веб-разработчиков, говорит о недостатке профессионализма и опыта.
Совершенно нормально создавать приложение и работать с кодом, написанным другими. Это часть повседневной работы профессионального программиста, и не нужно её бояться.
Профессионал не будет ныть, что его работа теперь полностью зависит от кода сотрудника, который, вероятно, больше не имеет отношения к компании или проекту, а вот если бы этот сотрудник использовал фреймворк А или фреймворк Б, то это сэкономило бы вам день работы.
Профессионалы так не думают. Ни один.
Возможно, свою роль в распространённости такого играет низкий порог входа в веб-разработку на PHP. Но в любом случае это говорит о том, что человек идёт по неверному пути.
Программирование во многом подразумевает взаимодействие с людьми, использующими чужой код. Это часть работы: пытаться улучшить существующую кодовую базу, и иногда приходится её полностью переписывать. Почитайте, что говорят мастера программирования в книге Coders at work. Reflections on the Craft of Programming.
Некоторые из крупнейших и наиболее успешных кодовых баз в мире разработали сотни людей, которые никогда не встречались друг с другом. Эти базы созданы без использования фреймворков, исключительно на процедурных языках программирования с применением одной лишь процедурной парадигмы. И никто даже не мечтал сделать по-другому.
Ядро Linux содержит более 20 миллионов строк кода, написанных исключительно с помощью процедурного программирования. В его создании участвовали 14 тысяч человек — и никаких фреймворков. Разные возможности BSD и большая часть Linux GNU userland также написаны только с помощью процедурного программирования без применения фреймворков.
То же самое можно сказать о сотнях open source проектов по всему миру, заброшенных авторами только для того, чтобы их подхватили другие опытные программисты. По многим из этих проектов очень мало документации (или её вообще нет), нет комментариев в коде, нет руководств или иных видов помощи.
Да чего уж там — вся кодовая база PHP написана на С, процедурном языке, без фреймворков.
Когда вы определяете класс в PHP или когда вы запускаете свой любимый PHP-фреймворк, вы выполняете чью-то процедурную работу!
Конечно, бывает и ужасный код, который, вероятно, изначально никак не проектировался или который разросся во много раз, но клиент не захотел его переписывать. Кодовая база настолько ужасна, что вы не можете найти концов. Но ни один фреймворк не защитит вас от такой ситуации. Зачастую это стадия нормального роста программы. В конце концов, любой фреймворк просто порвётся на куски.
Безусловно, существует кошмарный спагетти-код, но никто не пишет его намеренно. Иногда это результат нехватки опыта, зачастую — вина клиентов, много раз меняющих спецификации посреди разработки. Но в обоих случаях вы бы всё равно получили спагетти-код, даже при использовании фреймворка. И неважно, насколько интенсивно вы станете применять объектно ориентированную парадигму: результат окажется тем же.
Как программисты, мы должны предотвращать такие ситуации, но это нормально, в этом заключается искусство программирования, это часть того, что называется быть программистом!
Неправильный путь: бояться кода, написанного другими. 
Следование стандартам PHP-FIG
FIG расшифровывается как Framework Interoperability Group (Группа по совместимости фреймворков).
PHP-FIG была создана разработчиками фреймворков на конференции php|tek в 2009 году. С тех пор её состав увеличился с 5 до 20 участников.
С PHP-FIG связано много споров. Одни считают это лучшим начинанием PHP-сообщества со времён возникновения самого PHP. Другие уверены, что стоит вообще поскорее забыть о существовании этой группы.
Одна из проблем заключается в том, как PHP-FIG позиционирует себя в своём FAQ:
Задача нашей группы — дать возможность участникам говорить об общности между нашими проектами и постараться найти пути совместной работы. Наша аудитория — это мы сами, но мы прекрасно понимаем, что на нас смотрит всё остальное PHP-сообщество. Мы будем рады, если другие захотят принять то, что мы делаем, но это не самоцель. Никто в нашей группе не указывает вам, как создавать приложения.
Однако если мы посмотрим на работу нескольких участников группы, становится очевидно, что реальная цель полностью противоречит заявленному. Группа всячески старается превратить PHP-FIG в «группу PHP-стандартов», что было их первоначальным названием. В книгах участников группы, на их сайтах, в блогах, на форумах и т. д. работу PHP-FIG именуют современным PHP, а все остальные подходы объявляют устаревшими.
Проблема PHP-FIG в том, что, хотя многие фреймворки и open source-проекты внедрили у себя ряд стандартов группы, сами эти стандарты в основном призваны решать проблемы «с точки зрения фреймворка», что делает их бесполезными во многих практических ситуациях.
Немало разработчиков создают ПО, которое должно быть крайне эффективным, безопасным, выгодным, чтобы его хотели купить и использовать. Их нельзя отвлекать стандартами, которые должны соответствовать потребностям фанатиков фреймворков. Это будет катастрофой для бизнеса.
Если и нужна какая-то группа, то её стандарты должны отражать интересы всего PHP-сообщества, а не одних лишь разработчиков фреймворков и open source CMS проектов. Такая группа должна представлять разработчиков самого языка PHP, с гораздо большим количеством участников, причём с правом голоса.
Если вы решили следовать стандартам PHP-FIG, то вы должны понимать, что некоторые из них — например, стандарты автозагрузчика PSR-0 и PSR-4 и ряд других — напрямую влияют на то, как вы пишете код ПО.
Во многих сферах требуется высокомасштабируемое, критичное ко времени выполнения, экономически выгодное ПО, которое просто невозможно создать, если следовать стандартам PHP-FIG.
Неправильный путь: следовать стандартам PHP-FIG, за исключением PSR-1 и PSR-2. 
Пренебрежение безопасностью
С программистами есть одна проблема: вы никогда не знаете, что делает программист, пока не становится слишком поздно.
Сеймур Крей. defprogramming.com
Безопасный код — это способ написания программ, устойчивых к атакам злоумышленников и забавляющихся, а также других программ. Безопасный код защищает данные от кражи или повреждения. Небезопасный код может предоставить атакующим контроль над сервером или идентификационными данными пользователей. Последствия — любые, вплоть до выхода сервиса из строя и взлома систем тысяч пользователей.
Каждая программа — потенциальная цель для атаки. Нападающие попытаются найти в ваших приложениях уязвимости и использовать их, чтобы похитить важную информацию, нарушить целостность программ и данных, получить контроль над серверами и сетями. На кону собственность ваших клиентов и ваша репутация.
Нельзя просто добавить безопасность в приложение!
Чтобы сделать небезопасное приложение безопасным, возможно, придётся существенно перепроектировать его. Вы должны определять происхождение угроз для вашего ПО и внедрять методики безопасного кода с самого начала, придерживаясь их в течение всего планирования и разработки приложения.
Безопасность критических программных ресурсов сегодня важна как никогда, поскольку основной вектор атак неуклонно перемещается на уровень приложения. По итогам исследования SANS 2009 года, атаки против веб-приложений составили более 60 % всех атак, зарегистрированных в интернете.
Особенность PHP в том, что и это язык программирования, и веб-фреймворк. В язык встроено много веб-функций, из-за которых очень легко написать небезопасный код.
Безопасность по умолчанию
Сложность убивает. Она высасывает жизнь из разработчиков, затрудняет планирование продуктов, их создание и тестирование, ставит перед нами вызовы в сфере безопасности и утомляет конечных пользователей и администраторов.
Рей Оззи
Чтобы разрабатывать приложения с внедрением правильных требований по безопасности, необходимо использовать методики написания безопасного кода и уделять внимание рискам в ежедневных операциях, своих мыслях и процессе возможных вторжений злоумышленников.
Неправильный путь: не разрабатывать приложение безопасным по умолчанию. 
FAQ
Всё вышеописанное легко понять неправильно — давайте кое-что проясним.
В чём цель вашего сайта и почему вы плывёте против течения?
Цель — начать дискуссию о современных методиках и крайних точках зрения.
Так вы говорите, что объектно ориентированное программирование это плохо или хорошо?
Нет, конечно, нет! Речь о том, чтобы вы понимали: не стоит решать все проблемы исключительно посредством ОО-парадигмы. Нельзя делить всё на чёрное и белое, это ошибка. В рамках одного приложения могут существовать самые разные проблемы, и иногда лучший выход — использовать разные парадигмы в зависимости от конкретной ситуации. А если вы решаете проблему с помощью неподходящего способа, то ни к чему хорошему это не приведёт.
Вы говорите, что фреймворки — зло?
Мы не осуждаем конкретно фреймворки. Мы осуждаем лишь их постоянное использование поверх PHP.
Если фреймворк помогает мне быстро начать и продолжить работать, что в этом плохого?
Если вы проанализируете ситуацию и долгосрочные последствия и поймёте, что «быстро начать и продолжить работать» — единственная проблема, которую вы когда-либо решали, то в этом нет ничего плохого. Но тогда мы говорим не о программировании или разработке ПО, а об использовании point-and-click решений.
Быстро начать и продолжить работать — это не создание приложения; это означает, что вы не анализировали проблему и не осознали долгосрочных последствий своего выбора.
Вы хотите сказать, что сторонние пакеты — это плохо?
Нет. Мы рекомендуем использовать сторонние библиотеки. Код, который вы можете легко и без ограничений внедрять в свои проекты. Это отличная возможность!
Кто вы?
Наш сайт посвящён идее борьбы с экстремизмом в PHP-сообществе, а не личному продвижению или обретению известности. Если мы раскроем имена — это лишь отвлечёт внимание от поднятых на сайте проблем. Давайте не будем отвлекаться.
Каков ваш опыт в разработке ПО?
Чтобы прийти к идеям, мыслям и решениям, отражённым на нашем сайте, не требуется большого опыта, если вы всегда делаете то, что говорят другие.
Рекомендуемая литература
- PHP: Неправильный путь — на Hacker News. Когда мы запустили наш сайт, на Hacker News появилось много комментариев, в которых отражено немало ценных аргументов.
- Как программировать без ООП. Свежая и альтернативная точка зрения: Брайан Уилл в трёх видео рассуждает о том, что не стоит начинать с ООП. В завершение он приводит несколько замечаний, как писать не ООП код.
- Кодеры за работой. Размышления о ремесле программирования. Интервью основаны почти на 80 часах бесед с 15 величайшими программистами и специалистами по информатике. Здесь вы найдёте многогранный рассказ о том, как они учились программировать, как они оттачивали своё мастерство и что они думают о будущем программирования.
- Черты квалифицированного программиста. Компетентность означает достаточное количество опыта и знаний для выполнения задачи. Квалифицированность — знание, почему вы делает что-то именно таким способом и как это укладывается в общую картину. Иными словами, квалифицированный практик всегда компетентный практик, но обратное необязательно верно.
- Руководства по безопасному программированию. Не зависящий от технологий документ с набором общих методик безопасного программирования в формате чек-листа, который можно внедрять в жизненный цикл разработки ПО. Используя эти методики, вы избежите большинства распространённых уязвимостей.
- Принципы безопасного проектирования. Безопасность веб-приложений — неотъемлемый компонент любого успешного проекта, будь то open source приложение, веб-сервис сквозной обработки или проприетарные бизнес-сайты. Хостеры совершенно справедливо остерегаются небезопасного кода, пользователи остерегаются небезопасных серверов. Задача этого руководства — помочь бизнесу, разработчикам, дизайнерам и архитекторам решений создавать безопасные веб-приложения. Если пользоваться им с самых ранних стадий, то стоимость создания безопасных приложений будет сравнима со стоимостью небезопасных, при этом в долгосрочной перспективе финансовая эффективность окажется несравнимо выше.
- Выживание на глубине: безопасность в PHP. Все жертвы успешных взломов быстро отмечают в пресс-релизах и на сайтах: безопасность для них крайне важна, и они относятся к ней со всей серьёзностью. Примите это близко к сердцу до того, как прочувствуете на практике.
- Улучшение существующей структуры кода с помощью рефакторинга . Рефакторинг позволяет улучшить имеющуюся структуру кода. Это изменение системы таким образом, чтобы внешнее поведение кода не менялось, но при этом внутренняя структура становилось более гармоничной. С помощью рефакторинга вы даже можете превратить плохую структуру в хорошую. В книге обсуждаются принципы рефакторинга, рассказывается, где его стоит применять в первую очередь и как настраивать нужные тесты. Также приведён каталог более чем из 40 проверенных рефакторингов с описанием, когда и зачем их применять, и пошаговые инструкции по внедрению. Заодно иллюстрируются схемы работы рефакторингов. Книга написана на примере Java, но её идеи применимы в любом другом ОО-языке.
- Практика программирования. Сборник практических вопросов, актуальных для программистов.
- Прагматичный программист. Здесь исследуются ключевые процессы программирования, от подмастерья до мастера: выработка требований, выполнение работ, правильное сопровождение кода. Рассматриваются самые разные вопросы, начиная с личной ответственности и развития карьеры и заканчивая методикой разработки архитектуры ради сохранения гибкости, простоты адаптации и многократного использования кода.
- Понимание языков программирования. Выбор языка программирования — один из важнейших факторов, влияющих на общее качество программной системы. К сожалению, слишком многим программистам не хватает лингвистических навыков: они влюбляются в свой «нативный» язык и не способны критически анализировать его ограничения. Книга «Понимание языков программирования» написана, чтобы объяснить:
- какие альтернативы доступны разработчикам,
- какие языковые конструкции лучше использовать для повышения безопасности и читабельности,
- как эти конструкции реализованы и как их можно эффективно компилировать,
- какова роль языка в выражении и усилении абстракций.
Автор: Mail.Ru Group
