Обсуждение

По-моему, направление кодогенерации является тупиковым в принципе. Зачем вообще нужно представление программы в виде кучи текстовых файлов? Когда, наконец, инструменты для объектно-ориентированного программирования сами станут объектно ориентированными? Когда мы получим интегрированное объектное (динамическое) представление моделей, кода, тестов, документации, ресурсов? Это откроет совершенно новые возможности для анализа и рефакторингаи. Некоторые шаги в этом направлении были сделаны в Смолтолке, но код методов там все равно представлен как текст. Удивительно, но скажем, почтовые клиенты давно обогнали средства разработки в этом направлении. Мы давно работаем с электронными письмами как с объектами, не задумываясь, что это письмо собой представляет - один файл, много файлов, запись в базе данных.

Мелкой россыпью. Будет время подумать, может чего-то внятное выделю. http://www.metacase.com/ "вплоть до генерации кода" - Это http://www.executableumlbook.com/ и без action language ничего путного из моделей не выйдет. А его можно хоть на C++ сделать. Кстати, исходный код - это тоже своего рода модель. Тексты - это здорово, но картинки лучше. Тем более, что менеджеры только их и понимают. И DSL я б всё-таки не брал с потолка, а выделял из языка экспертов в предметной области. С вводом новых языков проблема будет со знающими их. Это как на заре языков программирования высокого уровня. Каждый писал язык для себя, а выжили единицы. Причём, все заимели перекрёстным опылением разумные особенности друг друга.

Martin Fowler - отец DSL и Software Factories. http://www.martinfowler.com/bliki/DomainSpecificLanguage.html

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

> Тексты - это здорово, но картинки лучше. Тем более, что менеджеры только их и понимают. Менеджеры, которые понимают только картинки - это рудимент. Со временем он отвалится. Не скажу что это будет прямо сейчас, но процесс уже пошел. В связи с кризисом. Хороший пример - август 2007. Тогда в Америкосии на биржах случился кризис ликвидности. Отмечу, что некоторые финансовые компании его пережили легко. Это те, кто построили специальные сети для выполнения приказов, объединяющие различные пулы ликвидности. У тех кого таких сетей не было или они работали не эффективно, были проблемы: поток заказов от клиентов их перегрузил, и задержки были громадные, они упустили лучшие цены. Удвоение кол-ва серверов не помогло - сама структура сети была неэффективной. Дык вот, построение эффективной сетки выполнения приказов не решается рисованием картинок. И это не могут делать менеджеры. И те компании, которые ставили на менеджеров рисующих картинки, сильно потрепало в кризис, потому что картинки от проблем не защищают, а вот снижение издержек очень даже способствует.

Менеджеры, которые понимают только картинки - это рудимент. Со временем он отвалится. Это сказки. Отвалится вместе с производством, переместившимся в Китай. Но ни как иначе. А менеджеров всяких A.I.G. да City спасёт государство.

Вы пролонгируете действующие ранее тенденции. На самом деле они не могут действовать вечно. Во-первых Китай свое производство начнет сплавлять в страны третьего мира, ибо его расти уже задолбало. Во-вторых он будет меньше финансировать американский госдолг, ибо это уже задолбало америку. В-третьих прочитайте проспекты эмиссии привилегированных акций за которые гос-во давало деньги Сити да АИГ. Я вот почитал бумажки которые Сити писало, там написано, что государство утверждает бонусы менеджерам, да и вообще получает контрольный пакет. Думаю, в АИГ аналогичная фигня.

Вы пролонгируете действующие ранее тенденции. На самом деле они не могут действовать вечно. Ну да. Европейские фирмы под плохим менеджментом разоряются. Но страдают не менеджеры, а те, кто очень внизу. Во-первых Китай свое производство начнет сплавлять в страны третьего мира, ибо его расти уже задолбало. Абсолютно бездоказательное утверждение. Что думает по этому поводу КПК? государство утверждает бонусы менеджерам, да и вообще получает контрольный пакет. Думаю, в АИГ аналогичная фигня. Опять же. За плохой менеджмент надо было давать под зад коленом, а не пересаживать на госдолжность. Первые и самые дикие убытки в Германии у государственных банков. Апатамучто там в руководстве люди, вообще с банковским делом не знакомые и образования соответствующего не имеющие.

