오늘 TIL 3줄 요약

1. 팀은 크기가 커질수록 효율이 떨어진다 소수( 작고 안정적인 )인 팀에 속하자.

2. 사용자가 필요한 것 가능한 빠르게 제공하자.

3. 코드에는 항상 서명( 내가 쓴것을 남겨 더좋게 ) 하는 것과 테스트를 항상 하는 것을 계속하여1 버릇을 들이자.

TIL (Today I Learned) 날짜

2022-04-06

오늘 읽은 범위

9장. 실용주의 프로젝트

책에서 기억하고 싶은 내용을 써보세요.

1. 팀의 크기가 커질 때 의사소통 경로의 수는 팀 구성원 수를 n이라 할 때 O(n 2 ) 속도로 늘어난다. 팀이 커질수록 의사소통이 나빠지기 시작하며 효율성도 떨어진다. ( p.378 )

2. Tip 84 작고 안정적인 팀을 유지하라. ( p.379 )

3. 이미 일어난 변화를 거부할 필요는 없다. 단지 그런 일이 벌어지고 있다는 것을 파악하고 있으면 된다. 그러지 않으면 여러분이 뜨거운 물 속에서 삶아지는 신세가 될 것이다. ( p.380 )

4. 새로운 기술 탐험 새로운 기술이나 프레임워크, 라이브러리를 그저 “다들 쓰니까”라는 이유 로, 또는 콘퍼런스에서 본 것이나 인터넷에서 읽은 글을 바탕으로 도입하지 말라. 후보 기술로 프로토타입을 만들어 보고 신중하게 조사하라. 새로운 것을 시도해 보고 결과를 분석하는 업무를 일정표에 추가하라. ( p.381 )

5. Tip 85 실현하려면 계획하라. ( p.382 )

6. (옮긴이) 여기서 ceremony란 어떤 일을 하기 위해 필요한 절차나 격식, 코드 등을 가리키는 표현으로, 절차가 많으면 high ceremony, 적으면 low ceremony라고 한다. 마틴 파울러가《 UML Distilled》에서 사용하여 유명해졌다.( p.383 )

7. Tip 87 유행하는 것이 아니라 실제로 잘 맞는 것을 사용하라. ( p.388 )

8. 진짜 목표 ( 진짜 목표는 작동하는 소프트웨어를 제공 함으로써 사용자가 즉각적으로 새로운 일을 할수있게 되는것이다. 몇 달, 몇 년 후가 아닌 지금. 사용자가 필요로 할때마다, 사업적으로 배포가 의미 있을 때마다 배포하는 것이다. ) ( p.390 )

9. Tip 88 사용자에게 필요할 때 제공하라. ( p.391 )

10. 하지만 우리 말을 곧이곧대로 받아들이지는 말라. 직접 이런 접근 방법들을 조사하고 시도해 보라. 하지만 지나치지 않도록 주의하라. 특정 방법론에 과도하게 투자하면 다른 대안을 보지 못하게 될 수도 있다. 하나에 고착되면 머지않아 다른 길을 보기 어렵게 된다. 한 가지 방식이 너무 굳어져 버리면더 이상 빠르게 적응할 수 없게 된다. 코코넛을 사용하고 있는지도 모른다 ( p.391 )

    1. 코코넛( 눈에 잘띄는 결과물(넷플릭스를 처럼 일해야한다 먼저,서버 수십만 대와 사용자 수억 명을 준비한다..) 을 흉내냈을뿐 내용을빠트린 경우)

11. Tip 89 버전 관리 시스템으로 빌드, 테스트, 릴리스를 운용하라. ( p.394 )

12. Tip 90 일찍 테스트하고, 자주 테스트하라. 자동으로 테스트하라. 코드를 작성하자마자 테스트해야 한다. 작은 잔챙이들은 꽤 빨리 자라나 사람을 잡아먹는 거대한 상어가 되는 고약한 성질이 있다. 상어를 잡는 일은 상당히 힘들다. 그래서 우리는 단위 테스트를 작성한다. 아주 많이. ( p.394 )

13. 사실, 훌륭한 프로젝트에는 제품 코드보다 테스트 코드가 더 많을 수도 있다. 테스트 코드를 만들기 위해 들이는 시간에는 그 노력만큼의 가치가 있다. 길게 보면 이쪽이 훨씬 더 싸게 먹히며, 결함이 거의 없는 제품을 만드는 꿈이 정말 이루어지기도 한다. 그에 더해서, 테스트를 통과했다는 것은 그 코드가 ‘완성’되었다는 말에 높은 수준의 확신을 준다. Tip 91 모든 테스트가 끝날 때까지는 코딩이 끝난 게 아니다. ( p.395 )

14. 서비스에 일부러 지장을 일으키고 ― 즉, “죽이고” ― 여러분 애플리케이션의 회복 능력을 테스트하라. 테스트를 작성할 땐 경보가 필요할 때 정말 울리는지 확인하라. ( p.397 )

15. 버그가 기존 테스트의 그물을 빠져나갔다면 다음번에는 그걸 잡아낼 수 있도록 새 테스트를 추가해야 한다. Tip 94 버그는 한 번만 잡아라. 한번 인간 테스터가 버그를 찾았다면 더는 인간 테스터가 그 버그를 만나서는 안 된다. 그 순간 이후로는 무조건, 매번, 예외 없이, 아무리 사소해도, 개발자가 “그런 상황은 절대 또 일어날 리 없습니다.”라고 불평을 하더라도, 해당 버그를 확인할 수 있게 자동화 테스트를 수정해야 한다. ( p.398 )

16. Tip 95 수작업( 말그대로 하나하나 손으로 확인하는 절차 ) 절차를 사용하지 말라. ( p.400 )

17. Tip 96 사용자를 기쁘게 하라. 그저 코드만 내놓지 말라. ( p.404)

18. 여러분의 직함이 명목상으로는 “소프트웨어 개발자”나 “소프트웨어 엔지니어” 비슷한 이름일지 몰라도 진정한 여러분의 직함은 “문제 해결사”다. 이것이 우리가 하는 일이고, 실용주의 프로그래머의 본질이다. 우리는 문제를 해결한다. ( p.404 )

19. Tip 97 자신의 작품에 서명하라.( 어떤식이던지 코드에 자기 이름을 남겨라. ) ( p.404 )

20. 자신의 코드만 좋게 보고 동료들의 코드는 깎아내리는 편견 prejudice 을 갖게 된다. 이는 우리가 원하는 바가 아니다. 경계심 때문에 여러분의 코드를 참견하는 사람으로부터 방어하려고 해서는 안 된다. 같은 맥락에서, 다른 사람의 코드를 존중해야 한다. ( p.405 )

오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요

항상 테스트를 하면서 코드를 짜고 테스트 코드 완성된 코드에 서명을 남기고. 항상 사용자가 필요한 기능을 빠르게 패치를 하자. 언제나 문제를 생각하고 해결할 방법을 생각해보자.

궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.

-

오늘 읽은 다른사람의 TIL

1. Eugene Kim 님의 TIL(https://nomadcoders.co/community/thread/4255)

2. 배지영 님의 TIL(https://nomadcoders.co/community/thread/4235)