티스토리 뷰
Open-Close 원칙
- 객체는 수정(modification)에는 닫혀있고(Close), 확장(extension)에는 열려있어야(Open) 한다.
중복을 제거하라
- 같은 기능을 하는 코드를 묶어, 중복을 제거하자는 원칙.
메소드 간소화
- 메소드는 두가지 일을 하게 만들지 말아라.
- 메소드의 이름에서 벗어나는 일을 하지 말라.
- 큰 규모의 행동이 필요하다면, 더 큰 범위의 단어로 메소드 명을 짓고, 그 큰 동작을 완성 시키기 위한 메소드의 연결만으로 구현하라.
직교성
- 클래스 끼리의 의존도를 낮춰, 해당 클래스가 변화를 국소화 시키고, 재사용을 촉진하라
가역성
- 변하지 않는 것은 없다. 코드도, 설계도 변화에 대비하라.
계약에 의한 설계
- 이 함수에 들어오기 전에 기대하는 선행 조건(Pre-Condition)과, 함수 종료시에 보장해야 될 후행 조건(Post-Condition)을 검사하라.
80-20법칙
- 20% 코드가 수행시간의 80%를 차지한다.
- 20%의 자주 불리는 코드를 수행하면 80% 이상의 성능향상을 거둘 수 있다.
'Software Engineering > Develop Theory' 카테고리의 다른 글
좋은 엔지니어의 자세 (0) | 2012.07.01 |
---|---|
좋은 관리자의 요건 (0) | 2012.06.25 |
조엘 테스트 (0) | 2008.02.24 |
코드 읽기에 대해서 (2) | 2008.02.13 |
80-20 법칙 (0) | 2008.01.20 |
댓글
공지사항
최근에 올라온 글
최근에 달린 댓글
- Total
- Today
- Yesterday
링크
TAG
- TraceRoute
- 임백준
- 멀티스레드
- SDL
- svn
- CppSQLite
- NDC2013
- 바로가기 프로그램
- Ruby on Rails
- 조엘 온 소프트웨어
- ruby
- 디자인 패턴
- EzShortcut
- 엘키
- 좋은 프로그래머
- TDD
- 디버깅
- ftp
- perfmon
- 루비
- EasyExec
- RoR
- 리버스 엔지니어링
- 루비 온 레일즈
- c언어
- Rails
- MS-SQL
- 게임데브포에버
- SQLite Spy
- 게임개발포에버
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 | 31 |
글 보관함