들어가며
소프트 웨어 엔지니어링이 프로그래밍이나, 컴퓨터과학과 구분짓는 특징은 무엇인가?
프로그래밍보다는 소프트웨어 엔지니어링이 좀더 진중하다는 느낌을 준다.
기존의 다른 엔지니어링 직업들과 달리, 소프트웨어 엔지니어링의 이론과 관례는 그리 엄격하지 않다.
하지만 소프트웨어가 우리 삶에 깊숙이 파고들면서 우리도 더 엄격한 엔지니어링 방법을 따라야하는 시대가 도래 했다.
시간 위를 걷는 프로그래밍
소프트 웨어 엔지니어링은 단순히 코드를 작성하는 행위에 더하여, 시간의 흐름에 발맞춰 한 조직이 코드를 구축하고 유지보수 하는데 이용하는 모든 도구와 프로세스를 포괄한다.
이책을 통해 공유하고자 하는 핵심은 흐르는 소프트웨어 엔지니어링은 흐르는 시간위에서 순간 순간의 프로그래밍을 모두 합산한 것이다
개념잡기, 도입, 유지보수, 폐기에 이르는 생애 주기 동안 코드를 지속가능하게 하려면 코드에 어떤 관례를 도입해야 할까?
이책은 세가지 기본원칭을 강조한다.
- 시간과 변경 : 코드가 수명을 다할때까지 요구사항에 적응하려면 어떻게 해야하는가?
- 규모와 성장 : 커져가는 규모에 발맞춰 조직은 어떻게 진화하는가?
- 트레이드 오프와 비용 : 위의 두가지에서 얻은 교훈들을 바탕으로 조직은 어떻게 의사결정을 내리는가?
소프트 웨어 엔지니어링이란?
프로그래밍과 소프트웨어 엔지니어링의 가장큰 차이는 시간, 확장, 트레이드 오프 세가지이다.
소프트웨어 엔지니어링 프로젝트에서 엔지니어는 시간의 흐름과 변경될 가능성에 더 신경을 써야한다.
또한 소프트웨어 자체뿐 아니라 제작하는 조직까지 확장과 효율에 집중해야 한다.
마지막으로 수명과 성장속도를 정밀하게 예측하기 어려운 상황에서, 결과에 더 큰영향을 주는 결정을 내려야한다.
소프트웨어 엔지니어링에서 프로그래밍이 큰 비중을 차지하는것은 맞지만, 프로그래밍은 새로운 소프크웨어를 제작하는 수단이다.
시간에 따른 차이
프로그램에 "이코드의 예상수명은?" 이라는 질문을 던져보자.
대학교 과제 코드는 그날이 끝난후로 죽는다.
하지만 기반 라이브러리, 운영체제, 하드웨어 프로그래밍 언어는 수명이 길다.
수명이 길어질수록, 변경이라는 요소가 중요하다.
이러한 지속가능성이 소프트웨어 엔지니어링과 프로그래밍을 가르는 핵심이다.
소프트웨어의 기대 생애동안 변경에 대응할 수 있다면 그 프로젝트는 지속가능하다.
변경에대한것은 가능성,즉 역량이다.
역략이 없다면 그 변경이 정말로 중요해질일이 없기를 바라는것밖에 없다.
규모
협업은 그자체로 새로운 문제를 유발하지만, 한명이 개발하는것보다 가치있는 시스템을 만들어낼 잠재력이 있다.
조직이 성장하고, 규모가 커짐에 따라 소프트웨어 생산효율이 높아지는가?
프로젝트나 조긱 규모가 확장되며 딸려오는 문제는정책에 영향을 주며, 반복수행하는 일들에 비용을 얼마나 쓸 것인가? 같은 소프트웨어의 지속 가능성을 묻는질문에 답하는 기초가 된다.
트레이드 오프
소프트웨어 엔지니어의 리더는 지속가능성을 잃지 않으면서, 규모를 확장하는 비용을 관리해야 한다.
이러한 사실을 주지하고, 유지보수에 도움되는 변경을 연기하거나 확장성이 떨어지는 정책을 받아 들여야한다.
이러한 결정은 훗날 다시 검토해야할 수도 있음을 잊지 말아야하며 이 결정때문에 생긴 지연비용을 계산해야한다.
시간과 변경
오랫동안 유지보수하는 앱을 생각해보자.
어떤 프로젝트는 꾸준히 오래가기도 하지만, 어떤 프로젝트는 단발성일수도 있다.
특히 모바일 앱의 수명은 짧은 편이며, 스타트업의 소프트웨어 또한 1~2년 이상 유지보수하기가 어렵다.
자 이제 반영구적으로 살아남은 프로젝트도 있다.
구글 검색, 리눅스 커널 같은 프로젝트들이다.
이런 프로젝트를 만들때 어느 기점에, 프로젝트는 외부 환경의 변화에 대비하기 시작해야만 한다.
물론 작업규모가 크기 때문에 새로 작성하거나 포기하는경우도 있겠지만, 어느선택이 옳은지는 프로젝트의 기대수명과 이익에 달려있다.
오래지속가능하려면, 현재상태를 안정되게 유지하게 해야한다.
그래서 요구되는 변경들의 영향을 계획하고 관리해야한다.
프로그램용 코드와 수명이 훨씬 긴 프로젝트가 만들어내는 코드는 무엇이 다를까?
수명이 길어질수록 "동작한다" 와 "유지보수 가능하다"의 차이를 분명하게 인지해야한다.
하이럼의 법칙
하이럼 법칙
API사용자가 충분히 많다면 API명세에 적힌 내용은 중요하지않다.
사용자는 눈에보이는 모든 동작을 이용하게 된다.
예를들어, 라이브러리의 어떤 동작에 이상한버그가 끼어있는데, 사용자들이 버그를 이용할수도 있기에,
쉽게 수정을 하면 안되는 내용이다.
유지보수에서도 하이럼의 법칙이 적용되기때문에, 무해할듯한 변경도 일부 사용자의 프트웨어를 망가뜨릴수 있다.
그렇기에 변경이 얼마나 유용할지 조사, 식별, 해결하는데 따르는 비용도 고려해야한다.
해시 순서
해시 테이블은 밝혀지지않은 나름의 알고리즘으로 정해짐을 알고있다.
그 알고리즘이 언제까지 유지될지 구체적인 정보를 아는사람은 거의 없다.
- 해시 플더딩 공격때문에 해시 반복순서가 비결정적이여야 한다.
- 개선된 해시 알고리즘과 해시 컨테이너 연구로 얻은 효율 개선효과를 보려면 해시 반복순서에 변화를 줘야한다.
- 하이럼에 법칙에따라 해시테이블의 순회 순서에 의존하는 프로그램을 작성하는 프로그램이 나타난다.
해시 컨테이너의 반복순서에 의존하더라도 해시 컨테이너
- 내가 마음에 드는 문장
- 분산빌드로 넘어오면서 빌드속도를 줄이는것에 대한 관심이 멀어졌다. (효율이 좋아지면 자원소비가 늘어난다.)
-프로그래밍은 코드를 생산하는 즉각적인 행위이며, 소프트웨어 엔지니어링은 코드를 유용하게 관리하고 팀간 협업을 가능케하는 정책 관계 도구 모두를 아우르는 종합적인 개념이다.
