16.2. Прозрачность — ключ к повторному использованию кода
16.2. Прозрачность — ключ к повторному использованию кода
История Дж. Рэндома Ньюби была испытана на множестве опытных программистов. Если читатель относится к их числу, то он, вероятно, отреагирует, как и большинство коллег: возгласом понимания. Если же читатель не является программистом, а управляет программистами, то автор искренне надеется, что история получилась назидательной.
Большинство из нас привыкли к исходным предположениям программной индустрии о том, что могут потребоваться значительные умственные усилия, прежде чем появится возможность выделить главные причины данной проблемы. Но в конечном итоге они не являются очень сложными.
В основе большинства неприятностей Дж. Рэндома Ньюби (и крупномасштабных проблем качества, которые они подразумевают) лежит прозрачность — или, вернее, ее недостаток. Невозможно устранить проблему в коде, который невозможно посмотреть изнутри. Фактически в любой программе с нетривиальным API-интерфейсом невозможно даже должным образом использовать то, что нельзя увидеть изнутри. Документация неадекватна не только на практике, но и в принципе. Она не способна передать все нюансы, реализованные в коде.
В главе 6 отмечалось, как важна для хорошей программы центральная прозрачность. Компоненты, состоящие только из объектного кода, разрушают прозрачность программной системы. С другой стороны, неудачи повторного использования кода гораздо менее вероятно нанесут ущерб, когда повторно используемый код доступен для чтения и модификации. Хорошо комментированный исходный код сам по себе является документацией. Ошибки в исходном коде можно устранить. В исходный код можно включить средства измерения и скомпилировать для отладки, что позволяет упростить проверку его поведения в непонятных случаях, а кроме того, всегда можно изменить поведение программы в случае необходимости.
Существует еще одна жизненно важная необходимость в исходном коде. Урок, который Unix-программисты изучали в течение десятилетий, заключается в том, что исходный код выдерживает испытание временем, а объектный — нет. Изменяются аппаратные платформы и служебные компоненты, такие как библиотеки поддержки, в операционных системах появляются новые API-интерфейсы и устаревают прежние. Меняется все, а непроницаемые двоичные исполняемые модули не способны адаптироваться к изменениям. Они хрупки, невозможно надежно обеспечить их дальнейшую переносимость, а кроме того, их необходимо поддерживать с помощью расширяющихся и подверженных ошибкам уровней кода эмуляции. Они замыкают пользователей в рамках предположений разработчиков. Исходный код необходим, ведь даже если нет ни намерений, ни необходимости изменять программу, в будущем для обеспечения работоспособности программы ее придется перекомпилировать в новых средах.
Важность прозрачности и проблема устаревания кода являются теми причинами, по которым следует требовать открытости повторно используемого кода для проверки и модификации[135]. Это лишь предварительный аргумент в пользу того, что сейчас называется "открытым исходным кодом". Понятие "открытый исходный код" имеет более важный смысл, чем просто требование прозрачности и видимости кода.
Данный текст является ознакомительным фрагментом.