내가 항상 명심하고 싶은 것 중 하나는 “미래는 예전과 같지 않다”는 것입니다.

어느 정도의 경험이 있으면 미래를 예측할 수 있다고 믿기 힘들지만, 그럴 수는 없습니다. 미래의 클라이언트 / 사용자 / 원하는 것이 무엇이든 원하는 기능을 쉽게 구상 할 수 있지만 이것이 바로 고객이 원하는 것을 의미하지는 않습니다. 또한 다른 상충되는 기능을 원한다는 의미는 아닙니다. 따라서 미래를 계획하기 위해 오늘 보내는 시간을 제한해야합니다. 특히 미래에만 사용될 예정인 오늘날 물건을 만드는 데 소비하는 시간을 제한해야합니다.

내가 똑바로 좁히도록 요구하는 질문은 “지금이 기능에 대한 지원을 구축하는 것보다이 기능을 나중에 빌드하는 것이 얼마나 더 어려울 것입니까?” 일반적으로, 미래의 노력은 지금하는 것과 거의 같거나 아마도 두 배의 노력이라는 것입니다. 이 경우 미래를 예측할 수 없기 때문에 지금 구축하지 않는 데 아무런 문제가 없습니다. 답이 10 배 이상이되면, 내년이나 2 년 안에 사람들이 이것을 필요로 할 것이라고 생각하는 사람들에 대해 물어볼 것입니다. 그럼에도 불구하고, 광범위한 동의가 없다면, 나는 미래에 그 목표를 달성하기 위해 오늘날 우리가하고있는 일을 취소 할 필요가 없도록 스스로를 제한 할 것입니다.

예를 들어, 나중에 Hibernate를 데이터 액세스로 사용하고 있다는 사실을 추상화하는 데 많은 시간을 소비 한 몇 가지 프로젝트를 수행했습니다. (내가 Hibernate 기반으로 구축 된 프로젝트가 그것을 사용하는 것을 본 적이 없어서 시작하는 데 시간이 낭비되었지만 그것을 따로 설정해 보자.) 나중에 변경하고 싶을만한 합리적인 가능성이 있었음에도 불구하고 우리는 또한 데이터 액세스 객체 패턴을 사용하고 있었기 때문에, 처음부터 유연성을 구축하는 것보다 최대 절전 모드를 변경하고 필요할 때 동시에 변경하는 것이 어렵지 않았습니다. 지금과 같은 상황에 직면했을 때, 나는 우리가 실제로 필요할 때까지 유연성을 갖기를 원했습니다.

대기업을위한 전략적 계획을 세우지 않는 한, 기술이 빠르게 변화하고 있기 때문에 2 ~ 3 년 이상 건축 문제에 대해 생각할 가치가 없습니다. 오늘날 구축에 대해 생각하고있는 기능은 2-3 년 안에 오픈 소스로 자유롭게 제공 될 수 있습니다. 거의 확실하게 비용-이익 분석이 변경 될 것입니다.

오늘날 필요한 것을 수행하고, 자랑스럽게 생각하며, 다음 번 변경으로 인해 몇 달 안에 작업 할 수있는 시스템을 구축하도록 제한하십시오. 정말 당신이 할 수있는 최선입니다.

답변