If anythong can go wrong, it will (뭔가 잘못될 수 있다면 반드시 일어난다.)
프로그래머는 기본적으로 눈 앞에 있는 모든 것을 의심해야 한다.
자신이 작성한 메쏘드에 입력되는 인수가 혹시 null은 아닌지,
적정한 범위를 벗어나는 값은 어닌지,
리스트에 포함된 객체가 혹시 엉뚱한 객체의 타입은 아닌지 등을 확인하고 점검하고, 검증하는 것
방어적 프로그래밍의 원리는 알고리즘의 복잡성을 최소화 하라.
Defensive programming is a form of defensive design intended to ensure the continuing function of a piece of software in spite of unforeseeable usage of said software. The idea can be viewed as reducing or eliminating the prospect of Murphy's Law having effect. Defensive programming techniques are used especially when a piece of software could be misused mischievously or inadvertently to catastrophic effect. -위키피디아
2. 성능과 확장성을 염두에 두기
일단은 요구사항대로 동작하는 프로그램을 작성하라. 성능 최적화는 제일 나중에 할일이다.
단, 성능 최적화를 신경쓰지 말라는 얘기가 아니라 개발 초기에는 소스트웨어 성능 최적화에 많은 시간을 할애하지 말라는 얘기다. 예로, '게으른 초기화(lazy initialization)',
아무곳에서나 맘대로 쓰레드 생성 vs 쓰레드 풀 사용
3. if-else 구문 사용하지 않기
if-else 구문을 아예사용하지 말라는 얘기는 아니고, 하나의 알고리즘에 서로 다른 성격의 기능을 수행하게 강제시키기 위하 if-else를 사용하지 말라는 얘기이다.
단기적으로는 개발이 편할지 모르나 결국 코드의 복잡성을 높혀서 관리가 어려워지고, 버그 가능성도 높아지고 프로그래머 지능을 낮게 만든다.
if-else 대신 새로운 메소드나 객체를 만들라.
- 버그의 '수'에 집착하지 말고 '성격'을 따져보는 습관을 가지자
- 프로그래머가 버그를 만들어내는 것은 모르고 그러는 것 보다 알고 그러는 경우가 더 많다.
- 당장의 눈앞의 기능을 만드는데 급급하기 때문에 스스로 타협하고 자신만의 규칙을 만들어낸다.
- 방어적 프로그래밍은 지금 이 순간 한줄의 코드를 작성하면서도 감각적으로 적용되어야 하며 그 순간이 지나고 나면 그 코드로 다시 돌아갈 수 있는 경우란 없다. 순간에 대한 집중력, 그것이 방어적 프로그래밍이 필요로 하는 것이다.
- 프로그래밍은 '소설가' 이다. 혼자 읽기 위한 소설은 없듯이 남이 읽기 위한 코드가 되어야 한다. 프로그래머는 현학적이면 안된다.
refer to '프로그래밍은 상상이다-임백준'
