Эпичный эпиграф:
«Паттернов можешь ты не знать,
но управленье знать обязан!»
Кто знаком с теорией Геделя о неопределенности (которая получила не совсем точное название «о неполноте»), тот понимает: все (достаточно) сложные системы испытывают принципиальные трудности в самопознании и самоописании на определенном уровне глубины и детальности. Сразу уточню: я НЕ утверждаю, что между теорией вышеупомянутого Г. и “вечными” (именно в кавычках!) проблемами ООП имеется прямая связь, нет. Но я, тем не менее, утверждаю, что проблемы «совершенного кода» – объективно не разрешимы. Не вообще никогда, а ровно до того момента, пока мы наконец-то не выйдем за пределы самого ООП – и не посмотрим на него с высоты еще более сложной системы. «Большое ведь видится на расстояньи»!
Так вот. Радуйтесь, люди и звери! У меня есть подходящая «высота»! Она называется «Достаточно Общей Теорией Управления» (далее – «ДОТУ»). Поскольку этот текст не должен ни популяризировать, ни тем более рекламировать ДОТУ, я о ней почти ничего не скажу. Как и все по-настоящему жизнеутверждающие идеи, она «говорит и показывает» сама за себя. Но вообще не упоминать ДОТУ тоже никак не получается – ведь должен же я предъявить свой мировоззренческий (и терминологический, если че) стандарт?
Создание программы – это процесс управления (восторженное «ах!» в зрительном зале!). Многоуровневого, очень сложноорганизованного – но все же именно управления. К сожалению, не многие задумываются, что управление – штука, существующая объективно (как, например, облака на небе или относительность пространства-времени). Последнее (объективность) и обуславливает существование таких наук и псевдонаук как management или метеорология. Короче, суть в том, что между программированием именно как процессом управления чем-то вполне определенным и управлением чем угодно другим (но тоже конкретным, так или иначе определенным) – есть нечто общее. Вроде вызова base. Обилие слов типа «что-то», «нечто» говорит о том, что мы забрались на очень высокий уровень абстракций – настолько высокий, что наш язык еле-еле справляется с объяснением. А значит, мы попали куда нужно: отсюда и начнем (только начнем!) разбираться с тем, что же такое «совершенный код».
Итак, управление – это когда в результате действий управленца какой-нибудь объект/процесс перешел из одного состояния (которое по неважно какой причине данного управленца не устраивало – иначе самой потребности в управлении и не возникло бы!) в другое состояние. А отсюда следует жизненно важный вывод: правильный подход к управлению буквально чем угодно обязательно требует, чтобы еще до начала активных действий управленец имел достаточно четкое представление о своих целях – т.е. о том, в каком состоянии в конце-концов должен оказаться тот объект/процесс, которым он еще только намеревается управлять. Если мы говорим о разработчике, то до того момента, пока у него в голове не вырисуется более-менее четкая (и достаточно детализированная, взаимосвязанная) картина конечно продукта – он не должен написать ни единой строчки кода. Обратите внимание: речь идет об образе самого конечного продукта, а не коде, стоящем за ним; код – это средство, при помощи которого реализуется замысел. И еще архиважное уточнение – здесь под «конечным продуктом» понимается не что иное, как конечный продукт. Другими словами, конечный продукт – это конечный продукт, а не промежуточная версия. На всякий случай еще разок: «конечный продукт» – это то, что получится в конце – то есть, в самом что ни есть конце. А конец – это, в свою очередь, не середина, не 2/3 и даже не 49/50. Ну, вы поняли…
А теперь включите совесть и честно ответьте на вопрос – как часто вы следуете этому простому и самоочевидному принципу управления вообще в своих проектах? А знаете, почему такая практика присуща лишь избранным? Да потому что это ОЧЕНЬ «интеллекто-емкая» задача – прорисовать в голове все детали будущего проекта. Особенно, если он обещает быть огромным и с непредсказуемыми поворотами на полпути. Но вины проекта в этом нет. Это означает только одно: данная управленческая задача не соответствует вашим (или моим, или его, или ее) управленческим способностям. Тут дело не в программировании как таковом; нисколечко не в том, что объект «Петя» класса «DotNetDevelopers» не знает, чем string x += string y отличается от StringBuilder x.Append(y). Проблема как раз в другом – я называю ее «управленческой импотенцией». И она гораздо более распространена (и опасна), чем просто импотенция!..
Че там нынче в моде при любой погоде? Паттерны? Честно говоря, я не знаток паттернов, но даже моего знакомства с ними (труды банды четырех читал и даже пробовал на вкус!) вполне хватает, чтобы утверждать с почти полной уверенностью: эти ваши паттерны проблему не решают. Максимум – замазывают. А как правило просто размазывают – равномерно по всем поверхностям, где проходил (чаще – проползал) очередной зомби от «Боже, храни паттерны». Решить эту проблему на уровне новых «штучег» компиляторов или фреймворков — нельзя. Не тот уровень.
Ну-ка берите в руки ручки и записывайте: НИКАКОГО СОВЕРШЕННОГО КОДА НЕ СУЩЕСТВУЕТ. Зато существует код, который решает конкретную управленческую задачу полностью. Поэтому рассматривать код отдельно от задачи – это такая же глупость, как рассматривать клетку отдельно от микроскопа. Скорее «Дом-2» закончится, чем такое произойдет! Поэтому, если особенность вашей задачи такова, что вам абсолютно наплевать на то, отвечает графический интерфейс или безнадежно занят каким-то сумасшедшим циклом, — то ваш монопоточный код – шикарен (конечно, при условии, что цикл не подкачает!). А если общение с пользователем в приоритете, то вы – то еще .Net-убожество!
Единственное, о чем имеет смысл говорить по существу на тему совершенного кода, так это о том количестве усилий, которые приходится тратить на его создание. Вот async/await, шпасиба умным дядям из Microsoft, круто экономит время. Поэтому (при прочих равных) код, основанный на async’е, должен быть признан объективно лучше, чем BeginXXX/EndXXX. Но это было понятно даже умственно отсталым. И совсем не к этому выводу я хотел подвести.
Проблема плохих проектов – не в плохих программистах, а в плохих управленцах, которые неумело управляют процессом создания локального кода/приложения в целом. И решать эту проблему нужно на соответствующем уровне (который, как вы возможно НЕ поняли, гораздо-гораздо выше всяких там компиляторов – при всем уважении к последним).
Есть у меня одна идейка по поводу решения проблемы. Неплохо было бы запилить «весчь», которая использовалась бы как своеобразный тест на способность управлять данным, конкретным проектом. Она бы работала примерно так: я кликаю «создать новый Проект». Дальше запускается хитрый алгоритм, по ходу которого создается массив параметров, которыми будет описываться то, что в вышеупомянутой ДОТЕ называется «Вектором целей» и «Вектором текущего состояния». А потом этап, на котором вы все обломитесь – указать КОНКРЕТНЫЕ значения созданных параметров для конечного состояния, к которому я пытаюсь привести этот объект/процесс (это и будет моя цель). Если я на это не способен (а я тот еще бездарь!), то это значит, что в настоящий момент я не обладаю достаточно ясной картиной происходящего, не способен поставить достаточно определенную цель, а следовательно и управление мое (т.е. мой код и проект в целом) будет попахивать сами догадаетесь чем. Конечно, можно это дело сдобрить паттернами, но тогда получится как в том анекдоте – «как будто кто-то под елкой насрал».
Но и инициализация «вектора целей» (в терминах все той же ДОТУ) – это еще не конец квеста. Дальше – больше. Двигаясь от конечного состояния к начальному, я должен разделить управленческий процесс на последовательность шагов. Каждый шаг – это множество состояний, в котором объект/процесс мог бы оказаться на соответствующем этапе своей реализации. Фактически, речь идет о создании сетки состояний («матрицы возможных переходов» (с) ДОТУ), в пределах которой будет продвигаться выполнение проекта. Ессесвенна, каждое состояние описывается тем же набором параметров – только они принимают уже другие значения. Здесь-то трушные управленцы от Бога и отделятся от прочей шелухи (независимо от сертификатов, возраста, зарплаты и самомнения). А если кто способен жизненно, убедительно довести проект от конечного состояния в начальное – ему и паттерны в руки!
«Паттернов можешь ты не знать,
но управленье знать обязан!»
«Большое видится на расстояньи»
Кто знаком с теорией Геделя о неопределенности (которая получила не совсем точное название «о неполноте»), тот понимает: все (достаточно) сложные системы испытывают принципиальные трудности в самопознании и самоописании на определенном уровне глубины и детальности. Сразу уточню: я НЕ утверждаю, что между теорией вышеупомянутого Г. и “вечными” (именно в кавычках!) проблемами ООП имеется прямая связь, нет. Но я, тем не менее, утверждаю, что проблемы «совершенного кода» – объективно не разрешимы. Не вообще никогда, а ровно до того момента, пока мы наконец-то не выйдем за пределы самого ООП – и не посмотрим на него с высоты еще более сложной системы. «Большое ведь видится на расстояньи»!
Фото моего кота
Так вот. Радуйтесь, люди и звери! У меня есть подходящая «высота»! Она называется «Достаточно Общей Теорией Управления» (далее – «ДОТУ»). Поскольку этот текст не должен ни популяризировать, ни тем более рекламировать ДОТУ, я о ней почти ничего не скажу. Как и все по-настоящему жизнеутверждающие идеи, она «говорит и показывает» сама за себя. Но вообще не упоминать ДОТУ тоже никак не получается – ведь должен же я предъявить свой мировоззренческий (и терминологический, если че) стандарт?
Создание программы – это процесс управления (восторженное «ах!» в зрительном зале!). Многоуровневого, очень сложноорганизованного – но все же именно управления. К сожалению, не многие задумываются, что управление – штука, существующая объективно (как, например, облака на небе или относительность пространства-времени). Последнее (объективность) и обуславливает существование таких наук и псевдонаук как management или метеорология. Короче, суть в том, что между программированием именно как процессом управления чем-то вполне определенным и управлением чем угодно другим (но тоже конкретным, так или иначе определенным) – есть нечто общее. Вроде вызова base. Обилие слов типа «что-то», «нечто» говорит о том, что мы забрались на очень высокий уровень абстракций – настолько высокий, что наш язык еле-еле справляется с объяснением. А значит, мы попали куда нужно: отсюда и начнем (только начнем!) разбираться с тем, что же такое «совершенный код».
«Не управленец не войдет»
Итак, управление – это когда в результате действий управленца какой-нибудь объект/процесс перешел из одного состояния (которое по неважно какой причине данного управленца не устраивало – иначе самой потребности в управлении и не возникло бы!) в другое состояние. А отсюда следует жизненно важный вывод: правильный подход к управлению буквально чем угодно обязательно требует, чтобы еще до начала активных действий управленец имел достаточно четкое представление о своих целях – т.е. о том, в каком состоянии в конце-концов должен оказаться тот объект/процесс, которым он еще только намеревается управлять. Если мы говорим о разработчике, то до того момента, пока у него в голове не вырисуется более-менее четкая (и достаточно детализированная, взаимосвязанная) картина конечно продукта – он не должен написать ни единой строчки кода. Обратите внимание: речь идет об образе самого конечного продукта, а не коде, стоящем за ним; код – это средство, при помощи которого реализуется замысел. И еще архиважное уточнение – здесь под «конечным продуктом» понимается не что иное, как конечный продукт. Другими словами, конечный продукт – это конечный продукт, а не промежуточная версия. На всякий случай еще разок: «конечный продукт» – это то, что получится в конце – то есть, в самом что ни есть конце. А конец – это, в свою очередь, не середина, не 2/3 и даже не 49/50. Ну, вы поняли…
А теперь включите совесть и честно ответьте на вопрос – как часто вы следуете этому простому и самоочевидному принципу управления вообще в своих проектах? А знаете, почему такая практика присуща лишь избранным? Да потому что это ОЧЕНЬ «интеллекто-емкая» задача – прорисовать в голове все детали будущего проекта. Особенно, если он обещает быть огромным и с непредсказуемыми поворотами на полпути. Но вины проекта в этом нет. Это означает только одно: данная управленческая задача не соответствует вашим (или моим, или его, или ее) управленческим способностям. Тут дело не в программировании как таковом; нисколечко не в том, что объект «Петя» класса «DotNetDevelopers» не знает, чем string x += string y отличается от StringBuilder x.Append(y). Проблема как раз в другом – я называю ее «управленческой импотенцией». И она гораздо более распространена (и опасна), чем просто импотенция!..
Че там нынче в моде при любой погоде? Паттерны? Честно говоря, я не знаток паттернов, но даже моего знакомства с ними (труды банды четырех читал и даже пробовал на вкус!) вполне хватает, чтобы утверждать с почти полной уверенностью: эти ваши паттерны проблему не решают. Максимум – замазывают. А как правило просто размазывают – равномерно по всем поверхностям, где проходил (чаще – проползал) очередной зомби от «Боже, храни паттерны». Решить эту проблему на уровне новых «штучег» компиляторов или фреймворков — нельзя. Не тот уровень.
Когда уже откровение про «совершенный код»?
Ну-ка берите в руки ручки и записывайте: НИКАКОГО СОВЕРШЕННОГО КОДА НЕ СУЩЕСТВУЕТ. Зато существует код, который решает конкретную управленческую задачу полностью. Поэтому рассматривать код отдельно от задачи – это такая же глупость, как рассматривать клетку отдельно от микроскопа. Скорее «Дом-2» закончится, чем такое произойдет! Поэтому, если особенность вашей задачи такова, что вам абсолютно наплевать на то, отвечает графический интерфейс или безнадежно занят каким-то сумасшедшим циклом, — то ваш монопоточный код – шикарен (конечно, при условии, что цикл не подкачает!). А если общение с пользователем в приоритете, то вы – то еще .Net-убожество!
Единственное, о чем имеет смысл говорить по существу на тему совершенного кода, так это о том количестве усилий, которые приходится тратить на его создание. Вот async/await, шпасиба умным дядям из Microsoft, круто экономит время. Поэтому (при прочих равных) код, основанный на async’е, должен быть признан объективно лучше, чем BeginXXX/EndXXX. Но это было понятно даже умственно отсталым. И совсем не к этому выводу я хотел подвести.
ВЫВОД, к которому я хотел подвести
Проблема плохих проектов – не в плохих программистах, а в плохих управленцах, которые неумело управляют процессом создания локального кода/приложения в целом. И решать эту проблему нужно на соответствующем уровне (который, как вы возможно НЕ поняли, гораздо-гораздо выше всяких там компиляторов – при всем уважении к последним).
И напоследок
Есть у меня одна идейка по поводу решения проблемы. Неплохо было бы запилить «весчь», которая использовалась бы как своеобразный тест на способность управлять данным, конкретным проектом. Она бы работала примерно так: я кликаю «создать новый Проект». Дальше запускается хитрый алгоритм, по ходу которого создается массив параметров, которыми будет описываться то, что в вышеупомянутой ДОТЕ называется «Вектором целей» и «Вектором текущего состояния». А потом этап, на котором вы все обломитесь – указать КОНКРЕТНЫЕ значения созданных параметров для конечного состояния, к которому я пытаюсь привести этот объект/процесс (это и будет моя цель). Если я на это не способен (а я тот еще бездарь!), то это значит, что в настоящий момент я не обладаю достаточно ясной картиной происходящего, не способен поставить достаточно определенную цель, а следовательно и управление мое (т.е. мой код и проект в целом) будет попахивать сами догадаетесь чем. Конечно, можно это дело сдобрить паттернами, но тогда получится как в том анекдоте – «как будто кто-то под елкой насрал».
Но и инициализация «вектора целей» (в терминах все той же ДОТУ) – это еще не конец квеста. Дальше – больше. Двигаясь от конечного состояния к начальному, я должен разделить управленческий процесс на последовательность шагов. Каждый шаг – это множество состояний, в котором объект/процесс мог бы оказаться на соответствующем этапе своей реализации. Фактически, речь идет о создании сетки состояний («матрицы возможных переходов» (с) ДОТУ), в пределах которой будет продвигаться выполнение проекта. Ессесвенна, каждое состояние описывается тем же набором параметров – только они принимают уже другие значения. Здесь-то трушные управленцы от Бога и отделятся от прочей шелухи (независимо от сертификатов, возраста, зарплаты и самомнения). А если кто способен жизненно, убедительно довести проект от конечного состояния в начальное – ему и паттерны в руки!