10 принципов хорошего программного кода, который устроит всех


Оглавление (нажмите, чтобы открыть):

10 принципов хорошего программного кода, который устроит всех

Для большинства разработчиков работа над PHP приложениями сейчас и десять лет назад отличается кардинально. В те времена многие из нас были веб-дизайнерами в чью ответственность входила не только разработка бекэнда, но и проектирование БД, системное администрирование, фронтэнд программирование, а иногда и создание UI.

За последние года картина довольно сильно изменилась. Простые сайты теперь представляют из себя целые SaaS приложения — зачем создавать очередной движок для блога, встраивать CMS или ecommerce систему, когда уже десятки разных продуктов существуют. Другими словами, всё что можно было автоматизировать уже оптимизировано. Но остается один момент не поддающийся этому процессу — нужды заказчиков.

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

10 основополагающих моментов в современной разработки на PHP

Нас часто спрашивают, как лучше проектировать приложения под нашу инфраструктуру (fortrabbit.com). Конечно существуют тысячи подходов к этому вопросу, я приведу самые часто распространенные исходя из личного опыта.

Многие применяют фреймворки как Laravel5, CakePHP3, Symfony2 и т.д.. Они уже содержат в себе стили и шаблоны проектирования. Но остаются участки на усмотрение разработчика. Так внесем же свою лепту в этом вопросе.

1. Код

Самая важная часть вашего приложения.

Управление

Следует использовать системы контроля версий. Опередим все холивары о лучшей системе и скажем сразу — используйте GIT, так как он самый распространенный.

Стиль

Придерживайтесь одного стиля: один стиль проще читать вашим коллегам, соответственно новые сотрудники легко смогут освоить ваш код. Независимо от размера команды (даже если вы один), управление кодом может занимать очень много времени (соответственно и денег), а хорошо отформатированный и задокументированный код снижает эти затраты. В конце концов, такой код просто приятно читать.

Открытый исходный код

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

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

2. Тесты

Автоматическое тестирование всегда отставало в PHP по сравнению с другими языками программирования. Но, к счастью, ситуация изменилась в лучшую сторону. Мнение, что написание тестов удваивает затраченное время, практически искоренено, и добавление нового функционала стало немыслимо без соответствующего теста.

Хорошо покрытое тестами приложение даёт ряд преимуществ. Вот список моих трех любимых:

  • Рефакторинг такого ПО значительно проще
  • Юнит тестирование подталкивает вас использовать модульный стиль (увеличивает повторное использование кода)
  • Тесты предоставляют не только примеры кода, но и документацию к нему

Конечно список преимуществ на этом не заканчивается, но для меня идея такова: лучше код — меньше проблем.

3. Зависимости

Зависимостями однозначно должен управлять Composer. Так как код очень тесно связан с определенными библиотеками и их версиями, то заявленные зависимости (composer.lock) должен также находится в GIT.

Каталог с зависимостями ( vendor ) не должен быть в GIT, так как их версиями уже управляет другой файл, который уже в GIT. Поэтому два раза добавлять в репозиторий одно и то же смысла нет.

Модульность

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

4. Настройки

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

Разделение кода и настроек

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

Главное правило, которое помогает определить полностью ли отделен ваш код от настроек, это ответ на вопрос: “Сможете ли вы показать свой код, не показав значения настроек?”. Если вы ответили “Да”, то все отлично.

Плохо: где нибудь в config.inc.php :

Хорошо: переменные среды Apache, SetEnv и подобные:

Сложные настройки

Переменные среды могут содержать сложные данные (многоуровневые массивы). Их следует перевести в JSON, закодировать в base 64 и сохранить в БД. Таким образом вы сможете легко их читать и изменять вне приложения.

5. Статические ресурсы

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

Развернутый ответ: компиляция CSS и Javascript или создание изменённых изображений само по себе требует разных инструментов, которые в свою очередь тянут за собой новые зависимости (представьте себе компилятор node расширения, который ужимает изображения при помощи magick или Java приложение для компиляции CSS. ). Все это неоправданно усложняет процесс размещения приложения. А потом еще вспомним про распределение ответственности. Такими ресурсами, как правило, заведуют фронтэнд разработчики. У каждого из них свой набор инструментов, к которому они привыкли. А компиляции ресурсов при размещении приложения ограничит их в использовании своих любимых инструментов.

Более глубокие размышления на тему доступны в недавней статье Френка.

6. Данные во время работы программы

Под такими данными я подразумеваю файлы (не БД), которые генерируются во время работы с пользователем. Как правило их хранят на отдельном сетевом файловом хранилище.

Я бы порекомендовал облачные хранилища (S3, Cloud Files, Cloud Storage. ), так как они: берут на себя проблемы мастабируемости, (масштабируют приложение между несколькими серверами или странами), избавляют от возможных проблем с переносом приложения (синхронизация данных), балансируют нагрузку между выполнением (PHP скриптов) и отдачей (файлов).

7. Ресурсы

Ресурсы приложения — все службы, которое оно использует, а именно БД, кеширование, очереди, вышеупомянутые хранилища, почтовые службы и так далее.

Абстрагирование