> Ну да. Европейские фирмы под плохим менеджментом разоряются. Но страдают не менеджеры, а те, кто очень внизу. Речь не о том, кто страдает. Просто социальная база нонешнего менеджмента размывается. Это болезненный процесс, но он идет. ИТ сильно повышает производительность труда, одновременно при этом сокращается кол-во персонала. Однако, сокращение персонала сдерживается социальными факторами. Кризис, эти факторы отбрасывает прочь. Таким образом, роль менеджера рулящего людскими ресурсами сокращается, потребность в них падает. Роль конструктивного менеджмента, однако, при этом возрастает, я имею в виду менеджеров, которые понимают в технологиях, а не в маркетинге. Потому как технологии дают рост эффективности труда, а не массовый труд. Т.е. роль людей возрастает, но отдельных людей, а не массовой рабочей силы. > Абсолютно бездоказательное утверждение. Что думает по этому поводу КПК? КПК тут не при чем. Надо понимать что общество не может и не хочет расти вечно. Ибо для этого надо тратить много ресурсов. Можно расти когда ты бедный, но по мере того как экономика выравнивается с ведущими, потребность в экономическом росте замедляется, появляются другие интересы. Например, хочется жить в чистом месте, а не в смоге. И работать не 16 часов, а 8. > Опять же. За плохой менеджмент надо было давать под зад коленом, а не пересаживать на госдолжность. Первые и самые дикие убытки в Германии у государственных банков. Апатамучто там в руководстве люди, вообще с банковским делом не знакомые и образования соответствующего не имеющие. Менеджер вознаграждается за текущие показатели. Даже если он очень умный и все понимает, он не может идти против системы - его выгонят с волчьим билетом. Поэтому они и наращивали текущие прибыли, игнорируя долгосрочные риски. Одна из причин такого поведения - существовавшая практика выплаты бонусов менеджерам. А бюджет бонусов крупного инвестбанка сравним с бюджетом Москвы - десятки млрд долларов. Теперь гос-во поставило это под контроль.

ИТ сильно повышает производительность труда, одновременно при этом сокращается кол-во персонала. IT как и другие технологии сами по себе ничего не повышают. Вопрос в правильном применении. А у нас менеджеры, которые только картинки понимают. Принцип Дильберта никто не отменял. Т.е. роль людей возрастает, но отдельных людей, а не массовой рабочей силы. Это на каком глобусе происходит? Сейчас основная тенденция: берётся обезьяна, сертифицируется по PMG, PRINCE 2 или чему-то подобному и ставится на ПРОЦЕСС. Потом набирается сотня обезьян (лучше всего индийских или китайских, чтоб была офигенная экономия) и сажается в соответствующие клетки ПРОЦЕССА. После чего всё работает само собой. Потому что по науке. С другой стороны, если брать команду крутейших спецов и делать что-то на самом деле, роль человеческого фактора возрастает неимоверно. Потому как спецы обычно а) умные б) плохо управляемые. КПК тут не при чем. Вот когда и если её скинут, тогда и будет ни при чём. А пока именно она всё определяет. Даже если он очень умный и все понимает, он не может идти против системы - его выгонят с волчьим билетом. У меня в блоге целых два свежих письма менеджеров, посылающих на юх свои любимые фирмы. Из тех же A.I.G.ов и Фреддей народ только так сваливал. Поэтому они и наращивали текущие прибыли, игнорируя долгосрочные риски. Мы ушли в глубокий оффтопик, но нынешний американский пузырь создан не менеджерами, а государством при активном участии как центробанка, так и конгресса. Теперь гос-во поставило это под контроль. Советую посмотреть таблички источников бабла на избирательную компанию и ещё раз подумать кто, что и куда поставил.

