Exception Handling
(예외 처리)
원칙과(principle) 실행 절차(사례:practice)는 어떻게 시스템을 구축해야 하는지 가이드합니다.
그러나 시스템이 이것을 벗어날 경우 무슨 일이 발생할까요?
때때로, 규칙에 예외가 되는 결정을 하게 되는 경우도 있습니다.
이러한 경우, 나중에 참조할 수 있도록 로그로 그러한 결정을 캡쳐할 가치가 있을 수도 있습니다.
충분한 예외가 발견된다면, 결국 세계에 대한 새로운 이해를 반영하기 위하여 원칙이나 실행절차를 변경해야 할 수도 있습니다.
예를 들면, 데이터 스토리지로 MySQL을 항상 사용할 것이라는 사례가 있을 수 있습니다.
그러나 "카산드라를 사용하는 경우에, 볼륨이 크게 증가하지 않는다면, 대부분의 스토리지 요구사항에 MySQL을 사용하십시오."라고 말하지만, 실행 절차를 변경하여 확장성이 뛰어난 스토리지를 위해서 카산드라(Cassandra)를 사용해야만 하는 강제적인 이유가 있을 수 있습니다.
그러나, 모든 조직이 다르다는 것을 되풀이할 가치가 있습니다.
나는 개발팀이 높은 신뢰와 자율성을 가지고 원칙이 가벼운 (분명한 예외 처리의 필요성이 제거되지 않으면, 크게 감소합니다.) 몇 개의 회사와 작업을 한 적이 있습니다.
개발자들이 덜 자유로운 더 구조화된 조직에서는 예외를 추적하는 것이 사람들이 직면한 과제들을 적절하에 반영하기 위해서 규칙들이 필수적일 수 있습니다.
언급된 이 모든 것들과 함께, 나는 가능한 훨씬 자유롭게 손에 있는 문제를 해결하는, 팀의 자율성을 최적화하기 위한 방법으로 마이크로서비스의 팬입니다.
만약 개발자들이 수행하는 방법에 많은 제약을 가하는 조직에서 일을 한다면, 마이크로서비스가 여러분에게 도움이 되지 않을 수 있습니다.
댓글을 달아 주세요
댓글 RSS 주소 : http://www.yongbi.net/rss/comment/817