결정의 자유, 해석의 책임-어떻게 그리고 왜 당신의 구조 문서를 자동화하는지

업무 중에 우리는 모두 두 배역을 맡고 있다.우선'전문가'역할이다.우리가 스스로 설계하고 작성한 코드에서 일할 때, 우리는 이 역할을 한다.우리는 그것이 어떻게 일을 하는지 안다. 우리는 문제의 근원이다.그 다음으로'신입생'역할도 있다.우리가 익숙하지 않은 코드 구역에 들어갔을 때, 우리는 이 역할을 맡았다.

When we work as experts, we decide. 
When we are newcomers, we encounter the decisions of others. 

'전문가'역할에서 우리는 소프트웨어의 체계 구조를 선택할 자유가 매우 크다.그 어떤 자유와도 마찬가지로 그 자유에는 책임이 따른다.이런 상황에서 결정의 자유는 우리의 결정을 기록하고 다른 사람에게 우리의 선택을 설명할 책임이 있다는 것을 의미한다.우리가 결정을 내릴 때, 우리는 반드시 자원을 창조하여 신입생들이 우리가 한 선택을 학습, 이해, 분석, 수정하고 최적화하도록 도와야 한다.
'선택'의 책임은 개발자의 책임이다.그러나 해명(기록)의 책임은 계속됐고 투쟁이었다.증거를 원하십니까?
AppLand에서 State of Software Architecture Quality에 대해 조사"설문 조사에서 응답자의 12%만이""자주 업데이트되고 정확한""설계 문서에 동의했습니다."그러나 84%는 "최신의 도표와 시각화된 코드 구조와 끝에서 끝까지 데이터 흐름을 제공하는 시스템이 유용할 것"이라고 동의했다.이것은 거대하고 중요한 차이다.

개발자는 진정으로 어떤 체계 구조 정보를 원합니까?

그렇다면 학습과 분석을 위해 성공한 구조 문서는 어떤 모습일까?많은 중요한 상황에서 소프트웨어 개발자는 최신 체계 구조 문서를 필요로 한다.다음을 포함합니다.

새 코드

문제 해결

재구성

설계 검토

보안 및 규정 준수 감사

은 불필요한 변화를 줄이기 위해 통일된 기준을 세웠다.

그러나 전통적인 구조 문서, 예를 들어UML은 팀의 기존 소프트웨어를 이해하고 개선하는 데 뛰어나지 않다.만약 그들이 원래 분석 도구로 쓰려고 한다면, 그것들은 이 방면에서 실패할 것이다.
왜?코드 이해와 분석에 도움이 되기 위해서는 문서를 구성하는 데 네 가지 관건적인 측면에서 더욱 잘해야 한다.

최신 제품이 필요합니다.잘못된 파일이 쓸모없는 파일보다 더 나쁘다. 오도이다.나는 그냥 코드를 써서 열심히 완성할게.

상호 작용이 필요합니다.종이에 인쇄할 수 있도록 설계된 정적 그림 한 장

은 상하문과 관련이 있어야 한다.기존의 아키텍처 문서는 너무 크고 복잡합니다.일단 특정한 용례에 집중하면 문서가 더욱 유용해진다.Stack Overflow와 개발자 블로그가 이렇게 유행하는 이유다.

코드에 최대한 접근해야 합니다.이상적인 상황에서 그것은 코드에 있다.코드는 작업이고, 코드는 진리이며, 이것이 모든 보조와 지원 정보가 필요한 곳이다.

AppMap - 자동으로 생성되는 문서는 무엇입니까?

구조 문서는 어떻게 최신식을 유지합니까?

소프트웨어 개발에는 보편적인 진리가 많지 않지만, 여기에는 다음과 같은 것이 있다.

Architecture documents and diagrams are always out of date. 

소프트웨어 프로그래머의 소프트웨어 업계에서의 역할이 떨어지면서 구조화 체계 구조 문서(예를 들어 UML)도 떨어지고 있다.전반적으로 말하면, 이것은 매우 좋다!가장 작은 상점에서 가장 큰 FAANG 개발자까지 누구와 대화를 하든지 간에 문서를 구성하는 것은 영원히 최신이 아니기 때문이다.프로그래머와 개발자 모두 그것을 제때에 갱신하지 못했다.그곳에는 아무런 변화가 없다.
그렇다면 개발자가 항상 최신 문서를 만드는 정확한 방법은 무엇일까?다행히도 이 문제는 매우 명확한 답안이 하나 있다.개발자들은 우리가 원하는 업무 방식에 대해 큰소리로 명확하게 이야기했고 두 가지 중요한 공감대를 형성했다.