> IT как и другие технологии сами по себе ничего не повышают. Вопрос в правильном применении. А у нас менеджеры, которые только картинки понимают. Принцип Дильберта никто не отменял. ИТ такие мощные, что они так или иначе все равно выливаются в рост производительности труда. Отдельные проекты могут проваливаться и даже делать это массово, но в общем и целом тенденция четкая - рост производительности труда от использования ИТ весьма заметный и устойчивый. Суммарно, автоматизация (сердцем которой является ИТ) дает рост в десятки раз. Я сам как-то нагенерил 8 Мб тестов и документации из 300 Кб исходного кода. Т.е. моя производительность труда как тестера выросла в 20-30 раз от применения автоматизации. Китайцы и индусы замучались бы меня догонять. И это при том, что я вносить изменения в код могу легким движением руки. А чтобы в индусье творение внести изменение, нужно новый проект организовывать. > Это на каком глобусе происходит? Везде. Просто это не массово пока, поэтому плохо видно на фоне описанного Вами. Дело в том, что есть сферы, куда сколько китайцев не сажай, и как их не пересаживай, а в музыканты они все равно не годятся. Я первый раз с индусьим кодом столкнулся лет 10 назад, мне его дали на сопровождение, и я не смог понять нафига он вообще нужен. Т.е. он был очень правильно оформлен, в соответствии со стандартами и все такое, но смысл в нем отсутствовал. Это была форма в чистом виде, без содержания. Соответственно, вопрос - какой экономический смысл нанимать индусов и китайцев, которые изготовляют такой продукт? Дело в том, что робот делает то же самое, только еще дешевле и менее геморройно. Конечно, сперва надо вложится в создание и развертывание автоматизированных систем. Но это все равно так или иначе делают. Т.е. на самом деле, все эти сертифицированные обезьяны играют не производительную роль, а социальную. Ведь автоматизация массово высвобождает рабочие места, и чтобы их как-то утилизировать, придумывают тупые процессы и сажают тупых обезьян. > С другой стороны, если брать команду крутейших спецов и делать что-то на самом деле, роль человеческого фактора возрастает неимоверно. Потому как спецы обычно а) умные б) плохо управляемые. Да это так. Но спецов много не надо, так как они на порядок производительнее обезьян. Более того, если не стремится к тупому наращиванию оборотов, то их надо уже на пару порядков меньше. А поскольку суммарно народу меньше, то взаимодействие между ними в конечном итоге выходит проще, ибо спецы как раз больше способны к самоорганизации. В силу этого они и являются менее управляемыми. А кризис как раз повод сбросить социальные обязательства, выгнать обезьян и снизить избыточное производство. > Вот когда и если её скинут, тогда и будет ни при чём. А пока именно она всё определяет. КПК не рулит долгосрочными объективными тенденциями, они не в ее власти. Пока КПК выглядит как вполне адекватно им следующая. Массовому недовольству сотен миллионов китайцев она не способна противостоять. И не думаю, что собирается. > Мы ушли в глубокий оффтопик, но нынешний американский пузырь создан не менеджерами, а государством при активном участии как центробанка, так и конгресса. Кризис спровоцировало гос-во, но система-то держится на менеджерах. Гос-во просто перестаралось, заставив ФРС выжимать из системы слишком много бабла. ФРС кстати сопротивлялся - Гринспен был против и его сместили. Бернанке тоже предупреждал о последствиях, но делал, что говорят. > Советую посмотреть таблички источников бабла на избирательную компанию и ещё раз подумать кто, что и куда поставил. Ну не менеджеры же Обаму выдвинули. Финансисты - да, но не менеджеры. Сложившаяся в Америке финансовая система угрожает(ла) стабильности доллара, что не в интересах американских финансистов. Да и даже если им пофиг до доллара, то все равно чистку финансовой системы проводить надо было. Потому как среди финансистов тоже есть два лагеря - старое условно "МБАшное" крыло и новое ИТшное, которые занимаются электронной торговлей и деривативами.

Я сам как-то нагенерил 8 Мб тестов и документации из 300 Кб исходного кода. Зачем? Соответственно, вопрос - какой экономический смысл нанимать индусов и китайцев, которые изготовляют такой продукт? Менеджер измеряется не количеством сделанного, а размером бюджета и поголовьем подчинённых. А поскольку суммарно народу меньше, то взаимодействие между ними в конечном итоге выходит проще, ибо спецы как раз больше способны к самоорганизации. Как правило, они организовываются в разные стороны. Мотивировать спецов делать то, что нужно, а не то, что они хотят, задача не из лёгких. Про Обаму и пр. как-нибудь в другой раз и в другом месте.

