심플 소프트웨어

책을 읽자 “심플 소프트웨어” !!!

책의 모든 내용이 아니며, 책을 읽는게 더 좋습니다. 
이 요약은 친절하지 않습니다.
"심플 소프트웨어" 정가:18000원 출판사:길벗 
주관적으로 판단한 주요 내용들은, 저의 뇌내 이해를 위해 축약 되었습니다.

1.시작하기전에

• 가능 한 좋은 프로그래머가 되기를 진심으로 원하지 않는 사람이라면
  아무리 가르치고, 지적하고, 세미나를 보내도 의미가 없다.
  그런 사람은 나아지지 않는다.
• 무언가 할 거라면, 그 분야에서 앞서 나가기 위해 최선을 다해야 한다.
• 더 나아지려면 나아지려는 의욕이 있어야 한다.

2.엔지니어의 자세

• 어떤 문제든 그 문제를 해결할 올바른 방법이 항상 존재한다.
• ‘올바른 방법’ == ‘발생할 수 있는 모든 상황에 대응하는 방법’
  여기에는 ‘상상할 수 없는 미지의 상황’ 도 포함한다.
• 단순성을 유지하는 동시에 미래에 있을 기능 개선에 대처할 유연성까지
  갖춘 소프트웨어 코드라면 ‘올바른 방법’ 이라고 볼 수 있다.
• 올바른 방법을 모른다는 핑계로 올바르지 않은 방법과 타협하지 말자.
  조금 더 공부하면 해결 할 수 있는 문제다.
• 올바른 방법들에 대한 논쟁은 신뢰성이 높은 시니어의 검토를 거쳐보자.
• 귀찮고 지치고 배고프다고, 여유가 없다고 하더라도 우리는 올바른 방법을 찾고 행해야 한다. 잠시 마음의 여유를 가지자.
  잠시 쉰다고 무책임한 것이 아니다. 올바른 방법으로 문제를 풀 환경과 상태를 갖추는 것도 중요하다.

3.능력자 프로그래머의 한 가지 비밀

• ‘자신이 하는 일을 잘 이해할수록 그 일을 더 잘한다.’
  소프트 웨어 개발자의 성패를 결정 짓는 단 한가지의 사실이며 핵심이다.
• 뛰어난 프로그래머가 되는 길은 기본을 깊이 있게 이해하는 것부터 시작하여 최첨단 데이터를 다룰 수 있는 수준에 닿을 때까지 완벽한 이해를 갖추는 것이다. 오랜 시간이 걸리는 일이지만 가치 있는 일이다.

4.두 문장으로 요약한 소프트웨어 설계

• 구현에 드는 수고보다 유지 보수에 드는 수고를 줄이는 게 더 중요하다.
• 유지 보수에 드는 수고는 시스템의 복잡성에 비례한다.

5.복잡성의 단서

코드가 복잡하다는 걸 알려주는 단서.
1. 약간의 '꼼수'를 써야만 코드가 잘 작동한다.
2. 다른 개발자들이 코드 작동 방식을 계속 물어본다.
3. 다른 개발자들이 코드를 잘못 사용해 버그가 계속 발생한다.
4. 경력이 많은 개발자조차 한 줄의 코드를 바로 이해하지 못한다.
5. 그 코드를 수정할 생각을 하면 두렵다.
6. 관리자가 클래스 하나 혹은 파일 하나를 다루는 일에 여러 개발자를 붙이려 한다.
7. 기능 추가 방법을 알아내기 어렵다.
8. 그 코드에 어떤 사항을 구현하는 방법을 두고 자주 논쟁이 벌어진다.
9. 수정 사항을 체크인한 후나 코드 리뷰를 할 때 겨우 알아차릴 정도의 무의미한 수정이 자주    이루어진다.
어떠한 코드(특정 부분일 수도 있는)에서 지속적인 변경이 발생 된다면.
무언가 잘못 작성된것은 아닌지 확인해보자.

6.복잡성을 키우는 방법 : API 분리

