- 사용자로부터 문자열 리터럴을 입력받아 SQL을 만들지 말 것. (eg: 항상 바인드 변수를 사용할 것)
- 데이터가 없는 상태 또는 실제 시스템의 극히 일부 데이터만 있는 상태에서 테스트하지 말 것. 실제 시스템의 통계 정보를 불러들이는 것도 소용 없음. 실제로 어떻게 되는지를 보려면 실제 만큼의 데이터가 필요함.
-
단일 사용자 환경에서 테스트하지 말 것. 확장성(scalability) 문제가 절대로 드러나지 않음.
-
다섯 명 이상의 개발자와 작업한다면 소스 코드 관리 시스템을 사용할 것.
CREATE,GRANT,ALTER,DROP(즉 모든 DDL, DML,create procedure,create table)으로 시작하는 모든 것을 소스 코드로 생각하고 모두 소스 코드와 동일하게 관리할 것. -
"이걸 제거한 다음 어떻게 되는지 보자"와 같은 식으로 말하지 말 것. 즉 처음부터 설계에 신경을 쓰고, 보안을 고려하고, 확장성을 생각할 것. 여러분의 시스템을 설계할 것. 일을 진행하면서 임기응변으로 대처하지 말 것. 이는 재미있게 들릴지는 모르지만, 수정하고, 패치하고, 동작하게 만들기기 위해 같은 시스템에 끊임없이 반복작업을 하게 될 것임.
-
전문가의 충고라도 자신의 상황에 실제로 적용되는지를 확인하기 전에는 무턱대고 받아들이지 말 것. 예를 들어 책에서 다음과 같은 말을 하며 이에 대한 이유나 가정, 예제, 증거를 제시하지 않는다면 가뿐하게 무시하기 바람:
- 리소스 절약을 위해 커밋을 자주 하라
- 데이터베이스의 부담을 줄이기 위해 조인을 하지 말고, 코드에서 직접 해결하라
- 기타 등등...
"왜 그런지"를 설명하려는 사람을 찾을 것. 자신의 지식을 늘릴 수 있을 뿐만 아니라 어떤 경우에 적용되지 않는지에도 이해할 수 있게 될 것임. (항상 100% 옳은 것은 없다)
-
가정을 기반으로 최적화하지 말 것. "이게 느린 것 같아"라고 말하지 말 것. "~같아"가 아니라, 그것이 실제로 느린지를 확인한 다음 최적화 할 것. 요점은, "X하는 것은 느릴 것 같다"고 하며 X를 안 하도록 시스템을 설계하는 사람들이 많은데, X가 실제로 느린지 증명할 것. (보통 데이터베이스에서 제공되는 기능이 느리다는 말만 듣고(ex: auditing) 이를 사용하지 않으려 하는 사람들이 많은데, 확인하라는 말임.)
- 그것이 실제로 느린지, 직접 구현하면 더 빠르게 할 수 있는지, 이 두가지를 모두 확인했다면 직접 구현해도 좋음.