태그: #programming
IDE 자동완성이 다음 메서드를 고민 없이 띄워 주는 순간을 통해, 좋은 API가 실제로 지키고 있는 약속을 살펴본다
원본 서비스 자리에 프록시를 끼워 넣었던 경험을 통해, 서비스의 정체성이 구현이 아니라 관찰 가능한 행동에 있음을 확인한다
리플렉션으로 짜여 있던 직렬화 코드를 코드 생성으로 갈아치웠던 경험을 통해, 편리함과 본질을 가르는 기준을 살펴본다
팀장을 맡으며 겪었던 조직과 코드 경계의 반복을 다시 떠올리며, 이 연작을 관통해 온 감각의 정체를 되짚는다
조직도와 선수과목 체계도가 우연히 같은 모양이 될 때, 무엇이 같아야 진짜로 같다고 부를 수 있는지 살펴본다
축척 모형과 Optional.map을 통해, 한 구조를 다른 구조로 옮기는 행위가 정확히 무엇을 보존해야 하는지 살펴본다
주문 목록에서 이메일을 찾는 두 가지 경로를 통해, 서로 다른 옮김들 사이에서도 지켜지는 일관성을 살펴본다
진동벨과 옵저버 패턴을 통해 서로 무관한 문제들이 자꾸 같은 모양의 해법으로 풀리는 이유를 살펴본다
GoF 디자인 패턴 책과 오픈소스 패키지를 통해 재사용이 실제로 저장하는 것이 코드가 아니라 관계의 모양임을 살펴본다
화이트보드 위 동그라미와 화살표를 통해, 대상의 내용을 지워도 구조가 그대로 남는다는 사실을 확인한다
약속 뒤에 감춰지는 것의 정체를 자동차 핸들과 함수 하나를 통해 살펴본다
버려진 자리에 남는 약속의 정체를 엘리베이터 버튼판과 결제 수단을 통해 살펴본다
개별 관계들이 사슬처럼 이어지며 프로그램 전체의 지도를 완성해 가는 과정을 지하철 환승과 메서드 체이닝으로 살펴본다
콘센트 규격이라는 물리적 표준을 통해 타입이 보장하는 것과 보장하지 않는 것의 경계를 살펴본다
대상을 이루는 것은 내부의 속성이 아니라 다른 대상과 맺는 관계라는 사실을 데이터베이스와 체스판을 통해 살펴본다
함수를 계산기가 아니라 한 대상에서 다른 대상으로 건너가는 통로로 다시 읽는다
같은 값도 어떤 해상도에서는 다르게 취급되어야 하는 이유를 부동소수점과 NaN을 통해 살펴본다
동치관계로 묶인 대상들에 이름을 붙이는 행위가 무엇을 압축하고 무엇을 약속하는지 살펴본다
왜 우리는 서로 다른 대상을 굳이 같다고 부르는지, 그 판단 뒤에 숨은 기준을 추적한다
물리적으로 다른 두 대상을 서슴없이 같다고 부르는 순간들을 여러 영역에서 관찰한다
코드를 채우는 자동화의 시대에서 프로그래머의 역할은 기술적 부채를 감지하고 의사결정의 경계를 설정하는 일로 전환된다.
프로그래밍 언어의 미적 기준 변화와 시대적 제약, 그리고 개별 코드의 기교에서 시스템 아키텍처와 거대 구조물로 관심사가 확장되는 필연성에 관한 고찰