일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | ||
6 | 7 | 8 | 9 | 10 | 11 | 12 |
13 | 14 | 15 | 16 | 17 | 18 | 19 |
20 | 21 | 22 | 23 | 24 | 25 | 26 |
27 | 28 | 29 | 30 |
- 게시판 제작
- workspace
- analysis
- 클래스
- network
- Eclipse
- vision document
- 이클립스 설정
- js꼬리
- jdbc
- System Requirement Specification
- srs
- IO
- 데이터베이스
- 파일
- mindmap
- 메소드
- 제안서
- 네크워크
- 소켓
- Ecilpse
- FIle
- java
- 자바
- 설정
- 게시판
- sequence diagram
- jdk설치
- custom Tag
- Database
- Today
- Total
공적's life
리팩토링 본문
리팩토링
- 정의
> 소프트웨어를 보다 쉽게 이해할수 있고, 적은 비용으로 수정할수 있도록 겉으로 보이는 동작의 변화 없이 내부 구조를 변경하는것
- 퍼포먼스 최적화
> 리팩토링과 반대되는 의미로 사용될수도 있다. 최적화를 위해서 코드의 가독성을 희생해야 할수도 있기 때문에 리엔지니어링?에 가까운거 같다.
언제 리팩토링 할까?
틈틈히!
- 삼진 규칙
> 중복 된 코드가 3번 보일때 리팩토링
- 기능 추가 할때
> 왜냐면 좋은 디자인으로 작성된 코드는 기능을 추가하기 편하다. 하지만 그렇지 않은 상황에서는???
- 버그를 수정할때
- 코드리뷰를 할때
- 프로그램에 대한 작업을 어렵게 하는 이유는 ..
• 읽기 어려운 프로그램은 수정하기 어렵다
• 중복된 로직을 가지고 있는 프로그램 수정하기 어렵다.
• 실행중인 코드를 변경해야 하는 특별한 동작을 요구하는 프로그램은 수정하기 어렵다
• 복잡한 조건문이 포함된 프로그램은 수정하기 어렵다
관리자를 설득 하는 비법
역시 글은 어그로가 최고임
관리자가 기술적인 지식이 있다면 리팩토링한다고 솔직히 이야기하자.
관리자가 품질에 더 관심있다면 역시나 솔직히 이야기하자
위 두가지 상황이 아니면 말하지 말자
보통 대부분 관리자들은 스케쥴을 중요시한다. 대부분은 품질보다 스케쥴을 더 선택한다.
스케쥴에 맞추고 시간남으면 하거나 혹은 다음번에 진행하자고 할것이다.
소프트웨어 개발자는 전문가다. 효과적인 소프트웨어를 가능한 빨리 만들어내는 것이다.
- 퍼포먼스
- 시스템이 어떻게 돌아가는지 알고 있더라도 추측만하지 말고 실제로 퍼포먼스 측정을 해보라
- 프로그램이 잘 분해 되어 있으면 세세한 부분 좀더 세밀한 분석이 가능하다.
- 모든 코드를 최적화 하면 90%는 낭비다. 대부분 코드의 작은 부분에서 발생하고 해당 부분을 수정하면 된다.
위와 같은 사유로 리팩토링은 퍼포먼스 향상에 도움을 준다.
'Software' 카테고리의 다른 글
복사 붙여 넣기를 편하게 할수 있는 tool clipx (0) | 2014.05.12 |
---|---|
구글 앱 엔진 시작하기 (Google App Engine) (0) | 2011.01.18 |
솔라리스 10에서 오라클 11g r2깔기 (0) | 2011.01.06 |
2011년의 목표와 다짐 (0) | 2011.01.05 |
Amazone EC2 and Google App Engine (0) | 2010.07.05 |