• API는 ‘언제든 우리가 알려준 대로 우리 프로그램과 안전하고 정확하게 인터랙션할 수 있다.’ 라는 약속이다.
• 불안정 하거나 문제가 있는 API( ex : old version API)를 더 이상 공개하지 말자.
• 사용 자가 바라는 API 사용법을 정확히 알아내자.
• API 출시 전 안정성을 최대한 보장하자.
• API를 공개 했다면 제발 API를 망가뜨리지 마라.

7.하위 호환성이 가치를 잃는 시점은 언제인가?

• 과거의 잘못된 선택이나 설계가 미래의 진보를 막는 일이 비일비재하다.
• 하위 호환성 유지가 진보를 막는 지경에 이르면 그 ‘유물’은 버려야 한다.
  진보를 포기하고 무제한의 하위 호환성 보장 == 제품의 사망, 데스 그것은 죽음
• 이 기능이 향후 3~4 년간 최소 10시간 이상을 쓸 정도의 가치가 있을까?
• 하위 호환성이 유용하고 중요한 새 기능을 가로 막는다면 하위 호환성을 포기하자.

8.복잡성은 감옥이다

• 스스로가 작성한 코드에 갇히게 되면, 휴가도 마음 편히 갈 수 없다.
• 복잡성을 양산하여 일자리를 보장받기 원할지도 모른다.
  챕터1을 다시 보자. 의지가 없으면 발전도 없고, 이렇게 정리하고 있을 필요도 없다.
• 복잡성은 감옥이고, 단순성은 자유다.

9.설계는 프로젝트 초반에 하라

• 프로젝트를 어떻게 단순하게 만들지 초반부터 고민해야 한다.
• 미래를 고려하지 않으면 코드가 엉망으로 설계되고 너무 복잡해진다.
  처음부터 미래를 생각하면, 코드베이스를 뜯어고치거나 변경에 대한 비용이 발생하지 않는다.
• 프로젝트 시작 초기 단계부터 Code Simplicty 에서 논의한 소프트웨어 설계 원칙을 적용해야 한다.
  이해할 수 있고 유지 보수도 가능한, 단순한 시스템을 만들어야 한다.

10.미래 예측의 정확성

• 미래는 예측하기 어렵다.

미래 예측의 정확성은 시스템이 복잡해질수록, 예측하고자 하는 시점이 멀어질수록 낮아진다.
[풀이]
1. 예측 대상인 시스템과 그 시스템 환경에 변화가 많을수록 미래예측이 어려워진다.
2. 시스템이 복잡할수록 더 많은 변화를 거쳐야 한다.
3. 때문에 복잡한 시스템에 대한 예측은 더 어려워진다.

• 미래예측은 단순 확률일 뿐이므로, 설계 관련 결정이 미래 예측에 기반하면 안된다.
• 미래 예측을 단정하여 코드를 짜면, 변화에 대한 걸림돌이된다.
• 미래의 변화에 대응하기 유용하도록 합리적인 선에서 단순성을 유지해야한다. 자신에게, 사용자에게, 시스템의 미래에 도움이될 결정을 하자.

11.단순성과 엄격성

• 엄격한 어플리케이션일 수록 더 단순하게 작성할 수 있다.
• 단순성(엄격성) 과 사용성은 트레이드오프 관계이다.
• 사용자 편의성을 위하면 필연적으로 복잡성도 증가한다.
  사용성을 위해 여러가지 입력에 대한 처리를 한다면, 코드는 그만큼 복잡해질 수 밖에 없다
• HTML을 예로든다. HTML은 덜 엄격하게 설계되었기 때문에브라우저 디자이너들이 엄청 고생했다. 표준화가 되었지만 크게 나아지지 않았으며.
  하위 호완성을 지키기 때문에 여전히 엄격하게 만드는건 불가능하다.

12.둘은 너무 많다

