들어가며
소프트웨어 개발을 하면서 발생하는 다양한 상황에 맞는 법칙을 찾아 봤습니다.
머피의 법칙
가장 흔하게 사용하는 법칙.
어떤 일이 잘못되어 가는 상황에 대해 이야기할 때 서양에서 흔히 사용되는 말입니다. 즉, 하려는 일이 항상 원하지 않는 방향으로만 진행되는 현상이 발생할 때 주로 사용합니다.
이 법칙을 회피 하려면, 방어 프로그래밍, 버전관리, TDD 등을 활용해야 합니다.
브룩스의 법칙
프레더릭 브룩스가 자신의 1975년 저서 《맨먼스 미신》 (The Mythical Man-Month)에서 "지체되는 소프트웨어 개발 프로젝트에 인력을 더하는 것은 개발을 늦출 뿐이다"라고 주장한 법칙입니다.
이 법칙은 호프스 태터의 법칙에 의해 회피 할 수 없습니다.
호프스 태터의 법칙
더글라스 호프스 태터가 자신의 1979년 저서 《괴델, 에셔, 바흐 : 영원한 황금 노끈》에서 "그 일은 항상 당신이 예상한 것보다 더 오래 걸린다, 비록 호프스 태터의 법칙을 고려했다고 해도 말이다."라고 주장한 법칙입니다.
이 법칙을 회피 하려면, 예상된 일정의 2~3배의 버퍼를 두면 됩니다.
콘웨이의 법칙
멜빈 콘웨이가 1968년 "모듈 프로그래밍 국제 심포지움”에 가서 발표한 논문에서 "모든 시스템은 그 조직의 의사소통 구조와 동일하게 만들어진다."라고 주장한 법칙입니다.
시스템의 구조가 엉망이라면, 그 조직의 의사소통 구조가 엉망이라서 그렇습니다.
이 법칙을 회피 하려면, 의사소통 구조 부터 개선해야 합니다.
포스텔의 법칙
존 포스텔이 전송 제어 프로토콜(TCP) 의 명세를 작성할때, "TCP 구현은 견고함의 원칙을 따라야 한다: 당신이 하는 일은 엄하게, 남의 것을 받아들일 때는 너그럽게”라고 설명한 것으로 견고함의 원칙으로도 불립니다.
이 원칙을 지키는지 여부에 따라 성공과 실패가 결정되기도 합니다. 오늘날의 고도로 발달된 환경에서는 꼭 지켜야 하는 법칙입니다.
파레토 법칙
80대 20 법칙으로도 불리는 파레토 법칙은 전체 결과의 80%가 전체 원인의 20%에서 일어나는 현상을 말합니다.
이것은 코드의 버그 중 80% 는 코드의 20% 에서 발생한다는 고통스러운 진실을 말합니다. 아니면, 지금 하고 있는 업무 성과의 80%는 20%의 팀원이 수행했다는 의미도 됩니다. 문제는 내 코드가 20% 에 포함되지 않는 다는 보장이 없고, 내가 20%의 팀원이라는 보장이 없다는 것입니다.
20%의 코드에 포함되지 않기 위해 TDD 를 권합니다.
20%의 팀원에 포함되기 위해서는 많은 고민이 필요 합니다.
피터의 법칙
1969년 로렌스 피터교수가 발표한 경영 이론입니다. 이론에 따르면 승진은, 승진 후보자의 승진 후 직책에 관련된 능력보다는 현재 직무 수행 능력에 근거하여 이루어진다고 합니다. 즉, 승진 후 업무 능력이 고려되지 않기 때문에 승진 후 무능력해 보이는 임직원이 많아 지는 현상을 말합니다.
내가 속한 조직의 무능력 임직원이 많다면, 당연한 것입니다. 당신도 승진하면 무능력해집니다.
내가 속한 조직의 무능력 임직원이 적다면, 당신은 승진 할 수 없을지도 모릅니다.
이 법칙을 회피하는 방법은 모릅니다.
리누스의 법칙
리눅스의 작성자인 리누스 토르발즈의 이름을 딴 이 법칙은 1999년 에릭 레이몬드의 저서인 《성당과 시장》에서 "눈알이 충분하면 모든 버그를 발견할 수 있다."라고 주장한 법칙입니다. 즉, 코드를 확인하고 사용하는 사람이 많을 수록 수정할 부분이 누군가의 눈에 명확히 보이게 된다는 것입니다.
이 법칙에 따르면, OpenSource 는 시간이 지날 수록 점점 더 빠르고 견고해 질 것입니다.
무어의 법칙
인텔의 공동 설립자인 고든 무어가 1965년에 “반도체 집적회로의 성능이 24개월 마다 2배로 증가한다.” 라고 주장한 법칙입니다. 즉, 컴퓨터의 처리 능력은 2년마다 두배가 됩니다.
이 법칙에 따르면, 새로 구축한 시스템은 2년뒤 구축한 시스템에 비해 동일 처리를 위해 2배의 비용을 지불하고 있는 것과 동일합니다. 개발자에게 2년 단위로 노트북을 새로 구매해 줘야 하는 타당한 이유가 됩니다.
워스의 법칙
“소프트웨어가 하드웨어 보다 빠르게 빨라진다.” 라는 법칙입니다.
이 법칙에 따르면, 매년 개발자에게 IntellJ 의 라이센스를 제공해야하는 타당한 이유가 됩니다.
이 법칙을 따르지 않고, 무어의 법칙도 따르지 않는다면, 2년 뒤 동일 처리를 위해 2배 이상의 비용을 지불하는 것과 같습니다.
90%의 법칙
"코드의 90%는 개발 기간의 10%를 차지 합니다. 나머지 10%의 코드가 90%의 개발 기간을 차지 합니다.” 라는 법칙으로 진행률 90% 에서 더 진척이 안되는 이유를 설명합니다. 이를 해결하기 위해 인력을 더 투입할 경우 브룩스의 법칙과 마주하게 됩니다.
이 법칙을 피하기 위해 호프스 태터의 법칙을 활용하는 것이 좋습니다.
결론
그냥 웃자고 쓴 내용입니다.