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

매주 '구글엔지니어는 이렇게일한다' 라는 책을 스터디 하기로 했다.
그래서 스터디를 진행하기 위해 내용을 정리하기 위해 글을 작성합니다. 문제가 될 시 비공개로 전환하겠습니다.

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

소프트웨어 엔지니어링과 프로그래밍의 차이점을 설명해 준다.

• 프로그래밍과 소프트웨어 엔지니어링의 가장 큰 차이는 시간, (규모)확장, 실전에서의 트레이드 오프이다.
  • 시간:
    • 시간이 프로그램에 미치는 영향을 알아보려면 이 코드의 예상 수명은 이라는 질문을 던져보면 좋다.
    • 짧게 생을 막마하는 코드는 대체로 시간의 영향을 받지 않는다.
    • 수명이 길어질수록 변경이라는 요소가 점점 중요해진다. -> 십 년 이상 살아남는다면 간접적이든 직접적이든 프로그램의 거의 모든 의존성이 처음과는 달라질 것이기 때문이다.
  • 지속 가능성
    • 기술적인 이유든 사업적인 이유든, 소프트웨어의 기대 생애 동안 요구되는 모든 가치 있는 변경에 대응할 수 있다면 그 프로젝트는 지속 가능하다고 말한다.
  • 규모
    • 소프트웨어 엔지니어링과 프로그래밍은 시간과 참여 인원 면에서 차이가 난다.(팀업무로 개발이 진행 된다.
      • 시간의 흐름에 따라 엔지니어들은 개발과 유지보수의 어느 부분에 관여하는가?
      • 몇 명이 참여하는가?
  • 의사결정의 복잡성과 이해관계
    • 소프트웨어 엔지니어링에서는 주기적으로 여러 선택지 사이의 트레이드오프를 평가해야 한다.
      • 때로는 불완전한 지표에 기대어 결과에 커다란 영향을 주는 선택을 해야 한다.

시간과 변경

어플리케이션의 생존기간에 따른 업그레이드의 중요도를 설명해준다.

• 기대수명
  • 소프트웨어의 기대 수명이 수년 수십년을 바라볼 경우 외부 환경의 변화에 대비를 시작해야한다.
  • 외부 환경대비를 안할 경우의 단점
    • 해당 프로젝트에서 수행해본 적 없는 작업을 진행해야 한다.
    • 업그레이드 담당 엔지니어들이 이런 종류의 작업을 경험해보지 못했을 가능성이 크다.
    • 일반적인 업그레이드보다 작업 규모가 큰 경우가 많다. 점진적으로 업그레이드하는 것이 아니라, 수년치 업그레이드를 한 번에 진행해야 하기 때문이다.
  • 기존 코드를 버리고 새로 작성하거나 기존 코드를 유지보수하거나 모든 결정은 업그레이드 비용, 업그레이드가 가져다줄 이익, 프로젝트의 기대 수명에 달려 있다.

하이럼의 법칙

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

• 시간의 흐름에 따른 변경과 유지보수를 논하려면 하이럼의 법칙을 알아야 한다.
• 하이럼의 법칙은 최선의 의도, 최고의 엔지니어, 꼼꼼한 코드 리뷰가 뒷받침되더라도 공표한 계약이나 모범 사례를 완벽하게 구현해냈다고 단정할 수 없다는 현실을 표현한 말이다.
  • API소유자는 인터페이스를 명확하게 설명해놓으면 어느 정도의 유연성과 자유를 얻을 수 있다.
• 당장 돌아가야 한다라는 생각으로 작성한 코드와 언제까지고 작동해야 한다라는 생각으로 작성한 코드의 차이를 생각해야 한다.
  • 이용하는 API의 명세에 명시되지 않은 즉 언제든 변할 수 있는 기능을 사용하는 코드는 임시방편적인 혹은 기발한 코드이다.
  • 반대로 모범 사례를 따르고 미래에 대비한 코드는 클린하고 유지보수가 가능한 코드이다.
  변하지 안힉를 목표로 하지 않는 이유
  • 대부분의 프로젝트는 세월이 충분히 흐르면 기반 환경을 모두 교체해야 할것이다.

규모 확장과 효율성

• 프로젝트 규모가 커진다면 비용을 생각해야한다. 비용을 생각할 때 인건비 외에도 메모리, 스토리지, 대역폭 같은 전통적인 자원들의 비용들도 생각해야 한다.
• 코드베이스 자체도 확장이 가능해야한다.
  • 코드가 많아지고 변경 이력이 쌓이는 등의 이유로 빌드 시스템이나 버전 관리 시스템이 점점 느려진다면 어느 순간 더는 정상 운영 할 수 없는 시점이 오기 때문이다.
• 조직에서 코드를 작성하고 관리하는데 활용하는 모든 것이 총비용과 자원 소비 측면에서 확장 가능해야 한다.
  • 특히 반복적으로 수행하는 일이라면 모두 인적 비용 측면에서 확장 가능해야 한다.

확장하기 어려운 정책들

• 시스템 폐기
  • 새로운 위젯을 개발했을 때 모두가 기존 것을 버리고 새 위젯을 쓰기로 결정 했을 경우 의존성 그래프가 조금만깊고 넓어지면 곧바로 실패하게 된다.
• 개발 브렌치활용하는 방법
  • merge를 관리하기 위해 철저히 통제하고 빈도를 줄일 경우(개발 브렌치를 나눠서 개발), 작은 조직에서는 쉽게 관리할 수 있지만, 규모가 큰 조직일수록 엄청난 시간이 할애된다.

확장 가능한 정책들

• 비욘세 규칙
  • 같은 문제가지속적 통합(CI)시스템의 자동 테스트에서 발견되지 않는다면 인프라팀의책임이아니다라는 정책
    • 공통CI시스템에 추가해두지않은 테스트는 인프라팀이 책임을 지지 않는다.
    • 테스트코드의 확장하여 쓸 수 있다는 예시이다.

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

• 개발 과정에서문제를 일찍발견할수록 비용이 적게든다.
  • 개념잡기 -> 설계 -> 구현 -> 리뷰 -> 테스트 -> 커밋 순으로 개발은 진행된다. 이 때 왼쪽으로 갈수록 문제를 발견했을 때 비용이 적게든다.

트레이드오프와 비용

트레이드오프 또는 상충 관계는 다른 측면에서 이득을 얻으면서 집합 또는 디자인의 품질, 양, 속성을 없애거나 잃어버리는 일이 수반되는 상황적 결정이다. 즉, 하나가 증가하면 다른 하나는 무조건 감소한다는 것을 뜻한다

개발 시간을 늘리면 제품의 완성도는 높아지겠지만, 개발 시간이 늘어날 수록 비용이 증가하게 된다. 

• 집중력이생상선에미치는 영향은 아주 크다.
• 비용의 정확한 의미
  • 투입된 노력과 다음의 요소들 까지 모두 포괄 된다.
  • 구성이 스스로의 가치를 느끼고 생산적인일을하고 있다는 생각까지 포함된다.

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

• 시간 흐름에 따른 코드 관리, 시간 흐름에 따른 규모 확장의 영향, 이런 관점에서의 의사 결정 방식등의 차이점이 존재한다.
• 프로그래밍은 코드를 생산하는 즉각적인 행위이다.
• 소프트웨어 엔지니어링은 활용 가치가 남아 있는 한 오랫동안 코드를 유용하게 관리하고 팀 간 협업을 가느케 하는 정책, 관례,도구 모두를아우르는 종합적인 개념입니다.