• 원칙적으로 개발자가 코드 일부를 수정한 후에 코드의 다른 부분까지 그와 비슷하거나 똑같은 방식으로 작동하도록 수정할 필요가 없어야 한다.
  강한 결합으로 한 코드의 변경이 필연적으로 다른 코드에서 수정이 일어나야만 하는 상황과 같다. 이런 상황을 만들면 안된다.
• 중복되는 로직이 눈에 띄면 둘을 하나로 만들어야 한다.
  한번에 두개씩 제한해서 통합하다보면 단순하고 문제에 잘맞는 솔루션이 완성된다.
• 함수는 오직 하나의 개념만 나타내야 한다.
  단일 책임 원칙 Single Responsibility Principle을 지켜라.
• ‘둘은 너무 많다’ 가 절대적인 법칙은 아니다.
  하지만 점진적 개발 작업을 진행할 때 설계 관련 결정을 내리는데 유용한 지침이다.

13.분별 있는 소프트웨어 설계

이 장의 내용은 어떠한 봉들로 이루어진 구조물을 만드는 과정들을 예시로 나타내고 있다.
잘못된 방법으로 이루어진 예시와 어떠한 점이 잘못되었는지.
올바른 방법으로 이루어진 예시와 어떻게 올바르게 진행했는지를 알려준다.
아래는 이 장에서 알려주고 싶은것 이라고 이해한 부분들을 정리한다.
- 인터페이스의 규격화
- 각 부분을 작고 간단하게 유지
- 모듈단위 변경을 고려한 설계
- 점진적 개발, 테스트, 적용, 피드백, 보완의 싸이클

14.버그란 무엇인가

• 버그의 정의?

1. 프로그램이 프로그래머의 의도에 따라 움직이지 않는다.
2. 프로그래머의 의도가 사용자의 평범하고 합리적인 기대를 충족시키지 않는다.

15.버그의 원인

• 버그의 원인 : 복잡성, 대상에 대한 잘못된 이해 , 오타
• 무슨 작업을 해야할지, 그 코드를 어떻게 써야 할지 아주 분명하고 정확하게 알 수 없다면 누군가는 실수할 것이다. 그리고 거기에 다른 코드가 추가된다면 잘못 사용할 가능성은 더욱 커진다.
• 프로그래머라면, 미래에 자신이 작성한 코드를 볼 다른 프로그래머가 쉽게 이해 할수 있는 코드를 쓰겠다는 책임감을 지녀야 한다.

16.재발을 방지하라

• 문제가완전히 사라질 때까지 문제의 근원을 추적하지 않는다.
  그러니 코드베이스가 진짜 ‘건강'해지지 않는다.
• 문제가 제대로 해결되었는지 확인하는 일반적인 방법
  아무도 그 문제에 다시는 주의를 기울일 필요가 없을 정도가 되어야 한다.
• 문제의 근원을 찾기위해 토끼굴로 들어가라. 최대한 깊이

17.디버깅의 기본 철학

• 원인을 추측하지 말자. 추측은 시간 낭비다.
• 디버깅을 완료하기위해 문제의 원인을 이해할수있는 데이터를 수집해야한다.
• 자유형식의 버그리포트에 원하는 정보가 있을리 없다.필요한 필수 정보들에 대한 양식을 준비하여 제공하자.
• 버그를 찾기위해선 시스템의 여러부분을 볼 수 있어야 한다.
  로그, 모니터링, 에러메시지, 코어 덤프
• 문제가 된 사용자에게만 이러한 볼 수 있는 시스템을 배포하여 빠르게 원인을 찾는 방법도 있다.

자신이 찾은 해결책이 다시는 문제를 재발시키지 않을 거라고 확신할 수 있어야 진짜 원인을 찾은 것이다.

• 문제의 원인을 찾지 않고 단순히 증상만 제거하는 미봉책은 피하자.

1.정상 시스템의 작동 이해 
2.문제의 원인을 모른다는 사실의 인지.
3.데이터 분석을 통한 문제 원인 파악
4.증상이 아닌 원인의 해결

18.엔지니어링 생산성을 효과적으로 개선하기

