소프트웨어와 깨진 유리창의 법칙
- Development/SW Engineering
- 2021. 12. 27.
소프트웨어에서의 깨진 유리창의 법칙
깨진 유리창 이론이 범죄나, 사람들의 실제 생활에만 존재하는 것은 아니다.
본 포스트에서는, 소프트웨어 개발과 깨진 유리창 법칙의 관계에 대해 정리한다.
깨진 유리창/창문의 법칙이란?
우선 깨진 유리창 이론에 대해서는 아래의 글을 참고하자.
깨진 유리창의 법칙이란?
깨진 유리창의 법칙에 대해 어떤 장소/ 건물에 깨진 유리창이 있다면 어떤 생각이 들까? '하나만 봐도 열을 안다'라는 속담을 생각해 보자. 한 곳에 문제가 있다면, 다른 곳은 굳이 보지 않아도
luran.me
소프트웨어에서의 깨진 창문
팀이 소프트웨어에 어떤 변경을 한다고 가정하자.
시간에 쫓겨, 혹은 개발할 당시에 정보의 부족으로, 혹은 MVP 버전으로 개발해야 하는 상황이라서 등등.
제대로 만들었어야 하는 것들을 제대로 해놓지 않았다면, 이는 시스템에 잠재적인 문제점이 된다.
예를 들어,
- 단위 테스트 코드를 작성하지 않았다.
- 통합 테스트를 하지 않는다.
- 코드 컨벤션이 잘못 되었다.
- 오탈자가 있다.
- 예외 처리를 하지 않았다.
- 잘못된 아키텍쳐를 갖고 있다.
- 무엇인가 하드코딩 되어 있다.
- 로직이 이상하다.
- FIXME라고 주석은 달려 있으나, 손보지 않은지 오래되었다.
그러나, 꼭 무엇인가 잘못해서만 생기는 것은 아니다.
개발할 당시에는 요구사항이 맞아 보이고, 그에 적절하게 만들었다 하더라도 시간이 지나면서 우리의 노후한 소프트웨어도 적절하게 변경해줘야 할 일도 생긴다.
개발 요구사항이 1-10까지 항상 깔끔한 것도 아니다.
프로젝트의 우선순위는 수시로 바뀌기 마련이다.
심지어 프로젝트를 수행하고 있는 중간에도, 마치 살아있는 생명체처럼 요구사항과 우선순위는 변한다.
그리고, 이 변화에 맞춰서 우리 코드에는 여러가지 잔존물이 깔끔하게 정리되지 않은 채로 남게 된다.
많은 개발자들이 오가면서, 크고 작은 변화를 만들어 낸다. 그리고, 이러한 변화들이 모여서 어떤 무질서를 만들어 내기 마련이다.
Ivar Jacobson은 이러한 현상을 소프트웨어 엔트로피라고 설명한 바 있다.
The second law of thermodynamics, in principle, states that a closed system’s disorder cannot be reduced, it can only remain unchanged or increased. A measure of this disorder is entropy. This law also seems plausible for software systems; as a system is modified, its disorder, or software entropy, always increases. This is called Software Entropy.
깨진 유리창은 곧바로 고치자
내가 고치지 않으면, 내 옆의 다른 누군가도 고치지 않는다.
FIXME 태그가 붙은지 오래된 코드가 몇 개월 지난 이제서야 내 눈에 띄었다면, 그 동안 그 코드를 본 어느 누구도 고치지 않았다는 소리이다.
특정 코드 구역의 테스트 커버리지가 낮았음에도, 그 부분에서 장애가 발생한다면 어느 누구도 해당 영역의 코드 커버러지가 낮음을 주의 깊게 보지 않았다는 뜻이다.
개발팀은 신규 개발 요구사항을 되도록 빨리 개발하고 배포하는 것이 사명이라고 여기곤 한다.
그러나, 동시에 기존 서비스의 퀄리티를 높이는 것 또한 목표로 해야 한다.
깨진 창문의 효과로 퀄리티가 낮은 프로덕트가 양산되고, 결국에는 고객 만족도나 비즈니스에도 악영향을 끼칠 수 있기 때문이다.
보이스카웃/걸스카웃의 규칙을 적용하라는 말도 소프트웨어 개발에 적용될 수 있다.
Always leave the campground cleaner than you found it.
캠프장을 떠날 때는, 처음에 왔을 때보다 더 깨끗하게 해놓을 것.
마찬가지로, 우리 코드도 처음에 발견했을 때보다 더 깨끗하게 해 놓으려는 노력이 필요하다.
이를 응용하여 Rober Martin (Uncle Bob)은 이런 말을 남기기도 했다.
Always leave the code you're editing a little better than you found it.
코드도 처음에 손대기 전보다 더 나은 코드로 바꿔놓도록 하자.
참고
'Development > SW Engineering' 카테고리의 다른 글
| Law of Demeter - 디미터 (데메테르) 법칙 (0) | 2021.08.18 |
|---|---|
| 12요소 (twelve factors) 애플리케이션 (0) | 2021.07.29 |
| 콘웨이 법칙 (Conway's Law), 역 콘웨이 법칙(Inverse Conway's Law) (0) | 2021.07.19 |
| 캐시(Cache) 적용 패턴 및 관리 전략 (0) | 2021.04.29 |
| Strangler Fig Application Pattern - 교살자 무화과나무 패턴 (0) | 2021.04.18 |
| PlantUML - 코드로 시퀀스다이어그램 그리기 (0) | 2021.04.07 |
| VS Code에서 PlantUML 사용설정 (0) | 2021.03.31 |
| Syntax Highlighter로 인용할 때 괄호 오류 보정하려면 (0) | 2010.07.17 |