소프트웨어 재사용이 프로세스 반복성을 배제합니까?

문제 로 코드 재사용

나는 소프트웨어 전달에 관한 이 질문 에 대해 생각하고 있었고 반복성 및 / 또는 재현성 문제로 계속 돌아왔다 . 프로젝트를 반복하지 않으면 프로젝트를 빌드하는 데 사용했던 프로세스를 개선하기가 더 어려워지기 때문에 문제가됩니다. 엔지니어링에는 고품질 프로젝트를 생성하기 위해 설계 및 시공과 관련된 프로세스를 지속적으로 개선하는 것이 포함됩니다.

소프트웨어는 디지털 형식으로 인해 재사용에 크게 의존 할 수 있습니다. 모듈을 다시 작성하는 대신 모듈을 다시 호출하거나 다른 시스템에 복사하면됩니다. 몇 가지 예는 인증 / 로그인 또는 로깅 기능입니다. 이러한 범주에 대해 잘 알려진 예가 많이 있으며, 기존의 지혜 는 자신을 굴리는 대신 존재하는 것을 재사용하는 것입니다.

다른 분야와의 일부 비교

구성

대조적으로, 물리적 시스템 (건물, 교량)의 건설은 재사용 할 수있는 곳이 거의 없습니다. 집의 청사진을 여러 번 재사용하여 집의 동일한 사본을 만들 수는 있지만 매번 건축을 수행해야합니다. 아날로그 세계에서는 잘라 내기 및 붙여 넣기가 작동하지 않습니다. 교량 설계도는 현장 조건이 다양하기 때문에 주택에 비해 재사용 성이 떨어집니다.