Доступ к ресурсам должен быть абстрагированным. Степень абстракции зависит от ваших будущих планов (планируете ли вы масштабировать приложение, если да, то следует применить адаптер для локальных ресурсов, который потом можно будет заменить на сетевой адаптер). Абстрагировать систему кеширования легко, что не скажешь о замене MySQL на ElasticSearch, поэтому применение шаблона репозиторий, поможет разрешить эту проблему. Размещение ресурсов должно указываться в настройках приложения.

Код слишком тесно связан с определенным драйвером MySQL. Если вдруг драйвер перестанет быть доступным или вы не сможете использовать MySQL, то вам придется переписывать код.

Легко использовать разные БД, изменить местоположение БД сервера также просто.

Слабое связывание

Все службы, без которых приложение может работать должны легко отключаться. Допустим, почтовая служба используется для приветствия новых пользователей: вы должны иметь возможность отключить её при помощи одной команды, в случае если поставщик службы перестанет работать. А еще лучше автоматизировать такое отключение. Самый лучшый вариант — создать очередь запросов, которая будет пытаться заново соединиться с почтовой службой.

8. Размещение приложения


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

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

9. Ступень развития приложения

Конечно автоматическое тестирование — это фундамент хорошего приложения, но место для ошибки всегда остается. Тут и появляется понятие об этапах разработки приложения. Рабочее приложения на локальной машине (development) — первая этап разработки. Другая стадия разработки — рабочий режим приложения (production). А между ними большая пропасть, в которой есть место тестированию, рецензированию, да и много чему еще.

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

Количество этапов зависит от размера приложения, команды, типа приложения и так далее. В этой статье вы найдете более подробное описание этого процесса. Я рекомендую применять три этапа: локальный (development), продуктовый (production) и, конечно же этап тестирования (testing).

10. Масштабируемость

Наверняка вас уже не раз называли DevOp. Что означает: при разработке надо учитывать технические возможности оборудования, на котором будет работать приложения, чтобы не бороться с недостатками, а использовать преимущества.

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

Заключение

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

Что дальше?

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

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

5 принципов хорошего кода для начинающих программистов

Сайт proglib.io представил перевод статьи, в которой собраны основные принципы того, как писать хороший код. Надеемся, это поможет начинающим разработчикам избежать банальных ошибок.

Читабельный код лучше, чем умный код

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

Если посмотреть на имя первой функции и список ее аргументов, то:

1) сразу не понятно, что делает функция
2) нет ни малейшего намёка на то, что она делает.

Тогда как имя второй функции сразу же говорит нам о её предназначении.

Чем меньше кода, тем лучше

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

Если в вашем коде много строк, это еще не значит, что он хорош. Цель написания программы — решить какую-то задачу, а не написать как можно больше текста. Чем меньше кода вам приходится писать для решения конкретной задачи, тем лучше. А также обычно чем меньше кода, тем легче с ним работать.

Лень здесь может стать вашим другом.

Для написания хорошего кода вам нужно общение

Чаще всего люди не умеют читать мысли. Вам нужна помощь? Задайте вопросы коллегам. У вас есть крутая идея? Поделитесь ей с другими. Нашли ошибку в проекте? Обязательно о ней расскажите, даже она не очень серьёзная. Неисправленный вовремя баг позднее может привести к гораздо более серьёзным последствиям.

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

Электронная почта, мессенджеры, sms, телефонные звонки, Slack, Google Hangouts и так далее. Форма общения не имеет большого значения (хотя обсуждение отдельных вопросов лучше подходит для определенных типов связи), главное, чтобы члены команды не теряли связь.

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

Читайте код других людей

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

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

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

Мастер Йода рекомендует:  Как ограничить доступ к контенту незарегистрированным пользователям

Просите о помощи

Если вы застряли и нуждаетесь в помощи с конкретной проблемой в коде, спросите кого-нибудь! Google отлично справляется с общими задачами, но когда вы имеете дело с определённой проблемой, вам может понадобиться еще одна пара глаз или кто-то, с кем можно это обсудить. Вы будете удивлены, как часто это помогает.

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

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

Чистый Код. 6 признаков отличного программного кода или “к чему стремиться?”

Программные продукты не создаются равными, но есть 6 основных признаков, что программный код получился отличным!

На сегодняшний день ежеминутно программисты создают тысячи строк программного года, да что там говорить, только у Google в репозитории более 2х миллиардов строчек! Однако не всегда код одинаково качественен. Разработчики часто имеют свои предпочтения в вопросе “что отличает сырой код от хорошего”.
Чтобы разобраться, что же отличает хороший программный продукт от плохого “изнутри”, я пообщался с большим количеством разработчиков ПО с солидным стажем. Также я опирался на форумы, чтобы понять, что ожидают увидеть другие разработчики и с чем им приятнее работать.

Опираясь на вышеизложенные источники, я определил 6 характеристик “хорошего” программного кода.

1. Он легкочитаем.

Любой разработчик согласится, что один из наиболее важных показателей качества кода – это его читаемость. Код, который написан таким образом, что любой другой программист поймет, что там написано в кратчайший промежуток времени считается “высшим пилотажем”.

“Я считаю, что если я не могу понять намерений автора втечение 5 минут или даже меньше, то разработчик плохо старался,” заявил Luke Burnham, старший разработчик в Lionbridge. “Компьютеру абсолютно без разницы, какие имена у переменных и какие отступы, но людям не все равно. Код, написанный единожды, читается сотни и сотни раз в последующем на протяжении своей жизни. Использование внятных названий переменных и соблюдение необходимых отступов для улучшения читаемости кода делает код лучше.”

Анонимный старший разработчик с более, чем десятилетним опытом также поведал мне, что же есть “хороший код”, “Следование постоянному стилю написания кода (горизонтальные и вертикальные отступы, общий логический порядок)”. Также он сделал акцент на важности выбора “Названий переменных, имеющих смысл”.

“Чем быстрее коллега может увидеть код и понять его – тем быстрее приложение начнет развиваться (как функционально, так и экономически),” поведал комментатор Glennular на Stack Overflow. Его поддержал пользователь mojuba, заявив, “На самом деле нет четких рамок, с какой скоростью ты понимаешь код.”

2. Он хорошо документирован.

В дополнение к хорошему форматированию и именованию, комментарии также делают код более понятным. Но не просто любые комментарии, как пояснил Burnham: “Мне не нужны комментарии, поясняющие работу цикла For. Мне нужны комментарии, которые рассказывают ЗАЧЕМ код делает то, что делает. Я думаю, что хороший код имеет комментарии, поясняющие, что было в голове автора на момент написания.”

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

Kevin Moylan, старший разработчик в Genuine Interactive подвел черту: “Комментарии – это важно.”


3. Он прост.

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

Moylan рассказал мне посредством email, что “Каждая частица кода должна делать строго одну работу и, если она делает ее хорошо, то позволяет следующей частице кода делать ее следующую работу. Лучше решения – это наипростейшие решения.”

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

В конце большинство разработчиков сошлись во мнении, что сложность кода прямо пропорциональна количеству багов.

4. Он гибок.

Функциональность какой-то части кода часто подвергается изменениям, усовершенствованиям или повторному использованию в будущем. Поэтому Burnham посоветовал “Хороший программный продукт написан с учетом требований, предъявляемых сегодня, так и с учетом будущих улучшений.” Конечно, очевидно, что предсказывание будущего невозможно, он отметил, что “Я могу писать программу сегодня достаточно гибкую, чтобы в последующем адаптировать её к новым требованиям с минимальными изменениями.”

5. Его легко поддерживать.

Не важно, насколько хорошо написан код, неизбежно в нем могут оказаться ошибки. Moylan: “Очевидно, что кому-то придется исправлять их. Сделайте так, чтобы это было удобно, этим человеком можете оказаться вы сами.”

Поддерживаемость – это ключевой атрибут хорошего кода. “Весь код рано или поздно придется поддерживать, нет необходимости усложнять этот процесс.” резюмировал gbn на Stack Exchange.

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

“Что отличает просто работающий код от прекрасного кода – его пригодность к поддержке.” David Rachamim написал на Quora.

6. Он работает.

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

Burnham подытожил это простым утверждением: “Не важно, насколько код хорошо выглядит, если он не выполняет свои задачи – он плох.”

Для того, чтобы научиться этим и другим техникам написания хорошего программного кода, приглашаем на наши Курсы программирования в Минске.

Запишитесь прямо сейчас или закажите звонок с бесплатной консультацией!

Пять принципов хорошего кода для начинающих программистов

10.01.2020, 08:54 21 Просмотров

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

Читабельный код лучше, чем умный код

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

Если посмотреть на имя первой функции и список ее аргументов, то:

  1. Cразу не понятно, что делает функция;
  2. На самом деле нет даже намёка на то, что она делает.

Тогда как имя второй функции сразу же говорит нам о её предназначении.

И если этот пример был до смешного прост, то вы можете себе представить эти же проблемы в более крупных масштабах.

Чем меньше кода, тем лучше

Единственным исключением здесь может быть только тот факт, что этот пункт противоречит предыдущему.

Если в вашем коде много строчек, это далеко не означает, что это хороший код. Цель написания программы –- решить какую-то задачу, а не написать как можно больше текста. Чем меньше кода вам приходится писать для решения конкретной задачи, тем лучше. А также обычно чем меньше кода, тем легче с ним работать.

Лень здесь может стать вашим другом.

Для написания хорошего кода вам нужно общение

Чаще всего люди не умеют читать мысли. Вам нужна помощь? Задайте вопросы коллегам. У вас есть крутая идея? Поделитесь ей с другими. Нашли ошибку в проекте? Обязательно о ней расскажите, даже она не очень маленькая. Неисправленный вовремя баг позднее может привести к гораздо боллее серьёзным последствиям.

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

Электронная почта, мессенджеры, sms, телефонные звонки, Slack, Google Hangouts и так далее. Форма общения не имеет большого значения (хотя обсуждение отдельных вопросов лучше подходит для определенных типов связи), главное чтобы члены команды не теряли связь между собой.

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

Коммуникация в команде необходима, независимо от того, как команда сформирована.

Читайте код других людей

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

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

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

Просите о помощи

Если вы застряли и нуждаетесь в помощи с конкретной проблемой в коде, спросите кого-нибудь! Google отлично справляется с общими задачами, но когда вы имеете дело с определённой проблемой, вам может понадобиться еще одна пара глаз или кто-то, с кем можно это обсудить. Вы будете удивлены, как часто это помогает.

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

Мне понравилось, что об этом говорит Stephanie Hurlburt в своём Twitter’е :

For people who are in a position to give help: Post to your timeline every now & then that you’re open to questions. That makes a difference

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

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

