꽤나 많은 상황에서 우리는 기존 코드를 분석해야 한다. 빌드업이라 불리는 프로젝트에 필요한 기능들을 만져나가는 과정에서도 우리는 라이브러리나, 오픈소스 코드등을 통해서 기존 코드를 분석해나가야 한다. 물론 이 과정은 섬세하게 만져나갈 여지가 있고, 그간의 결합도를 조절해나갈 여지가 있으므로 상대적으로 코드 분석의 여지가 적다. 심지어 사용하는 라이브러리들이 익숙하거나, generic하게 구현되어있다면 더더욱이 쉽고. 사실 가장 곤욕스러운 과정은 프로젝트 dependency 한 코드를 분석하게 될 때이다. 이 과정에서, 코드간의 결합도를 낮출려고 노력해온 흔적이 있는 경우는 그래도 상대적으로 쉬운 편에 속한다. 예를 들어 패킷으로만 다른 티어와 통신을하고, 패킷 핸들링 코드가 명확하다면 기존 코드가 난해하..
문득 코드를 작성하던 중 이런 생각이 들었다. "과연 지금 내가 작성한 이 코드가 분석하기 쉬운 코드일까?" 생각해보면 아마추어 일때를 제외하고는 새 코드 작성보다 다른 사람의 코드 분석하는 시간이 더 잦았고, 새 코드를 작성하더라도 다른 코드와 어울려야 했기 때문에 코드 분석은 늘 필요했다. 심지어 내 코드를 분석해야 되는 일도 잦았다. 기억력에는 한계가 있고, 시스템의 전체적인 이해도는 높을 수록 좋겠지만 세세한 코드 하나 하나가 하는 일까지 외울 필요는 없다고 생각한다. 그렇기에 내 코드를 내가 몇달이 지나고, 심지어 몇년 후에 봤을 때도 읽기 쉽고 유지보수하기 쉬운 코드를 만들기 위해 노력해야 한다. 그래서 우리는 디자인 패턴, 리팩토링 등을 통해서 좋은 코드를 만들기 위해 노력하고, 표기 법을 ..
- Total
- Today
- Yesterday
- 루비 온 레일즈
- perfmon
- Ruby on Rails
- svn
- EzShortcut
- 디버깅
- 바로가기 프로그램
- 멀티스레드
- 게임데브포에버
- 좋은 프로그래머
- RoR
- SQLite Spy
- Rails
- CppSQLite
- MS-SQL
- 디자인 패턴
- ruby
- 엘키
- EasyExec
- ftp
- SDL
- 리버스 엔지니어링
- TDD
- TraceRoute
- 조엘 온 소프트웨어
- c언어
- 임백준
- NDC2013
- 루비
- 게임개발포에버
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |