This post if the first from series of posts where I will write my translations of Vector (Journal of British APL Association) articles (in Russian).
От редакции: повторное использование кода по максимуму (Джонатан Бармен)
Повторное использование кода выглядит просто, особенно учитывая то множество вспомогательных функций, которое мы копируем в свой CLEAR WS, перед началом разработки новой системы. Однако, получить максимальную выгоду от повторного использования довольно сложно, это требует непростой проектировочной работы. На последнем собрании Адриан Смит рассказал о технологии, которая помогла ему писать только 20% кода для каждой новой системы. Он применил аналогию с постройкой здания из кирпичей с помощью последовательных «кладок».
Нижняя «кладка» проста -- большая часть кода, публикуемого в журнале Vector относится к этой категории. Обеспечение переносимости между разными версиями APL также помогает в определении функций. Каждый разработчик APL системы имеет свое представление о том, как стоит решать распространенные задачи и каждый программист может использовать особенности конкретной реализации. В реальности, действительно важно иметь набор основных кирпичиков, которые не зависят от различий интерпретаторов APL.
Следующим шагом Адриан определил среднюю «кладку» функций, использующих распространенные интерфейсы, такие как SQL и PostScript в качестве базиса для написания высокоуровневого кода, который может быть повторно использован во многих случаях. Проектирование на этом уровне становится гораздо сложнее, и использование существующих идей, знакомых большой аудитории, это хорошая идея.
Определение областей, которые могут содержать некий общий код это самая сложная задача. Проблемы растут в геометрической прогрессии, когда мы имеем дело с большой системой, созданной слаженной командой проектировщиков и программистов. Чтобы члены команды могли грамотно определить общие процессы, протекающие в системе, необходим четкий и ясный способ выражения проектировочных идей.
Одно из решений, которое в последнее время становится популярным -- это объектно-ориентированный анализ (ООА). В наши дни все стало можно называть объектно-ориентированным, поэтому неудивительно, что эту характеристику имеет и один из видов анализа. ООА похож на анализ сущностей, в том плане, что он позволяет описывать отношения между данными и процессами, которые манипулируют этими данными. Основные идеи этого анализа существовали уже долгое время, а ярлык «объектно-ориентированный» был приклеен сравнительно недавно.
ООА не нужно путать с объектно-ориентированным проектированием или объектно-ориентированными языками или объектно-ориентированным чем-то еще. При поверхностном взгляде ООА выглядит интуитивно понятным и довольно простым в использовании.
Нет никаких проблем в использовании ООА для анализа систем, написанных на APL, поскольку он не зависит от какого-то конкретного языка программирования. Я видел несколько реализаций APL, которым небольшое формальное проектирование перед началом собственно кодирования приносило весьма большую пользу. Прототипирование хорошо по-своему, но оно может стать своего рода оправданием тем, кто ленится проводить хоть какое-нибудь проектирование. Некоторый формальный анализ ситуации позволяет извлечь выгоду из выявления тех деталей, которые действительно важны и необходимы. Одним из главных преимуществ ООА является то, что четко определен уровень, до которого он должен проводиться, поэтому ни у кого не должно возникнуть искушения проводить перепроектирование до тех пор, пока система не станет совершенной.
ООА может применяться на довольно низком уровне, так что не будет никаких сложностей в нахождении каждой элементарной функции APL, которая необходима для системы. Однако, в некоторых источниках говорится, что связь между конечным результатом анализа и реализацией слишком расплывчата. Возможно, это цена за то, что метод анализа не зависит от применяемого языка программирования.
Тем, кто еще не знаком с методами системного анализа, я бы порекомендовал обратить свой взгляд в сторону ООА и самостоятельно определить, может ли он помочь в уменьшении времени, необходимого для разработки программных систем. APL быстр, но с хорошей методологией проектирования и максимальным повторным использованием кода он может летать на космических скоростях!
От редакции: повторное использование кода по максимуму (Джонатан Бармен)
Повторное использование кода выглядит просто, особенно учитывая то множество вспомогательных функций, которое мы копируем в свой CLEAR WS, перед началом разработки новой системы. Однако, получить максимальную выгоду от повторного использования довольно сложно, это требует непростой проектировочной работы. На последнем собрании Адриан Смит рассказал о технологии, которая помогла ему писать только 20% кода для каждой новой системы. Он применил аналогию с постройкой здания из кирпичей с помощью последовательных «кладок».
Нижняя «кладка» проста -- большая часть кода, публикуемого в журнале Vector относится к этой категории. Обеспечение переносимости между разными версиями APL также помогает в определении функций. Каждый разработчик APL системы имеет свое представление о том, как стоит решать распространенные задачи и каждый программист может использовать особенности конкретной реализации. В реальности, действительно важно иметь набор основных кирпичиков, которые не зависят от различий интерпретаторов APL.
Следующим шагом Адриан определил среднюю «кладку» функций, использующих распространенные интерфейсы, такие как SQL и PostScript в качестве базиса для написания высокоуровневого кода, который может быть повторно использован во многих случаях. Проектирование на этом уровне становится гораздо сложнее, и использование существующих идей, знакомых большой аудитории, это хорошая идея.
Определение областей, которые могут содержать некий общий код это самая сложная задача. Проблемы растут в геометрической прогрессии, когда мы имеем дело с большой системой, созданной слаженной командой проектировщиков и программистов. Чтобы члены команды могли грамотно определить общие процессы, протекающие в системе, необходим четкий и ясный способ выражения проектировочных идей.
Одно из решений, которое в последнее время становится популярным -- это объектно-ориентированный анализ (ООА). В наши дни все стало можно называть объектно-ориентированным, поэтому неудивительно, что эту характеристику имеет и один из видов анализа. ООА похож на анализ сущностей, в том плане, что он позволяет описывать отношения между данными и процессами, которые манипулируют этими данными. Основные идеи этого анализа существовали уже долгое время, а ярлык «объектно-ориентированный» был приклеен сравнительно недавно.
ООА не нужно путать с объектно-ориентированным проектированием или объектно-ориентированными языками или объектно-ориентированным чем-то еще. При поверхностном взгляде ООА выглядит интуитивно понятным и довольно простым в использовании.
Нет никаких проблем в использовании ООА для анализа систем, написанных на APL, поскольку он не зависит от какого-то конкретного языка программирования. Я видел несколько реализаций APL, которым небольшое формальное проектирование перед началом собственно кодирования приносило весьма большую пользу. Прототипирование хорошо по-своему, но оно может стать своего рода оправданием тем, кто ленится проводить хоть какое-нибудь проектирование. Некоторый формальный анализ ситуации позволяет извлечь выгоду из выявления тех деталей, которые действительно важны и необходимы. Одним из главных преимуществ ООА является то, что четко определен уровень, до которого он должен проводиться, поэтому ни у кого не должно возникнуть искушения проводить перепроектирование до тех пор, пока система не станет совершенной.
ООА может применяться на довольно низком уровне, так что не будет никаких сложностей в нахождении каждой элементарной функции APL, которая необходима для системы. Однако, в некоторых источниках говорится, что связь между конечным результатом анализа и реализацией слишком расплывчата. Возможно, это цена за то, что метод анализа не зависит от применяемого языка программирования.
Тем, кто еще не знаком с методами системного анализа, я бы порекомендовал обратить свой взгляд в сторону ООА и самостоятельно определить, может ли он помочь в уменьшении времени, необходимого для разработки программных систем. APL быстр, но с хорошей методологией проектирования и максимальным повторным использованием кода он может летать на космических скоростях!
Комментариев нет:
Отправить комментарий