• 내가 생산성 담당자라면, 생산성을 높이기 위해서는 여러 의견을 들어야 한다. 개발자 라던지.. 또는 개발자 라던지.. 개발…
• 개발자의 의견에 너무 휘둘릴 필요는 없다. 대부분의 경우 생산성 장애물은 거대한 코드 복잡성이다.
• 단기간에 완료할 수 있는 작은 문제들을 해결하여 엔지니어링 팀과의 신뢰를 쌓도록 한다. 개발자 들이 변화를 따르기 위해서는 신뢰가 바탕이 되어야 한다.
• 점진적으로 변화 시키고, 변화에 적응 하는 시간을 제공한다.
  단계적 접근으로 이러한 변화들에 대한 반발을 줄일 수 있다.
• 장애물(괴팍,고집,고위직)사람이 나타난다면
  동맹군(의견의 지지자)을 찾고 핵심 지지 기반을 구축하라.
  이외에도 방법이 있지만 Pass -_-. 신뢰를 유지하면 결국엔 저항 세력이 무너지거나 장애물이 떠나간다.
• 혼자만의 시선으로 문제를 인지 하지 말자.
  사람들이 인지하고 있는 문제를 해결해야한다.
• 진짜 문제를 해결하라.

19.개발자 생산성 측정하기

• 개발자의 생산성를 측정하려면 그사람이 생산한 제품을 측정하라
  생산적인 사람은 정기적으로 그리고 효율적으로 제품을 생산하는 사람이다.
• LOClines of code는 생산성의 기준이 될 수 없다. 작성한 제품을 기준으로 생산성을 측정해야한다.
• 개발자가 만든 제품을 기준으로 생산성을 측정한다면
  요청의 횟수, 신규 릴리즈 API 함수(테스트 완료 된) 갯수 등이 측정 기준이 될 수 있겠다.
• 샌산성 개선 담당자라면, 도움으로 인해 단축된 시간, 작성한 개발자 도구 들이 측정 기준이 될 수 있겠다.

20.소프트웨어 회사에서코드 복잡성을 다루는 법

한 명의 프로그래머만이 코드 복잡성을 해결할 수 있다.

• 위의 말은 다음과 같이 해설될 수 있다.

코드 복잡성을 해결하려면 한 사람 수준의 섬세한 작업이 요구된다.

• 광범위한 해결책을 모든 문제에 일괄적용해 본들, 대부분의 문제에 맞지 않는다.각 팀원 각자가 문제를 해결할 수 있게 도와주자.
• 1단계 : 문제 목록

각 팀원이 답답하다고 느끼는 부분. (수정할 때 부담이 되는, 답답한 부분)
각 소프트웨어 엔지니어가 각자의 목록을 만들도록 한다.(자신의 코드베이스가 아닌 부분도)
원인이 아니라 증상을 찾는 단계이다.

• 2단계 : 회의

작은 단위의 팀 회의를 통해 증상과 연관된 코드베이스를 확인한다.
여러 의견을 듣고 문제를 구체적으로 정리한다.

• 3단계 : 버그 리포트

회의에서 수집한 정보를 바탕으로 문제를 나타내는 버그리포트를 작성한다.
버그란 복잡한 이해도롤 요구하는 함수,코드 일수 있다.

• 4단계 : 우선순위 선정

문제들의 우선순위를 정하는 부분은 중요하다.
문제와 연관된 다른 문제들이 있다는 것을 명심해야한다. 연관 문제들을 파악하고 
주요 문제를 기준으로 깊게 찾아 근본적인 문제를 우선하도록 하자.

• 5단계 : 과제

각 작업자에게 버그를 할당하고, 필요하다면 타팀과의 협업을 통해 진행해야 한다.

• 6단계 : 계획

버그를 정리한 후에는 언제 고칠지가 중요하다.
되도록 일정 수준의 코드 품질 개선 작업을 수행하여, 꾸준히 품질이 개선되도록 하자.

21.리팩토링할 때는 기능에 주목하라

