Legacy code refactoring video rental systemJaehoon Oh
Legacy Code Refactoring
- 마틴 파울러의 Refactoring 책 1장 예제를 워크샾 형태로 구성했다.
- 레거시 코드인 비디오 렌탈 시스템을 리팩토링 하는 방법을 단계적으로 살펴본다.
- 마이클 페더스의 Characterization Test 방법을 이용해서 Legacy Code 의 테스트를 작성한다.
- 새로운 기능을 추가할 때는 Sprouting Pattern(마이클 페더스가 만든 용어)를 이용해서 기능을 추가한다.
- 코드 스멜을 찾고 코드 스멜을 제거하면서 코드의 설계를 개선한다.
Legacy code refactoring video rental systemJaehoon Oh
Legacy Code Refactoring
- 마틴 파울러의 Refactoring 책 1장 예제를 워크샾 형태로 구성했다.
- 레거시 코드인 비디오 렌탈 시스템을 리팩토링 하는 방법을 단계적으로 살펴본다.
- 마이클 페더스의 Characterization Test 방법을 이용해서 Legacy Code 의 테스트를 작성한다.
- 새로운 기능을 추가할 때는 Sprouting Pattern(마이클 페더스가 만든 용어)를 이용해서 기능을 추가한다.
- 코드 스멜을 찾고 코드 스멜을 제거하면서 코드의 설계를 개선한다.
모두를 위한 기계번역 (박찬준)
○ 개요
2014년 본격적으로 NMT에 대한 연구가 진행되었으며 현재는 Transformer 기반의 다양한 NMT 시스템들이 연구되고 있습니다.
더 나아가 최근 NLP에서 가장 뜨거운 연구분야인 Language Representation 분야에서도 Transformer를 기반으로 한 BERT, GPT-2, XLNET 등의 모델이 개발되고 있습니다.
본 테크톡에서는 먼저 RBMT와 SMT에 대해서 간략하게 살펴보고 RNN기반 NMT 부터 Transformer를 기반으로 하는 NMT까지 자세히 살펴볼 예정입니다.
더 나아가 최근 WMT에서 매년 Shared Task로 열리고 있는 Automatic Post Editing System과 Parallel Corpus Filtering, Quality Estimation 분야에 대해서 설명하며 NMT를 이용한 다양한 응용 연구분야를 소개해드리겠습니다. (ex. 실시간 강연통역 시스템, 문법교정 시스템) , 기계번역에 대해서 아무것도 모르시는 분, 궁금하시분들도 이해할 수 있는 수준으로 쉽게 설명을 진행할 예정입니다.
○ 목차
1)기계번역이란
2)RBMT에 대한 간략한 소개
3)SMT에 대한 간략한 소개
4)RNN기반 딥러닝부터 Transformer까지
5)NMT를 이용한 다양한 응용 연구 소개
a. Automatic Post Editing
b. Quality Estimation
c. Parallel Corpus Filtering
d. Grammar Error Correction
e. 실시간 강연통역 시스템
6)OpenNMT 소개
여러 언어에서 null 안전성을 주요 마케팅 쟁점으로 내세우면서 null 안전성이 관심을 많이 받고 있습니다.
자바에서도 null을 잘 다루어야 소프트웨어 결함을 줄이고 견고하게 만들 수 있는데 null의 위협에서 코드를 안전하게 지키는 설계 지침을 정리하고 안전하다고 확인하는데 도움이 되는 도구를 소개합니다.
AI 연구자를 위한 클린코드 - GDG DevFest Seoul 2019Kenneth Ceyer
올바른 코드 작성을 고민하는 연구자들을 위하여 - 클린코드는 여러분의 코드를 복잡한 패턴으로 구현하여 시간을 잡아먹는, 겉만 화려한 장식이 아닙니다. 모델을 구현하고, 또 그것을 테스트 할 때 이것이 정말 올바른 코드인지 궁금하셨나요? 이 세션에서는 연구 모델을 작성할 때 발견할 수 있는, 빈번한 코드 악취(Code smell)들과, 그것들을 어떻게 없앨 수 있을지에 대해서 알아봅니다. 코드에 영혼을 불어넣고, 그 어떤 코드라도 부끄럽지 않게 구현할 수 있는 연구자들이 되어봅시다!
자바 개발자가 파이썬 개발을 배우면서 실무에 활용하고 집필을 하면서 겪었던 경험담 및 생각을 코드와 함께 풀어본다. 자바에 익숙한 사람이 파이썬을 배우고 있거나, 자바와 파이썬의 사이에서 고민을 했던 사람들에게 비교를 위한 기본 정보를 제공한다. 더 나아가 컴파일 언어와 스크립트 언어의 차이점, 개발 생산성을 측정할때 간과하는 컴파일 시간 및 순수 코딩 시간에 대한 통찰을 이끌 생각이다.
애자일을 제대로 실천하려면 실패와 실수에서 학습하고, 공동의 목적을 이루기 위해 다른 사람들을 도우려는 마음가짐이 필요하다.
고착화된 마인드셋에서 성장 마인드셋으로 바뀌었던 경험을 토대로 고착화된 마인드셋에서 애자일 마인드셋을 얻게 되었는지 살펴보았다.
애자일 마인드셋이 필요한 이유와 어떻게 애자일 마인드셋을 키울 것인지도 알아본다.
모두를 위한 기계번역 (박찬준)
○ 개요
2014년 본격적으로 NMT에 대한 연구가 진행되었으며 현재는 Transformer 기반의 다양한 NMT 시스템들이 연구되고 있습니다.
더 나아가 최근 NLP에서 가장 뜨거운 연구분야인 Language Representation 분야에서도 Transformer를 기반으로 한 BERT, GPT-2, XLNET 등의 모델이 개발되고 있습니다.
본 테크톡에서는 먼저 RBMT와 SMT에 대해서 간략하게 살펴보고 RNN기반 NMT 부터 Transformer를 기반으로 하는 NMT까지 자세히 살펴볼 예정입니다.
더 나아가 최근 WMT에서 매년 Shared Task로 열리고 있는 Automatic Post Editing System과 Parallel Corpus Filtering, Quality Estimation 분야에 대해서 설명하며 NMT를 이용한 다양한 응용 연구분야를 소개해드리겠습니다. (ex. 실시간 강연통역 시스템, 문법교정 시스템) , 기계번역에 대해서 아무것도 모르시는 분, 궁금하시분들도 이해할 수 있는 수준으로 쉽게 설명을 진행할 예정입니다.
○ 목차
1)기계번역이란
2)RBMT에 대한 간략한 소개
3)SMT에 대한 간략한 소개
4)RNN기반 딥러닝부터 Transformer까지
5)NMT를 이용한 다양한 응용 연구 소개
a. Automatic Post Editing
b. Quality Estimation
c. Parallel Corpus Filtering
d. Grammar Error Correction
e. 실시간 강연통역 시스템
6)OpenNMT 소개
여러 언어에서 null 안전성을 주요 마케팅 쟁점으로 내세우면서 null 안전성이 관심을 많이 받고 있습니다.
자바에서도 null을 잘 다루어야 소프트웨어 결함을 줄이고 견고하게 만들 수 있는데 null의 위협에서 코드를 안전하게 지키는 설계 지침을 정리하고 안전하다고 확인하는데 도움이 되는 도구를 소개합니다.
AI 연구자를 위한 클린코드 - GDG DevFest Seoul 2019Kenneth Ceyer
올바른 코드 작성을 고민하는 연구자들을 위하여 - 클린코드는 여러분의 코드를 복잡한 패턴으로 구현하여 시간을 잡아먹는, 겉만 화려한 장식이 아닙니다. 모델을 구현하고, 또 그것을 테스트 할 때 이것이 정말 올바른 코드인지 궁금하셨나요? 이 세션에서는 연구 모델을 작성할 때 발견할 수 있는, 빈번한 코드 악취(Code smell)들과, 그것들을 어떻게 없앨 수 있을지에 대해서 알아봅니다. 코드에 영혼을 불어넣고, 그 어떤 코드라도 부끄럽지 않게 구현할 수 있는 연구자들이 되어봅시다!
자바 개발자가 파이썬 개발을 배우면서 실무에 활용하고 집필을 하면서 겪었던 경험담 및 생각을 코드와 함께 풀어본다. 자바에 익숙한 사람이 파이썬을 배우고 있거나, 자바와 파이썬의 사이에서 고민을 했던 사람들에게 비교를 위한 기본 정보를 제공한다. 더 나아가 컴파일 언어와 스크립트 언어의 차이점, 개발 생산성을 측정할때 간과하는 컴파일 시간 및 순수 코딩 시간에 대한 통찰을 이끌 생각이다.
애자일을 제대로 실천하려면 실패와 실수에서 학습하고, 공동의 목적을 이루기 위해 다른 사람들을 도우려는 마음가짐이 필요하다.
고착화된 마인드셋에서 성장 마인드셋으로 바뀌었던 경험을 토대로 고착화된 마인드셋에서 애자일 마인드셋을 얻게 되었는지 살펴보았다.
애자일 마인드셋이 필요한 이유와 어떻게 애자일 마인드셋을 키울 것인지도 알아본다.
TDD 규칙은 간단하지만, TDD 를 배우는 것은 어렵고, 실천하기는 더 어렵다.
왜 그럴까? TDD 는 설계 방법이기 때문이다. TDD 의 규칙 리듬을 알고 따르려고 해도, 설계 용어들을 모르면 TDD 를 제대로 할 수 없다.
TDD 를 잘 하려면, 설계용어의 의미를 이해하고, 언제 적용하는지도 알아야 한다.
왜 프로그래머가 가독성을 향상시키는 수련을 평생 해야 하는지를 알려준다. 단지 상투적인 이유만 들먹이는 게 아니다. 좋은 가독성은 프로그래머를 프로로 만들어주고, 큰 기쁨을 주며, 성장할 기회를 준다고 역설한다. 가독성을 향상시키려면 눈에 보이는 것들부터 신경을 써야 하며, 코드 자체가 프로그램을 설명해야 하며, 흐름을 단순화하고 주석을 잘 쓰고 퇴고해야 한다는 간단한 원칙부터 지켜나가야 한다.
4. 리팩토링 배경:
: Bad Code가 야기시키는 문제점
Broken Window Theory
나쁜코드에 의한 생산성 저하는 계속 악화됨
5. 리팩토링 정의
명사형 정의
“소프트웨어를 보다 쉽게 이해할 수 있고, 적은 비용으로 수정할 수 있도록 겉으로 보이는 동작의 변화 없이 내부 구조를 변
경하는 것”
동사형 정의
“일련의 리팩토링을 적용하여 겉으로 보이는 동작의 변화 없이 소프트웨어의 구조를 바꾼다.”
다음 방법으로 동작의 변경 여부 검증
테스팅
최대한 개발 Tool의 지원 기능 사용
아주 조심히 진행
Refactoring의 예
public int getCharge(int quantity) { public int getCharge(int quantity) {
int charge = 0; int charge = 0;
Date now = new Date(); Date now = new Date();
// 현재 Summer타임 기간이라면 if (isSummerTime(now)) {
if (now.before(SUMMER_START)|| now.after(SUMMER_END)) { charge = quantity * WINTER_RATE +
charge = quantity * WINTER_RATE + WINTER_SERVICEC_CHARGE;
WINTER_SERVICEC_CHARGE; } else {
} else { charge = quantity * SUMMER_RATE;
charge = quantity * SUMMER_RATE; }
} return charge;
return charge }
}
private boolean isSummerTime(Date now) {
return now.before(SUMMER_START) || now.after(SUMMER_END);
}
6. 리팩토링 원리
: 왜 리팩토링을 해야 하는가?
프로그램을 빨리 작성하도록 도와줌
어떻게?
리팩토링은 디자인을 개선시켜 줌
디자인이 나쁜 코드는?
같은 작업을 위해 더 많은 코드 사용
중복이 많고 이해하기 어려움
수정 시 어려움으로 나타남
리팩토링은 소프트웨어를 더 이해하기 쉽게 만듬
리팩토링된 코드는 숨겨진 사용자인 유지보수자의 이해를 도움
낮선 코드에 대해 리팩토링 하면서 코드에 대해 이해하기도 함
7. 리팩토링 원리
: 언제 리팩토링을 해야 하는가?
틈틈이 계속
리팩토링 자체가 목적이 아니라, 다른 것을 하기 위해 리팩토링
을 하는 것이고, 리팩토링은 그 다른 것을 하는데 도움을 준다.
삼진 규칙
세 번째로 비슷한 것을 하게 되면 리팩토링을 한다
기능을 추가할 때, 버그를 수정할 때
코드에 대한 이해를 돕기 위해서
코드 검토 시
고수준의 의견을 얻을 수 있음
준비가 많이 필요함
8. 리팩토링 원리
: 두 개의 모자
기능 추가 리팩토링
기존 코드 수정 없이 새로운 기능 추가 기능 추가 없이 코드 구조 수정
테스트 추가 테스트 추가하지 않아야 함
테스트 정상 동작 확인 테스트 정상 동작 확인
개발할 때에는 모자를 자주 바꿔 쓰고(10분~30분),
한 시점에는 하나의 모자만 써야 한다.
9. 리팩토링 원리
: 리팩토링을 할 때의 문제
데이터 베이스와 연관된 코드의 리팩토링
인터페이스의 변경
Publish 된 인터페이스의 이름 및 파라미터에 대한 리팩토링
Ex) Android의 Service.onStart() 메소드
새로운 I/F를 만들고 Delegation 사용
예방책 : 애매한 메소드는 API에 넣지 말자
Publish 된 인터페이스의 Throw절의 변경
이 경우 Delegation 사용 불가
예방책 : Super Exception 사용
리팩토링이 어려운 디자인 변경
디자인에 실수가 있어 마음대로 리팩토링 할 수 없을 때
어떤 디자인 결정 사항이 너무 중요해서 리팩토링을 기대할 수 없는 경우
보안 문제, 퍼포먼스 문제
언제 리팩토링을 하지 말아야 하는가?
코드를 처음부터 작성 하는 게 나을 정도로 엉망인 경우
현재의 코드가 작동하지 않을 경우
마감일에 가까울 경우
10. 리팩토링 원리
: 사전 디자인과 리팩토링의 효용성 관계
“디자인으로는 생각을 아주 빨리 할 수 있지만, 그 생각에는 여
기저기 작은 구멍이 뚫려있다.”
“With design I can think very fast, but my thinking is full of little
holes” – Alistair Cockburn
리팩토링에 의해 사전 디자인의 Role이 변경됨
완벽한 사전 디자인이 아닌 적절한 솔루션을 제공하는 디자인이면
충분
리팩토링을 통해 변경에 많은 비용이 들지 않기 때문
따라서, 디자인이 단순화 됨
디자인 중심의 단점
설계 비용이 많이 든다.
복잡해 진다.
유지보수 비용이 상대적으로 많이 든다.
중복에 의한게 아닌 Complexity 때문
11. 리팩토링 원리
: 리팩토링과 퍼포먼스
리팩토링은 장기적으로 최적화 단계에 소프트웨어의
튜닝을 돕는다.
리팩토링을 통해 퍼포먼스 튜닝에 할당할 수 있는 시간을
얻을 수 있음.
프로그램이 잘 분해되어 있으면, 튜닝을 위한 분석 시 좀
더 세밀한 분석이 가능하다.
12. 냄새
냄새(코드냄새)는 코드에 잠재된 문제에 대한 경고 표
시
리팩토링을 해야 하는 문제점 표시
대표적 냄새
중복코드
부적절한 이름
기능에 대한 욕심
부적절한 친밀
주석
긴 메소드
긴 파라미터 리스트
Switch문
13. 냄새
: 중복 코드
가장 많이 발생하는 냄새
두 가지 중복이 있음
Obvious 중복
보통 Copy & Paste에 의해 발생
Unobvious 중복
계층구조의 병렬적 구현
비슷한 알고리즘(ex, 문자열, 도메인 특화 로직)
해결책
하나의 클래스에서 중복
ExtractMethod
두 형제 클래스에서 중복
ExtractMethod -> Pull Up Field or Pull Up Method -> Form
Template Method
14. 냄새
: 부적절한 이름
잘못된 이름은 코드의 이해를 방해한다.
“People often make assumptions based on the object
names alone” – Word Cunningham
해결책
Rename Method
Rename Field
Rename Constants
Tip !
일관성 없는 상세이름 보다는 일관성 있는 광의의 이름이 적합
add, register, put, create -> add
일관성 있는 이름을 위해서 용어 사전은 필수적
15. 냄새
: 기능에 대한 욕심
특정 클래스 내의 메소드가 동 PriceCalculator Product
작을 위해 다른 클래스에 있는 ..
calculate()
..
getQuantity()
정보를 많이 필요로 하는 경우 bmethod() getDiscountRate()
해결책
Move Method
16. 냄새
: 부적절한 친밀
특정 클래스 내의 메소드가 다른 Class A Class B
클래스에 있는 메소드(private 이 .. ..
어야 할)를 더 많이 사용하는 경우
amethod() xmethod()
bmethod() ymethod()
해결책
두 개의 독립적인 클래스가 엉켜 있다
면
Move Method
서로를 가리키고 있다면
Change Bidirectional Reference to
Unidirectional
중재하는 클래스가 없기 때문에 엉켜
있다면
Extract Hierarchy-> Hide Delegate
17. 냄새
: 주석
주석은 대부분 코드가 명확 치 않다고 판단될 때 쓰임
주석은 나쁜 코드를 유도함
해결책
코드의 일정 블록 설명
Extract Method
메소드가 하는 일 설명
Rename Method
선 조건 설명
Introduce Assertion
18. 냄새
: 긴 메소드
긴 메소드는 코드를 이해하기 힘들게 만든다.
주석을 달아야 할 필요를 느낄 때 마다 메소드로 분리
해결책
Extract Method
주의점
코드의 이해를 돕기 위해서는 코드의 의도를 잘 나타내는
이름 지어야
부적절한 이름을 가진 짧은 메소드 집합은 긴 메소드보다 이해하
기 힘들다.
19. 냄새
: 긴 파라미터 리스트
객체지향 코드에서는 파라미터가 많을 필요 없다.
문제점
이해하기 어려움
일관성 없음
변경이 많이 됨
해결책
이미 알고 있는 다른 객체로부터 값 얻어올 수 있음
Replace Parameter with Method
매개변수가 하나의 Object로 부터 나오면
Preserve Whole Object
매개변수 데이터가 하나의 논리 객체로 부터 얻어지는게 아닐 경우
Introduce Parameter Object
주의점
Caller와 Callee간의 데이터 종속성을 만들고 싶지 않을 경우 리팩토링을 피해야함
20. 냄새
: Switch 문
Switch문은 본질적으로 중복의 문제를 발생
타입 추가 시, 관련된 모든 Switch문을 수정해야 함
좋은 OOP코드의 특징은 Switch문이 비교적 적음
해결책
동일한 조건에 대한 Switch문이 여러 곳에서 사용됨
Step 1: Extract Method를 통해 각 조건 절에서 코드 추출
Step 2: Move Method를 통해 연관된 코드를 옳바른 클래스로 옮김
Step 3: Replace Type Code with Subclass or
Replace Type Code with State/Strategy 를 통해 상속구조 만듬
주의
Switch문의 중복이 많지 않다면 바꿀 필요 없음
20 Confidential 12/13/2011
21. 결론
리팩토링은 코드를 이해하기 쉽게 만든다.
리팩토링은 목표가 아니라, 다른 작업을 하기 위한 과
정이다.
리팩토링은 틈틈히 계속 해야 한다.
21 Confidential 12/13/2011