마스터 빌더는 해당 지역에서 수십, 수백 또는 수천 개의 물건을 설계 및 / 또는 구축 한 것으로 인정되는 전문가입니다. 예를 들어, 세계적으로 유명한 건축가이자 디자이너 인 Frank Lloyd Wright 가 있습니다 designed more than 1,000 structures and completed 532 works. 5 개의 언어 (Turbo Pascal; Delphi; J ++; C #; Typescript)를 설계 한 Anders Hejlsberg와는 대조적입니다 . 여러면에서 도메인이 다르기 때문에 불공평 한 비교입니다. 그러나 넓은 차원에서, 두 명의 매우 똑똑한 사람들의 수량화 가능한 생산은 크게 다릅니다.

무술

무술가들은 움직임의 숙달은 수천 번의 반복에서 비롯된 것이라고 말합니다. 이러한 반복의 상당 부분이 들어간 후, 많은 무술가들은 이전에 복잡한 카타나 형태로 인식 된 방식이 단순 해졌다는 것에 놀랐습니다. 또한이 학생들의 강사는 모션이 유동적이고 목적이 있고 모션 경제가 어떻게 이루어지는 지 알 수 있습니다. 마찬가지로, 숙련 된 무술가는 경험이 적은 학생들보다 더 복잡한 카타를 더 빨리 선택할 수 있습니다. 반복 경험으로 인해 더 빨리 배울 수있는 프레임 워크 또는 프로세스가 제공되었습니다.

목공

목 공자들도 비슷한 변화를 경험합니다. 취미 목공은 항상 많은 서랍이 필요한 첫 번째 프로젝트를 다시 언급합니다. 그들이 프로젝트를 완료하면 조립 라인이 생산하는 효율성에 대한 새로운 인식을 얻게됩니다. 목재 사용을 극대화하기 위해 시트 스톡에 서랍 부품을 배치하는 방법에 대한 이해와 같은 다른 이점도 있습니다. 전문 목공업자는 애호가와 비교하여 이전에 여러 번 제작 한 아이템을보다 빠르게 설계, 시작 및 구성 할 수 있습니다. 또한 다른 사람의 설계 내에서 자신의 작업에서 실수를 저지른 고유의 문제를 볼 수 있습니다.

그렇다면 소프트웨어 재사용이 소프트웨어 개발자의 숙달을 방해 하는가?

여러면에서 소프트웨어 설계 및 구성은 항상 새로운 것입니다. 모듈, 라이브러리 또는 시스템을 재사용 할 수 있다면 우리는 과거의 작업을 반복하지 않습니다. 전체 내용 을 처음부터 다시 작성하기 전에 기존 시스템을 우선적으로 확장합니다 . 그러나 반복은 디자인과 시공에서 효율성을 찾을 수있게 해줍니다. 운동이나 신체 활동을 한 사람은 반복이 좋은 개업의가되는 열쇠라고 말할 것입니다.

내 질문 : 소프트웨어를 재사용 할 수있는 능력이 프로젝트를 반복함으로써 발생하는 프로세스 개선 및 효율성을 방해합니까?

소프트웨어 재사용 기능이 프로세스 개선을 방해하지는 않습니다.

요구 사항 개발, 시스템 설계, 시스템 구현, 시스템 배치, 요구 사항 관리, 구성 관리, 작업 제품 검증 및 유효성 검증, 변경 사항 추적 및 기타 여러 가지 소프트웨어 빌드 프로세스에 대해 생각하는 경우 ( 소프트웨어 개발에서 주요 활동을 분석 할 수있는 CMMI 프로세스 영역 )-재사용 횟수에 관계없이 모든 프로젝트에서 반복됩니다. 또한 각 프로세스에는 특정 프로세스 나 활동이 얼마나 좋은지, 결과적으로 개발 프로세스 전체가 얼마나 좋은지를 결정하는 데 사용할 수있는 일종의 정량적 및 정 성적 조치가 있습니다.

극단적 인 측면에서 우리는 강력한 소프트웨어 제품 라인을 가정 할 수 있습니다. 다른 한편으로는, 그린 필드 개발을 가정 할 수 있습니다. 비록 다른 속도로 또는 심지어 다른 순서로 발생할 수 있지만, 이러한 모든 프로세스를 다양한 정도로 수행 할 필요가 여전히있다. 예를 들어, 많은 양의 재사용에서 시스템 수준 (요구 사항 V & V, 통합 테스트, 시스템 테스트, 승인 테스트)에서 통합 및 검증 / 검증 활동에 할당 된 시간의 더 많은 시간이 소비 될 수 있습니다. 새로운 개발 노력으로 설계 및 구현에 더 많은 시간이 필요할 수 있습니다. 프로젝트 진행 중 프로세스를 한 번 이상 수행하는 한 (정량 및 정 성적으로) 측정 할 수 있습니다. 조정을 수행 한 후 해당 조정이 프로세스 영역 또는 소프트웨어를 제공하는 전체 기능에 어느 정도 영향을 미치는지 확인하면,

프로세스 개선의 핵심은 활동 및 프로세스를 논리적으로 분류하고이를 측정하는 방법 (바람직하게는 일관되게)을 결정하고 이러한 측정을 이해하여 프로세스를 어느 정도 끝까지 변경하는 것입니다. 프로젝트를 반복하는 것이 아니라 프로세스를 반복하는 방식의 일관성에 관한 것입니다.

다른 공학 분야에서는 재사용을 사용하지 않는다는 생각이 잘못되었다고 생각합니다. 건물 / 기계를 설계 할 때도 여전히 많은 다른 프로젝트에서 사용하는 구성 요소가 있습니다. 예를 들어, 나만의 나사를 설계합니까? 엔진? 문이나 창문? 당연히 아니지. 그것들은 종종 다른 사람들이 디자인 한 다음 다른 제품에서 사용합니다. 그리고 그들은 종종 표준화되어 훨씬 더 많은 재사용을 촉진합니다.

나는 문제가 복잡성을 좋아한다고 생각한다. 가장 복잡한 건물의 복잡성을 복잡한 소프트웨어와 비교할 수는 없습니다. 소프트웨어의 복잡성이 엔지니어링 측면에서 접근하기 어렵게한다는 것이 일반적으로 통용되는 아이디어입니다. 수용 가능한 품질의 소프트웨어를 생성 할 수있는 프로세스가 진행되는 순간, 생성해야하는 소프트웨어의 복잡성이 규모에 따라 크게 증가합니다. 따라서 프로세스를 사용할 수 없습니다. 따라서 결과에 만족할 때까지 소프트웨어의 일부를 여러 번 반복해야한다면 해당 소프트웨어를 완성하지 못할 것입니다.

그래서 깨끗한 코드가 승격됩니다. 새로운 경험을 바탕으로 과거 코드를 변경하는 기능은 디자인 재사용의 형태라고 할 수 있습니다. 따라서 서로 다른 소프트웨어를 여러 번 만드는 대신 새로운 경험을 재사용하고 오래된 문제에 대한 디자인을 통해 단일 소프트웨어를 리팩토링하고 개선합니다. 소프트웨어를 똑같이하려고 노력하는 동안.

소프트웨어 는 대부분의 다른 분야와 다르므로 시간을 가장 잘 보내는 장소의 경제학은 종종 다릅니다.

건설 과정에서 청사진에 일정 시간과 돈을 소비하고 소프트웨어는 건물을 만드는 것보다 청사진을 만드는 것과 훨씬 비슷합니다. 따라서 청사진을 올바르게 만드는 데 많은 노력을 기울일 가치가 있습니다. 더 구체적으로 귀하의 질문에-최종 제품을 조금 더 좋게 만들기 위해 처음부터 끝까지 노력을 반복하는 것이 좋습니다.

소프트웨어에서 청사진을 사용하면 청사진을 만드는 것보다 제품을 만드는 것이 훨씬 저렴합니다. 적어도 대부분의 시간-소프트웨어가 맥박 조정기에 내장되어 있다면 브리지 빌더의 상황에 훨씬 더 가깝습니다. 그러나 일반적으로 소프트웨어를 재사용하면 가장 큰 예산 항목 비용의 90 %를 절약 할 수 있으며, 교량 건설을 위해 훨씬 작은 예산 항목의 90 %를 절약 할 수 있습니다. 따라서 재사용이 더 자주 이깁니다.

생산성과 관련하여 다리를 만들 때 실제로 중요한 제약 조건에 직면하게됩니다. 건축 비용이 0에 가까우며 실제 세계보다 제한이 적은 대규모 멀티 플레이어 온라인 게임을위한 교량을 설계하기 위해 건축가에게 많은 돈을 지불했다고 상상해보십시오. 그들은 실제 교량 표준에 의해 엄청나게 복잡한 교량을 설계 할 것입니다. 청사진 단계가 약간 더 오래 걸릴 수 있습니다.

또한, 건설해야 할 교량의 수가 제한되어 있으며, 디자인은 비용의 작은 부분이기 때문에 최고를 지불 할 수 있으며, 최고 중 일부는 대부분의 설계를 수행 할 수 있습니다. 수십만 명의 소프트웨어 개발자가 있으며 기본적으로 모두 시간이 있으면 할 일에 대한 거대한 백 로그가 있습니다. 당신은 그 모든 것의 많은 부분을 수행하는 한 사람을 찾지 못할 것입니다. 정말 가까운 사람들이 있다는 것은 놀라운 일입니다.

당신의 진짜 요점은 우리가 일을 반복하고 개선하는 대신에 재사용함으로써 무언가를 잃을 수도 있다는 것 같습니다. 나는 당신이 요점을 가지고 있다고 생각합니다. 문제는 기초적인 것들 중 일부를 다시 작성하고 개선하려고 노력하는 것이 전 세계적으로 더 효율적일 것이지만, 그 위험을 감수하는 사람은 모든 위험을 감수하고 아마도 그다지 많은 보상을받지 못한다는 것입니다. (종속성 지옥에 대한 실질적인 문제도있다.이 문제는 아마도 재 작문에서 약간의 승리를 거둘 것이지만, 적어도 세계적인 그림을 보면 가치가 없다는 점까지는 아니다. 저작권과 특허 또한 제안 된 재 엔지니어링 노력으로 인해 기존 코드의 작은 조각을 다시 작성하기 위해 약간의 재 작성 작업이 중단되었습니다.

반복을 통한 학습 측면에서 볼 때, 모든 분야에서 건설보다 설계 가 덜 발생합니다. 반복 횟수 가 적고 학습 기회가 적고 혜택이 적기 때문입니다. 또한 디자인 프로세스 는 그다지 반복되지 않을 것입니다. 소설을 쓰는 과정을 밟는 것과 비슷합니다. 좋은 프로세스는 거의 확실하게 도움이 될 수 있으며 소프트웨어는 일반적으로 소설보다 훨씬 더 협력 적이지만 목표가 새로운 것을 발명 할 때 프로세스를 반복하는 것은 문제가됩니다. 소설가들조차도 과거로부터 많은 것을 배우지 만, 반복 가능한 과정은 창조적 노력의 이차적 요인입니다. 그리고 소프트웨어 개발의 일부가 실제로 반복 가능하다면 왜 컴퓨터가 그렇게하지 않습니까?

소프트웨어를 재사용 할 수있는 능력이 프로젝트를 반복함으로써 발생하는 프로세스 개선 및 효율성을 방해합니까?

나는 지난 17 년간 같은 대형 프로젝트에서 항공기 산업에서 우연히 (첫 번째 링크에서 Airbus A380 참조를 생각하면서) 시스템 및 소프트웨어 엔지니어로 근무했지만, 제 임무는 군용 항공기 부문에 있습니다. 그런 이야기는 기본적으로 순수한 소설이며, 내부 통찰력이있을 때 실제로 보는 것은 정말 재미 있습니다.

그러나 당신의 간단하고 간결한 질문 : 내 경험으로, 나는 그렇기도 하 고 아니오라고 말할 것입니다.

먼저 모든 형태의 소프트웨어 재활용을 위해 모든 사람에게 도움이된다고 말하겠습니다. 잘라 내기 및 붙여 넣기 코드 스 니펫 및 알고리즘에서 전체 코드 모듈 및 함수 라이브러리에 이르기까지 거의 모든 것을 재사용하는 이점은 항상 처음부터 다시 시작하는 것 (약간 밀기)보다 훨씬 낫습니다.

단점은 지적한대로 (또는 적어도 추론 한대로) 주어진 구성 요소 집합을 조합하여 기능을 추가 할 때 (그렇습니다. 극단적으로 단순화하고 있습니다) 실제로는 프로그래머, 엔지니어 또는 무엇이든.

직장에서 내 주변의 소프트웨어 엔지니어를 보면 오랜 경험을 통해 대부분의 사람들이 알지 못하고 더 나쁘다-학습에 관심이 없다. 우리가 생산해야 할 최소한의 것 이외의 제품에 대해 관심이 없다. 그들이 할당 된 문서 또는 코드 조각.

여기 주제 오프 약간 비틀 거리고 있어요,하지만 내 포인트는 프로그래머가되지 않을 때 즉 필요 가 구축하는 코드가 정말 사용되며,하지 않는 것을 배울 필요가 시스템의 내부 동작을 배울 수 있기 때문에 그들은 단지 수 이미 작성하고 테스트 한 구성 요소를 재사용하면 대부분 그렇게하지 않아도됩니다.

물론 이것은 우리가 구성하는 제품이 엄청나게 복잡하고 한 사람이 모든 제품에 대해 배우는 것이 불가능한 것과 같은 다른 상황 때문이기도합니다. 가장 복잡한 것 중 하나이지만 여전히).

우리의 소프트웨어 엔지니어들이 많은 코드를 재사용 할 수있는 옵션이 없다면, 그들은 일반적으로 그들의 직업에서 더 나아질 것이며 프로젝트에 더 큰 자산이 될 것이라고 확신합니다.

아, 그리고 당신은 내가 그들에 대해 많이 이야기한다는 것을 알았을 것입니다 . 물론이 소프트웨어 엔지니어들도 포함되어 있습니다. 예외는 내가 더 호기심이 많고 다른 것들보다 새로운 것을 배우고 싶어한다는 것입니다. 사실의 형태와 소스 코드를 연구함으로써 (그렇습니다. 실제로 그것을 좋아합니다).

아-댕, 다시 추적 ... 내 변명은 내가 32 시간 동안 잠을하지 않았기 때문에 내 초점 능력이 조금 ... 내가 무슨 말을 했습니까?

누구든지 여전히 읽고 있다면 내 결론은 다음과 같습니다.

그렇습니다 . 소프트웨어를 너무 많이 재사용하면 지식이 부족한 소프트웨어 엔지니어가 실제로 물건의 작동 방식을 알아야 할 때 현저하게 효율성이 떨어집니다. 문제 분석은 좋은 예이거나 심지어 제안 된 설계 솔루션이 실행 가능한지 알 수 있습니다. 물론 실제로 수행중인 작업을 모르는 경우 프로세스 개선도 달성하기가 더 어렵습니다.

그리고 아니오 , 소프트웨어를 재사용 주의 , 잠재적으로 당신에게 여분의 고려해야 할 시간과 계획 프로세스 개선을 많이 제공합니다.

다른 프로그래머의 질문에 대한 대답 에서 지적했듯이 , 구성이있는 유추는주의해서 다루어야합니다.

이에 대한 권장 자료는 소프트웨어 구성 유추가 깨짐입니다.

소프트웨어는 종종 구성에 비유됩니다. 불행히도이 비유에는 결함이 있으며 건설 업계에서 배운 교훈은 의심됩니다 ...

내가 관찰 한 것은 훌륭한 소프트웨어 프로젝트는 많은 반복성을 품질 보증으로 "이동"한다는 것입니다.

1,5 년 길이의 프로젝트에서 테스터로 일했을 때, 우리는 매주 "체크 포인트"릴리스에서 테스트주기를 실행합니다.이주기는 프로젝트 전체의 약 70 배입니다. 그것은 ... 반복적이고 부드럽게 말해서 일주일에 많은 변화가 없었습니다. 야간 빌드 테스트는 자연스럽게 훨씬 더 반복 가능해졌습니다. 프로젝트를 통해 약 500 배입니다.

이제 "의심스러운"비유에 따라 500 명의 교량을 건설 한 건설 회사에 대해 모두 같은 팀으로 구성하십시오.

• 더 나아가서, 각각의 새로운 교량에서 거의 동일한 벽돌과 철을 사용하고있는 회사에 대해 이야기 해주십시오. 주- "많이 변경되지 않음").
  

