안녕하세요 Jercy입니다. 오늘은 프로그래밍에서의 가치와 원칙에 대해 알아보겠습니다.
프로그래밍을 할 때 우리는 매순간 판단을 해야 합니다. 하지만 그 판단을 하는데 많은 시간을 사용할 수 없죠. 주어진 시간 안에 기능을 구현해야 하기 때문입니다. 그래서 결합도를 낮추고 응집도를 높이는 행위를 하면서 코드를 수정하다 보면, 오히려 코드가 더 이상해지는 경우가 생깁니다.
이럴 때 우리는 왜 이런 일이 벌어졌는지, 내가 어떤 판단을 잘못했기에 이런 상황이 된 건지 고민해봐야 합니다. 이때 제대로 된 판단을 하기 위한 기준이 필요한데요. 그 판단기준은 주관적일 수 있어서 개발자마다 생각이 다를 수 있습니다. 그래서 팀 작업 시 각자의 생각이 다른 부분에 대해 합의를 해야 하죠. 그렇지 않으면 누군가는 만족스럽지 못한 상황이 될 수 있습니다.
판단 기준은 빨리 판단하는 데 도움이 될 뿐만 아니라, 공동 작업 시 서로 간의 생각 차이를 줄이고 함께 일할 수 있게 해줍니다.
오늘은 켄트 벡의 '구현 패턴'이라는 책에 나온 프로그래밍의 가치와 원칙을 소개해드리겠습니다. 이는 개인이나 조직의 코드에 대한 훌륭한 판단 기준이 될 수 있습니다.
프로그래밍에서 가장 중요한 가치는 다음 세 가지입니다:
1.
커뮤니케이션
2.
단순성
3.
유연성
이 중 가장 중요한 것은 커뮤니케이션입니다. 코드는 개발자와 개발자 사이의 소통 수단이기 때문이죠. 문서나 대화는 거짓말 할 수 있지만, 코드는 절대 거짓말하지 않습니다. 그래서 읽고 이해시킬 수 없는 코드는 가치가 없다고 할 수 있습니다.
두 번째로 중요한 가치는 단순성입니다. 단순한 코드는 커뮤니케이션에 도움이 되고, 버그도 적습니다. 단순성을 추구하다 보면 복잡한 문제도 작고 단순한 문제들의 조합으로 바라볼 수 있게 됩니다. 이는 개발자의 중요한 능력 중 하나입니다.
다만 여기서 주의할 점이 있습니다. 단순함의 기준은 개발자마다 다르다는 것이죠. 초보 개발자에게 단순한 코드가 숙련된 개발자에게는 복잡할 수 있습니다.
또한 단순함을 추구한다고 해서 미래의 확장성을 위한 복잡한 패턴들을 무조건 배제해서는 안 됩니다. 현재 문제를 해결하는데 가장 단순한 방법을 우선적으로 택하되, 나중에 확장이 필요하면 그때 수정하는 것이 좋습니다.
iOS 개발에서 단순함의 예시를 들자면, 복잡한 뷰 계층 구조 대신 단순한 뷰 구성을 사용하는 것이 있겠네요. 나중에 뷰를 추가하거나 수정할 일이 생겨도 쉽게 대응할 수 있습니다.
참고로 단순함이 곧 코드의 길이가 짧다는 뜻은 아닙니다. 짧고 간결한 코드라고 해서 반드시 단순한 건 아니에요. 오히려 길지만 이해하기 쉬운 코드가 더 단순할 수 있죠.
마지막으로 중요한 가치는 유연성입니다. 단, 유연성은 커뮤니케이션과 단순성을 해치지 않는 선에서 추구해야 합니다. 개발 시간의 대부분은 기존 코드를 수정하면서 보내기 때문에, 유연한 구조를 유지하는 게 중요하죠.
하지만 유연성을 확보하기 위해 단순성을 포기해야 하는 상황이 생길 수 있습니다. 이는 일종의 트레이드오프인데요. 유연성이 꼭 필요하지 않다면 단순성을 우선시하는 게 좋습니다.
이제 위의 가치들을 지키기 위한 6가지 원칙을 알아보겠습니다.
1.
지역적 변화: 코드 수정 시 함께 수정돼야 할 부분들이 한 곳에 모여있어야 합니다. 여러 곳에 흩어져 있으면 관리 비용이 늘어나죠.
2.
최소 정보: 코드의 중복을 최소화해야 합니다. 중복된 코드는 한 곳이 수정되면 다른 곳도 함께 수정해야 해서 관리 비용이 높아집니다.
3.
로직과 데이터의 결합: 데이터가 바뀌면 로직도 함께 수정돼야 하므로, 한 곳에 두는 것이 좋습니다.
4.
대칭성: 코드에 대칭적인 구조를 만들면 이해하기 쉽습니다. 예를 들어 생성과 소멸이 대칭을 이루는 거죠. 또한 대칭성을 통해 코드 중복을 줄일 수도 있습니다.
5.
선언적 표현: '어떻게'보다는 '무엇을' 하는지 기술하는 방식으로 코딩하는 것이 좋습니다. 이는 코드의 가독성을 높여줍니다.
6.
변화율: 같은 시간에 함께 변해야 할 코드는 한 곳에 모아두는 것이 좋습니다. 변화율이 다른 내용은 분리하고, 같은 내용은 묶는 거죠.
이를 iOS 개발에 적용해보면:
•
로직과 데이터 결합의 예로, 모델 객체와 그를 다루는 코드를 함께 두는 것을 들 수 있겠네요.
•
대칭성의 예로는, delegate 프로토콜에 메서드를 추가할 때 필요하면 remove 메서드도 함께 추가하는 것 등이 있겠습니다.
•
변화율의 예로는, 특정 뷰와 관련된 코드는 해당 뷰 클래스 안에 모아두는 것 등이 있을 거예요.
이상으로 프로그래밍의 가치와 원칙에 대해 알아보았습니다.
생각해볼 점:
1.
내가 짠 코드들은 위의 가치와 원칙을 얼마나 잘 따르고 있나요?
2.
팀 내에서 코드에 대한 판단 기준이 잘 합의되어 있나요?
3.
코드 리뷰 시 위의 가치와 원칙을 기준으로 삼으면 어떨까요?
저의 답변:
1.
항상 커뮤니케이션, 단순성, 유연성을 염두에 두고 코딩하려 노력하지만, 개선의 여지는 있을 것 같아요. 앞으로는 위의 원칙들도 더 신경 써서 적용해봐야겠어요.
2.
사실 팀 내에서 명확한 기준을 합의한 적은 없는 것 같네요. 같은 기준을 가지고 코드를 판단하는 게 더 효율적일 테니, 팀원들과 한번 이야기를 나눠봐야겠어요.
3.
그러면 좋을 것 같아요! 코드 리뷰가 단순히 스타일을 지적하는 데 그치지 않고, 코드의 본질적인 가치를 논하는 자리가 될 수 있을 거예요. 리뷰 기준에 이 내용을 추가해보면 어떨까 싶네요.
이상으로 프로그래밍의 가치와 원칙에 대한 내용이었습니다. 참고가 되셨길 바라며, 다음에는 더 실질적인 코딩 이야기로 찾아뵙겠습니다. 감사합니다!