구글 엔지니어는 이렇게 일한다 part 1 전제 - 1장 소프트웨어 엔지니어링이란

이직 전 책 한 권을 읽고 들어갈까 고민하던 중 요새 이 책이 그렇게 내용이 재미있고 유익하다길래 알라딘 ebook으로 사서 읽고 있다. 읽으면서 내가 느낀 내용을 각 챕터 별로 조금씩 정리를 하고자 한다.

프로그래밍? 소프트웨어 엔지니어링?

우리가 흔히 말하는 프로그래밍은 개발(development) 작업이고 소프트웨어 엔지니어링은 더 포괄적인 의미로 개발, 수정, 유지보수가 들어가 있다. 소프트웨어 엔지니어링은 더 이상 프로그래밍이 아닌 더욱 고차원의 개념이다. 수정과 유지보수는 더욱 고차원적인 개념에서 파생된 부분으로 프로그래밍과 소프트웨어 엔지니어링의 가장 큰 차이를 만들어주는 시간, (규모) 확장, 실전에서의 트레이드오프에서 비롯되었다.

시간이 프로그램에 영향을?

내가 작성을 하던, 하지 않았던 이 코드의 예상 수명을 예측해보자. 학교 과제로 만들어진 경우 더 이상 유지보수를 하지 않을 확률이 높기 때문에 예상 수명은 딱 거기까지다. 회사에서 만든 코드는 어떨까? 주요 기능으로 들어간 코드의 경우 수명은 학교 과제에 사용한 코드와 비교자체가 되지 않을 것이다. 이렇게 오래 살아남은 코드의 경우 추후 작성될 코드, 라이브러리, 운영체제 등에 많은 영향을 받고 의존을 하게 될 것이다. 우리는 이 코드가 영향을 받고 의존하게 될 것을 예상하며 코드를 작성해야 한다.
이 차이가 소프트웨어의 지속 가능성의 핵심이다.

동작하다 vs 유지보수 가능하다

사용자가 있는 프로젝트를 유지보수하고 있다면 ‘동작하다’와 ‘유지보수 가능하다’를 구분하는 가장 큰 요인은 하이럼의 법칙이다.

하이럼의 법칙
API 사용자가 충분히 많다면 API 명세에 적힌 내용은 중요하지 않다. 시스템에서 눈에 보이는 모든 행위(동작), 기능을 누군가는 이용하게 될 것이기 때문이다.

비욘세 규칙의 개발자식 이해
담당자는 개발부터 테스트까지 제대로 만들어야 한다. 다른 사람이 신경 쓸 일도 아니고 담당할 일도 아니다.

조직 성장에 따르는 비용

100명의 자바 엔지니어가 있는 조직에서 질문에 기꺼이 답해줄 전문가가 한 명만 있어도 곧 더 나은 자바 코드를 작성하는 100명의 엔지니어가 생겨납니다.

 

원점 회귀(왼쪽으로 옮기기)

어떤 개발자의 워크플로는 다음과 같은 순으로 진행된다.
개념잡기 - 설계 - 구현 - 리뷰 - 테스트 - 커밋 - 카나리 - 배포
결함 수정 비용은 지수 곡선으로 단계가 진행될 수록 그 비용이 커진다. 문제를 수정하기 위해 왼쪽 상태로 옮기는 것을 원점 회귀라 한다.

트레이드오프와 비용

모든 엔지니어링에서는 트레이드오프에 따른 비용을 생각하며 의사 결정을 해야 한다.
엔지니어링 조직의 선택을 결정짓는 요인은 다음 몇 가지로 압축된다.

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

의사결정이 ‘내가 시켰으니까’가 되어서는 안 된다.

시스템의 생애 동안 과거에 내린 결정을 수시로 재고해야 한다. 장수 프로젝트라면 초기에 정한 방향을 트는 게 가능한지 여부가 앞으로의 생존에 치명적일 수 있다. 이때 중요한 것은 결정권자에게 잘못을 인정할 권리가 있느냐이다. 어떤 사람의 직관에는 맞지 않을지 모르지만, 잘못을 인정할 줄 아는 리더가 더 존경받는다.

 

결론

소프트웨어 엔지니어링은 활용 가치가 남아 있는 한 오랫동안 코드를 유용하게 관리하고 팀 간 협업을 가능케 하는 정책, 관례 도구 모두를 아우르는 종합적인 개념이다.