1장 설계와 아키텍처란?
자유롭게 작성 해 주세요.
<재영>
빠르게 진행되어야 하는 일정에서 나는 어떻게 판단했었나
- TODO 를 남기고 이후에 리팩토링 하는 시간을 따로 갖는다.
- 하지만 임시 코드 적용 후 실시간으로 데이터가 빠르게 쌓이거나, 다른 의존하는 코드가 무분별하게 붙어 금방 코드가 고착되면 리팩토링 난이도 급상승
<상명>
좋은 소프트웨어 설계의 목적은 소프트웨어를 개발하고 유지하는 데 인력 자원을 최소화 하는 것이다.
케이스 스터디를 통해 잘못된 설계를 통해 빌드된 시스템은 버젼업을 할 수록 많은 인력들이 필요하고 각 인력들이 열심히 일함에도 불구하고 성과가 낮음. 고객의 요구사항을 반영하는데 많은 인력자원과 시간이 소모되고 이런 비용들은 경영진에게 부담이 됨.
왜 잘못된 설계를 하게 되는 걸까?
- overconfidence
- 나중에 고치거나 리팩터링 할 수 있다고 생각함 하지만, 현실은 소프트웨어가 릴리즈 되면 그럴 시간이 없음. market pressuare + bugfix 기타이유
- 개발자들은 자신이 나중에도 생산성이 뒤떨어지지 않을것이라 착각함. 잘못된 코드위에 빌드된 소프트웨어에서는 그 위에 모듈을 쌓을수록 생산성이 점점 떨어짐. 심지어 하나를 해결하면 다른 곳에서 문제가 발생할 확률이 높음 (lack of decoupling business logic)
<성헌>
-추천사 부분
아키텍처의 매력은 그 구조에 있다. 구저란 패러다임을 지배하고 소프트웨어 개발의 논의를 지배하는 무언가로서, 컴포넌트, 클래스, 함수, 모듈, 계층, 서비스가 그 예다. 하지만 거시적인 구조가 우리의 믿음을 저버리거나 이해와 상반되는 시스템이 정말 많다. (ex. 소련 산업체계)
건축물은 명확한 물리적 구조가 있다. 지반의 지질학적 특성, 기후 등등
그런데 소프트웨어는 유연하고, 소프트웨어가 소프트웨어를 떠받치고 있다.
마치 거북이가 서로를 떠받치고 있는 것처럼 (turtles all the way down)
아키텍처는 시스템을 구체화하는 중요한 설계 결정을 표현하며, 그 결정의 중요도는 변경에 드는 비용으로 측정된다.
- 그래디 부치
아키텍처란 프로젝트 초기에 제대로 정할 수 있기를 바라는 결정사항이지만, 제대로 정할 가능성이 그외 사항들보다 반드시 더 높지는 않다.
- 랄프 존슨
(사견)즉, 미래에 결정하거나 변경할 사항을 고려하여 현재 아키텍쳐에서 고려하면 좋지만, 이는 거의 불가능에 가깝다.
이러한 상황에서 갈 수 있는 길은 3가지가 있는데
- 미래의 변경될 상황에서 그냥 변경을 무시하거나 (가장 캄캄한 길)
- 너무 지나치게 일반화하거나(speculative generality)
- clean한 길을 갈 수 있다.
아키텍처는 종착지가 아니라 여정에 더 가까우며, 고정된 산출물이 아니라 계속된 탐구과정에 더 가까움을 이해해야 좋은 아키텍쳐가 만들어진다.
- 1장 설계와 아키텍쳐의 차이 --> 저자는 절대적 차이는 없고 본질적으로 의사결정이다. 라고 주장하는 것 같다. 그런데 상대적 차이는 분명히 있다는 듯한 뉘앙스인 것 같다. 아키텍쳐 고수준, 설계(design) --> 저수준. 그런데 연속적임.
<용상>
개발자가 속는 더 잘못된 거짓말은 '지저분한 코드를 작성하면 단기간에는 빠르가 갈 수 있고, 장기적으로 볼 때만 생산성이 낮아진다는 견해다. 12p
- 테스크 코드를 짜거나 페어프로그래밍 할때 많이 느낍니다. 페어를 하면 느린거 같아보이지만 실제로 훨씬더 버그가 적은 코드가 나와서 출시가 더 빨리집니다.
빨리 가는 유일한 방법은 제대로 가는 것이다. 13p
<명욱>
- 아키텍처라고 해서 구조만 잡고 디테일은 설계하지 않는 것이 아니다. 저수준 고수준 가리지 않고 아키텍처가 필요하다.
- 아키텍처의 목적은 필요한 시스템을 만들고 유지보수하는데 드는 인력을 최소화하는데에 있다.
- 엉망으로 만들면 깔끔하게 유지할 때보다 항상 느리다.
- 대부분의 일은, 긴급하지만 중요하지않고, 중요하지만 긴급하지않다. 이럴 때는 중요한 일이 먼저다.
- 아키텍쳐를 위해 투쟁하라.
주어진 인력에 비해 운영업무(사실은 엉망인 코드로 인해 발생한 일들이 대부분)가 많아 어떻게 하면 이 문제를 해결할 수 있을 지 팀 내부적으로 논의한 적이 있습니다. 결국 주어진 일을 안할 수는 없기 때문에 남은 시간에 최대한 리팩토링을 하는 쪽으로 결론이 났던 것으로 기억이 납니다. 1장을 읽고 나니 아키텍처를 위해 투쟁했어야 했다는 생각이 드네요. 아키텍처에 시간을 할애해야 한다고 설득하는 것을 하지 않았던 것 같습니다.
<보성>
빨리 가는 유일한 방법은 제대로 가는 것이다.
아키텍쳐를 위해 투쟁하라.
예전에 진행했던 프로젝트 중에, 비슷하게 진행중이던 프로젝트의 코드를 가져와서 시작하게 된 프로젝트가 있었습니다. 기존 코드는 처음에는 POC부터 시작해서, 차츰차츰 덧붙여지다 상용화까지 나아간 터라 코드가 정돈이 안되어 있었습니다(물론 어떻게든 시간을 내서 정리를 할 수 있었겠지만요). 문서도 없었고, API route 함수 하나의 길이가 (파이썬 코드였는데도) 1200줄이나 되는 경우도 있었습니다. 그런 와중에 저희 프로젝트도 빠르게 고객사에 MVP부터 전달해야했기 때문에 처음에는 포팅하기에 급급했습니다. 기존 코드로 동작하는 프로젝트의 사정과는 다르게 저희 프로젝트는 고객사의 요구사항이 보다 직접적이고 다양하게 들어왔기 때문에, 작업 시간은 계속해서 부족했고, 엉망인 코드 속에서 기능을 변경하거나 추가하는 것은 매번 오랜 시간이 걸렸습니다. 도저히 이대로는 작업할 수 없겠다고 느낀 저희는, 프로젝트가 시작한 지 1-2개월 후 1차 릴리즈가 된 다음부터 보다 적극적이고 과감하게 리펙토링을 하기 시작했습니다. PM 및 고객사쪽에도 최대한 설득해서 일정을 가능한 한 미루고, 모듈과 역할을 나눠서 집중적으로 리버스 엔지니어링을 하며 야근과 특근으로 계속 코드와 구조를 정리해 갔습니다. 계속되는 요구사항 반영과 기능 변경 + 항시 서비스 되고 있는 서버를 유지하면서, DB부터 서버 구조까지 모든 것을 다 바꾸는데 추가로 4개월 정도 걸렸던 것 같습니다. 그 과정에서 불안함도 있었고 주변의 많은 압박이 있었지만 든든한 PM님의 지원과 개발팀원들 모두의 의지가 있었기 때문에 잘 버텨냈던 것 같습니다. 그래도 그렇게 정리를 하고 나니 그 이후로는 모든 작업이 기존보다 훨씬 적은 시간에 끝나 작업시간에 여유가 생겼고, 계속해서 정리된 상태를 유지할 수 있는 시간이 있었습니다. 결과적으로는 고객사를 포함해 모두가 만족하면서 일할 수 있었던 것 같습니다.
시간이 나야 리팩터링(또는 설계)를 할 수 있는 것이 아니고, 리팩터링을 해야 시간이 나는 것이라고 확신하게 되었습니다.
<지환>
- '아키텍처의 목적은 필요한 시스템을 만들고 유지보수하는데 드는 인력을 최소화하는데에 있다.'
- '엉망으로 만들면 깔끔하게 유지할 때보다 항상 더 느리다.'
- '자신을 과신한다면 재설계하더라도 원래의 프로젝트와 똑같이 엉망으로 내몰린다.'