>> Я сам как-то нагенерил 8 Мб тестов и документации из 300 Кб исходного кода. > Зачем? Дык работа такая у меня была - тесты писать. Поскольку руками мне писать было лень, да я бы руками и не успел к сроку, то я код генерировал. Это было несложно. Кто-то руками писал. А так я за неделю протестировал то что обычно не знаю даже сколько времени занимает. Думаю минимум пару месяцев, но тормозной программер может и на полгода растянуть - я бы точно растянул, ибо скучно однообразный код писать. > Менеджер измеряется не количеством сделанного, а размером бюджета и поголовьем подчинённых. Вот-вот. Собственно, я хочу сказать, что после кризиса, эта парадигма менеджмента будет усыхать. Может медленно, будет трепыхаться, но постепенно будет уступать место более эффективным парадигмам.

Задача тестов - найти ошибки. Я сильно сомневаюсь, что куча мегабайт, нагенерённых из исходного кода, способна в этом помочь. А кризисы были, есть и будут. Менеджмент же не меняется. Ещё сам Сименс ругался на своих управляющих за то же самое, за что сейчас их все ругают.

> Задача тестов - найти ошибки. Я сильно сомневаюсь, что куча мегабайт, нагенерённых из исходного кода, способна в этом помочь. Зависит от целей. В моем случае, цель была вообще не поиск ощибок, а сертификация :). Вообще говоря, чем больше тестов тем лучше. Тут имеет значение лишь наличие ресурсов, которые можно/нужно выделить на тестирование. В моем случае, мегабайты - это были вообще крохи, ибо проект в котором я учавствовал, был самым большим софтовым проектом в мире на то время, да и сейчас думаю тоже (по объему кода по крайней мере). Это было проект по тестирования Java - Java Comaptibility Kit, его гоняют, чтобы просертифицировать того, кто делает альтернативную реализацию Джавы. Я конечно немного перестарался, потому что мои тесты работали слишком долго - около получаса. При том что полный прогон длился несколько суток. Поэтому я немного тесты подрезал, но сам код вряд ли сократился, просто переменные циклов поменьше стали. Это я к тому, что если бы я циклы развернул, то там даже и не 5 метров кода было бы, а хрен знает сколько, и они бы в Джава машину бы уже не влезли. Но! Все равно это было поверхностное тестирование. Грубо говоря, мы какие-то баги находили, но которые лежали более-менее на поверхности. Поиском багов занимались отдельные люди. Просто в Джаве на тот момент было пара тысяч классов (публичных) в каждом десяток методов, у каждого несколько параметров. У каждого параметра несколько значений, даже просто перебрать это все хотя бы по разу и проверить результат, уже куча кода получается. И на самом деле то чем я занимался - это детский лепет. Потому как есть такая компания Боинг, Анатолий Левенчук писал в этом блоге, что она уже софтовая компания, ибо 50% ресурсов уходит на верификацию авионики. Дык вот у них там один тестовый сценарий может несколько мегабайт занимать. Я просто на досуге играюсь с верификацией софта. И там нагенерить пару мегов, это обычное дело. Т.е. чтобы одно утверждение проверифицировать, генерируется файл на несколько мегов, его суешь на вход верификационой системы, а верификционных систем может быть несколько. Ну и на каждый метод, несколько утверждений и т.д. и т.п. Но для авионики это необходимо, иначе самолетик может упасть в ненужный момент. > А кризисы были, есть и будут. Менеджмент же не меняется. Ещё сам Сименс ругался на своих управляющих за то же самое, за что сейчас их все ругают. Да это все так. Это есть свойство больших групп. Однако, происходит изменение в метастратегии, т.е. раньше большие батальоны хоть и безмерно тупые, но они массой заваливали. А сейчас, массы уже все чаще и чаще не хватает, потому как и спрос на массу на самом деле раздутый. Поэтому большие батальоны, а с ними и менеджеры будут потихоньку сливаться, придет время профессионалов. Это тот же процесс что и с армиями, вопрос соотношения мобилизационного потенциала и потенциала уничтожения. Рано или поздно появится гений, который сгенерирует операционную систему типа Винды в одиночку. Естественно, используя существующие наработки и код. Просто возьмет к примеру, Линуксовые драйвера и перегенерирует под свои цели. Возьмет Виндовый код запарсит автоматически, сгенерирует к примеру по нему тесты для Вин АПИ. Ну и нагенерирует код, который эти тесты проходит используя Линуксовые открытые драйвера. И он будет выглядеть и работать как Винда в 95% случаев.

