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