ch.1 소프트웨어 엔지니어링이란

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

• 시간, 규모(확장), 실전에서의 트레이드오프 이다.
  1. 시간
  • 소프트웨어 엔지니어링은 시간의 흐름과 변경가능성, 지속가능성을 신경써야한다.
  • 프로그래밍 = 개발
  • 소프트웨어 엔지니어링 = 개발 + 수정 + 유지보수 2. 규모
  • 소프트웨어 엔지니어링은 팀 업무이다. 3. 실전에서의 트레이드오프
  • 지속가능성을 고려하여 조직,제품,개발 워크플로의 규모를 확장하는 비용을 관리해야한다.

    1.1 시간과 변경

    하이럼의 법칙 (Hyrum’s law)

• 사용자가 충분히 많다면, API 명세에 적힌 내용만 사용되지않고, 시스템에서 눈에보이는 모든 동작을 누군가는 사용하고있을것이다.
• 변경이 얼마나 유용할지 분석할때는, 변경으로인해 일어날 충돌을 조사,식별,해결하는데 따르는 비용도 고려해야한다.

ex_해시순서

• Hash table 순서는 내부 나름의 알고리즘을 가지고 구현되어있는데, 순서가 비결정적이기때문에, 순서에 의존하면 안된다.
• 이용하는 API에 명시되지않은 기능을 활용하는 코드는 임시 방편적, 기발한 코드.= 프로그래밍
• ,, 의 모범사례를 따르고 미래에 대비한 코드는 clean 하고 유지보수 가능한 코드.= 소프트웨어 엔지니어링
• 우리는 ‘기발한‘이 칭찬으로 느껴진다면 프로그래밍, 질책으로 느껴진다면 소프트웨어 엔지니어링이라고 말한다.

‘변하지 않기’를 목표로 하지 않는 이유

• 소프트웨어 설계도 제때 변경해주지 않으면, 최신 하드웨어를 도입하는 효과가 퇴색된다.
• 최신 장비의 잠재력을 최대한 끌어 쓸 의지와 역량이 없다면 지불한 비용만큼의 효과를 얻지 못할 수 있다 > 비효율적!

1.2 규모 확장과 효율성

• 코드베이스의 수명이 다할때까지 직면하는 변화가 몰고오는 모든 변경을 안전하게 처리할 수 있다면, 그 코드베이스는 지속 가능하다.
• scalable: 규모 확장에 따른비용이 선형보다 완만하게 증가해야한다.
  • 100의 작업을 반복해서 수행할때 100의 노력이 필요하다면 확장가능하지 않은것.
• 빌드소요시간, 코드베이스를 clone하는 시간, 버전업그레이드 비용 등은 조직차원에서 관리해야한다.

확장하기 어려운 정책들

• 확장성이 낮은 정책을 찾는 방법
  1. 조직이 커졌을때, 작업도 똑같이 많아지는가
  2. 조직이 커졌을때, 엔지니어가 해야할 양도 늘어나는가
  3. 코드베이스가 커질수록 작업양도 늘어나는가
     • 1,2,3 위 질문들중 작업을 자동화하거나 최적화할 수 있는가? > NO 라면 확장성이 낮은것.
• ex) 버전업으로 인한 마이그레이션 작업을 사용자에게 책임을 넘기는것
  • 확장가능한 폐기방식 : 시스템 담당 팀 내부에서 스스로 처리할수 있도록 책임소재를 옮겨야한다.

    확장가능한 정책들

• 비욘세 규칙 : 코드를 짰으면 자기 코드에 대한 테스트도 제대로 만들었어야지
  • 인프라 변경으로인한 서비스 장애발생이 있더라도, CI 자동테스트에서 발견되지 않았다면 인프라팀의 책임이 아니다.

    사례 : 컴파일러 업그레이드

• 구글에서 최초 컴파일러 업그레이드를 시도했던 2006년에, 결국 의존성을 끊지못하고 변경사항 중 적용방법을 찾지못한 것들을 우회하는 방식으로 해결하였는데, 이는 이후에 하이럼법칙 문제들의 발견 등 으로 더 큰 문제를 야기했다.
• 인프라는 더 자주 변경할수록 변경하기가 오히려 쉬워진다
• 코드베이스의 유연성에 영향을 주는 요인
  • 전문성
  • 안정성 : 더 규칙적으로 배포하여 변경량을 줄였다.
  • 순응 : 규칙적인 업그레이드
  • 익숙함 : 잦은 업그레이드로 발견된 중복작업을 자동화
  • 정책 : 비욘세규칙과 같은 유용한 정책과 절차를 갖추어 인프라팀에서는 하이럼의 법칙을 고민하지 않고 업그레이드를 할 수 있다.

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

• 결함 수정비용은 개발과정 초반(설계,개발,,) 에서 발견할수록 줄어든다. <> 배포후에는 결함수정 비용이 커짐
• 결함발견 시점을 초반에 잡을 수 있도록 품질,안정성,보안문제 등을 알려주는 도구와 관례를 사용하는 전략.

트레이드오프와 비용

• 비용 : 금융 + 리소스(CPU) + 인적비용 + 거래비용(조치를 취하는 비용) + 기회비용(조치를 취하지 않는 비용) + 사회적 비용(선택이 사회에 미치는영향)
• 소프트웨어 엔지니어링처럼 창의적이고 수익성높은 분야에서는, 금융보다 인적비용이 제한요소일 가능성이 커서, 워라벨을 높여주어 직업 만족도를 높여주면 효율이 높아진다?

화이트보드 마커

• 브레인스토밍이 마커가 고장나서 찾아다니는것보다 중요하다고 판단한 구글.
• 좋은 엔지니어링이란 가용한 모든 근거자료에 적절한 가중치를 부여하고, 풍부한 지식을 바탕으로 균형점을 잡는 일.
• 선택을 결정짓는 요인
  • 반드시 해야하는일 : 법적 , 고객의 요구사항
  • 근거에 기반하여 당시 내릴수있는 최선의 선택 : 적절한 결정권자가 확정.
• 의사결정의 이유가 ‘시켰으니까’ 가 되면 안된다.

의사결정을 위한 근거 자료

• 관련한 정량적데이터를 측정하거나 추정하여 결정하는 경우, 결정으로 인한 결함이 줄어든다.
• 정량화하기 어려운 정보로 의사결정을 위해서는 경험,리더십,선례에 기대어 선택하게 되는데, 이런 결정에도 똑같은 우선순위를 가져야한다.

사례 : 분산 빌드

• 로컬빌드로 인해 소요되는 시간과 로컬장비 성능향상 필요성으로 인해 소요되는 비용이 커서 프로덕션 환경에 분산 빌드 시스템을 구축했으나, 빌드 최적화의 중요성이 떨어지면서 빌드자체의 속도가 느려졌다.
• 빌드 최적화를 놓침으로써 필요할 비용을 예측하지못했다 > 추후에야 시스템의 목표와 제약을 설정하고 모범사례를 만들어 투자함.

사례 : 시간과 규모 확장 사이에서 결정하기

결정 재고하기와 잘못 인정하기

• 데이터에 기초한 의사결정을 선호하기때문에, 데이터가 시간의 흐름에따라 변화하여 과거의 결정이 오류가 있었는지 수시로 돌아봐야한다.
• 판단을 내리고, 그 판단을 검증하는것이 중요하다.

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

• 이 둘에 적용되어야하는 제약사항, 가치, 모범사례가 다른것일뿐 SWE가 더 좋다는것이 아니다.

정리

• 프로그래밍은 코드생산에 관한것
• SWE는 SW 수명까지 코드를 유지보수하는 문제를 포함.
• 코드의 기대수명동안 의존성,기술,제품 요구사항 변경 등에 대응할 역량이 갖춰어져야 지속가능한 소프트웨어.
• 전문성은 규모의 경제와 결합될때, 조직이 커질수록 효과가 커진다.