아키텍처
목차
Architecture??
TL;DR → 나쁜 아키텍처는 없음 효율적인 아키텍처가 있을뿐, 하지만 거대한 시스템에서 아키텍처가 없는건 나쁨
- 사전적 정의 : 건축학 → 다른 구조물을 계획하고 이러한 요소들을 모아 설계하여 건설 하는 과정
- 개발자 → 현실 세계의 목적을 달성하기 위해 문제를 모델링 하고 이를 구현 하기 위해서
시스템 끼리의 상호작용및 제약을 파악해 설계 및 개발을 해야함
- 소프트웨어설계 와 건축학의 유사점
- 건축 : 계획 → 설계 → 시공
- 개발 : 분석 → 설계 → 구현
- 어찌 보면 생긴지 반세기 정도 밖에 안된 공학이 수백년전부터 있던 공학을 참고 하는것은 당연
- 좋은 설계의 필요성
- 단순하고 간단한 제품의 경우 설계 없이 진행해도 별 무리가 없음
- 단기적으론 개발이 빠른것 처럼 보이나 차후 시간이 가면 갈수록 기능 추가, 개선이 어려워짐
- 또한 제품이 거대해질수록 개발을 진행하며 방향성을 잃기 쉬움
- → 이를 바로 잡아 주는것이 설계(아키텍처)
- 클린 코드 → 르블랑의 법칙(Leblanc’s Law) : 나중은 절대 돌아오지 않는다.
- 좋은 설계는 확장이 유리하며 데이터의 흐름 또한 올곧음 → 인력 유입 ↑ | 빠른 적응 ↑
- 소프트웨어가 커지고 성장할때 가장 중요한것은 프로젝트 의 상호간 이해도가 중요
- 아키텍처가 존재한다면 프로젝트 구성원간 이해와 설명이 쉬움
- 현실
- 안좋은 아키텍처로 출시된 앱
- 처음에는 생산성이 좋지만 안 좋은 구조로 점점 많은 코드와 작업이 필요해진다
- 기능적 추가를 위해 개발자를 점점 더 고용하여 인건비는 늘어난다
- 개발자 들의 흔한 착각
- 지저분한 코드를 작성하면 단기간에는 빠르게 개발이 가능하고,
- 장기적으로 볼 때만 생산성이 낮아진다” 라는 것이다
- 하지만 진실은 엉망으로 만들면 깔끔하게 유지할 때보다 항상 더 느리다 라는 것이다
→ 제이슨 고먼
System Architecture??
TL;DR → 설계가 코딩을 대신 해주진 않음(설계와 코딩은 별개의 개념)
- 사전적 정의 : 소프트웨어 시스템의 구조를 정의하고, 시스템을 설계하고 개발 하고 관리하기 위한 기법으로
시스템 및 개발의 청사진 역활을 수행함
- 좋은 소프트웨어의 특징
- 사용자 친화적 → 이해하기 쉬우면서 간단함
- 안정적이며 빠름 → 높은 신뢰성, 가용성
- 인터페이스와 기능이 잘 조화되어있음 → 명확한 문서화(체계적)
- 확장성, 유연성 높음 → 언제든지 확장과 업데이트 가능
- 아키텍처의 종류
- 모듈화 아키텍처(Modular Architecture)
- 서비스 지향 아키텍처(Service Oriented Architecture)
- 비관계형 데이터베이스 아키텍처(Non-Relational Database Architecture)
- 로드 밸런싱(Load Balancing)
- 분산 시스템(Distributed System)
- 시스템의 요구사항에 따라 적절한 아키텍처를 선택하는것이 중요
Design Pattern??
Architecture Pattern??
