1. simple is best.
- 좋은 프로그래머는 사람이 이해할 수 있는 코드를 짠다. - 마틴 파울러
- 짧게 쓸 시간이 없어서, 대신에 길게 쓰도록 하겠습니다. - 마크 트웨인
기계가 빠르게 이해하는 코드가 사랑받는 시기는 갔다.
사람(프로그래머)이 이해하기 쉬운 코드가 사랑받는 코드이다.
2. 입력값 체크는 프로그래밍의 40%이다.
입력값을 체크 안하고 어떻게 정상적으로 프로그램이 돌거라 생각하는지...
정말 특이한 개발자들 많다.
해커가 정상적인 루틴 이외에 방법으로 들어왔을때 그 값들을 그냥 DB에 넣을건지 ㅡㅡ
정 입력값 처리하기 싫으면 코맨트에 아예 써놔라.
"// 가정 1. 변수 A 는 항상 문자열만 들어온다. NULL 불가"
"// 가정 2. 변수 B 는 항상 숫자만 들어온다. NULL 불가"
다른 개발자라도 그거 수정해서 에러 안나게 할것이다.
여기서 고민되는것이 메소드 안에서 변수를 체크할것인가, 아니면 메소드를 호출하는 곳에서 할것인가...
메소드 안에서 체크하는 것이 정답이다.
어떤 값을 메소드에 보내든 메소드 자체는 항상 무결하기 때문이다.
정상적인 개발자라면 메소드에 변수를 보내기 전에 확인하긴 하겠지만, 그래도 메소드 내부에서도 체크해야 한다.
입력값은 언제든 어디서든 항상 철저히 체크해야 한다.
3. 머리로 디버깅하고, 컴파일러로 확인한다.
처음에는 머리로 아무리해도 안될거같지만, 연습하면 가능하다.
세상 그 어떤 디버깅 툴보다 좋은것이 사람 머리이다.
연습하고 연습하면 가능한 것이다.
여러분도 가장 뛰어난, 거기다 설치할 필요도 없는 디버깅툴을 가지고 싶지 않은가.
4. 좋은 개발자는 도구를 탓하지 않는다.
어제까지는 멋진 개발자였는데 개발툴에서 IDE 를 뺏어가서 갑자기 개허접 개발자가 되었다.
이런건 말도 안된다.
정상적인 개발자는 메모장가지고도 8-90%까지 하던거 한다.
심지어는 컴파일러 없이도 대부분 개발해놓고 컴파일러 생기면 디버깅할수도 있다.
5. 하드웨어 발전은 낙관적으로, 소프트웨어 발전은 비관적으로.
기계는 누구나 알듯이 빠르게 발전한다.
따라서 (비교적 작은) 돈만 들이면 업글이 가능하다.
그러나, 사람을 업글하는건 쉽지 않다.
따라서, 서버의 부하가 좀 있더라도, 사람(개발자)이
이해하기 쉬운 코드는 좋은 코드이다.
물론... 아주 엄한 코드는 제외.(for 문 내에서 무언가 생성하는 등등)
6. 소스에 자기 이름을 남기자.
최소한 소스 상단에 자기 이메일 주소를 남기자.
만약 이 소스가 정상적으로 작동한다면 연락할 그런 심심한 사람은 없다.
그러나, 정상 작동 안한다면 연락할 것이다.
7. 않될땐 안된다.
안될때가 있다. 그럴때 더 붙잡고 있는것은 시간낭비이다.
차라리 다른것을 하거나, 집에가서 발 씻고 자는게 낫다.
다음날 보면 소스가 다르게 보일것이다.
급하면 급할수록 더 코딩은 안된다. 급할수록 더더욱 마음을 편히 만들자.
조금씩 길이 보이게 된다.
프로그래밍이 늦어지는것은 타자가 늦어서가 아니다.
길이 안보이기 때문이란것 잊지말자.
8. 아닌건 갈아엎는게 낫다.
가끔 너무나 심하게 잘못 코딩되어 있는 소스를 보게 된다.
그럴때는 갈아엎는것도 하나의 방법이다.
9. 일정은 항상 예상치보다 1.5배 잡는다.
지나치게 빡빡한 일정은 언젠가는 사고를 일으킨다.
또한, 코딩은 언제나 위험성이 잠재되어 있는 작업니다.
그 작업중에 일정에 못맞추는 일이 생기면 납기를 놓치게 될것이다.
10. 2 대 8 법칙.
꽤나 유용한 법칙이다.
20%의 코드에서 80%의 에러가 발생한다.
20%의 코드에서 80%의 서버부하가 발생한다.
20%의 웹페이지가 80%의 조회수를 일으킨다.