Блог о программировании

Модели ветвления git. Gitflow

 11 февраля 2018 г. 17:01

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

Как это работает gitflow. Начальное состояние

В самом начале в master-ветке делается какой-то начальный коммит. Master-ветка содержит код, который всегда готов быть отправлен на рабочку. Обычно каждому обновлению кода ветки master присваивают релизный номер в теге. Таким образом, master-ветка содержит все релизы проекта. Так, первому коммиту можно присвоить тег v0.0.1 и считать, что это отправная точка проекта. После этого от master fork’ается ветка с говорящим названием develop. В develop-ветке находятся последние наработки по проекту, которые напрямую не коммитятся в develop. Все изменения кода выполняются в так называемых feature-ветках - для каждой фичи своя отдельная ветка.

Читать далее  

Теги:  workflow  git  git workflow  gitflow 

Обзор блога за 2017 год. Цели на 2018 год

Категория: Рабочие моменты
 20 января 2018 г. 0:11

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

Обзор за 2017 год

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

Читать далее  

Теги:  разное 

Модели ветвления git. Github flow

 4 января 2018 г. 15:49

В современном мире разработки знание команд для работы с git не означает обязательный успех в командной разработке. В команде важно закрепить какой-либо способ работы с git: какая ветка является основной для разработки, когда необходимо производить слияние веток, какая из них является той, которая выгружается на рабочку, и т.д. Набор таких правил называется моделью ветвления (англ.: workflow). В зависимости от того, над каким проектом вы работаете, а также какую модель ветвления в git вы используете и определяется эффективность работы команды разработчиков.

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

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

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

В данном цикле статей предполагается, что у читателя имеется базовый опыт работы с git, он ориентируется в терминах git: коммит, слияние, ветка, репозиторий, pull-request, fork. Также предполагается, что читатель умеет работать с git. Статьи преследуют цель показать суть той или иной модели ветвления, а не подробнейшее описание моделей.

Описание популярных моделей ветвления начнется с одной из самых простых – github flow.

Читать далее  

Работа в PHP по протоколу Stomp

Категория: PHP
 16 июля 2017 г. 19:49

В последнее время все более активно продвигается идея построения событийно-ориентированной архитектуры программного обеспечения. Такая архитектура предполагает, что её компоненты - отдельные сервисы, общаются между собой путем отправки асинхронных событий через общую шину ESB. Событие – это сообщение (например в терминологии AMQP), у которого есть название и набор параметров. Обычно событием является запрос какой-то информации, либо это может быть просто уведомление о чем-то заинтересованных сторон. В общем случае, событие отправляется безадресно, то есть без конкретных знаний, какой сервис должен получить данное событие. Конкретные же сервисы слушаю общую шину на предмет появления в них тех или иных событий или запросов с целью реагирования. Прелесть построения событийно-ориентированной архитектуры в том, что сервис-отправить может отправить событие в шину и, не дожидаясь ответа, приступить к выполнению других важных задач. Ответ будет получен позже также через шину.

Схема использования ESB

Схема использования ESB

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

Читать далее  

Теги:  php  stomp  ActiveMQ  RabbitMQ  php7 

Слабая связность и сильное зацепление программного кода

 10 июля 2017 г. 0:44

Одно из главных правил разработки программ сводится к тому, чтобы код был слабо связным между собой и в то же время имел сильное зацепление(low coupling, high cohesion). Никогда не нравились эти заумные слова и термины, особенно, когда за ними стоит совершенно простой смысл.

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

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

Зацепление (cohesion) - это степень общности выполняемых функций конкретного класса. Зацепление должно быть сильным, что в терминах ООП означает, что каждый класс должен быть сфокусирован на решении одной конкретной задачи. Например, у нас есть класс, который хранит информацию о банковском кредите - это круг решаемых задач класса. Если же мы в этом классе добавим метод, выполняющий печать данных, то зацепление будет уменьшено. Соответствует принципу Single Responsibility Principle в SOLID.

Профилирование PHP7 кода с использованием xhprof

 2 июля 2017 г. 20:05

Со временем любой PHP-программист сталкивается с проблемой низкой производительности своего приложения. Это может быть медленная загрузка конкретной страницы или слишком долгий ответ от API. И порой достаточно сложно понять, в чем причина тормозов? Порой случаются более сложные ситуации: на боевом сервере api сильно тормозит, но на стенде, где происходит разработка, - все хорошо. И пойди разберись, что идет не так. Производить отладку на рабочем сервере - это крайняя степень безысходности, до которой, конечно, лучше не доводить.

Именно для таких ситуаций и были придуманы специальные инструменты, называемые профилировщиками приложений. В мире PHP эту роль выполняют xDebug, а также xhprof. xhprof является более легковесным, простым и гибким инструментом, поэтому его использование более предпочтительно. Что интересно, xhprof был разработан в facebook еще в 2009 году, однако до сих пор от них нет официальной поддержки php7 и больше не будет, поскольку facebook перешел на HHVM. Однако, благодаря обширному сообществу php-разработчиков, появился форк, поддерживающий php7, установка которого не вызывает каких-либо сложностей.

Читать далее  

Теги:  php  xhprof  php7 

Цикломатическая сложность

Категория: DevOps
 25 июня 2017 г. 21:44

Цикломатическая сложность (Cyclomatic Complexity Number, ccn) программного кода является одной из наиболее старых метрик. Впервые эта метрика была упомянута в 1976 году Томасом МакКэбом. Эта метрика подсчитывает доступные пути выполнения кода во фрагменте программного обеспечения, чтобы определить его сложность. Каждый путь выполнения включает одну условную конструкцию из приведенного ниже списка, так что это их довольно легко обнаружить в существующем исходном коде:

  • ?
  • case
  • elseif
  • for
  • foreach
  • if
  • while

В данном случае нет конструкций else и default, потому что они в любом случае предполагают использование конструкций if и case, которые присутствуют в списке.

Читать далее  

Статический анализ и метрики PHP-кода

Категория: DevOps
 17 июня 2017 г. 20:43

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

Читать далее  

Теги:  PHP  ci  cd  php7 

Непрерывная интеграция и непрерывная доставка PHP-кода

Категория: DevOps
 22 мая 2017 г. 23:01

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

Непрерывная интеграция (англ. Continuous Integration, CI) — это практика разработки программного обеспечения, которая заключается в выполнении частых автоматизированных сборок проекта для скорейшего выявления и решения интеграционных проблем. Обычно сборка проекта осуществляется после внесения изменения разработчиком в код, либо через определенные промежутки времени, например, каждые 20 минут. В любом случае, за определенной сборкой закрепляется определенный коммит в репозитории кода.

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

Читать далее  

Теги:  PHP  ci  cd  php7 

PHP 7 в подлиннике

Категория: Книги
 2 апреля 2017 г. 18:48

Авторы: Дмитрий Котеров, Игорь Симдянов

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

В целом - еще одна всеобъемлющая книга по PHP, соответственно, книга для широкого круга читателей. В книге описывается весь процесс разработки на php, а также сопутствующие темы, правда в краткой форме. Присутствуют главы с описанием работы с системой контроля версий git, виртуальных машин, веб-сервера nginx и php-fpm. Также в общих чертах дается описание работы cgi-интерфейса. Уделено внимание работе с composer, использованию компонентов, расширениям php, документированию кода и стандартам PSR. Описанию разработки с использованием ООП уделено достаточно внимание, трудностей с пониманием данного материала не должно возникнуть у читателя.

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

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

Теги:  php  книга  php7