실용주의 프로그래머 (4/13)

4/13(수)

분량 : topic 1~15

 

3인 토의 내용 : 각자 깨진창문은 그대로 두지 않기로 하였다. 또한 적당히 괜찮은 소프트웨어를 위해 코드가 정상 작동한다면 만족스럽지 않더라도 일정 부분은 지나치기로 하였다. 또한 코딩을 작성하고 항상 ETC를 떠올려본다.

 

책에서 나온 도전해볼 것을 하나 선정해서 실제로 도전해보고 도전한 과정을 에세이로 작업한다.

 

- 목표

ETC & 깨진창문 & 적당히 괜찮은 소프트웨어를 균형있게 고려해서 기존코드에 기능추가를 잘하기

 

- 어떻게 했는가

한 개발 요청을 예시로...

코드를 작성하기 전에 변경하기 쉬운 구조인가? 기존의 코드를 얼마나 수정해야하는가? 고민하였다.

해당 부분 개발 요구는 1년 전이 마지막이었으며 또한 앞으로도 바뀔 일이 없다(단언할 수는 없다!)

결국 기존의 코드의 규칙을 지키면서도, 또한 조금의 하드코딩을 섞어서 빠르게 코딩을 완성하였다.

 

- 배운점

가끔은 하드코딩도 괜찮다(?) 왜냐하면 가장 중요한 것은 실제로 기능을 구현하는 것이기 때문이다.

물론 과도한 하드코딩은 지양해야하며 좋은 구조와 설계를 항상 고민해야 한다.

 

- 앞으로 어떻게 적용할 것인가

요구사항에 더해 추가적인 요구사항이 올 수 있음을 항상 인지한다. 내가 지금 변경한 코드가 나중에 또 변경될 수 있으며 그때에 좀 더 쉽게 변형할 수 있도록 고민한다.

 

4/20(수)

분량 : topic 16~29

 

다른 사람의 과제 피드백

 

1. 의식적인 연습을 해야 사람이 체화된다.

ex) ETC 팝업을 처음에는 만들어두고 의식적으로 생각하게 하면, 나중에는 ETC 팝업이 없어도 자동적으로 알게 된다.

ex) 테스트코드를 작성할 때 given, when, then 을 주석을 달고 코딩을 한다. 하지만 나중에는 given, when, then을 쓰는것이 귀찮아진다. 자연스럽게 체득되었기 때문이다.

 

2. 깨진 창문을 발견하면 다른 팀원들에게 모두 공유해서 깨진 곳을 의식하고 조심하도록 해야한다. 위키로 빠르게 공유하고 서로 확인한다면, 본인 업무에 집중할 수 있는 시간이 더 확보되고 불필요한 소요가 줄어든다.

 

DSL -> 특정한 분야를 잘 해결하기 위한 언어. 흔히 쓰고있지만 잘 인식하지 못하는 @Controller는 객체지향, 단일책임원칙과 상관없이 일종의 input, ouput의 형식이다. 

 

DBC 토의

계약에 의한 설계. 계약이란 자신과 상대편의 권리 및 책임을 정의한다.