Publish 2018-06-27 Example-driven development article

This commit is contained in:
2018-06-27 11:18:30 +03:00
parent 42908c0eca
commit 8f5eb01ee4
22 changed files with 1000 additions and 267 deletions

View File

@@ -0,0 +1,70 @@
Title: Разработка через создание примеров
Date: 2018-06-27 00:00
Category: News
Slug: example-driven-development
Lang: ru
![Screenshot][screenshot]
Эта статья описывает то, как создание третьего кросс-платформенного примера
OpenSceneGraph привело нас к разработке через создание примеров.
**Третий кросс-платформенный пример OpenSceneGraph**
Третий кросс-платформенный пример OpenSceneGraph содержит реализацию
[удалённой отладки, работающей на всех поддерживаемых платформах][osgcpe-03].
Этот пример относится не столько к OpenSceneGraph, сколько к поддержке
различных платформ.
Удалённое взаимодействие ныне предполагает использование HTTP(s) поверх
TCP/IP. Таким образом, первая идея реализации подразумевала встраивание сервера
HTTP в приложение, чтобы клиенты HTTP могли взаимодействовать с этим сервером.
Однако, раздача HTTP на различных платформах имеет свои сложности:
* на десктопах есть межсетевые экраны (firewalls)
* на мобилках есть ограничения по работе фоновых процессов
* веб-браузеры являются клиентами HTTP по дизайну
Эти ограничения подтолкнули нас к созданию посредника между отлаживаемым
приложением и пользовательским интерфейсом отладки.
[Брокер отладки][debug-broker], небольшое приложение Node.js, стало тем самым
посредником. Брокер отладки не имеет внешних зависимостей, поэтому его легко
использовать практически везде. Благодаря тому, что брокер отладки - это
серверное приложение, его достаточно настроить лишь раз и использовать для
любого количества приложений.
И [пользовательский интерфейс отладки][debug-ui],
и [брокер отладки][debug-broker] используют JavaScript, т.к. мы хотели сделать
эти инструменты максимально доступными без предварительной установки. Данное
решение привело нас к реализации инструментов именно для веб-браузеров.
Десктопное приложение потребовало бы дополнительных усилий на установку и
поддержку, что лишь усложнило бы работу с инструментами.
**Разработка через создание примеров**
После создания третьего примера мы осознали важность и достоинства разработки
новых функций вне основного проекта:
* освобождение основного проекта от шума изменений (commit noise)
* публичное освещение новой функции приглашает всех к её изучению, критике и улучшению
Когда мы делимся нашими знаниями:
* мы обязаны создавать документацию, объясняющую происходящее (в том числе для нас самих позже)
* мы обязаны сторониться непродуманных решений, т.к. они повредят нашей репутации
С этого момента все новые функции вроде обработки ввода, загрузки раскладок
Маджонга, кэширования ресурсов и т.п. мы будем сначала реализовывать в виде
примеров. Мы называем этот подход разработкой через создание примеров.
На этом мы заканчиваем описание того, как создание третьего
кросс-платформенного примера OpenSceneGraph привело нас к разработке через
создание примеров.
[screenshot]: {attach}/images/2018-06-27-example-driven-development.png
[osgcpe-03]: https://github.com/OGStudio/openscenegraph-cross-platform-examples/tree/master/03.RemoteDebugging
[debug-broker]: https://github.com/OGStudio/debug-broker
[debug-ui]: https://github.com/OGStudio/debug-ui

View File

@@ -0,0 +1,64 @@
Title: Example-driven development
Date: 2018-06-27 00:00
Category: News
Slug: example-driven-development
Lang: en
![Screenshot][screenshot]
This article explains how the third OpenSceneGraph cross-platform example
opened our eyes to example-driven development.
**The third OpenSceneGraph cross-platform example**
The third OpenSceneGraph cross-platform example explains how to implement
[remote debugging across platforms][osgcpe-03]. This example is less about
OpenSceneGraph and more about different platforms.
Remote anything nowadays assumes the use of HTTP(s) over TCP/IP. Thus, the
first idea was to embed HTTP server into an application and let HTTP clients
interact with the server. However, serving HTTP across all platforms is
complicated:
* desktops have firewalls
* mobiles have restrictions on background processes
* web browsers are HTTP clients by design
That's why we decided to create a mediator between debugged application and UI.
[Debug broker][debug-broker], a small Node.js application, became that mediator.
Debug broker uses no external dependencies, so it's easy to run virtually
anywhere. Also, since debug broker is a server application, you can configure
it once and use it for any number of applications.
Both [debug UI][debug-ui] and [debug broker][debug-broker] use JavaScript
because we wanted these tools to be accessible from anywhere with no prior
installation. This decision limited us to web browser solution. Providing
any sort of desktop application would incur additional installation and
maintenance effort, which would only complicate the tools.
**Example-driven development establishment**
Once the third example was implemented, we realized how important and
beneficial it is to develop new features outside the main project:
* the main project is freed from excessive commit noise
* a new feature is publicly shared for everyone to learn, criticize, and improve
When we publicly share our knowledge:
* we must create documentation for everyone (including ourselves later) to understand what's going on
* we must not use hacks because that would break your trust in us
From now on, all new features like input handling, Mahjong layout loading,
resource caching, etc. are going to be first implemented as examples.
We call this example-driven development.
That's it for explaining how the third OpenSceneGraph cross-platform example
opened our eyes to example-driven development.
[screenshot]: {attach}/images/2018-06-27-example-driven-development.png
[osgcpe-03]: https://github.com/OGStudio/openscenegraph-cross-platform-examples/tree/master/03.RemoteDebugging
[debug-broker]: https://github.com/OGStudio/debug-broker
[debug-ui]: https://github.com/OGStudio/debug-ui