암호는 진리의 근원이다.

코드는 표준화된 작업 흐름을 통해 유지보수를 진행한다.

개발자의 업무 절차(2)는 이미 표준화되고 최적화되어 효과가 현저하다.대체로 다음과 같다.

작업 선택

현지 환경 개발

설계

코드

테스트

필요에 따라 반복 단계(a)

소스 코드 관리(SCM) 서버로 코드 푸시

자동 테스트 및 기타 자동 품질 검사 실행

코드 검사 실행

필요에 따라 반복(2)

발표 공작물

생산

에 부품 배치

이 워크플로에 적합하지 않은 프로세스는 제거되고 폐기되었습니다.개발자의 인정을 받기 위해서는 모든 작업이 이 과정을 통해 이루어져야 한다. 과정 자체의 개선(예를 들어 인프라 시설을 구축하고 갱신하는 것)을 포함한다.물론 이것은 이상화된 관점이다.그러나 승리한 조직은 이 과정을 가장 순수한 방식으로 운영하는 조직이다.
따라서 구조 문서를 처리할 때 문제는 다음과 같다. 이 지속적이고 민첩한 개발 과정에서 이 문서들은 어디에서 창설하고 갱신하며 심사할 수 있습니까?어떻게 코드를 사용하여 실현합니까?

개발자의 우호적인 해결 방안은 어떤 모양입니까?

앱랜드의 소프트웨어 아키텍처 품질 현황 조사에서 응답자의 84%는 "최신의 차트와 코드 구조 및 종단간 데이터 흐름을 시각화하는 시스템이 유용할 것"이라고 말했다.
그러나 Lattix, CodeScene, Structurizer, PlantUML 등 구조 시각화 도구를 사용하고 있다고 답한 사람은 19%에 불과했다.이 공구들에 대해 59%는 "우리는 그것들을 사용하지 않을 것이며 사용할 생각도 없다"고 말했다.이것은 새로운 방법이 필요하다는 강렬한 신호이다.
92%가'개발자가 고품질 코드 생성에 필요한 자원을 가지고 있다'고 동의했다
그래서 이 진술들을 함께 놓아라.

84%의 개발자들은 최신 코드 구조 도표와 시각화, 그리고 끝에서 끝까지의 데이터 흐름을 원하지만 아직 이런 능력은 없다.

명의 사람들은 그들의 팀이 고품질 코드를 만드는 데 필요한 자원을 가지고 있다고 생각한다.

은 기존의 코드/구조 시각화 도구를 19%만 사용하고 계속 사용하고자 합니다.

문제는 현재의 사용 가능한 방법에 대한 인식이 부족한 것이 아니다.개발자는 더 좋은 선택을 원한다.우리는 더욱 높은 가치의 체계 구조가 가시화되고 강력해지기를 희망하며 표준 개발 과정을 통해 창설되고 실제 체계 구조를 개선하는 데 사용될 수 있기를 바란다.

앞으로 무슨 일이 일어날까요?

AppLand에서 우리의 임무는 개발자가 체계 구조의 방식을 이해하고 분석하며 개선하는 것이다.우리는 상호작용식 체계 구조와 코드 행위 데이터를 자동으로 수집하고 분석하며 시각화와 상호작용식으로 데이터를 표현함으로써 이를 실현한다.
우리는 세 가지 주요 목표가 있다.

은 최신 아키텍처 정보에 액세스하려는 개발자의 84%와 현재 최신 아키텍처 정보를 보유한 개발자의 12%의 격차를 좁혔습니다.

은 건축 정보의 현대화를 나타낸다.

은 아키텍처 정보를 자동으로 생성하여 최신 상태로 유지합니다.자동화는 이 목표를 실현하는 유일한 방법이기 때문이다.

이러한 목표를 실현하기 위해서 우리는 아직 해야 할 일이 많지만, 우리는 이미 많은 성과를 거두었다.따라서 이 시리즈의 나머지 부분에서 저는 여러분과 우리의 방법을 공유하고 미래에 대한 계획을 토론할 것입니다.