Дефрагментация мозга. Софтостроение изнутри. Сергей Тарасов
Чтение книги онлайн.

Читать онлайн книгу Дефрагментация мозга. Софтостроение изнутри - Сергей Тарасов страница 10

СКАЧАТЬ крупных корпораций и развивается эволюционно.

      Тем не менее в софтостроении, даже кустарном и далёком от индустриализации, технологии составляют основу. О них мы и поговорим.

      Можно ли конструировать программы как аппаратуру?

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

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

      Возможность собирать изделия из «кубиков» стала предметом зависти софтостроителей, вылившейся в итоге в компонентный подход к разработке. Панацеи, разумеется, не получилось, несмотря на серьёзный вклад технологии в повторное использование «кубиков», оказавшихся скорее серыми ящиками с малопонятной начинкой. Но появился целый рынок, где писатели компонентов предлагают свои изделия «компонентокидателям» – это жаргонное слово возникло в среде наиболее массового применения компонентов, где их выбирают на палитре мышкой и, протаскивая, кидают[17] на разрабатываемую экранную форму.

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

      В софтостроении использовать конечно-автоматную модель для программного компонента можно при двух основных условиях:

      • Программисту не забыли объяснить эту теорию ещё в вузе (см. выше про «Круговорот»).

      • Количество состояний обозримо: они, как и переходы, достаточно легко определяются и формализуются.

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

      Возьмём относительно простой пример: компонент, конвертирующий сумму из одной валюты в другую.

      Из элементов стандартизации точно присутствуют коды валют по ISO 4217[18] и, частично, список служб, к которым компонент может обращаться (см., например, каталог служб Financial API). Интерфейс самого компонента не стандартизован, для возможной его СКАЧАТЬ



<p>17</p>

Англ. Drag and drop.

<p>18</p>

Международный стандарт, регламентирующий кодификацию валют.