10 принципов объектно-ориентированного программирования, о которых должен знать каждый разработчик

Мне довольно часто встречаются разработчики, которые не слышали о принципах SOLID (мы подробно рассказывали о них здесь . — Пер.) или объектно-ориентированного программирования (ООП), или слышали, но не используют их на практике. В этой статье описываются преимущества принципов ООП, которые помогают разработчику в его ежедневном труде. Некоторые из них хорошо известны, другие — не очень, так что статья будет полезна и новичкам, и уже опытным программистам.

Напоминаем: для всех читателей «»Хабра» — скидка 10 000 рублей при записи на любой курс Skillbox по промокоду «Хабр».


Skillbox рекомендует: Образовательный онлайн-курс «Java-разработчик» .

DRY (Don’t Repeat Yourself)

Довольно простой принцип, суть которого ясна из названия: «Не повторяйся». Для программиста это означает необходимость ухода от дублирующего кода, а также возможность использовать в работе абстракцию.

Если в коде есть два повторяющихся участка, их стоит объединить в один метод. Если жестко заданное значение используется больше одного раза, стоит преобразовать его в общедоступную константу.

Это нужно для того, чтобы упростить код и сделать его поддержку проще, что является основной задачей ООП. Злоупотреблять объединением тоже не стоит, поскольку один и тот же код не пройдет проверку как с OrderId, так и с SSN.

Инкапсуляция изменений

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

Принцип открытости/закрытости

Этот принцип можно легко запомнить, прочитав следующее утверждение: «Программные сущности (классы, модули, функции и т.п.) должны быть открыты для расширения, но закрыты для изменения». На практике это означает, что они могут позволять менять свое поведение без изменения исходного кода.

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

Вот пример кода, который нарушает этот принцип.

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

Кстати, открытость-закрытость — один из принципов SOLID.

Принцип единственной ответственности (SRP)

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

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

Принцип инверсии зависимостей (DIP)

Выше приведен пример кода, где AppManager зависит от EventLogWriter, который, в свою очередь, тесно связан с AppManager. Если нужен иной способ показать уведомление, будь это пуш, SMS или email, нужно изменить класс AppManager.

Проблема может быть решена при помощи DIP. Так, вместо AppManager мы запрашиваем EventLogWriter, который будет введен при помощи фреймворка.

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

Композиция вместо наследования

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

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

Даже “Effective Java” Джошуа Блох (Joshua Bloch) советует отдавать предпочтение композиции, а не наследованию.

Принцип подстановки Барбары Лисков (LSP)

Еще один принцип из инструментария SOLID. Он гласит, что подтипы должны быть заменяемыми для супертипа. То есть методы и функции, которые работают с суперклассом, должны иметь возможность без проблем работать и с его подклассами.

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

Вот участок кода, который противоречит LSP.

Метод area(Rectangle r) просчитывает площадь Rectangle. Программа упадет после выполнения Square, поскольку Square здесь не является Rectangle. Согласно принципу LSP, функции, которые используют ссылки на базовые классы, должны иметь возможность использовать и объекты производных классов без дополнительных инструкций.

Этот принцип, который является специфичным определением подтипа, был предложен Барбарой Лисков в 1987 году на конференции в основном докладе под названием «Абстракция данных и иерархия» — отсюда и его название.

Принцип разделения интерфейса (ISP)

Очередной принцип SOLID. Согласно ему интерфейс, который не используется, не должен быть реализован. Следование этому принципу помогает системе оставаться гибкой и пригодной для рефакторинга при внесении изменений в логику работы.

Чаще всего эта ситуация происходит, когда интерфейс содержит сразу несколько функциональностей, причем клиенту нужна лишь одна из них.

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

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

Программирование для интерфейса, а не реализации

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

Мастер Йода рекомендует:  ASCII – путеводитель для новичков

Следует использовать тип интерфейса для переменных, возвращаемых типов или же типа аргумента метода. Пример — использование SuperClass, а не SubClass.

List numbers= getNumbers();

ArrayList numbers = getNumbers();

Вот практическая реализация того, о чем говорится выше.

Принцип делегирования

Распространенный пример — методы equals() и hashCode() в Java. Когда требуется сравнить два объекта, то это действие делегируется соответствующему классу вместо клиентского.

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

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

stokito on software

Спустя многие годы я обнаружил что следующие относительно немногие фундаментальные принципы помогли мне стать более эффективным программистом.

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

DRY (Don’t repeat yourself) Не делайте одну и ту же работу дважды

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

Принцип абстракции (Abstraction Principle)


Относящийся к DRY принцип абстракции: «Каждый значительный кусок функциональности в программе должны быть реализован в одном месте исходного кода».

KISS (Keep it simple, stupid!) Не усложняй, тупица

Упрощение (и избежание сложности) всегда должно быть ключевой целью. Простой код занимает меньше времени чтобы его написать, имеет меньше ошибок, и его легче изменить.

YAGNI (You aren’t going to need it) Вам это не понадобится

Вам стоит пытаться не добавлять функциональности пока она вам не нужна. Только потратите время на разработку, отладку, поддержку и будет постоянно мешаться.

Делай сразу простейшую вещь, которая скорее всего заработает (Do the simplest thing that could possibly work)

Когда программируете сразу задайте себе вопрос: «Что является простейшей вещью, которая могла бы вот сразу заработать?». Это помогает удерживать нас на пути к простоте дизайна.

