나의 리팩토링 기준 및 리팩토링 방법 정리 1. 중복을 제거하라. (DRY. Don't Repeat Yourself)같은 일을 하는 클래스, 혹은 메소드 등이 한 곳에만 존재하도록 하라. 2. 메소드가 존재해야 할 클래스는 명확해야 한다. (직관성)기본적으로 어떤 동작을 행하는 쪽에 메소드를 만들어라. (그 일을 하는데에 필요한 멤버도 포함)예를 들어, 밥을 먹는다면 밥을 먹는 주체는 사람이다. 그렇다면 사람 클래스에 무언가를 먹는다는 메소드(Eat)가 있어야 할것이다. 3. 메소드 이름에 해당하는 일만 해야 한다. (직관성)다른 일을 하게 될 일이 생길 경우 메소드를 분리한다.단어의 포괄적인 의미에 속하는 일을 하게 될지라도 메소드를 하나 더 만들고, 그 메소드를 호출하게 해 Function per m..
1. 비정상적인 상황에서 남기는 로그. 비정상 적인 상황을 만든 값들과, 주변 정보를 모두 기록하도록 한다. 이런 경우는 무조건 로그를 남겨야 한다. 그래야 기록된 정보를 토대로 발생한 원인을 추적해 수정하기 쉬워진다. 로그를 남기고 처리를 멈추었을 때, 해당 처리가 요청 되기 전으로 모든 상황을 되돌려야 한다. 복원을 수동으로 하려는 것은 좋지 않다. 만들기도 어렵고 모든 상황마다 만드는 것은 시스템을 복잡하게 만든다. 그래서 throw로 예외를 발생시키고, 스택 되감기 하는 것이 더 좋은 선택이 되기도 한다. 물론 그렇게 하기 위해서는 소멸자에서 예외가 발생하지 않도록 하고, 생성자에서 예외가 발생했을 때도 메모리가 새지 않도록 하는 것을 잊지 말아야 할 것이다. 2. 비정상적인 입력 서버라면 클라이..
* 멀티 쓰레드 시 동기화는 주의 깊게 하라 -> 멀티 쓰레드에서 같은 데이터를 동시에 접근하지 못하도록 동기화는 필수다. 현재 사용중인 데이터가 특정 시점까지 변해선 안 된다면, 데이터 사용이 끝나기 전까지 다른 쓰레드에서 접근이 불가능 하도록 해야 한다. * DB처리를 하러 간 사이에 벌어질 수 있는 일에 주의하라 -> DB처리를 위해 블럭이 되는 서버가 아니고선, DB처리를 하러 간 사이에는 간극이 존재한다. 이 때를 주의하자. 또, 서버가 여러 대인 경우, 다른 서버로 처리하러 떠난 상태까지 고려하도록 하자. * 돈은 signed 형을 사용한다. -> unsigned형을 쓰다 잘못해 언더플로우가 나는 것보다, 돈이 –가 되는 것이 낫다. * 검사 시점을 주의하라 -> 즉시 이뤄지는 처리가 아닌, ..
패치시에 문제가 하나도 발생하지 않는다면 얼마나 좋겠냐만은... 패치 과정에서 실수가 생기는 경우가 많은 것이 사실이다. 패치 준비과정에서의 피로와, 수작업으로 인해 사소한 실수가 큰 파장을 일으키는 것이 현실. 주로 점검시에 발생하는 문제는 패치 준비가 제대로 되지 않아 생기는 문제가 많다. 다음은 실 서비스 적용시 문제를 덜 일으키기 위한 방법이다. * 테스트는 최대한 실 서버와 같은 환경에서 -> 가급적이면 서버는 테스트 코드나 테스트 데이터를 적게 사용해야 한다. QA와 같은 테스트는 가급적이면 실 서버와 같은 환경과 데이터로 하는 것이, 실 서버 패치 시에 생기는 문제를 줄일 수 있다. 점검시 실서버 QA의 경우 특히나 가급적이면 테스트 데이터를 사용하지 말자. 또한 환경 설정 파일 (cfg, ..
프로그램은 기본적으로 조건과 상황에 따른 판단과, 결정으로 이루어진다. 네트워크 프로그램은 클라이언트와 상호 작용하기 마련인데, 처음 서버 프로그램을 작성할 때 할 수 있는 실수는 클라이언트를 너무 쉽게 믿어버린 다는 것이다. 클라이언트가 이 약속을 안지키면 어떻게 할 것인가? 클라이언트에 버그가 있다면 어떻게 할 것인가? 정상적인 클라이언트를 이용하지 않는다면 어떻게 할 것인가?? 서버는 반드시 방어적으로 동작해야 한다. 클라이언트가 잘못된 요청을 하더라도, 서버는 그 요청을 무시하거나, 잘못된 요청이라는 것을 알려주는 것에 그쳐야지 서버에 예외 또는 버그가 발생해선 절대 안된다. 다음은 직접 경험했던 상황들의 예이다. 직접 작성한 코드와, 유지 보수하던 코드에서 발생한 문제가 뒤섞여있지만, 클라이언트..
* 추가 하는 코드에 대해 명확히 이해하라 -> 코드를 추가할 때, 그 코드가 어떤 기능을 하는지 간단한 테스트라도 해라. 처음 시도, 사용하는 알고리즘이나 라이브러리 사용시에는 특히 주의하라. 그 기능을 명확히 이해하지 못하고 사용한다면, 그 것은 우연에 맡기는 프로그래밍을 하는 것이다. * 적은 조건을 만족해도 잘 돌아가는 코드를 작성해라 (복잡도를 줄여라) -> 다른 코드나 외부 데이터에 적게 영향 받는 코드를 만들어라. * 가정 하지 마라. 코드에서 직접 제약을 걸어라. -> 어떤 처리에 대한 클라이언트와의 규약 (예를 들면, 비번 방 지정은 방장만 할 수 있다던가, 게임 방에서만 가능하다던가 하는 가정)은 반드시 지켜질 수 있도록 코드에서 그 동작이 불가능 하도록 만들어라. * 자료구조에서 넣는..
- Total
- Today
- Yesterday
- ruby
- 리버스 엔지니어링
- 루비 온 레일즈
- 멀티스레드
- MS-SQL
- svn
- 좋은 프로그래머
- 게임개발포에버
- perfmon
- 디자인 패턴
- 루비
- 엘키
- EasyExec
- NDC2013
- 디버깅
- SQLite Spy
- SDL
- 바로가기 프로그램
- TDD
- ftp
- Rails
- EzShortcut
- RoR
- Ruby on Rails
- 게임데브포에버
- c언어
- TraceRoute
- 조엘 온 소프트웨어
- 임백준
- CppSQLite
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |