TIL 7장.코딩하는 동안 – 노마드 코더 Nomad Coders

새로운 프로젝트를 시작하는데 두려운 이유

1. 어떤 작업을 앞두고 마음속에 의심이 계속 남아 있거나 앤지 꺼림칙하다면, 여러분의 경험이 여러분에게 말을 거는중일지도 모른다. 그 느낌을 따라라. 어떤 것이 문제라고 정확하게 짚지 못하더라도, 시간을 좀 주면 여러분의 의심은 아마도 좀 더 실체가 있고 대응책을 생각할 수 있는 무엇으로 구체화 될것이다.(p.277)

2. 합리적인 두려움이다.
코드의 오류를 자신의 부족한 능력 때문이라고 받아들일 수도 있다.(p.277)

나 자신과 싸우기

한걸음을 떼려면 어마어마한 노력이 필요하고, 세걸음 나아갔더니 두 걸음 미끄러지기도 한다.

하지만 전문가라면 여러분은 계속해 나가야 하지 않을까?(p.278)

파충류와 이야기하는 법(p.278-279)
1. 하고 있는 일을 멈춰라.

2. 시간과 공간을 확보하라.

3. 위 방법이 잘 안되면 문제를 표면으로 끄집어내 보라.

4. 작성하는 코드에 대한 그림을 그려보라.

5.동료에게 설명해 보라.(프로그래머 아닌 사람, 고무오리도 ok!)

6. 여러분이 어려움을 겪는 부분을 더 잘 처리할 수 있는 부위가 있는지 보라.

프로토타이핑 만들기

1. 포스트잇에 ‘프로토타이핑 중”이라고 써서 모니터 옆에 붙여라

2. 프로토타이핑은 원래 실패한다고 자신에게 상기시켜라. 실패하지 않더라도 프로토타입은 버리는 것이라는 점도 함께 상기시켜야 한다. 프로토타이핑으로 손해 볼 일은 없다.

3. 텅 빈 에디터 화면에 여러분이 배우고 싶은 것 혹은 하고 싶은 것을 한 문장의 주서으로 표현해봐라.

4. 코딩을 시작하라.

처리방식이 이상해 보이는 부분이 눈에 띄면 적어 놓아라. 계속 작업하면서 패턴을 찾아보라. 만약 그런 식으로 코드를 작성해야만 했던 원인을 찾아낼 수 있다면 코드를 이해하는 일이 훨씬 더 쉬워질지도 모른다. 다른 사람들이 은연중에 적용한 패턴을 여러분은 의식적으로 적용할 수도 있다. 그 과정에서 여러분이 새로운 것을 배울 수도 있다.(p.281)

직감에 귀 기울이는 방법은 계속 갈고닦아야 할 중요한 기술이다.(p.281)

여러분의 목소리에 귀를 기울여 주는 환경에 있다면 적극적으로 표현하라. 탐험하라. 어두운 출입구에 무언가가 숨어있을 것이다. 본능에 귀를 기울이고 문제가 여러분 앞에 튀어나오기 전에 미리 대처하라.(p.281)

우연히 돌아가는 코드를 주의깊게 봐야하는 이유

1. 정말로 제대로 돌아가는 게 아닐지도 모른다. 그저 돌아가는 듯이 보이는 것일 수도 있다.

2. 여러분이 의존하는 조건이 단지 우연인경우도 있다. 화면 해상도가 다른 경우나 CPU 코어가 더 많은 경우 등 다른 상황에서는 이상하게 작동할지도 모른다.

3. 문서화되지 않은 동작은 라이브러리의 다음 릴리스에서 변경될 수도 있다.

4. 불필요한 추가 호출은 코드를 더 느리게 만든다.

5. 추가로 호출한 루틴에 새로운 버그가 생길 수도 있다.(p.284)

비슷하다고 괜찮을 리는 없다.

하지만 사실 특정한 경우에만 ‘딱’ 한 시간 틀리는 것은 그저 우연이었다. 사실은 더 깊고 근본적인 문제가 있었다. 시간을 다루는 적절한 모데일이 없었기 때문에 점점 말도 안되는 양의 +1, -1 명령들이 코드 전체에 퍼져 나갔다.
결국 제대로 맞는 값이 없었고, 프로젝트는 폐기되었다.(p.285)

우연에 맡기는 프로그래밍을 하지 말라.(p.287)

의도적으로 프로그래밍 하기

1. 언제나 여러분이 지금 무엇을 하고 있는지 알아야 한다.

2. 경험이 적은 개발한테 설명할수 있을 정도로 얘기해야한다. 그렇지 않다면 우연에 의존하고 있다.

3. 자신도 잘 모르는 코드를 만들지 말라.

4. 계획을 세우고 그것을 바탕으로 진행하라.

5. 신뢰할 수 있는 것에만 기대라. 가정에 의존하지 말라. 무언가를 신뢰할 수 있을지 판단하기 어렵다면 일단 최악의 상황을 가정하라.

