Здравствуйте, VladD2, Вы писали:
A>>А еще есть обезьянья работа по переводу спецификаций и требований в код. Написание документации. И проч.
VD>А вот это как раз автоматизировать можно. Нужно формализовать спецификации. Придумать для них ДСЛ (возможно не один). Написать генераторы кода которые превратят спеки в рабочий код.
Забыл глумиться. Сори.
Для вас скорее всего это такой рокет-сайнс, что вы даже не считаете это реальным. Но это более чем реально, если не упираться рогом в ООП или ФП.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>А вот это как раз автоматизировать можно. Нужно формализовать спецификации. Придумать для них ДСЛ (возможно не один). Написать генераторы кода которые превратят спеки в рабочий код. VD>Структуру документации тоже таким образом можно создать. Саму документацию придется писать вручную (ИИ пока нет). Но это опять же не обязьянья работа. И опять работа не для программиста, а для тех.писателя.
вот мне интересно, а как ты себе это представляешь?
все спецификации с которыми мне доводилось работать выглядели примерно так: значение в третьем столбце таблицы должно вычислятся по формуле .. и дальше математическая выкладка на полстраницы.
вот как к примеру ты формализовал бы эту спецификацию, чтобы избавится от рутины?
Здравствуйте, genre, Вы писали:
G>вот мне интересно, а как ты себе это представляешь?
G>все спецификации с которыми мне доводилось работать выглядели примерно так: значение в третьем столбце таблицы должно вычислятся по формуле .. и дальше математическая выкладка на полстраницы.
G>вот как к примеру ты формализовал бы эту спецификацию, чтобы избавится от рутины?
Любому полю всегда можно дать краткое и развернутое описание. Если заставлять их заполнять и контролировать их качество, то вполне можно будет генерировать краткую справку.
В общем, конечно нужно смотреть по обстоятельством. Но пытаться автоматизировать нужно. Все стремится к хаосу (т.е. бардаку), а бардак автоматизировать нельзя (с). Так что нужно бороться с хаосом как получается. Формальные спецификации один из видов такой борьбы. Некоторые задачи можно полностью описать формальными спецификациями. Классический пример — парсеры ЯП. Грамматика — это и есть формальная спецификация.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Любому полю всегда можно дать краткое и развернутое описание. Если заставлять их заполнять и контролировать их качество, то вполне можно будет генерировать краткую справку.
не понял, а при чем тут справка?
VD>В общем, конечно нужно смотреть по обстоятельством. Но пытаться автоматизировать нужно. Все стремится к хаосу (т.е. бардаку), а бардак автоматизировать нельзя (с). Так что нужно бороться с хаосом как получается. Формальные спецификации один из видов такой борьбы. Некоторые задачи можно полностью описать формальными спецификациями. Классический пример — парсеры ЯП. Грамматика — это и есть формальная спецификация.
Ага, то есть переложим рутину на плечи аналитиков? ведь запись требований на формальном языке это и есть программирование
кроме того вызывает серьезные сомнения экономическая эффективность такого подхода.
Здравствуйте, genre, Вы писали:
G>не понял, а при чем тут справка?
Подставь нужный термин.
VD>>В общем, конечно нужно смотреть по обстоятельством. Но пытаться автоматизировать нужно. Все стремится к хаосу (т.е. бардаку), а бардак автоматизировать нельзя (с). Так что нужно бороться с хаосом как получается. Формальные спецификации один из видов такой борьбы. Некоторые задачи можно полностью описать формальными спецификациями. Классический пример — парсеры ЯП. Грамматика — это и есть формальная спецификация.
G>Ага, то есть переложим рутину на плечи аналитиков? ведь запись требований на формальном языке это и есть программирование
Ну, да. Это и есть программирование. Разница только в уровне кода. Если ты будешь долбить его на явах, сишарпах и прочей вижулбясите, то аналитик поглядит на это минут пять и пойдет заниматься чем-то другим.
Если же ты создашь для своего аналитика формальный, но высокоуровневый, язык, который будет оперировать понятиями предметной области, а не классами или функциями, то толковый аналитик сможет включиться в процесс программирования. Возможно, не один, а вместе с тобой, как экспертом в области программирования.
G>кроме того вызывает серьезные сомнения экономическая эффективность такого подхода.
А ты подумай. У тебя исчезает целый не формализованный слой. Код становится декларативным и высокоуровневым.
Единственная проблема этого подхода — нужно реализовать поддержку этого ДСЛ-я. Нужен компилятор и (желательно) поддержка в IDE. И тут становится очевидна другая проблема. Современные мэйнстрим-инструменты на это не рассчитаны. Поддержка ДСЛ-я средствами ООЯ или даже ФЯ — это слишком сложная задача. Так что если ты не видишь жизни за пределами мэйнстрима, то этот подход не для тебя.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, genre, Вы писали:
G>Здравствуйте, VladD2, Вы писали:
VD>>А вот это как раз автоматизировать можно. Нужно формализовать спецификации. Придумать для них ДСЛ (возможно не один). Написать генераторы кода которые превратят спеки в рабочий код. VD>>Структуру документации тоже таким образом можно создать. Саму документацию придется писать вручную (ИИ пока нет). Но это опять же не обязьянья работа. И опять работа не для программиста, а для тех.писателя.
G>вот мне интересно, а как ты себе это представляешь?
Здравствуйте, VladD2, Вы писали:
VD>Если же ты создашь для своего аналитика формальный, но высокоуровневый, язык, который будет оперировать понятиями предметной области, а не классами или функциями, то толковый аналитик сможет включиться в процесс программирования. Возможно, не один, а вместе с тобой, как экспертом в области программирования.
Что-то есть у меня сомнения по этому поводу и очень серьезные. Нет, звучит все крайне привлекательно, но в реальной жизни мне кажется это применимо к крайне узкому кругу задач.
Как это можно применить к например написанию какой-нибудь трехзвенной платформы, с сервером, бд и толстым клиентом я не очень понимаю.
Или даже проще. Допустим мы пишем почтовый клиент. Или даже просто простой текстовый редактор. Что тут можно описать адекватным дслем?
G>>кроме того вызывает серьезные сомнения экономическая эффективность такого подхода.
VD>А ты подумай. У тебя исчезает целый не формализованный слой. Код становится декларативным и высокоуровневым.
Ну вот например в тех областях с которыми мне доводилось работать предметная область настолько объемна, что затраты на создание подобного дсл выглядят сравнимыми с затратами на написание собственно кода.
Ну и куча сопутствующих проблем, например где найти аналитика, который не только эксперт в предметной области, но и готов учится писать на этом дсл?
VD>Единственная проблема этого подхода — нужно реализовать поддержку этого ДСЛ-я. Нужен компилятор и (желательно) поддержка в IDE. И тут становится очевидна другая проблема. Современные мэйнстрим-инструменты на это не рассчитаны. Поддержка ДСЛ-я средствами ООЯ или даже ФЯ — это слишком сложная задача. Так что если ты не видишь жизни за пределами мэйнстрима, то этот подход не для тебя
Ну для большинства коммерческих продуктов жизни за пределами мейнстрима действительно нет.
Здравствуйте, Abyx, Вы писали:
VD>>>А вот это как раз автоматизировать можно. Нужно формализовать спецификации. Придумать для них ДСЛ (возможно не один). Написать генераторы кода которые превратят спеки в рабочий код. VD>>>Структуру документации тоже таким образом можно создать. Саму документацию придется писать вручную (ИИ пока нет). Но это опять же не обязьянья работа. И опять работа не для программиста, а для тех.писателя.
G>>вот мне интересно, а как ты себе это представляешь?
A>есть же FitNesse, Cucumber
что-то я не могу найти на их сайтах внятного описания о том как оно работает для написания кода, а не для его тестирования.
Здравствуйте, genre, Вы писали:
G>Здравствуйте, Abyx, Вы писали:
VD>>>>А вот это как раз автоматизировать можно. Нужно формализовать спецификации. Придумать для них ДСЛ (возможно не один). Написать генераторы кода которые превратят спеки в рабочий код. VD>>>>Структуру документации тоже таким образом можно создать. Саму документацию придется писать вручную (ИИ пока нет). Но это опять же не обязьянья работа. И опять работа не для программиста, а для тех.писателя.
G>>>вот мне интересно, а как ты себе это представляешь?
A>>есть же FitNesse, Cucumber
G>что-то я не могу найти на их сайтах внятного описания о том как оно работает для написания кода, а не для его тестирования.
так же как и другие test-first техники. пишите тест, и он помогает во время написания кода
VD>>>>>А вот это как раз автоматизировать можно. Нужно формализовать спецификации. Придумать для них ДСЛ (возможно не один). Написать генераторы кода которые превратят спеки в рабочий код. VD>>>>>Структуру документации тоже таким образом можно создать. Саму документацию придется писать вручную (ИИ пока нет). Но это опять же не обязьянья работа. И опять работа не для программиста, а для тех.писателя.
G>>>>вот мне интересно, а как ты себе это представляешь? A>>>есть же FitNesse, Cucumber
G>>что-то я не могу найти на их сайтах внятного описания о том как оно работает для написания кода, а не для его тестирования. A>так же как и другие test-first техники. пишите тест, и он помогает во время написания кода
