섹션 두 부류, 정책 둘
코퍼스가 배분이라는 걸 받아들이고 나면 섹션이 알아서 두 종류로 갈려. 어떤 건 작고 유일하고 대체 불가능해. 온도 측정 몇 개, 통째로 읽은 기사 둘, 어제 요약. 다른 건 덩치 크고 반복적이고 탄력적이야. 헤드라인. 늘 더 있고 하나하나가 조금씩 보태는 것들.
둘은 반대 정책을 받을 자격이 있어. 작고 유일한 섹션은 통째로 예약돼야 해. 그 일부는 거의 무가치하니까. 온도 측정 반쪽은 아무것도 안 알려줘. 덩치 크고 탄력적인 섹션은 남은 걸 받고 깔끔하게 멈춰야 하고. 설계상 우아하게 저하되니까. 헤드라인이 적은 건 더 작은 조망이지 망가진 조망이 아냐.
탄력 섹션 안에서도 순서가 중요해
고정 섹션을 예약하고 나서도 남은 몫을 여러 선반 사이에 어떻게 쓸지 정해야 해. 자연스러운 구현은 선반별로 도는 거고, 그건 원래 버그를 한 층 아래서 재현해. 앞쪽 몇 선반은 온전히 대표되고 뒤쪽 여럿은 통째로 없어져.
순위별 라운드로빈이 고쳐. 모든 선반의 톱 헤드라인을 가져오고, 그다음 모든 선반의 두 번째를, 그런 식으로. 그러면 예산이 떨어질 때 주제를 통째로 지우는 대신 각 주제가 깊이를 조금씩 잃어. 그리고 하루 조망한텐 주제 하나가 빠지는 게 각각을 좀 얇게 다루는 것보다 훨씬 큰 결함이야.
공짜로 얻는 연속성
예약 섹션 하나는 따로 언급할 값어치가 있어. 기능으로 위장한 지출 결정이거든. "어제 이후 뭐가 바뀌었나"는 일간 브리핑이 말해주면 진짜 쓸모 있는 거고, 뻔한 구현은 이틀을 비교하는 두 번째 생성이야. 그러면 상시 비용이 두 배가 되지.
그리고 불필요해. 이 생성이 이미 답하고 있는 같은 질문이거든. 어제 브리핑을 예약 섹션으로 넣으면 몇백 자에 추가 호출 0 건이야. 그러면 모형이 뭐가 움직였는지 말할 수 있고, 쓸모 있게도, 어제 뭘 틀렸는지도 말할 수 있어. 생성 단계를 추가하기 전에, 지금 하려는 그 안에서 답에 닿을 수 있는지 확인해.
예약은 넘치게 하는 테스트로 지켜
예약은 뭔가 강제해야 진짜야. 중요한 테스트는 평범한 날을 확인하지 않아. 탄력 섹션에 예산이 허용하는 것보다 훨씬 많은 내용을 일부러 들이붓고, 그다음 예약 섹션이 여전히 온전히 있는지 단언해. 그 테스트는 원래 구현에서 실패하고 예산 구현에서 통과하고, 이 부류 버그의 회귀 테스트가 해야 할 게 정확히 그거야.