마스터 빌더는 해당 지역에서 수십, 수백 또는 수천 개의 물건을 설계 및 / 또는 구축 한 것으로 인정되는 전문가입니다.

좋아, 위에서 인용 한 반복성에 대한 당신의 설명을 따르면, 나는 그렇게 말할 수 있습니까? 그 당시에 우리의 아주 특별한 테스터 그룹은 확인하지 않았으며, 우리 지역의 수백 가지 이상의 것들을 볼 수 있습니다.

프로젝트 개발자는 문자 그대로 빌드 ( "야간 빌드")합니다. 단어는 동일하며 의미는이 맥락에서 옳습니다.

만약 "의심스러운"비유를 "수천 개의 것들"까지 더 계속 유지하고 싶다면, 이러한 양은 다시 한 번 올바른 것을 볼 때 소프트웨어 개발에있어 놀라운 것은 아닙니다.

• 예를 들어, 과거의 또 다른 프로젝트 (다시 말해서, 다소 정기적이지 않은 프로젝트)가 이번에는 개발 역할로 5 년 이상 진행되었습니다 (8 개의 주요 릴리스, 수십 개의 작은 프로젝트). 비슷한 주별 체크 포인트 ( 5x52~=250그들), 비슷한 야간 릴리스 ( 5x365~=1800그들) 및 이와 비슷한 작업을하는 개발자 / QA 팀이있었습니다. 약속대로, 수천 번 (1800) 범위에서, 매일 반복, 매주, 매월, 대부분 반복적 인 것들 (2 개의 야간 빌드 사이에 큰 변화는 없음).