Не заставляйте меня напрягаться и думать (Don’t make me think)

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

Принцип Открытости/закрытости (Open/Closed Principle)

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

Пишите код для сопровождающего (Write Code for the Maintainer)

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

Программируй так, как если бы человек, который будет поддерживать твой код, будет брутальным психопатом и будет знать, где ты живёшь. © Martin Golding

Принцип наименьшего удивления (Principle of least astonishment) POLA

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

Принцип единственной ответственности (Single Responsibility Principle)

Компонент кода (т.е. класс или функция) должен выполнять единственную хорошо определённую задачу.

Слабая связанность (Minimize Coupling)

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

Максимальное сцепление (Maximize Cohesion)

Код который имеет похожую функциональность должен находится в том же компоненте.

Скрытие деталей реализации (Hide Implementation Details)

Скрытие деталей реализации позволяет изменять реализацию код компонента с минимальными затрагиваением любых других модулей которые используют этот компонент.

Закон Деметры (Law of Demeter)

Компоненты кода должны взаимодействовать только с их непосредственными отношениями (например, классы от которых они унаследованы, объекты которые они содержат, объекты переданные с помощью аргументов и т.д.)

Избегайте преждевременной оптимизации (Avoid Premature Optimization)

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

Мы должны забыть про небольшие улучшения эффективности, скажем на протяжении 97% времени: преждевременная оптимизация — это корень всех бед. © Дональд Кнут

От переводчика:

Преждевременная оптимизация хуже преждевременной эякуляции. © namezys

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

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

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

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

Повторное использование это хорошо (Code Reuse is Good)

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

Разделение ответственности (Separation of Concerns, SoC)

Различные области функциональности должны управляться различными и минимально перекрывающимися модулями кода.

Обними изменения (Embrace Change)

Это заголовок книги Кента Бека, в которой рассматривается принципы экстремального программирования (XP) и методологии гибкой разработки (Agile) в целом. Многие другие принципы основаны на концепции, что вы должны ожидать и приветствовать изменения. На самом деле очень старые принципы разработки, вроде минимизации связанности, непосредственно предназначаются для более лёгкого изменения кода. Даже если вы не приверженец экстремального программирования этот подход к написанию кода не теряет смысла.

От переводчика: и ещё один очень важный принцип не упомянутый автором

В объектно-ориентированом дизайне обязателен SOLID: аббревиатура из первых букв названий приниципов, часть которых уже описана в этой статье:

UPD
Посмотрите ещё на отличные мотиваторы с этими приницпами для программистов.

10 принципов для избавления от иерархии

Это перевод статьи из блога corporate-rebels.com, посвященного прогрессивным организациям, трансформации компаний, который собрал вокруг себя целое сообщество единомышленников — людей, меняющих организации к лучшему. Блог известен в более чем 100 странах, входит в список «Top 30 Emergent Management Thinkers» и номинируется на премию «Thinkers50 Breakthrough Idea Award».

Об авторе статьи
Лиза Гилл — тренер и коуч в компании Tuff Leadership Training, которая проводит обучение эффективных менеджеров, с их помощью трансформирует процессы и целые организации. Основатель Reimaginaire.

Недавно я летала в Лиссабон, чтобы принять участие в двухдневном разговоре и воркшопе Pablo Aretxabala и Jabi Salcedo из компании K2K Emoncionado. K2K успешно трансформировали 70 организаций (многие из которых — индустриальные компании) Страны Басков (Испания) из традиционных иерархий в процветающие, самоуправляемые организации. То, что они успешно трансформировали и улучшили показатели (прибыльность, продуктивность, прогулы, зарплаты) в таком большом количестве компаний с такой воспроизводимостью привлекло мой интерес. Итак, как они это делают?

Люди, которые верят в людей

В ядре их подхода концепция их бывшего CEO «nuevo estilo de relaciones» т.е. «новые стили отношений». K2K поддерживает компании — обычно в течение трех лет — в радикальном изменении их организационной структуры, избавлении от менеджеров, контроля и привилегий, во внедрении прозрачности, общей ответственности и разделения прибыли. Прежде чем они начинают процесс, сотрудники должны выбрать его. Jabi говорит: «Ничего не делайте, прежде чем спросить и вовлечь людей…» (можете больше прочитать про это в прошлом посте Corporate Rebels).

В методе трансформации K2K — 10 основополагающих компонентов. Однажды к ним обратилось государство: «Вы преобразовали около 70 организации в Стране Басков, а у нас их двадцать две тысячи. Можете ли вы сделать больше? Может быть, если исключить часть самых радикальных шагов, заинтересуется больше компаний?». Команда ушла подумать и несколько дней проводила встречи, чтобы исследовать такую возможность. В конце концов они решили, что каждый из этих 10 компонентов важен — если убрать хотя бы один результаты не получить. Итак, вот они:


1. Абсолютная прозрачность

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

2. Нет иерархии

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

Генеральный директор становится Генеральным Координатором и больше не обладает властью принимать решения за кого бы то ни было. Вместо этого он посвящает время заботе о людях и упрощению их работы. Jabi пошутил, что одна компания, с которой они работали, имела 70 сотрудников и девять уровней иерархии и еще больше уровней зарплаты — и они удивлялись, почему люди не работали как команда!

3. Самоуправляемые команды

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

