🌈 Chapter 15: 실제 사용자 인터페이스를 향해

📚 스나이퍼 이벤트의 단순화

🎈 잠깐의 휴식

• Bidding이라는 스나이퍼 이벤트가 하나 있는데 애플리케이션에서는 이 이벤트를 처리할 수 있다. 그리고 Winning, Lost, Won에 대해서도 똑같이 해야 한다.
• 다른 경우에 대해서도 동작하게 만들자면 너무 많은 반복 작업을 해야한다. 즉, 스나이퍼에서 설정한 후 여러 계층을 통해 전달해야 한다. 설계가 뭔가 잘못된 것이다.
• 이 문제는 결국 코드에 미묘한 중복이 생길 것이라는 사실을 알 수 있었다.
• ... P.184쪽

📚 고찰

🎈 단일 책임

🎈 소프트웨어 키홀 수술

• 이번 장에서 시스템 전체에 걸쳐 아주 자그마한 단편에 해당하는 행위만을 추가하느 실천법을 반복해 사용했다. 즉, 레이블을 테이블로 교체한 후 동작하게 만들고, 스나이퍼가 입찰하는 것을 보이게 한 후 그 부분을 동작하게 했으며, 또 다른 값을 추가한 후 그것으르 동작하게 만들었다.
• 일단 중대한 재작업을 시작하고 나면 해당 작업이 완료되기까지는 멈출 수 없으며, 브랜치하지 않고는 체크인할 수 없으며, 팀의 나머지 사람들과 병합하기는 더 어렵다.
• 외과 의사들이 개복 수술보다 키홀 수술(수슬 부위에 작은 구멍을 뚫고 내시경 등으로 수술하는 방식)을 선호하는 이유가 바로 여기에 있다. 그러한 수술법이 덜 침습적이고 비용이 덜 들기 때문이다.

🎈 프로그래머의 높은 민감성

• 반복적으로 복사해서 약간만 고쳐 쓰는 코드처럼 재능을 최대한 이용하지 않는 활동을 주시한다(추상화에 맞게 했다면 그런 고생을 하지 않아도 될 것이다).
• 설계를 언제 변경할 것인지 결정하는 데는 타협점에 대한 좋은 감각이 필요한데, 이런 감각은 민감도와 기술적 성숙도를 모두 의미한다.
• 단순하고 재현 가능한 기법은 없다. 그러자면 기술과 경험이 필요하다. 개발자들은 자신의 활동을 되돌아보고 코드를 작성하고 남은 자투리 시간에 자기 시간을 투자하는 가장 좋은 방법을 반추(회고)해보는 습관을 들여야 한다. 이는 하던 대로 계속하는 것을 의히할 수도 있지만 최소한 반성에 관해서는 생각해보게 될 것이다.

🎈 생각이 바뀌는 것을 받아들이라

• 코드에서 여러 기능의 이름이 바뀌는데 많은 개발 문화에서 이처럼 이름을 바꾸는 것을 취약함을 신호로 본다. 다시 말해 적절한 작업을 할 능력이 없음을 의미한다는 것이다.
• 작성한 코드를 이용하면서 구조가 어떠해야 할지를 배워나가는 것처럼 해당 코드를 사용할 때 우리가 택한 이름에 관해 좀 더 배우게 된다. 우리는 타입과 메서드 이름이 얼마나 잘 어울리는지, 개념이 명확한지 아닌지 확인하는데, 이는 새로운 아이디어의 발견을 자극한다.
• 어떤 기능의 이름이 올바르지 않으면, 해야 할 가장 현명한 일은 이름을 바꿔서 나중에 해당 코드를 읽을 사람이 어마어마한 혼동의 시간을 보내지 않게 하는 것이다.