Windows, Java 또는 AutoCAD와 같은 장기 프로젝트는 10 년, 20 년, 30 년에 걸쳐 진행될 수 있습니다.이 프로젝트는 "수천"의 야간 빌드 및 야간 테스트가 반복되는 횟수를 쉽게 설명합니다.

지속적인 통합 을 통해 QA 로의 반복성 전환 개념이 더욱 두드러집니다 ...

모든 개발자 작업 사본을 하루에 여러 번 공유 된 메인 라인 과 병합하는 관행 ... CI는 주기적 통합 관행의 강화로 볼 수 있습니다.

CI를 사용하는 조직은 일반적으로 자동화 된 단위 테스트 외에도 빌드 서버를 사용하여 일반적으로 작은 노력으로 품질 관리 를 적용 하는 지속적인 프로세스를 자주 적용합니다. 이러한 프로세스는 단위 및 통합 테스트를 실행하는 것 외에도 추가적인 정적 및 동적 테스트를 실행하고 성능을 측정 및 프로파일 링하며 소스 코드에서 문서를 추출 및 형식화하며 수동 QA 프로세스를 용이하게합니다. 품질 관리의 목적이 연속 용 애플리케이션 개선하는 소프트웨어의 품질 및 적용 품질 관리의 전통적인 관행을 대체하여, 그것을 전달하는 데 걸리는 시간을 줄이기 위해 후모든 개발 완료. 이것은 QA 프로세스에만 적용되는 통합을 쉽게하기 위해 더 자주 통합한다는 원래 아이디어와 매우 유사합니다 ...

