테스트하기 쉬운 코드가 아키텍처가 잘 디자인된 코드다 ? X
테스트하기 어려우면 아키텍처도 Bad? O
설계가 잘된 코드는 테스트하기 쉽다. O
Dependency Injection
Static Method는 Test 의 적!
What is an Object?
Object => Instance of a class
Encapsulated entity with state and behavior
Things or cencepts with crisp boundary
<=> Entity with unique identity
Elegantly tackle complexity & create easy adaptability
polymorphism(다형성)
Dependece Management
Not rigid, not fragile, reusable, low viscosity
경직성: Cascade dependcy 문제점
Design Smells: The Odors of Rotting Software
Rigidity, Fragility, Immobility, Viscosity, Needless Complexity, Needless Complexity, Needless Repetition, Opacity
분석단계에서 철저히 해라 > 애자일: 현단계에서 필요한큼만 설계하라
우리시스템을 이용해서 goal을 달성하는 당사자 Primary Actor를 파악한다.
Supporting Actor는 왜 찾아야 할까요?
우리시스템이 누굴 상대할지, 어떤 Protocol을 특정 밴더 프로토콜 dependecy하게 진행하면 안된다.
우리 시스템과 interaction 하는 당사자
시스템과 interaction하는것은 Actor이다.
Reengineering
성공적인 소프트웨어는 stakeholder들의 요구사항을 만족해야만 한다.
제시간, 예산에 맞춰서 개발되어야 한다.
변화에 대한 요구를 쉽게 받아들일 수 있어야 한다.
You should use iterative development only on projects
Forward Engineering
- Requirements, Design, Implementation
Reverse Engineering
- 코드를 역추적, 안좋은 의미의 리버스 엔지니어링으로 많이 쓰였다.
- source code가 low level이라고 본다. 문제는 design document(model)가 없다. 분실되엇거나 만들지 않았다.
diagram을 역추적하는게 리버스 엔지니어링이다.
- 정적모델: class model, 동적모델: interaction diagram, sequence diagram
- 디자인 모델을 역추적한다.
Restructuring
- 동일한 abstraction레벨에서의 transformation
Golden Mater Testing
- 코드를 캡쳐해서 수정하기 이전 수정한 이후 결과가 같은지, 가능하면 많은 인풋을 주는게 좋다
Legacy Code: 내가 아닌 남이 짠 코드? 우리한테는 여전히 가치가 있는 코드
남이 싼 똥? 내가 싼 똥일 수도.. 테스트코드가 없는 코드는 legacy코드다
Refactoring?
소프트웨어의 내부 structure를 바꾼다.
두가지 목적: 이해하기 쉽게, 변경하기 용이하도록
GRASP Patterns
General Responsibility Assignment Software Patterns
Information Expert or Expert
Creator
High Cohesion
Low Coupling
Controller:시스템 이벤트를 맞이할 책임을 누가 가지는가?
Clean Architect
Typical Layers
- User Interface(Presentation Layer)
- Application Layer
- Domain Layer
- Infrastructure Layer
Repository에 대한 interface는 domain data가 있는 곳에 있어야 한다.
Aggregate Rules
ex) Customer, Rental, Video
technical debt - Ward Cunningham이 언급
7가지 설계 죄악
1. Rigidity – make it hard to change
2. Fragility – make it easy to break
3. Immobility – make it hard to reuse
4. Viscosity – make it hard to do the right thing
5. Needless Complexity – over design
6. Needless Repetition – error prone
Long Method
특징: 중간중간 주석이 많다.
Change Prevents: 수정할 곳이 많다.
Shotgun Surgery: 동시다발적으로 여러곳 수정필요 관련 메소드 데이터 한쪽으로 몰아야 한다.
Parallel Inheritance Hierarchy: 쌍으로 같이 management해야 되는 개수가 double로 늘어나니 하나로 만들어라
Dispensables: 없느니만 못한애들 발견되는 족족날려버려야 한다.
- duplicate code, lazy class, data class(단순 getset, dto는 괜찮음, 비즈니스클래스가 이러면 문제있음), dead code, speculative Generality, comments
Couplers: 냄새
– Feature Envy: method를 옮겨라
– Inappropriate Intimacy: 둘이 너무 가까워 서로의 filed를 다 알고 있어 이거는 바람직 하지 않다.
– Message Chains: a.getB().getC().getD().getValue(); mesage chains이런식의 설계는 피하자
– Middle Man
– Incomplete Library Class
CC = Decision point + 1
과제
- Architecture Refactoring Result > GraphicUI로 동작하는 것을 보여줘야한다.
- 느낀점
- Smells and Code/Design Level Refactorings (5개) > 남아있는 smell identity식별하여 문제가 있는것같으니까 이런 refactoring을 적용하면 이렇게 나온다.
- 제출: kimjs@hanyang.ac.kr (B5-과제2,1조)
- Due: 8/26 or 8/27
완성되는 대로 send
참고: ppt로 만듬.
befor after 변경되는점
스멜
https://nesoy.github.io/articles/2018-05/Refactoring-BadSmell
Refactoring - 나쁜 냄새(Bad Smell)
nesoy.github.io
리팩토링
Refactoring and Design Patterns
Hello, world! Refactoring.Guru makes it easy for you to discover everything you need to know about refactoring, design patterns, SOLID principles, and other smart programming topics. This site shows you the big picture, how all these subjects intersect, wo
refactoring.guru
