1장 - 소프트웨어 엔지니어링이란?

프로그래밍과 소프트웨어 엔지니어링의 차이

책에서는 프로그래밍과 소프트웨어 엔지니어링을 나누어 소개합니다.

소프트웨어 엔지니어링을 수행할 때 프로그래밍이 큰 비중을 차지합니다.

 

• 프로그래밍 = 개발
• 소프트웨어 엔지니어링 = 개발 + 수정 + 유지보수

 

과연 이 코드의 예상 수명은 얼마일까?

가장 중요한 포인트는 지속가능성이다.

 

그러면 프로그래밍 < 소프트웨어 엔지니어링일까?

무엇이 값지다고 판단할 수는 없습니다.

며칠 동안 사용될 프로젝트에 통합 테스트나 지속적 배포(CD)는 필요 없을 수 있습니다.

 

시간과 변경

구글 검색, 리눅스 커널, 아파치 HTTP 서버는 반영구적으로 살아남는 성공한 프로젝트들입니다.

소프트웨어의 기대수명이 수십년에 달하게 되면 업그레이드가 필요해집니다.

 

하지만 점진적 업그레이드가 아닌경우에는 매우 큰 비용이 발생합니다.

결국에는 차세대와 같이 기존 코드를 버리고 새로 작성하곤 합니다.

 

업그레이드를 수행할때는 고통을 덜어줄 방법을 찾아야 하며 비용, 이익, 기대 수명을 잘 고려해야 합니다.

 

하이럼의 법칙

API 사용자가 충분히 많다면 더 이상 API 명세는 중요하지 않습니다.

시스템에서 눈에 보이는 행위를 누군가는 이용합니다.

 

• 누군가는 해시 테이블의 원소 순서가 항상 같은 결과를 나타낼 것이라 기대하고 코드를 작성할 수 있습니다.
• 누군가는 항상 같은 순서로 역직렬화된다고 가정한 코드를 작성할 수 있습니다.

 

확장성

• 조직이 10배로 커지면 이 작업도 10배로 많아지는가?
• 엔지니어가 해야 할 일이 조직이 커질수록 늘어나는가?
• 코드베이스가 커질수록 작업량도 늘어나는가?

 

위의 질문에 해당할 경우 다음 질문에 답이 아니오라면 확장성에 문제가 있는 것입니다.

• 해당 작업을 자동화하거나 최적화할 수단이 있나요?

 

원점 회귀

제품을 고객에게 배포한 후 취약점이 발견되면 해결하는 비용이 막대합니다.

하지만 배포 직전에 발견하고 해결하면 더 저렴해집니다.

만약 개발자가 커밋하게 전에 알게 된다면 훨씬 더 저렴해집니다.

 

이런 이유로 정적 검사, 코드리뷰를 수행합니다.

 

 

의사 결정

• 반드시 해야 하는 일 (법적 요구사항, 고객 요구사항)
• 근거에 기반하여 당시 내릴 수 있는 최선의 선택(적절한 결정권자가 확정)

 

누군가 의사결정을 하지만 "누가 시켰으니까"가 되어서는 안 됩니다.

잘못된 결정이라고 판단되면 찾아가야 할 사람들의 에스컬레이션 경로도 명확히 정의해야 합니다.

 

 

내가 2주 동안 연결 리스트를 고성능 데이터 구조로 변환하면 메모리 5GB를 더 쓰지만 필요한 CPU 수를 2,000개 줄일 수 있어, 진행해야 할까요?

메모리와 CPU 비용뿐만 아니라, 2주간의 소프트웨어의 인건비, 기회비용 (2주 동안 엔지니어가 할 수 있는 다른 일)까지 고려해야 합니다.

 

구글에서는 데이터를 기초한 의사결정을 강력히 지지합니다.

하지만 데이터는 시간이 지나면 변할 수 있습니다.

따라서 과거의 내린 결정들도 수시로 재고해보아야 합니다.

하지만 데이터에 기초하되 측정할 수 없는 요인들도 고려해야 하며 리더에게 요구되는 덕목입니다.