6. 가정을 기록으로 남겨라.
자신의 마음속에서 가정을 명확하게 하는 데 도움이 될뿐더러, 다름사람과 그에 대해 소통하는 데에도 도움이 된다.

7. 코드뿐 아니라 여러분이 세운 가동도 테스트해 보아야 한다. 어떤 일이든 추측만 하지 말고 실제로 시험해 보라. 가정이 맍았다면 코드를 더 이해하기 쉽게 만든 셈이고, 가정이 틀렸다면 일찍 발견했으니 운이 좋았다고 생각하라.(p.288)

‘성급한 최적화’를 조심하라.(p.298)

마틴 파울러의 ‘리팩터링’ 정의

밖으로 드러나는 동작은 그대로 유지한 채 내부 구조를 변경함으로써 이미 존재하는 코드를 재구성하는 체계적 기법.(p.301)

‘리팩터링’ 정의의 핵심적인 부분

1. 이 활동은 체계적이다. 아무렇게나 하는 것이 아니다.

2. 밖으로 드러나는 동작은 바뀌지 않는다. 기능을 추가하는 작업이 아니다.(p.302)

코드를 리팩터링하는 이유

1. 중복: DRY원칙 위반을 발견했다.

2. 직교적이지 않은 설계

3. 더 이상 유효하지 않은 지식

4. ‘꼭 필요하다고’고 생각했던 기능은 그렇지 않은 경우도 있다는 것을 깨닫게 될 것이다.

5. 성능을 개선하려면 시스템의 한 영역에서 다른 영역으로 기능을 옮겨야 한다.

6. 테스트 통과(p.302-303)

종양을 제거하려면 수술이 피요하다. 지금 바로 수술해서 아직 종양이 작을 때 제거할 수도 있다. 아니면 종양이 자라고 다른 곳으로 전이할 때까지 놓아둘 수도 있다. 하지만 그 때가 되면 제거하는 데 드는 비용도 더 늘어날뿐더러 위험도 훨씬 커진다. 시간을 더 끌면 환자는 생명을 잃을지도 모른다.(p.304)

일찍 리팩터링하고, 자주 리팩터링하라.(p.304)

마틴 파울러가 한 조언의 핵심은 탄탄한 회귀 테스트를 유지하는 것이야말로 안전한 리팩터링의 비결이라는 것이다. 리팩터링만으로는 부족해서 결국 외부에서 보이는 동작이나 API를 바꿔야 한다면, 일부러 빌드를 깨트려 보는 것이 유용할 수도 있다. 리팩터링 대상 코드에 의존하는 옛날 코드들은 컴파일이 안되게 만드는 것이다. 이렇게 하면 고쳐야하는 부분을 알야낼 수 있다.(p.306)

테스트가 코드의 첫번째 사용자다.(p.309)

TDD 발상의 핵심은 이 반복 주기가 기껏해야 몇 분 정도로 매우 짧아야 한다는 것이다.(p.311)

큰 그림을 살피는 것을 잊지말라. 초록색 “테스트 통과” 메시지에 중독된 나머지 진짜 문제 해결에는 보탬이 안되는 코드를 한 무더기나 쓰게 되기 쉽다.(p.312)

상향식이나 하향식이 아니라 끝에서 끝까지 만들어라.(p.313)

테스트할 수 있도록 설계하라.(p.317)

여러분의 소프트웨어를 테스트하라. 그러지 않으면 사용자가 테스트하게 된다.(p.318)

믿으라, 하지만 확인하라 - 러시아 속담(p.321)

속성 기반 테스트로 가정을 검증하라.(p.322)

기본 보안의 원칙

1. 공격 표면을 최소화하라

2. 최소 권한 원칙

3. 안전한 기본값

4. 민감 정보를 암호화하라

5. 보안 업데이트를 적용하라(p.332)

보안패치를 신속히 적용하라(p.338)

이름을 잘지어라. 필요하면 이름을 바꿔라(p.347)

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

그전에 왜 테스트주도개발 중요할까? 의문을 품었는데 쉽게 고칠 수 있을때 빨리 하는 편이 좋다는걸 알았다.
보안에 대해 얘기가 나왔는데 리서치하다가 어떤 홈페이지보니깐 console창에 섹션값을 바로 띄운곳이 있어서 진짜... 심각하다...라는 생각을 가진적이 있었다.
리팩터링은 정말 이건....숙련이 답인듯하다. 아직도 쉽지않는 문제이다. 늘 항상 어렵다.

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

대문자 O표기법:계산 복잡도 표현 (
https://jfun.tistory.com/235 )

오늘 읽은 다른사람의 TIL

https://nomadcoders.co/community/thread/5419

글쓰기

노마드코더 이벤트노마드 코더, 강의 1:1 상담 해드려요~️⭐️📚 노마드코더 신간 안내 📚 IT 5분 잡학사전

# interview