80%의 효과는 20%의 노력으로 얻어진다는 법칙으로 중요한 일에 노력을 집중해 성공적인 삶을 살 수 있다는 것이다. 이 법칙을 프로그래밍에서 적용해보자면, - 코드 중에 20%가, 수행시간의 80%를 차지한다. - 프로그램의 리소스의 80%는 전체 실행 코드의 약 20%만이 사용한다. - 메모리의 80%는 실행 코드의 약 20%만이 사용한다. - 디스크 접근 회수의 80%는 실행 코드의 20%가 접근한 회수다. - 프로그램 유지보수에 들어가는 수고의 80%는 실행 코드의 20%에 집중된다. 여기서 80-20법칙의 진정한 의미는 아무 곳이나 골라잡고 효율을 향상시키려고 애쓰는 것은 별 도움이 안된다는 의미를 갖고 있다.
* 멀티 쓰레드 시 동기화는 주의 깊게 하라 -> 멀티 쓰레드에서 같은 데이터를 동시에 접근하지 못하도록 동기화는 필수다. 현재 사용중인 데이터가 특정 시점까지 변해선 안 된다면, 데이터 사용이 끝나기 전까지 다른 쓰레드에서 접근이 불가능 하도록 해야 한다. * DB처리를 하러 간 사이에 벌어질 수 있는 일에 주의하라 -> DB처리를 위해 블럭이 되는 서버가 아니고선, DB처리를 하러 간 사이에는 간극이 존재한다. 이 때를 주의하자. 또, 서버가 여러 대인 경우, 다른 서버로 처리하러 떠난 상태까지 고려하도록 하자. * 돈은 signed 형을 사용한다. -> unsigned형을 쓰다 잘못해 언더플로우가 나는 것보다, 돈이 –가 되는 것이 낫다. * 검사 시점을 주의하라 -> 즉시 이뤄지는 처리가 아닌, ..
패치시에 문제가 하나도 발생하지 않는다면 얼마나 좋겠냐만은... 패치 과정에서 실수가 생기는 경우가 많은 것이 사실이다. 패치 준비과정에서의 피로와, 수작업으로 인해 사소한 실수가 큰 파장을 일으키는 것이 현실. 주로 점검시에 발생하는 문제는 패치 준비가 제대로 되지 않아 생기는 문제가 많다. 다음은 실 서비스 적용시 문제를 덜 일으키기 위한 방법이다. * 테스트는 최대한 실 서버와 같은 환경에서 -> 가급적이면 서버는 테스트 코드나 테스트 데이터를 적게 사용해야 한다. QA와 같은 테스트는 가급적이면 실 서버와 같은 환경과 데이터로 하는 것이, 실 서버 패치 시에 생기는 문제를 줄일 수 있다. 점검시 실서버 QA의 경우 특히나 가급적이면 테스트 데이터를 사용하지 말자. 또한 환경 설정 파일 (cfg, ..
프로그램은 기본적으로 조건과 상황에 따른 판단과, 결정으로 이루어진다. 네트워크 프로그램은 클라이언트와 상호 작용하기 마련인데, 처음 서버 프로그램을 작성할 때 할 수 있는 실수는 클라이언트를 너무 쉽게 믿어버린 다는 것이다. 클라이언트가 이 약속을 안지키면 어떻게 할 것인가? 클라이언트에 버그가 있다면 어떻게 할 것인가? 정상적인 클라이언트를 이용하지 않는다면 어떻게 할 것인가?? 서버는 반드시 방어적으로 동작해야 한다. 클라이언트가 잘못된 요청을 하더라도, 서버는 그 요청을 무시하거나, 잘못된 요청이라는 것을 알려주는 것에 그쳐야지 서버에 예외 또는 버그가 발생해선 절대 안된다. 다음은 직접 경험했던 상황들의 예이다. 직접 작성한 코드와, 유지 보수하던 코드에서 발생한 문제가 뒤섞여있지만, 클라이언트..
도스시절 한글라이브러리인 한라 프로를 만드신 임인건님께서 쓰신 글입니다. 프로그래밍을 공부하시는 분들께 큰 도움이 되리라 생각합니다.--------------------------------------------------------------------------------------------------1. 정보를 모음에 소홀히 하지 말고 설명서를 읽음에 게을리 하지 말지어다. 오늘 필요 없는 정보는 내일 필요하리라. 가장 가치 있고도 저렴 한 지식은 책 속에 있느니라. 서점과 동료의 책꽂이에 무엇이 꽂혀 있는지 때때로 살피어라. 무심코 흘렸던 종이 한 장이 너의 근심을 풀어 주었으리라. 설명서는 충분히, 꼼꼼히 읽을지어다. 모든 의문은 설명서를 안 보는 데서 생기니라. 그렇더라도 모두 다 읽을 필요..
* 추가 하는 코드에 대해 명확히 이해하라 -> 코드를 추가할 때, 그 코드가 어떤 기능을 하는지 간단한 테스트라도 해라. 처음 시도, 사용하는 알고리즘이나 라이브러리 사용시에는 특히 주의하라. 그 기능을 명확히 이해하지 못하고 사용한다면, 그 것은 우연에 맡기는 프로그래밍을 하는 것이다. * 적은 조건을 만족해도 잘 돌아가는 코드를 작성해라 (복잡도를 줄여라) -> 다른 코드나 외부 데이터에 적게 영향 받는 코드를 만들어라. * 가정 하지 마라. 코드에서 직접 제약을 걸어라. -> 어떤 처리에 대한 클라이언트와의 규약 (예를 들면, 비번 방 지정은 방장만 할 수 있다던가, 게임 방에서만 가능하다던가 하는 가정)은 반드시 지켜질 수 있도록 코드에서 그 동작이 불가능 하도록 만들어라. * 자료구조에서 넣는..
- Total
- Today
- Yesterday
- TraceRoute
- NDC2013
- 리버스 엔지니어링
- 게임데브포에버
- ruby
- RoR
- SDL
- Ruby on Rails
- 임백준
- 바로가기 프로그램
- CppSQLite
- 멀티스레드
- 좋은 프로그래머
- TDD
- SQLite Spy
- EzShortcut
- 루비 온 레일즈
- svn
- 조엘 온 소프트웨어
- Rails
- 엘키
- ftp
- 디버깅
- MS-SQL
- 루비
- 디자인 패턴
- perfmon
- EasyExec
- c언어
- 게임개발포에버
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |