Til 구글은 이렇게 일한다 1장

JPA 강의

• database를 java collections 사용하듯
• Java Persistence API -> 프로그램이 종료되어도 값이 보관되도록 해주는 api

구글이렇게일한다

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

• 흐르는 시간위에서 순간순간의 프로그래밍을 모두 합한것
• 시간이라는 요소가 더해지면서 프로그래밍에는 중요한 차원이 하나 더 늘어 입체적으로 바뀐다.
• 정육면체는 정사각형이 아니고 거리는 속도가 아니듯 소프트웨어 엔지니어링은 프로그래밍이 아니다.
• 소프트웨어 작업 하나는 대체로 개인창작이지만 소프트웨어 엔지니어링은 팀 업무
• 프로그램의 수명이 길어질수록 동작한다와 유지보수 가능하다의 차이를 분명하게 인지해야한다.

1.1 시간과 변경

• 1.1.1 하이럼의법칙
  • 최선의 의도 최고의 엔지니어 꼼꼼한 코드리뷰가 뒷받침 되더라도 공표한 계약(명세)나 모범사례를 완벽하게 구현해냈다 단정할수 없다.
  • API소유자는 인터페이스를 명확하게 설명해놓으면 어느정도 유연성과 자유를 얻을 수 있지만 현실에서는 사용자가 명세에 없는 기능을 찾아 활용하기도 하며 그 기능이 유용해 널리 쓰이면 추후 API를 변경하기도 어렵게된다
  • 노출시간이 길어지고 사용자가 늘다보면 가장 무해할듯한 변경도 일부 사용자의 소프트웨어를 망가트릴수있다.
• 1.1.2 해시순서
  • 해시반복순서가 무작위임을 눈치챈 누군가는 이를 난수발생기로 사용할수도있다. ㅋㅋㅋ
  • 동작한다와 옳다의 차이
  • 당장 돌아가야하는 코드와 언제까지고 작동해야하는 코드의 차이
  • 이용하는 API명세에 명시되지않은, 즉 언제든 변할 수 있는 기능을 사용하는 코드는 임시방편적(hacky) 혹은 기발한(clever)코드이다.
  • 반대로 모범사례를 따르고 미래에 대비한 코드는 클린하고 유지보수 가능한 코드이다.
  • 둘 다 나름 목적이 있지만 어느쪽을 선택할지는 코드의 기대 수명에 크게 좌우된다.
  • 구글에선 기발한이 칭잔이라 느껴진다면 프로그래밍, 질책으로 느껴진다면 소프트웨어 엔지니어링이라고 한다.
• 1.1.3 변하지않기를 목표로 하지 않는 이유
  • 변경은 피할 수 없다.
  • 보안취약점, 장비의 발전 등..
  • 지속 가능성에 투자하지 않는 장기 프로젝트는 위험하다.
  • 변경은 본질적으로 좋지 않으니 변경을 위한 변경은 삼가하여야 하지만.. 변화에 대응은 할 수 있어야한다.

1.2 규모 확장과 효울성

1.3 트레이드오프

비욘세 규칙

제번스의 역설 : 효율이 좋아지면 자원소비가 늘어난다. 자원소비를 줄이려는 기술혁신이 자원의 가격을 떨어뜨려서 오히려 소비를 늘리는 경향이 있다. 가령 연비를 높인 자동차를 내놓으면 운전자들이 더 자주 멀리 차를 몰고 다니게된다.

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

1.5 마치며

부디 이 책이 '나의 코드가 마지막 필요한 순간까지 제대로 작동하게 하려면 어떻게 유지 관리해야 하는가?' 라는 보편적인 질문의 답을 찾는데 유용한 틀이 되기를 바랍니다.

1.6 정리

차원의 개수라는 점에서 소프트웨어 엔지니어링과 프로그래밍은 다르다. 프로그래밍은 코드 생산에 관한 즉각적인것. 소프트웨어 엔지니어링은 프로그래밍을 확장하여 소프트웨어의 수명이 다할때까지 코드를 유지보수하는 문제까지 고려한다. (소프트웨어 엔지니어링은 시간위에 프로그램들의 합이다.)

단명하는코드와 장수하는코드의 수명차이는 10만배는 될것이다. 동일한 보함사례를 수명양끝단에 위치하는 두 사례에 똑같이 적용하려는건 너무 안일하다.

코드의 기대 수명동안 의존성, 기술, 제품 요구사항 변경에 대응할 역량이 갖춰져야 지속가능한 소프트웨어이다. 여러 이유로 변경을 하지 않기로 선택하더라도 변경할수있는 역량 자체는 필요하다.

• 하이럼의 법칙 : API사용자가 충분히 많다면 명세에 적어놓은 내용은 중요하지않게된다. (명세에 없더라도) 시스템에서 눈에 보이는 모든 동작(행위)를 누군가는 이용하게된다
• 조직에서 반복적으로 수행하는 모든 작업은 필요 인력 측면에서 확장 가능해야한다. 정책은 개발프로세스를 확장가능하게 해주는 아주 멋진 도구이다.
• 개발 프로세스를 포함한 소프트웨어 개발 업무의 많은 것의 효율은 눈치채기 어렵게 천천히 나빠지는 경향이 있습니다. 끓는물속의 개구리가 되지 않도록 주의합시다.
• 전문성은 규모의 경제와 결합될때, 즉 조직이 커질수록 효과가 커진다.
• 누군가 시켰으니까라는 이유로 어떤일을 수행하는것은 아주 끔찍하다.
• 의사결정을 데이터 주도로 하겠다는 생각은 좋은 출발이다. 하지만 현실에서 대부분 의사결정은 데이터, 가정, 선례, 논의를 종합하여 이루어진다. 고려 요소의 대부분에 객관적인 데이터가 주어지면 가장 좋겠지만 순전히 데이터만으로 결정되는 경우는 드물다.
• 데이터 주도 방식은 시간이 흘러 데이터가 변하면(혹은 가정이 무너지면) 프로젝트의 방향도 바뀔 수 있음을 뜻한다. 잘못을 인정하고 계획을 수정하는것은 당연한 일이다.