Команды также проводят Встречи по Обязательствам каждые две-три недели, чтобы обсудить командные обязательства («коммитменты») и цели. Каждая команда выбирает «лидера» как представителя, однако у него нет власти или дополнительной зарплаты. Этот человек служит не более одного или двух лет, так как после этого, по словам Jabi, «люди начинают становиться боссами». Команды могут разделить эту роль между двумя или большим количеством людей и заменить лидера в любой момент.

4. Никаких привилегий

С первого дня все привилегии устраняются: кабинеты, столовые для руководителей, отдельные парковочные места, любые бонусы или индивидуальные KPI, особый доступ к информации.

5. Справедливый баланс зарплаты

Когда K2K представляет новую организационную структуру команде, они также презентуют новые уровни зарплаты. Прекращается оплата сверхурочных, самые низкие зарплаты поднимаются для минимизации разрыва в оплате. Ничьи зарплаты не уменьшаются (например, бывших средних менеджеров), однако есть одно правило: наиболее высокооплачиваемые 10% не должны зарабатывать более чем в 2,3 раза по сравнению с 10% наименее оплачиваемых сотрудников. Иногда это приводило к соглашению, что генеральный директор уменьшит свою зарплату.

6. Никакого контроля

На заводах исчезает система учета рабочего времени, входа и выхода. «Мы движимы целями и обязательствами, не часами», объясняет Pablo. Команда ответственна за разрешение любых случаев неподобающего поведения, если такие случаются. Особенно важно, что людям разрешается делать ошибки. В первые шесть месяцев это почти всегда полный хаос и фрустрация. Но какой молодой менеджер не делал ошибок? Ошибки — основа обучения, за них не нужно наказывать или демотивировать. Как Pablo говорит: «Иногда вы достигаете успеха, иногда вы учитесь».

7. Измерение и отслеживание всего

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

8. Общее принятие решений

Для начала K2K помогает фасилитировать дискуссии по принятию решений, так как принимать решения без начальника очень в новинку для команд. Чтобы оценить решение, K2K предлагает задавать четыре вопроса:

Будет ли лучше чем раньше (думайте долгосрочно)?

Можем ли мы объяснить это всем? (это прозрачно или нет?)

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

Если мы поставим себя на место тех, на кого повлияет решение, примем то же решение?

Большинство решений могут быть приняты в командах, однако решения, которые касаются большего количества людей, принимаются на Общих Собраниях.

9. Никаких увольнений

Удивительно, но K2K никогда никого не уволила в процессе трансформации. Средние менеджеры должны найти новые роли. Это помогает компенсировать увеличение многих зарплат, потому что, как объяснил Jabi, 15% рабочей силы, которые раньше контролировали других, теперь занимаются повышением эффективности. Также большой процент рабочих, которых раньше контролировали, теперь более эффективен, так как у них появилась возможность сконцентрироваться на важном!

10. Разделение прибыли

В любой трансформации K2K это необсуждаемое правило: 30% прибыли должны быть разделены со всеми сотрудниками. «Без этого всё остальное просто дым», сказал нам Pablo.

Итак, с чего начать?

Если вы воодушевлены, и вам не терпится начать собственную трансформацию в стиле K2K, вот несколько предложений Pablo, с которых можно начать:

  1. Что вы чувствуете? — много раз Pablo говорил нам, что результаты и «как» менее важны, чем то, как вы чувствуете. На самом деле, девиз K2K: «Чувствуй, думай, делай». Прочитав этот материал, как вы себя ощущаете? Вдохновленным? Испуганным? Скептичным? Мотивированным? Получившим вызов? Осознайте это.
  2. Наберите информацию — просветите себя о новых стилях отношений в организациях: читайте, смотрите видео, посетите прогрессивные компании, обсуждайте, сравнивайте с собственной ситуацией.
  3. Действительно, действительно захотите — такого рода трансформация требует упорства и твердой решимости и никогда не сработает, если вы действительно не хотите её. Если вы делаете это ради результатов или потому что это последний тренд, вы можете навредить другим и себе.
  4. Поделитесь и решите — поделитесь своим видением с другими и решите меняться, включив всех, кто будет частью трансформации. Pablo говорит, что важно сделать это решение формальным. Сила деклараций («А теперь я объявляю вас мужем и женой») и ритуалов глубоко влияет на нашу приверженность и личную трансформацию.
  5. Наслаждайтесь дорогой, потому что тут нет финишной прямой — не существует конечной точки трансформации. Jabi говорит, что нет ни одной компании, которая на 100% работает так, как им бы хотелось для своего портфолио, также как нет ни одной традиционной компании в мире, которая работает на 100% так, как нам бы хотелось. Начать этот процесс означает отправиться в пожизненное путешествие за знаниями.

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

Что дальше для K2K?

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

10 принципов хорошего программного кода, который устроит всех

Для большинства разработчиков работа над PHP приложениями сейчас и десять лет назад отличается кардинально. В те времена многие из нас были веб-дизайнерами в чью ответственность входила не только разработка бекэнда, но и проектирование БД, системное администрирование, фронтэнд программирование, а иногда и создание UI.

Мастер Йода рекомендует:  Краткое руководство по единицам измерения в CSS

