y2o2u2n
commented
3 years ago 시작
복잡성, 개념 누락, 관계 잘못 설정, 언어가 이해가 잘 안됨, 새로운 요구 사항을 수용할 수 없음... 으로부터 리팩터링이 시작됨
조사팀
- 도메인을 잘 아는 개발자, 모델링 기술이 뛰어난 개발자, 해당 문제에 뛰어난 개발자, 도메인 전문가 등 4~5명이 모임
- 30분 ~ 1시간 30분 동안브레인 스토밍
- 만족스러운 개념을 발견하면 코드로 옮김
- 또는 더 생각해보기로 결정함
빠르게 모여서 회의해보고, 작은 문제부터 해결해도 좋고, 보편 언어를 잘 정리하라고 함
선행 기술
- 책, 자료, 또는 기존 프로그램에서 유용한 추상적인 도메인 개념을 발견하기
- 다른 사람들의 분석 패턴을 활용해보기(경험에 기반하기 때문에 내 프로젝트에 온전히 적용할 수 없음)
개발자를 위한 설계
유연한 설계를 하라...? 는 듯
타이밍
- 현재 팀에서 도메인을 이해하고 있는 바가 설계에 표현돼 있지 않은 경우
- 중요한 개념이 설계상에 암시적으로 표현돼 있는 경우
- 설계상의 중요한 부분을 더욱 유연하게 만들 기회가 보이는 경우
단, 출시 전날 ㄴㄴ, 기교 뽐내기 위한 목적 ㄴㄴ, 도메인 전문가를 설득할 수 없는 모델 ㄴㄴ
위기를 기회로
리팩터링은 지속적으로 하는 것. 하다 보면 과거 모델이 결함투성이로 보임. 더 훌륭한 모델을 만들 수 있음.
bearics
고전적인 리팩토링 - 1 ~ 2명의 개발자가 개선의 여지가 있는 코드를 발견하고 즉석에서 변경
시작
문제 발견
Exploration Team (조사팀)
선행 기술
서적, 도메인 자체 지식을 정리한 자료, 분석 패턴, ...
개발자를 위한 설계
작성한 코드를 시스템의 다른 부분과 통합하는..
반복적으로 코드 리팩토링 -> 유연한 설계 = 설계 의도 전달 + 코드 영향을 쉽게 예측 -> 리팩토링이 쉬워짐
타이밍
지속적인 리팩토링
도메인을 지속적으로 조사하고, 개발자를 교육하며, 개발자와 도메인 전문가가 의견의 일치를 이루는 과정의 일부가 되어야 함
안되는 것
위기를 기회로
점진적인 변화를 거쳐 짧은 기간의 폭발적이면서 신속한 변화. 전에 계속 하던 얘기
모델을 일정 기간 꾸준히 정제 -> 통찰력
기회가 아닌 위기로 보임 -> 모델 내에 결점 발견 = 팀이 새로운 이해 수준에 도달