코드 작성 부터 코드 만 들 기 까지

더 읽 기
    소프트웨어 개발 은 일종 의 공학 기술 로 서 그 연구 의 중점 은 어떻게 해야만 소프트웨어 제품 의 연구 개발 원 가 를 효과적으로 낮 출 수 있 는 지 하 는 것 이다.이 방향 에서 구성 요소 기술 은 전례 없 는 성공 을 거 두 었 다.그것 이 제공 하 는 기본 적 인 그림 은 블록 을 쌓 는 것 처럼 무 에서 유 를 창조 하여 최종 제품 을 조립 하 는 것 이다.어떤 의미 에서 이것 은 현대 건축 공업 에 대한 모방 과 경 의 를 표 하 는 것 이다.새로운 자재, 예비 부품, 구조, 이런 건축학 의 발전 은 소프트웨어 분야 에서 일일이 복제 되 었 고 건축 현장의 노동자 들 도 자연히 프로그래머 들 이 배 우 는 본보기 가 되 었 다.결국 구성 요소 의 세계 에서 코드 코드 를 코드 하 는 것 도 대체적으로 '벽돌 을 옮 기 는' 행위 이다.
    다행히도 소프트웨어 개발 은 일종 의 지능 활동 으로서 천성적으로 '탈 민 공화' 경향 을 가지 고 있다.정보 제품 은 물질 세계 제품 과 완전히 다른 추상 적 인 본질 을 가지 고 있다.물리 적 공간 에서 100 채 의 집 을 짓 는 데 는 100 배의 노력 을 기울 여 100 번 을 성실 하 게 일 해 야 한다.개념 공간 에 100 채 의 집 을 지 었 는데 우 리 는 다른 집 들 이 첫 번 째 집 과 똑 같 고 평 이 를 해서 회전 하면 된다 고 말 할 수 있다.벽돌 로 기 초 를 메 우 면 지붕 을 덮 는 데 쓸 수 없 으 며, 쓴 코드 는 사용 가능 한 장소 에서 손실 없 이 사용 할 수 있다.건 설 된 집 에서 수도관 이 새 는 것 을 발견 하면 크게 싸 우 고 완 성 된 소프트웨어 에서 부분 bug 를 보충 하 는 것 은 식 은 죽 먹 기다.추상 적 인 세계 에서 효과적으로 생산 을 하 는 데 의존 하 는 것 은 큰 일, 힘 든 일 을 쌓 는 것 이 아니 라 유도 할 수 있 는 원 리 를 발견 해 야 한다. 이런 원 리 를 바탕 으로 정 보 를 입력 하면 즉각 최종 결과 로 전환 할 수 있 고 점차적으로 구 조 된 과정 이 필요 하지 않다.조립 적 생산 을 넘 어 수학 과 유사 한 원리 적 생산 을 실현 할 수 있다 는 것 이다.http://canonical.iteye.com/blog/325051
    코드 재 활용 은 현재 소프트웨어 산업 에서 생산 원 가 를 낮 추 는 주요 구호 중 하나 이다.그러나 구성 요소 기술 의 지향 하에 서 일반적으로 재 활용 되 는 것 은 특정한 구조 원리 가 아니 라 구축 에 사용 되 는 벽돌 일 뿐이다.모든 정보 가 확 정 된 상황 에서 도 우 리 는 수요 에서 즉시 실행 가능 한 제품 을 얻 을 수 없다.많은 코드 들 이 우리 가 상상 속 에 이미 눈 에 선 하 더 라 도 그것 을 옮 겨 써 야 한다.우리 가 시스템 에 추상 적 인 구성 요소 가 없다 는 것 을 발 견 했 을 때, 여전히 많은 작업 이 기계화 되 어야 한다.코드 재 활용 의 이상 국 은 우리 에 게 는 아직 멀 었 다.
    하위 루틴 (subroutine) 은 최초의 코드 재 활용 메커니즘 이다.어제 완 료 된 작업 을 녹화 해 필요 할 때 재생 하 는 것 과 같다.함수 (function) 는 하위 루틴 에 비해 더욱 강하 다.많은 코드 들 이 달라 보이 지만 그 차이 점 을 변수 로 본다 면 그들의 구 조 는 통 일 될 수 있다.게다가 판단 과 순환 까지 겹 쳐 서 많은 면 모 를 가 진 것들 이 사실은 정 보 를 많이 공유 하 는 것 이다.대상 을 향 한 기술 은 비약 적 인 발전 이다.많은 관련 정보 가 하나의 이름 (유형) 에 포장 되 어 재 활용 입도 와 복잡 도가 크게 향상 되 었 다.파생 류 는 기본 클래스 에서 계승 하여 재 부팅 을 통 해 기 존 코드 에 대한 세밀 한 조정 을 실현 할 수 있다.그러나 이런 방식 은 여전히 날로 늘 어 나 는 복용 수 요 를 만족 시 킬 수 없다.우리 가 최종 적 으로 필요 로 하 는 코드 구 조 를 표시 하기 에는 이름 이 부족 하고 실제 사용 할 때 더 많은 정 보 를 보충 해 야 할 때 가 많다.유형 매개 변수 화, 즉 범 형 기술 로 종사 후의 측면 에서 볼 때 사실은 뚜렷 한 해결 방안 이다.매개 변수 동적 생 성 기류 에 따라 자연히 더 많은 변 화 를 흡수 할 수 있다.이른바 Modern C + + 의 발전 을 거 친 후에 우 리 는 현재 매우 명확 해 졌 다. 범 형 은 유형 변화 만 실현 할 수 있 는 것 이 아니 라 유형 매개 변수 에서 더욱 풍부 한 구조 정 보 를 도입 할 수 있다. 그의 본질은 코드 생 성 과정 이다.http://canonical.iteye.com/blog/57244 이 점 을 똑똑히 인식 하면, 그것 의 확장 은 매우 뚜렷 해진 다

       BaseClass --> CodeGenerator

 