> Задача тестов - найти ошибки. Я сильно сомневаюсь, что куча мегабайт, нагенерённых из исходного кода, способна в этом помочь. Вообще, бОльшая часть издержек при создании софта, это как раз тестирование. Обычно от 50-60% до 80% (аэрокосмос) ресурсов уходит на тестирование. Т.е. на самом деле развитие софтовых продуктов задается методологией тестирования - я имею в виду конечно не только тестеров, но и тестирование которое выполняет девелопемент, анализ требований/спецификаций. Грубо говоря, накодировать можно что угодно, вопрос как убедится, что это то, что требуется? Неэффективно организованное тестирование способно сильно подвинуться сроки релиза и это еще не самый худший вариант, ибо релизить отстой может оказаться накладно по последствиям. Так что нагенерить мегабайты, а то и сотни мегабайт кода зачастую очень полезная на практике инвестиция (к тому же она стоит относительно дешево). ХРшники говорят что они пишут тестов в несколько раз больше кода и это хорошо, потому как баги отлавливаются на ранних этапах. Вобщем я хочу сказать, что тестировать это хорошо, даже если новые баги не обнаруживаются. Потому как эффективная методология тестирования позволяет сократить цикл разработки софта в несколько раз, а неэффективная - увеличить соответственно. Это даже при том, что кол-во найденных на этапе тестирования багов может уменьшиться - собственно, поскольку каждый найденный баг требует существенных ресурса на его обработку (воспроизведение, анализ, исправление, анализ последствий, повторное тестирование), то это и есть важный фактор сокращения сроков.

Вобщем я хочу сказать, что тестировать это хорошо, даже если новые баги не обнаруживаются. :-)

В моем случае, цель была вообще не поиск ощибок, а сертификация Как правило, люди зарубающиеся на автоматическое тестирование, пропускают целые классы очень интересных ошибок. К Яве это тоже относится. Про авиацию не знаю, но "верификация" в других критических областях выглядит достаточно смешно. Судя по тому, что было слышно про обычных инженеров в Аэрбусе, насчёт авиации тоже иллюзий не питаю.

> Как правило, люди зарубающиеся на автоматическое тестирование, пропускают целые классы очень интересных ошибок. Да конечно, тут есть свои ограничения. Но мы сознательно фокусировались на своей задаче, а другими проблемами занимались другие люди. Разделение труда и все такое. Я когда занимался вопросами создания QA системы, дык вообще всем говорил, что для эффективного тестирования надо работать на нескольких уровнях: девелопмент (юнит) тестинг, КуА тестирование, системеное, перформанс и т.д. У меня в группе минимум три вида тестирования было, и еще были тестеры в других регионах. И еще мы девелопмент заставляли тесты писать. > Про авиацию не знаю, но "верификация" в других критических областях выглядит достаточно смешно. Судя по тому, что было слышно про обычных инженеров в Аэрбусе, насчёт авиации тоже иллюзий не питаю. Смешно потому что затраты на верификацию пока еще очень высоки, ну и результата который можно было бы пощупать руками нет. И там чего-то делает реально несколько человек, а остальные фигней страдают, потому что не понимают просто что к чему.

> Про авиацию не знаю, но "верификация" в других критических областях выглядит достаточно смешно. Взглянул на это дело со стороны. Действительно, выглядит очень комично: какие-то люди потратили кучу времени и ресурсов, и заявляют что они типа как проверифицировали вообще-то только часть функциональности (зато наиболее важную) и с некоторыми ограничениями, при этом нашли только какие-то хитрожопые баги, про которые трудно вообще вообразить что они могут возникнуть в действительности. Ну и еще обнаружили какие-то принципиальные проблемы, которые возникли настолько давно, что теперь уже никто не будет их решать, потому что надо переделывать весь проект, а на это никто не пойдет. Т.е. как бы выхлопа-то от них никакого практического нет, а что они делали - непонятно. Шаманы какие-то. Вобщем-то необходимость в такой деятельности созревает постепенно. К примеру, выпустила Интел или АМД проц с ошибкой, а обнаружили это поздно, и это обернулось для них полной задницей, потому как им стали возвращать кучи процов и требовать новых. И пиар плохой и убытки. Теперь они очень осторожно новые процы выпускают. Сан вот отложила свой Rock на год, чтобы его дополнительно потестировать. А ведь за год ситуация на рынке процессоров может поменяться кардинально, т.е. их проц может оказаться уже неактуальным попросту.