한빛미디어의 소프트웨어 아키텍쳐 101을 요약 정리했습니다.
이 포스팅은 개인 학습 목적으로 작성되었으며, 한빛미디어 도서 저작권 가이드라인을 준수하였습니다.
도서에 대한 자세한 정보는 아래 링크에서 확인 가능합니다.
https://www.hanbit.co.kr/store/books/look.php?p_code=B1494466807
아키텍쳐 사고
- 아키텍쳐와 설계의 차이를 이해하고 개발팀과 어떻게 협력할지를 아는 것
- 폭 넓은 기술 지식을 확립하여 다른 사람들이 보지 못하는 해결책과 가능성을 찾는 것
- 다양한 솔루션과 기술간의 트레이드 오프를 이해, 분석, 조율하는 것
- 비즈니스 동인의 중요성을 이해하고 아키텍쳐 관심사로 해석하는 것
아키텍쳐 vs 설계
- 기존에는 아키텍쳐가 정하면 개발자가 따라서 설계하고 개발하는 일방향 관계
- 제대로 된 아키텍쳐를 만드려면 아키텍트와 개발자를 가르는 장벽을 허물고 소통하는 관계로 되어야 한다.
- 아키텍쳐와 설계가 경계가 있다고 생각하지 말고 프로젝트 생명 주기의 일부로서 서로 동기화 되어야 성공 할 수 있음
기술 폭
- 업무를 진행하기 위해 개발자는 기술 깊이를 확보해야 하지만, 아키텍트는 기술 너비(폭)을 갖춰야 함
- 아키텍트는 기술적인 제약 하에 어떤 기능이 가장 알맞는지 결정해야 하므로 폭 넓은 솔루션을 두루 꿰고 있어야 함
- 개발자가 아키텍트로 변신하려면 기존 개발자였을때처럼 전문성을 늘려가나 옛날 전문성을 고집하려고 하지 말아야 함
트레이드 오프 분석
- 아키텍쳐는 모든 것인 트레이드 오프이다.
- 아키텍쳐 사고는 어떤 솔루션의 장점도 보면서, 그와 연관된 단점이나 트레이드오프는 없는지 분석한다.
- 여러 솔루션 중 하나를 택하는 일은 언제나 비즈니스 동인, 환경 등 다양한 요인에 좌우됨
비즈니스 동인의 이해
- 아키텍쳐 사고는 비즈니스 동인을 이해하고 확장성, 성능, 가용성 등의 아키텍쳐 특성으로 해석하는 것임
아키텍쳐와 코딩 실무간의 균형
- 병목 트랩에 빠지지 말아야 한다. 아키텍트는 풀타임 개발자가 아니므로 개발자의 역할과 아키텍트의 역할의 균형을 찾아야 한다. 그래서 크리티컬 패스와 프레임워크 코드는 다른 개발팀에게 넘기고 비즈니스 기능을 코딩하는 작업에 집중해서 반복을 수행하는것이 낫다. 그렇게 하면 프로덕션 실제코드를 작성하면서, 코드를 개발팀에 분산시키고, 비즈니스 연관 코드를 직접 작성하면서 개발자들이 어느 부분에서 가장 고통을 겪는지 확인 가능하다.
- 개념증명으로 아키텍쳐가 각 제품을 응용한 예제 코드를 짜보고 결과를 직접 비교하는 방식으로 아키텍쳐 특성을 구체적으로 비교한다. 가능한 고품질 코드를 작성해서 다른 사람들이 레퍼런스 코드로 사용할 수 있도록 한다.
- 기술 부채나 아키텍쳐에 전념한다.
- 버그를 잡으면서 아키텍쳐에 존재하는 이슈나 약점을 발견한다.
- 간단한 도구를 만들어 개발팀의 일상 업무를 간소화, 자동화한다. 컴플라이언스를 검증하는 툴을 만드는 것도 좋다.
- 코드리뷰를 자주 하면서 컴플라이언스를 확인하거나 다른 팀원들을 멘토링, 코치한다.
Frontend Developer