За последние года картина довольно сильно изменилась. Простые сайты теперь представляют из себя целые SaaS приложения — зачем создавать очередной движок для блога, встраивать CMS или ecommerce систему, когда уже десятки разных продуктов существуют. Другими словами, всё что можно было автоматизировать уже оптимизировано. Но остается один момент не поддающийся этому процессу — нужды заказчиков.

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

10 основополагающих моментов в современной разработки на PHP

Нас часто спрашивают, как лучше проектировать приложения под нашу инфраструктуру (fortrabbit.com). Конечно существуют тысячи подходов к этому вопросу, я приведу самые часто распространенные исходя из личного опыта.

Многие применяют фреймворки как Laravel5, CakePHP3, Symfony2 и т.д.. Они уже содержат в себе стили и шаблоны проектирования. Но остаются участки на усмотрение разработчика. Так внесем же свою лепту в этом вопросе.

1. Код

Самая важная часть вашего приложения.

Управление

Следует использовать системы контроля версий. Опередим все холивары о лучшей системе и скажем сразу — используйте GIT, так как он самый распространенный.

Стиль

Придерживайтесь одного стиля: один стиль проще читать вашим коллегам, соответственно новые сотрудники легко смогут освоить ваш код. Независимо от размера команды (даже если вы один), управление кодом может занимать очень много времени (соответственно и денег), а хорошо отформатированный и задокументированный код снижает эти затраты. В конце концов, такой код просто приятно читать.

Открытый исходный код

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

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

2. Тесты


Автоматическое тестирование всегда отставало в PHP по сравнению с другими языками программирования. Но, к счастью, ситуация изменилась в лучшую сторону. Мнение, что написание тестов удваивает затраченное время, практически искоренено, и добавление нового функционала стало немыслимо без соответствующего теста.

Хорошо покрытое тестами приложение даёт ряд преимуществ. Вот список моих трех любимых:

  • Рефакторинг такого ПО значительно проще
  • Юнит тестирование подталкивает вас использовать модульный стиль (увеличивает повторное использование кода)
  • Тесты предоставляют не только примеры кода, но и документацию к нему

Конечно список преимуществ на этом не заканчивается, но для меня идея такова: лучше код — меньше проблем.

3. Зависимости

Зависимостями однозначно должен управлять Composer. Так как код очень тесно связан с определенными библиотеками и их версиями, то заявленные зависимости (composer.lock) должен также находится в GIT.

Каталог с зависимостями ( vendor ) не должен быть в GIT, так как их версиями уже управляет другой файл, который уже в GIT. Поэтому два раза добавлять в репозиторий одно и то же смысла нет.

Модульность

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

4. Настройки

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

Разделение кода и настроек

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

Главное правило, которое помогает определить полностью ли отделен ваш код от настроек, это ответ на вопрос: “Сможете ли вы показать свой код, не показав значения настроек?”. Если вы ответили “Да”, то все отлично.

Плохо: где нибудь в config.inc.php :

Хорошо: переменные среды Apache, SetEnv и подобные:

Сложные настройки

Переменные среды могут содержать сложные данные (многоуровневые массивы). Их следует перевести в JSON, закодировать в base 64 и сохранить в БД. Таким образом вы сможете легко их читать и изменять вне приложения.

5. Статические ресурсы

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

Развернутый ответ: компиляция CSS и Javascript или создание изменённых изображений само по себе требует разных инструментов, которые в свою очередь тянут за собой новые зависимости (представьте себе компилятор node расширения, который ужимает изображения при помощи magick или Java приложение для компиляции CSS. ). Все это неоправданно усложняет процесс размещения приложения. А потом еще вспомним про распределение ответственности. Такими ресурсами, как правило, заведуют фронтэнд разработчики. У каждого из них свой набор инструментов, к которому они привыкли. А компиляции ресурсов при размещении приложения ограничит их в использовании своих любимых инструментов.

Более глубокие размышления на тему доступны в недавней статье Френка.

6. Данные во время работы программы

Под такими данными я подразумеваю файлы (не БД), которые генерируются во время работы с пользователем. Как правило их хранят на отдельном сетевом файловом хранилище.

Я бы порекомендовал облачные хранилища (S3, Cloud Files, Cloud Storage. ), так как они: берут на себя проблемы мастабируемости, (масштабируют приложение между несколькими серверами или странами), избавляют от возможных проблем с переносом приложения (синхронизация данных), балансируют нагрузку между выполнением (PHP скриптов) и отдачей (файлов).

7. Ресурсы

Ресурсы приложения — все службы, которое оно использует, а именно БД, кеширование, очереди, вышеупомянутые хранилища, почтовые службы и так далее.

Абстрагирование

Доступ к ресурсам должен быть абстрагированным. Степень абстракции зависит от ваших будущих планов (планируете ли вы масштабировать приложение, если да, то следует применить адаптер для локальных ресурсов, который потом можно будет заменить на сетевой адаптер). Абстрагировать систему кеширования легко, что не скажешь о замене MySQL на ElasticSearch, поэтому применение шаблона репозиторий, поможет разрешить эту проблему. Размещение ресурсов должно указываться в настройках приложения.

Код слишком тесно связан с определенным драйвером MySQL. Если вдруг драйвер перестанет быть доступным или вы не сможете использовать MySQL, то вам придется переписывать код.

Легко использовать разные БД, изменить местоположение БД сервера также просто.

Слабое связывание

