Средства и методы разработки

Я не могу с вами согласиться. Программы пишутся для людей, чтобы их читали. Хорошие программы пишутся не по принципу: написал и забыл, а их приходится дорабатывать, улучшать, добавлять новые функции. Нечитаемые программы превращают дальнейшую работу с ними в ад. Я знаю. Если над кодом работает больше одного человека -- это опять ад. Если у каждого из них свои понятия о программе -- это ад. Давайте поговорим про верифицируемость. Как вы верифицируете программы? Насколько я помню проблема полной формальной верификации программы на соответствие требованиям или документации или схеме конечного автомата - не решена до сих пор. Кроме тех случаев, когда сам код для автомата сгенерирован автоматические из диаграммы состояний автомата. Тогда да: автоматиски сгенерированный код обычно читать не возможно и никто его не читает. Используется исходное представление автомата в виде диаграммы состояний и переходов, а сгенерированный си-код -- это продукт компиляции, аналогичный объектным файлам или файлам листинга. (хотя листинги я читаю, но нечасто). Либо у вас есть какая-то сложная формальная система для генерации кода из диаграмм и верификации, либо ваши слова -- это просто описание идеальной ситуации к которой (мне тоже) хотелось бы стремиться, но приходится жить с тем что есть. Или поговорим про автоматические тесты. Даже лучше про автоматические тесты. Писать тесты для автоматов - это геморрой. Я пробовал. Я знаю. Это больно. И чем больше состояний у автомата, тем больнее. Автоматы -- это плохо для тестов, потому что у них есть состояние. Изменение этого состояния -- это side-effect. Это не тестируется нормально. Если состояние это глобальная переменная, то к проблеме с тестами добавляются проблемы с глобальными переменными, которые могут сохранять свои значение между запусками отдельных тестов. Если вам надо проверить поведение автомата для конкретного состояния, вам надо автомат перевести в это состояние в начале теста. Если кроме состояния автомата при работе используются еще и дополнительные данные, которые формируются по мере прохождения других состояния -- это опять геморрой. Проще всего тестировать функциональные программы. Подали на вход аргументы - получили результат. Если порезать автомат на отдельные функции -- это можно. Но это опять ад. У вас будет столько функций сколько состояний. При их числе больше чем пальцев на одной руке -- это ад. Я тестировал автоматы как черные ящики. И делал специальные бэкдоры, чтобы устанавливать автомат в нужное состояние. Это можно сделать. Но цена! Если я смогу уйти от автоматов на функции, то я смогу облегчить себе жизнь в плане тестирования. Если я хочу уйти с текущей работы на другую, то как ответственный человек я хочу, чтобы тот кто придет после меня, смог разобраться в моем коде. Лучше чтобы этот код был таки читаемым и понимаемым. Если мне достался в наследство код от уволившегося программиста, и глядя на этот код на ум приходят только нехорошие слова и еще кое-что похуже, то я предпочту все-таки читаемый код. Короче я никак не могу согласиться. Не так давно я прочитал хорошую книгу Dustin Boswell, Trevor Foucher, "The art of readable code" вот тут неплохой обзор http://demin.ws/bl …/art-of-readable-code/ Я имею основания считать, что верифицируемость программ -- это такой миф, и что в реальности все немножко не так. Поэтому читабельность кода для меня важна.