반복성? 생각할 수있는만큼 많이 있습니다.

빈번하고 지속적인 QA를 통해 잘못된 문제는 신속하게 실패한 테스트를 통과 할 때까지 올바른 시도를 반복해야하는 개발자에게 신속하게 돌아옵니다. 어떤 의미에서, 반복 할 때까지 반복되는 주기는 코드 cata 와 유사 합니다 .

프로그래머가 연습과 반복을 통해 기술을 연마하는 데 도움이되는 프로그래밍 연습 ...

예를 들어 라이브러리는 기계 언어로 해결되지 않은 문제를 해결하는 어셈블리로 해결되지 않는 문제를 해결하는 고급 언어로 해결되지 않은 기능을 해결합니다. java에서 System.out.println ()을 호출하면 CPU가 장치로 출력되는 방식을 볼 수 없습니다.

그렇습니다, 당신은 무언가를 잃고 있습니다. 당신이 얻는 것은 해결되지 않은 문제에 집중할 수있는 능력입니다. 이제 문제를 해결하기 위해 기술의 다른 측면 (예 : 네트워크 작동 방식)에 몰두해야 할 수도 있습니다. 그러나 웹 페이지를 작성하기 만하면 기계 언어를 읽는 데 전문가가 될 필요는 없습니다.