Все службы, без которых приложение может работать должны легко отключаться. Допустим, почтовая служба используется для приветствия новых пользователей: вы должны иметь возможность отключить её при помощи одной команды, в случае если поставщик службы перестанет работать. А еще лучше автоматизировать такое отключение. Самый лучшый вариант — создать очередь запросов, которая будет пытаться заново соединиться с почтовой службой.

8. Размещение приложения

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

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

9. Ступень развития приложения

Конечно автоматическое тестирование — это фундамент хорошего приложения, но место для ошибки всегда остается. Тут и появляется понятие об этапах разработки приложения. Рабочее приложения на локальной машине (development) — первая этап разработки. Другая стадия разработки — рабочий режим приложения (production). А между ними большая пропасть, в которой есть место тестированию, рецензированию, да и много чему еще.

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

Количество этапов зависит от размера приложения, команды, типа приложения и так далее. В этой статье вы найдете более подробное описание этого процесса. Я рекомендую применять три этапа: локальный (development), продуктовый (production) и, конечно же этап тестирования (testing).

10. Масштабируемость

Наверняка вас уже не раз называли DevOp. Что означает: при разработке надо учитывать технические возможности оборудования, на котором будет работать приложения, чтобы не бороться с недостатками, а использовать преимущества.

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

Заключение

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

Что дальше?

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

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

stokito on software

Спустя многие годы я обнаружил что следующие относительно немногие фундаментальные принципы помогли мне стать более эффективным программистом.


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

DRY (Don’t repeat yourself) Не делайте одну и ту же работу дважды

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

Принцип абстракции (Abstraction Principle)

Относящийся к DRY принцип абстракции: «Каждый значительный кусок функциональности в программе должны быть реализован в одном месте исходного кода».

KISS (Keep it simple, stupid!) Не усложняй, тупица

Упрощение (и избежание сложности) всегда должно быть ключевой целью. Простой код занимает меньше времени чтобы его написать, имеет меньше ошибок, и его легче изменить.

YAGNI (You aren’t going to need it) Вам это не понадобится

Вам стоит пытаться не добавлять функциональности пока она вам не нужна. Только потратите время на разработку, отладку, поддержку и будет постоянно мешаться.

Делай сразу простейшую вещь, которая скорее всего заработает (Do the simplest thing that could possibly work)

Когда программируете сразу задайте себе вопрос: «Что является простейшей вещью, которая могла бы вот сразу заработать?». Это помогает удерживать нас на пути к простоте дизайна.

Не заставляйте меня напрягаться и думать (Don’t make me think)

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

Принцип Открытости/закрытости (Open/Closed Principle)

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

Пишите код для сопровождающего (Write Code for the Maintainer)

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

Программируй так, как если бы человек, который будет поддерживать твой код, будет брутальным психопатом и будет знать, где ты живёшь. © Martin Golding

Принцип наименьшего удивления (Principle of least astonishment) POLA

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

Принцип единственной ответственности (Single Responsibility Principle)

Компонент кода (т.е. класс или функция) должен выполнять единственную хорошо определённую задачу.

Слабая связанность (Minimize Coupling)

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

Максимальное сцепление (Maximize Cohesion)

Код который имеет похожую функциональность должен находится в том же компоненте.

Скрытие деталей реализации (Hide Implementation Details)

Скрытие деталей реализации позволяет изменять реализацию код компонента с минимальными затрагиваением любых других модулей которые используют этот компонент.

Закон Деметры (Law of Demeter)

Компоненты кода должны взаимодействовать только с их непосредственными отношениями (например, классы от которых они унаследованы, объекты которые они содержат, объекты переданные с помощью аргументов и т.д.)

Избегайте преждевременной оптимизации (Avoid Premature Optimization)

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

Мы должны забыть про небольшие улучшения эффективности, скажем на протяжении 97% времени: преждевременная оптимизация — это корень всех бед. © Дональд Кнут

От переводчика:

Преждевременная оптимизация хуже преждевременной эякуляции. © namezys

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

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

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

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

Повторное использование это хорошо (Code Reuse is Good)

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

Разделение ответственности (Separation of Concerns, SoC)

Различные области функциональности должны управляться различными и минимально перекрывающимися модулями кода.

Обними изменения (Embrace Change)

Это заголовок книги Кента Бека, в которой рассматривается принципы экстремального программирования (XP) и методологии гибкой разработки (Agile) в целом. Многие другие принципы основаны на концепции, что вы должны ожидать и приветствовать изменения. На самом деле очень старые принципы разработки, вроде минимизации связанности, непосредственно предназначаются для более лёгкого изменения кода. Даже если вы не приверженец экстремального программирования этот подход к написанию кода не теряет смысла.

От переводчика: и ещё один очень важный принцип не упомянутый автором

В объектно-ориентированом дизайне обязателен SOLID: аббревиатура из первых букв названий приниципов, часть которых уже описана в этой статье:

UPD
Посмотрите ещё на отличные мотиваторы с этими приницпами для программистов.

10 принципов автоматизации, которые я не предам

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

Я предлагаю по-новому взглянуть на автоматизацию в проектах и увидеть общие ошибки. Я расскажу о 10 принципах автоматизации, к которым пришла моя команда на собственном опыте, и которые помогут не наступать на одни и те же грабли.

Доклад смогут «прочувствовать» все тестировщики, работающие на проектах, где есть автоматизация.

Добавить комментарий