Building Resilient Frontend Architecture • Monica Lent • GOTO 2019

https://www.youtube.com/watch?v=TqfbAXCCVwE

직장 동료가 공유해 준 영상. 요즘에 이런저런 재밌는 링크를 던져줘서 열심히 받아 먹고 있다. 아무튼 아래는 내용 요약!

회복 탄력성이 높은 프론트엔드 아키텍처에 관해 설명한다. 업무를 하면서 코드 재작성이나 마이그레이션은 불가피한 일이다. 처음 프로젝트를 착수할 때는 마냥 재밌기만 하지만 시간이 지나면 기술 부채가 쌓여가고 리팩터링을 하게 된다. 하지만 어찌 된 일인지 기술 부채는 불어나기만 한다.
그렇다면 '좋은' 아키텍처란 무엇인가? 이미 정의가 너무 많은데, 가슴에 손을 얹고 나는 우리 회사의 아키텍처에 대해 잘 알고 있는지 스스로에게 질문해 보자. 자신있게 대답하는 사람이 의외로 별로 없다. 레거시 코드뿐만 아니라 내가 새로 작성하는 코드 한 줄 한 줄이 아키텍처를 결정하는 행위이다. 이미 완성되어 있는 코드 디렉터리 만이 아키텍처가 아니다. 그렇기 때문에 좋은 아키텍처란 '제한을 줄 수 있는' 아키텍처여야 한다. 아우토반은 왜 사고가 적을까? 제약이 많기 때문이다. 안전과 빠른 속도는 많은 제약 사항 위에서 보장된다. 사람들에게 많이 알려진, 구글에서 흔히 나오는 아키텍처가 내 프로젝트에 꼭 맞는다는 보장은 없다. 다른 프로그래밍 언어 패러다임도 유연하게 받아들이는 자세가 필요하다.
프로젝트에 적용할 쉽게 적용할 수 있는 세 가지 제약사항을 소개하고자 한다. 첫째는 소스 코드 의존성이 내부로 향해야 한다. 그러면 변경 사항의 영향을 최소화 할 수 있다. 두 번째로 소스 코드 재사용은 보수적으로 결정할 필요가 있다. 재사용만이 능사가 아니라 때로는 컴포넌트를 복사 후 붙여 넣기 하여 따로 분리하는 게 나을 수도 있다. 마지막으로 경계를 확실히 구분 짓는 일이다. 각 모듈이 불러올 수 있는 의존성에 제약을 걸면 리팩터링이 잘못되는 것을 방지할 수 있다.

---

• Sometimes rewriting or migrating is inevitable
  • Technical debt: Code that negatively and repeatedly affects the speed or quality of delivery
  • Greenfield project - super fun! But… time passes… developers cannot do it anymore. Let me do my refactor. What often happens… recurring technical debt
  • Second system effect: You think something is terrible, and rewrite it, and it is worse than the previous one. Is rewriting my destiny?
  • The real cost = maintenance over time
  • Why do we rewrite a software? How can we make our system more resilient to changes?
• “Good architecture”
  • Hmm, already knows… “Architecture” has too many meanings.
  • What’s my companies architecture? Most people find that this problem is detached from their daily works. But, in whatever context, former people made your task difficult to be achieved for some reason.
    • You’re making architectural decisions every time you write a function or small piece of code. Small changes also affect the architecture.
  • Architecture as ‘enabling constraints’ - why there are few accidents in autobahn? Because there’re many constraints. We can drive fast above those constraints. For safety & speed.
    • OOP -> Independency deployable components
    • Functional -> Eliminate race conditions and concurrency problems
    • Using const instead of var -> Predictable data
    • jQuery instead of React -> Predictable UI
    • CSS instead of CSS-in-JS -> safety and fewer global clashes
  • You don’t have to derive architecture from the first principles.
    • Google cannot tell you the answer which fits your project perfectly.
    • Be open to other programming paradigms from other languages!
• Practical 3 constrains you can use today for more resilient FE architecture (Constraint -> Enables)
  1. Source code dependencies must point inwards -> Easier to isolate the impact of changes
     1. A few ways of organizing our dependencies: Big Ball of Mud(don’t know what will happen if you make a change), Layered(Limited regression scope), Modular
  2. Be conservative about code reuse -> Avoid coupling code that diverges over time
     1. What about the shared components?
        1. Design system or copy & paste
        2. Sometimes reusing cannot be an answer.
        3. Decoupling is usually more important than keeping it DRY.
  3. Enforce your boundaries -> preserve your architecture over time
     1. Forbidden dependency tests: dependency-cruiser.json -> put constraints to prevent someone do wrong refactoring.