• 리팩토링을 위한 리팩토링은 하지말자.
  집에 불이 났는데 짚 앞 잔디에 물을 주는 꼴이다.
• 복잡한 코드베이스를 정리하는 핵심 원칙은 항상 기능을 위해 리팩토링 하는 것이다.
• 최우선 목표는 시간이 지날수록 더 나빠지지 않게 하는 것이다.
• 정리를 포기하면 원하는 제품이 완성되지 않고, 생산을 포기하면 리팩토링을 할 이유가 없다.
  잔디에 물을 주는 건 좋은 일이다. 하지만 불부터 끄자.

22.친절과 코드

• 현실에서 소프트웨어 시스템을 작성하는 건 사람이다.
• 소프트웨어 설계 법칙이 적용되었는지 확인하고 가독성과 유지보수를 고려해서 이해하기 쉬운 시스템을 만들수 있도록 좋은 길로 가자고 권하는 건 도움이 된다.
  하지만 그렇게 하기위해 무례하게 굴어도 되는 건 아니다.
• 무례한 방식은 아무것도 좋은게 없다.
  코드를 작성하는데 실수에 벌벌떨며 일하는 분위기를 조성하지 마라.
• 동료의 말에 동의를 하든 안하든 들어라. 그들의 생각을 정중하게 인정하고 자신의 생각을 건설적인 방식으로 전달해라. 이해심을 발휘해라.

별 의미 없이 아는 척하며 동떨어진 이야기를 한다고 할지라도 이해하자.
세상은 멍청한 사람으로 가득하다. 그중 몇명은 내 동료일 수도 있다. (나 일지도?)
그들에게 무례하게 구는건 아무 효과가 없다.
그들에게 필요한건 연민과 도움이다.
그리고 사실 그들은 멍청하지 않다. 선의를 지닌 똑똑한 사람인데 실수를 한 것 뿐이다.
그들의 행동을 선의로 해석하고, 친절한 태도로 협력하여 더 나은 소프트웨어를 만들어라.

여기 까지만 정리..

‘18.엔지니어링 생산성을 효과적으로 개선하기’챕터의 인간 장애물에 대한 부분도 많이 공감이 된다. 주변에서 들은 협업의 어려운 사례들을 회상하며 많은 부분에서 대입되었다.
‘22.친절과 코드 ‘챕터가 얼마나 중요한지 많이 느낀다,
사람이기에 상대방의 말에 얼마나 내가 휘둘리고 위축되는지 잘 알고 있다.
그래서 항상 말할때 상대방을 살피고, 불필요한 말을 줄인다.
나 혼자서는 만들 수 없다. 상대방을 이해하고 또 이해해야 함께 갈 수 있다.
아무 도움도 안되는 오만함은 가지지말자.

더 나아지기 위해 책을 보도록 한다.

23.간략하게 살펴보는 오픈 소스 커뮤니티

24.컴퓨터란 무엇인가?

25.소프트웨어 구성 요소 : 구조 , 동작, 결과

26.소프트웨어 개정판 : SAR 구별하기

27.지식으로서의 소프트웨어

28.기술의 목적

29.간략하게 살펴보는 프라이버시 문제

30.단순성과 보안

31.테스트 주도 개발과 관찰 주기

32.테스트철학

33.성공의 비밀 : 나아지기

34.개떡 같은 부분을 찾아내는 방법

35.’아니요’의 힘

36.프로그래머가 개떡 같은 이유

37.빠른 프로그래밍의 비결 : 생각하지 않기

38.개발자의 자만심

39.’일관성’과 ‘획일성’은 다르다

40.사용자는 문제를 알려주고, 개발자는 해결책을 만든다

41.즉각적인 만족감 == 즉각적인 실패

42.성공은 혁신이 아니라 실행에서 온다

43.훌룡한 소프트웨어

아래는 책의 표지에 써 있는 말이다.
- 100년 뒤에도 유용할 소프트웨어 설계 원칙 & 프로그래머의 바른 길!
- 단순함을 추구하라! 더 나은 프로그래머가 될 것이다!