Рефакторингуем проджект риквайменты
- Дяденька, зачем Вы стоите здесь и проповедуете добро?
Ведь Вас никто не слушает.
Да и разве Вы в силах что-либо изменить?
- Все это я и сам понимаю.
Но если я не буду каждый день пытаться изменить человечество,
то боюсь, что оно изменит меня.
Эйгель Нансен, внук Фритьофа Нансена
Откуда берется коэффициент эффективности/компактности в тысячу?
В 2000-х Херрайц и Хассан измерили опенсорсные проекты из миллионов строк кода по десяткам различных метрик, и получили показательный результат: все они дают высокую корреляцию с таким нехитрым показателем, как число исходных строк кода программы (кроме пустых и комментариев:). В том числе и цикломатическая сложность Маккейба, и такая интересная вещь, как метрика Хэлстеда, показывающая понимаемость программы (число умозаключений, которое мозг должен проделать, дабы понять смысл исходников). Поэтому и будем опираться именно на этот просто измеряемый критерий -- число строк кода (sloc).
Понятно, что программку в тысячу строк кода не уместить в один оператор, а в пару сотен можно вполне. Наоборот, для extremely large projects, коэффициент может быть и выше. Прологарифмируем опыт Алана Кея:
десятки/сотни тысяч sloc : K = 100+
1-100 млн sloc : K = 1000+
миллиард sloc : K = 10,000
трилион sloc : K = 100500 :)
То есть весь написанный на планете за всю историю вычислительной техники код можно заново переписать, уместив на флешку -- в "объем", примерно эквивалентный хорошему дистрибутиву Linux.
Теперь главное: надо связать практику Метакода по созданию наглядных программ, тысячекратно компактнее своих "классических" аналогов, с повседневными мэйнстримовскими проектами. Предлагается следующая модель этой связки: объем итоговой программы в sloc должен быть примерно эквивалентен текстовому описанию ее функциональности (в тех же sloc).
Эта схожесть в первом приближении неплохо коррелирует с аланокеевским подходом: 20 тысяч строк текста, в каждой пускай 50 букв. Получается миллион знаков, типовая книжка. То есть умещенные им в 20 тыс sloc операционная система и прикладные пакеты вполне естественно описываются хорошим учебником == ТЗ.
Работает эта метрика и для других размеров. Например, задачку на тысячу императивных sloc, обычно описываемую десятком предложений, правильнее закодировать тем же десятком функциональных операторов. Я прикинул разные проекты из практики, ТЗ на проекты в сотни тысяч sloc практически всегда умещаются в объем обычной газеты.
Понятно, что требования заказчика/постановщика должны быть как следует отрефакторены. Например, для шахматной программы функциональность интерфейса наверняка опишется сотней предложений (и соответственно она может быть реализована сотней операторов). Но поиск лучшего хода -- функциональность уже неочевидная. В таком случае требование из одного предложения "программа ищет лучший ход" должно быть раскрыто: на естественном языке полностью описывается алгоритм его работы/реализации.
С этого и надо начинать: представить ТЗ в достаточно формальном текстовом (это принципиально) декларативном формате, и далее вручную "откомпилировать" эти требования в аналогичный по объему исполнимый код. В таком случае достаточно очевидная схема реализации проекта сколь угодно высокой сложности складывается из в принципе хорошо известных шагов:
- подготовки ТЗ (этим может заниматься человек, с программированием не знакомый);
- рефакторинга ТЗ в декларативный вид, пригодный для околомашинной обработки;
- "компиляции" требований в компактный код (сможет выполнять программист типовой квалификации по предлагаемой Метакодом методике).
Она должна хорошо масштабироваться, потому что постоянно поддерживается примерно однозначная отображаемость требований в исходный код с сохранением прозрачности, понимаемости и наглядности. При этом не вводится никаких дополнительных "программистских" сущностей типа классов или модулей, а так как мы исходим из того, что текстовые требования непротиворечивы (что легко выверить), то и от межмодульной запутанности избавляемся сразу.
Отличие данного подхода, шаги которого в принципе и так давно известны, в этапе "компиляции" требований в код. Его можно хорошо формализовать, по аналогии, например, с работой движков логического вывода типа Пролога итп. Функциональное программирование для этого замечательно подходит, так как помогает не "как делать", а "что делать".
"Каждое очередное пятилетие приносит нам новый взгляд на программирование.
Экстравагантный промежуточный этап в решении задачи, математическая головоломка,
дело необычайной трудности, доступное лишь посвященным,
своеобразное инженерное конструирование, особого рода логическое рассуждение, наконец -- основа любой целеустремленной деятельности,
вторая грамотность современного образованного человека".
(с) академик Андрей Петрович Ершов, 80-е гг. (архив)
P.S. Оформил Метакоду платный аккаунт.