개발자 99% 커뮤니티에서 수다 떨어요!
오늘 TIL 3줄 요약
바꾸기 더 쉽게 코드를 작성하라 (Easier to Change)
DRY: 반복하지 말라 (Don't Repeat Yourself)
관련 없는 것들 간에 서로 영향이 없도록 하라.
TIL (Today I Learned) 날짜
03. 21
오늘 읽은 범위
2장 실용주의 접근법
책에서 기억하고 싶은 내용을 써보세요.
왜 이름 짓기가 중요한가? 이름이 좋으면 코드가 읽기 쉬워지고 코드를 바꾸려면 코드를 읽어야 하기 때문이다. ETC! - page.39
파일을 저장할 때마다 "ETC?"라는 내용의 팝업을 띄우도록 설정하라. -page.41
모든 지식은 시스템 내에서 단 한 번만, 애매하지 않고 권위 있게 표현되어야 한다. - page.43
개발자 간의 중복에 대처하려면 크게는 의사소통을 잘하는 튼튼하고 유대가 돈독한 팀을 만들어야 한다. 우리가 끄기기에 최선책은 개발자 간에 적극적이고 빈번한 소통을 장려하는 것이다. - page.53
우리가 설계하고 싶은 것은 자족적(self-contained)인 컴포넌트, 즉 단일하고 잘 정의된 목적을 가진 독립적인 컴포넌트다. -page.57
직교적인 시스템을 작성하면 두 가지 큰 장점이 있다. 바로 생산성 향상과 리스크 감소다. - page.57
자신의 힘으로 제어할 수 없는 속성에 의존하지 말라. - page.60
직교성을 유지하기 위해 사용할 수 있는 몇가지 기법이 있다. 1. 코드 결합도를 줄여라 2. 전역 데이터를 피하라 - page.61
이 책의 많은 주제는 유연하고 적응 가능한 소프트웨어를 만드는 방법에 초점을 맞추고 있다. 여기서 추천하는 방법들 특히 DRY 원칙, 결합도 줄이기 , 외부 설정 사용하기를 따른다면 중요하면서도 되돌릴 수 없는 결정의 수를 가능한 한 줄일 수 있을 것이다. - page 67~68
시스템을 정의하는 중요한 요구 사항을 찾아라. 의문이 드는 부분이나 가장 위험이 커 보이는 곳을 찾아라. 이런 부분의 코드를 가장 먼저 작성하도록 개발 우선순위를 정하라. - page.73
프로토타입은 제한된 몇 가지 질문에 답하기 위한 것이므로 실제 제품보다 훨씬 적은 비용으로 빠르게 개발할 수 있다. - page.80
여러분이 계산한 추정치를 기록으로 남겨라. 그리고 각 추정치가 얼마나 정확했는지도 기록으로 남겨라. 만약 오차가 50% 이상이라면 잘못된 추정치를 내게 된 원인이 무엇인지 찾아보라 - page.102
오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요
코드를 함수형 프로그래밍 방식으로 짜면 의존성 배열을 줄일 수 있고 반복해서 여러번 작성하는 것이 아닌 매개변수만 바꾸면서 여러번 사용할 수 있다고 이해했다. 함수형 프로그래밍을 연습해야 겠다고 느꼈습니다.
어려운 코드가 좋은 코드가 아닌 누구나 쉽게 이 정도면 나도 작성하겠는데? 라는 정도의 난이도로 작성하는 코드가 좋은 코드라고 생각이 되었습니다. 기본적으로 어려운 코드라면 수정하기도 쉽지 않고 자신이 작성한 것이 아니라 다른 팀원이 수정할 경우 그 코드를 쳐다보고 이해하는 시간또한 팀 리소스차원에서 낭비라고 생각이 되기 때문입니다.
궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.
예광탄 코드 대 프로토타이핑 - page.77 (잘 이해가 되지 않았습니다)
피닉스 라우터, 앤서블 - page.87~88 (처음 듣는 용어이고 책을 읽어도 무엇인지 잘 모르겠습니다)
오늘 읽은 다른사람의 TIL
님의 TIL (url 링크)