2/14
TDD, 리팩터링
- production 코드가 잘 돌아가는지 검증하는 코드 -> Test Code
- TDD란? TFD(Test First Development) + 리팩토링.
- 실패하는 코드를 만들고 성공하게 하는 것. 일단 코드를 성공하게 한 다음에 정말 의미를 갖는 코드인지 리팩터링한다.
- TDD 하는 이유: 디버깅 시간을 줄여준다. 동작하는 문서 역할을 한다. (단위테스트 있으면 동일한 거 아닌가?) 변화에 대한 두려움을 줄여준다. -> 왜 TDD를 해야 하는가?
- 이미 구현된 코드에 대한 단위테스트를 작성하면 단순히 커버리지만 높은 코드가 나올 수 있다. (구현 사항을 이미 알고 있기 때문에)
- 심적으로 안정감을 얻을 수 있다.
- 처음부터 완벽한 설계를 하는 것이 아니라 점진적으로 설계를 개선해 나갈 수 있다. 과도한 설계에 따른 추가 비용을 해소한다.
- 빠른 피드백을 받을 수 있다.
TDD 원칙
- 실패하는 단위 테스트를 작성할 때까지 프로덕션 코드를 작성하지 않는다.
- 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다.
- 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다.
빠른 피드백을 통한 개발 효율
- 버그를 찾는 시점이 빨라진다.
- 일정한 리듬으로 일함으로써 프로그래밍에 재미를 느낌 (?)
- 더 많은 삽질을 할 수 있다. (?) 삽질은 더 많은 배움이다.
- 지금 필요한 것은 새로운 접근방식에 도전할 수 있는 용기
개발을 잘한다의 기준은?
- 코드 작성 시 가장 중요한 것은? -> 성능 / 가독성 / 유지보수성
- 개발자가 코드를 신경쓰는 이유는 비용을 절약하기 위함이다.
- 기술부채가 쌓이는 것은 어쩔 수 없는 것. 적절한 기술부채를 쌓을 수도 있어야 한다.
- 언제나 자신만의 기준이 필요하다.
- 내가 코드를 작성할 때 가장 중요한 것은? : 수정이 용이한 코드. 다른 사람이 읽기 쉬운 코드. 최선의 코드를 위해 적절한 기술부채를 쌓을 줄 알고, 적절한 시점에 기술 부채를 정리할 수 있어야 한다.
- 테스트 커버리지는 어디까지?
- 본인이 생각하는 자바를 잘한다는 기준은 무엇인가?
- 자바를 잘하는 사람이 되기 위해 어떠한 시도를 할 것인가?
- 미션을 진행하며 위 시도를 하였을 때 본인이 성장하고 있는지 어떻게 측정할 수 있는가?
메타인지
- 인지에 대한 인지, 생각에 대한 생각
- 인지: 온갖 사물을 알아보고 기억하며 추리해서 결론을 얻어내고, 그로 인해 생긴 문제를 해결하는 등의 과정
- 메타인지: 문제를 해결하는 것에 대해 생각하기
- 메타인지 향상을 위해 내가 무엇을 알고 모르는지 판단. 학습 기록을 남기고 학습 로드맵을 그려보기!
짝 프로그래밍 메타인지
- 어떻게 하면 불확실성이 높은 현실 세계의 요구사항을 빠르게 반영하고, 유연하게 반응하고, 빠르고, 더 일찍 고객에게 가치를 전달할 수 있을까? -> 더 빠르게, 더 자주, 더 꾸준하게 피드백을 받기 위한 방법 중에 하나로 짝 프로그래밍을 시작한 것
짝 프로그래밍의 장점
- 버그 감소, 앱을 만들고 통합하는 시간이 감소
- 디버깅이 잘 됨 -> 문제가 있을 때 상대에게 설명하는 순간 답을 아는 경우가 많아짐
- 전문가의 암묵지를 효과적으로 배울 수 있는 장점이 있다. -> 단축키 어떻게 하는지, 모르는 버그를 만났을 때 어떻게 구글링하는지, 디버깅은 어떻게 하는지 등
- 새로운 신입, 주니어 개발자가 오면 시니어와 짝 프로그래밍하는 경우도 많다. 개발 도메인 지식 뿐만 아니라 시니어가 갖고 있는 프로그래밍에 대한 전문성
- 팀워크 향상: 갈등이 생기는 건 당연하다. 갈등을 더 작은 단위로 빠르게 만나고 빠르고 해소하는 경험을 할 수 있기 때문에 짝 프로그래밍이 팀워크 향상에도 도움이 된다.
- 짝 용기: 같이 하기 때문에 혼자서 하기 어렵거나 두렵거나, 귀찮은 것들을 같이 해낼 수 있는 용기가 생긴다.
2/15
웹 기초
인터넷이란?
- 전 세계적으로 연결된 컴퓨터 네트워크
- 네트워크의 네트워크
웹이란?
- 월드 와이드 웹 (WWW)
- 인터넷에 연결된 컴퓨터를 이용해 사람들과 정보를 공유할 수 있는 공간
하이퍼텍스트
- 하이퍼링크를 통해 독자가 한 문서에서 다른 문서로 즉시 접근할 수 있는 텍스트
- 하이퍼텍스트는 링크에 따라 그 차례가 바뀌는 임의적이면서 나열형인 구조
웹의 기능
- URL : Uniform Resource Locator
- HTTP : HyperText Transfer Protocol
- HTML
URI vs URL
- URI : 통합 자원 식별자. 인터넷에 있는 자원을 나타내는 유일한 주소. URI의 하위 개념으로 URL, URN이 있다.
- URL : 흔히 웹 사이트 주소로 알고 있지만, URL은 웹 사이트 주소뿐만 아니라 컴퓨터 네트워크상의 자원을 모두 나타낼 수 있다.
HTTP
- 웹 상에서 정보를 주고받을 수 있는 프로토콜
- 주로 HTML 문서를 주고받는 데에 쓰인다.
- HTTP는 요청과 응답으로 구성되어 있고, 클라이언트가 요청을 하면 서버가 응답하는 구조로 되어있다.
- http:// 는 이 프로토콜을 사용해서 정보를 교환하겠다는 표시
HTML
- 웹 페이지의 모습을 기술하기 위한 마크업 언어 (규약)
- HTML 태그 : HTML을 기술하기 위해 사용하는 명령어의 집합. 여는 태그 + 닫는 태그로 구성되며 닫는 태그 없이 사용하는 태그도 있다. (element, attribute...)
<!DOCTYPE html>: 웹 브라우저가 HTML을 올바르게 표시할 수 있도록 버전 표시- p 태그 : 단락/문단을 구분
- br 태그 : p 태그 없이 강제 개행
- h# 태그 : 섹션의 제목을 나타내는 태그. 숫자들은 제목의 등급을 나타낸다.
- a 태그: 하이퍼링크를 걸어주는 태그
- img 태그: 이미지를 삽입하는 태그
CSS
- 마크업 언어가 실제 표시되는 방법을 기술하는 언어
- 디자인적 요소를 HTML과 분리해보자!
2/16
좋은 코드
- 코드를 줄여쓰지 않는다. 코드 자체로 설명이 되도록 코드를 작성하면 유지 및 관리의 비용이 줄어든다. 주석을 달지 않아도 잘 읽히는 코드가 좋다.
- 원시값을 포장하면 확실하게 의도를 코드를 통해 전달할 수 있다.
- 일관된 코드 스타일을 가져야 동료 개발자의 혼동을 줄일 수 있다.
- 하나의 역할만을 담당하라. 하나의 함수가 많은 일을 하면 추상화 계층이 나빠진다.
- 추상화 계층: 특정한 집합의 기능의 자세한 부분을 숨기는 한 방법이다. (출처 - 위키백과) 추상화할 부분은 사람마다 다르다.
- 매개변수를 명확히 해라. 매개변수는 함수를 부르는 곳에서 이해하기 어렵다.
- 내 생각: 주석은 관리가 힘들기 때문에 최대한 자제하는 것이 좋다. 코드가 변경되었을 때 연관된 주석까지 바꾸기는 힘들기 때문이다.
- 명확하지 않은 것도 문제가 되지만, 과한 설계도 독이 된다. 정답은 없으니 상황에 맞게 판단하자.
- 적절한 API를 사용하면 견고한 코드를 작성할 수 있다.
- 적절한 자료구조를 사용하는 것도 좋다. (중복을 허용하지 않는 set을 쓰는 등)
- API를 위한 코드는 작성하지 말자. (stream이 주가 되는 경우 등)
예측 가능한 코드
- 의미있는 값을 반환하라. (값이 존재하지 않으면 -1을 응답하는 등) 차라리 예외를 반환하는 것이 좋을 듯. magic number를 사용하지 않도록 조심하기.
- 값이 올바르지 않는 경우 외부에서 처리하도록 위임한다.
- 정답은 없고, 설계를 할 때 문제
- Collection은 값이 없다면 null이 아닌 빈 Collection으로 작성한다. 객체도 동일하게 Null Object라는 것을 사용한다. 시작되지 않은 위치일 때의 상황도 하나의 객체로 바라보자.
- 부수효과를 제거하라. 명령과 조회가 같이 존재하지 않도록 하자.
- 중요한 입력/비즈니스 로직에 대해 무시하지 마라. 아무것도 리턴하지 않는 대신에 사용자가 정보를 알 수 있게 확인하라.
- 원시값을 포장하면 의도를 전달할 수 있고, 잘못 사용하기 어렵다. 상태가 불변한 경우 상태의 변화에서도 자유로울 수 있다.
- 변경 가능성을 최소화한다. 매개변수를 변경하며 생길 수 있는 버그와 성능 중 무엇이 더 중요할 지 생각한다.
- 객체의 값을 외부에 노출할 때 또한 방어적 복사(새로운 객체를 따로 생성하는 등)를 통해 보호해야 한다. 불변 구조(unmodifiableList)를 통해 외부로부터 방어할 수도 있다.
- 가독성 높은 코드를 작성하기 위해 어떠한 노력을 했는가?: 어떤 메서드에서 다른 메서드를 사용할 때, 해당 메서드가 사용된 위치 바로 밑에 두어 잘 읽힐 수 있도록 코드를 작성했다. 또한 생성자에 들어가는 매개변수를 최대한 줄이기 위해 책임을 여러 클래스로 분산했다.
- 예측 가능한 코드를 작성하기 위해 어떠한 노력을 했는가?: 최대한 주석을 제외하고, 변수 이름과 메소드 이름으로 동료 개발자가 이해할 수 있도록 노력했다. 사회적으로 통용되는(?) 단어를 사용하려고 노력했다.
- 실수를 방지하는 코드를 작성하기 위해 어떠한 노력을 해봤는가?: 예외를 꼼꼼하게 처리했다.
좋은 회고란?
- 나를 돌아보고 다음에 더 개선할 부분이 있는지 생각하기 위해서
감정 회고
- 감정적으로 소통하는 것
- 회고를 통해 꼭 구체적인 action plan이 없어도 된다. 감정 공유만으로도 가치가 있다.
- 좋은 이야기만 할 경우 학습 개선도 행복도 얻기 힘들다. 좋았던 점, 개선할 점, 감정 회고가 적절히 섞여야 한다.
- 상대방을 진정 위한다면 개선점이나 감정적인 부분에 대해서도 피드백을 해주면 성장하는데 많은 도움이 될 수 있다.
- 감정을 표현할 때는 상대방이 주어가 되기 보다 '나'를 주어로 하는 문장을 쓴다.
- 구체적인 행동과 상황을 공유하고 그 순간 느낀 감정에 대해 언급을 하는 것이 중요하다.
- 큰 변화를 만드는 것이 중요한 것이 아니라 내가 작은 변화로 개선되는 것이 중요하기 때문에 우선순위에 따라 하나씩 개선해나가자.
- todo 리스트를 작성해보고 시간 날 때 도전해보는 것도 좋다.