같은 방식으로, 교량 건설업자는 매번 약간 다른 문제를 해결하고 있습니다 (다른 강). 그들은 특정 인장 강도의 강철 빔을 만드는 방법이나 볼트를 특정 공차로 가공하는 방법에 대해 걱정하지 않습니다. 그들은 그 문제를 해결 한 전문가에게 맡깁니다.

자세히 살펴보면 전체 사회와 인프라가 99 % 재사용되고 1 % 만 진전 된 진전으로 구축 된 것을 볼 수 있습니다. 대부분의 새로운 것은 추가되거나 제거 된 약간의 추가 사항이있는 오래된 것입니다. 인간 지식의 축적입니다. 누군가가이 시점에 도달하는 데 필요한 복잡하고 복잡한 모든 것을 알아 냈기 때문에 괜찮은 라이브러리로 고급 언어로 코드를 작성할 수 있습니다. 새롭고 흥미로운 문제를 해결할 수 있습니다.

이 모든 것을 하나로 묶고 의견에 응답하려면 : 숙련도를 높이기 위해 이미 해결 된 문제를 해결할 필요가 없습니다. 또한, 당신이하는 많은 일들이 바퀴를 재발 명 할 것입니다. 간단히 말해 대답은 '아니오'입니다. 라이브러리의 기능을 다시 구현할 필요가 없습니다. 많은 기회가 있으며, 일부는 썩었 고, 일부는 공예품을 연마하는 데 독창적입니다.

그것은 자원에 관한 것입니다. 몇 년 전, 대형 메인 프레임 컴퓨터 용 소프트웨어 프로젝트를 개발 한 경우, 거의 정적 개발 환경에서 15 년 정도되었을 수 있습니다. 급여 또는 COBOL 프로그램을 계산하기 위해 작성된 FORTRAN 프로그램은 지속적으로 사용되어 왔기 때문에 수십 년에 걸쳐 완성되었습니다. 이것이 어떻게 개선 될 수 있는지에 대한 자료가있었습니다. 우리는 더 이상 특정 프로젝트에 대한 기술을 미세 조정하고 연마하기 위해 느린 환경을 가지고 있지 않습니다. 그러나 우리는 기술을 활용하여 다음 프로젝트 자원에 적응시킵니다. 그러나 결국 새로운 프로젝트에서 일을하거나 많은 양의 금도금으로 새로운 일을하기 위해 소비 한 돈을 선택하게됩니다. 프로젝트를 금도금하는 것은 프로젝트를 n 도로 향상시키고 사용자가 말했더라도 많은 종과 휘파람을 추가하는 것을 의미합니다.

우리가 할 수있는 최선의 방법은 새로운 프로젝트의 전반적인 디자인을 살펴보고 팀의 과거 경험을 바탕으로 개선 될 수있는 방법을 보는 것입니다. 그러나 실제 경험은 소프트웨어 아키텍트가 실제로 기술을 향상시키기 위해 디자인을 개선하는 것으로 간주되는 것에 대한 비전을 갖기보다는 단순히 애자일, OOP 등과 같은 개발에서 최신 유행어를 씌우는 것입니다.