DSL (또는 특정한 모델 대상) 은 일반적인 유형 (Class) 에 비해 정보 밀도 가 매우 높 고 더욱 풍부 하고 완전한 입력 정 보 를 제공 할 수 있다.한편, CodeGenerator 는 기초 언어 자체 가 제공 하 는 각종 컴 파일 체제 에 얽 매 이지 않 고 각종 텍스트 생 성 기술 을 유연 하 게 응용 할 수 있다.http://canonical.iteye.com/blog/309395 CodeGenerator 가 여기 서 제공 하 는 것 은 바로 입력 모델 에 따라 코드 를 완전 하 게 실현 하 는 구조 원 리 를 유도 하 는 것 이다.
    현재 많은 사람들 이 자신의 간단 한 코드 생 성 도 구 를 개발 하 는 데 열중 하고 있다. 이런 도 구 는 간단 한 상황 에서 체력 적 인 작업 을 줄 일 수 있 지만 생 성 된 코드 는 일반적으로 수 요 를 직접적 으로 만족 시 키 지 못 하고 대량의 삭제 작업 을 손 으로 수행 해 야 한다.코드 가 생 성 된 후에 이 는 경화 된 물질 제품 이 되 었 고 코드 생 성 도구 의 개선 에 따라 동기 화 되 지 않 았 다. 장기 적 인 시스템 진화 과정 에서 이런 도 구 는 반드시 누적 작업량 을 줄 일 수 있 는 것 이 아니다.

             ==> CodeGenerator

 
상기 코드 생산 과정 을 개선 하기 위해 일부 사람들 은 CodeGenerator 에 점점 더 많은 배치 가능성 을 도입 하여 각종 변화 가능성 을 구조 원리 에 내장 하려 고 한다.분명히 이것 은 CodeGenerator 의 비정상적인 붓 기 를 야기 할 것 이다.더 많은 우연성 이 원리 에 포 함 될 때 반드시 원리 의 단순 성과 보편성 을 파괴 할 것 이다.

          +           +      =     

 
반드시 [수정 보충] 이 존재 해야만 상기 방정식 의 지속 적 인 균형 을 유지 할 수 있다.
    인공 수정 과정 에서 벗 어 나 모델 조정 을 개념 세계 에 포함 시 키 기 위해 서 는 계승 체 제 를 뛰 어 넘 고 더욱 강력 한 새로운 기술 수단 이 필요 하 다.사실 현재 의 기술 배경 에서 이 기술 은 이미 부 르 고 싶 어 한다.바로 AOP, Aspect Oriented Programming 입 니 다.http://canonical.iteye.com/blog/34941

      Biz ==[AOP extends]==> CodeGenerator 

 
계승 은 동명 방법 간 의 간단 한 커버 만 실현 할 수 있 고 AOP 가 대표 하 는 기술 원 리 는 코드 구조 공간 에서 임 의적 으로 복잡 한 삭제 작업 을 하 는 것 으로 잠재 적 인 능력 은 인공 조정 과 같다.
    상기 생산 모델 을 실현 하기 위해 서 는 프로 그래 밍 언어, 구성 요소 모델, 프레임 디자인 등에 대해 일련의 개 조 를 해 야 한다.현재 통용 되 고 있 는 AOP 실현 과 원 편 정 기술 은 사실 상기 모델 을 지원 하기에 충분 하지 않다.http://canonical.iteye.com/blog/275015     이 생산 모델 이 어떻게 진 화 될 지도 흥미 로 운 문제 다.급 열 이론 에 따 르 면 우 리 는 바로 다음 과 같은 발전 방향 을 얻 을 수 있다.

   Context0 + DSL1 + EXT0 = DSL0  
   Context1 + DSL2 + EXT1 = DSL1  
   ...     

 http://canonical.iteye.com/blog/33824
Witrix 플랫폼 에서 BizFlow 는 DaoWebAction 에 대한 수정 모델 로 볼 수 있 지만 그 자체 가 완전한 의 미 를 가지 고 직관 적 으로 이해 할 수 있 습 니 다.BizFlow 를 바탕 으로 SeqFlow, StateFlow 등 모델 을 점차적으로 구축 할 수 있다.http://canonical.iteye.com/blog/126467
      현재 어떤 사람들 은 함수 식 언어 를 깊이 파고 패턴 일치 와 같은 개념 을 이용 하여 기호 공간의 전체적인 최 적 화 를 시도 하고 있다.그러나 우 리 는 통용 되 는 메커니즘 이 매우 적 고 통용 언어 배경 에서 명확 하 게 제 기 될 수 있 는 문제 가 더욱 적다 는 것 을 인식 해 야 한다.특정 분야 에서 더 많은 국부 정 보 를 파악 한 상황 에서 만 우 리 는 풍부 한 문 제 를 제기 하고 일정한 배경 에서 해답 을 할 수 있다.DSL 의 세계 에는 해 야 할 일과 할 일이 많다.http://canonical.iteye.com/blog/147065       프로그래머 에 게 미래 는 점점 더 풍부 하고 복잡 해 질 것 이 며, 우리 의 통찰력 을 지속 적 으로 고문 할 것 이다.우 리 는 한 줄 의 코드 를 작성 하 는 것 이 아니 라 하나의 실현 에 필요 한 것 을 번역 하 는 것 이 아니 라 국부 적 인 생산 원 리 를 계속 발명 하고 자신 이 제정 한 규칙 에 따라 추상 적 인 공간 에서 새로운 이미 지 를 계속 창조 하 는 것 이다.