지속 가능한 개발을 위한 원칙

예측 가능한 코드의 범위는 변수, 함수, 클래스의 이름 그리고 로직을 포함합니다. 코드에서는 비유법, 반어법, 이중적 표현 이런거 절대 쓰지 맙시다. 우리는 문과감성 없는 개발자잖아요 😀 누가봐도 명확한 이름과, 로직을 작성해야 합니다. 타인이 보더라도, 3개월 뒤 내가 보더라도 동일한 이해를 할 수 있어야 한다는 생각으로 코드를 작성해야합니다. 조금이라도 혼동의 여지가 있으면 언젠가 그 여지는 장애로 돌아옵니다. 변수명을 구체적으로 적다보면 굉장히 길어질 수 있고, "변수명이 너무 길지 않아요?" 라는 피드백을 받을 수 있습니다. 이 때, 변수명을 짧게 바꿔도 누구나 이해할 수 있는 변수명이 된다면 🙆‍♂️, 하지만 현재 상태가 정말 사람이 이해할 수 있는 최소 단위라면 그 변수명을 지켜주세요. 설득해주세요. 변수명이 길다고 프로그램의 성능 저하, 앱 용량 증가 등 사용자에게 부정적인 영향을 주지 않습니다. 그냥 짧은 변수명을 선호하시는 분들의 심기만 불편할 뿐입니다. 대신 우리는 예측 가능한 코드를 얻을 수 있죠. 이걸로 장애 1번만 막아도 솔직히 본전은 뽑는다고 생각합니다.

Figma, Zepplin 에서 유사한 화면을 보면 1개의 ViewController 에서 처리를 하고 싶죠. 로직을 구성할 때에도 비슷한 부분이 있으면 상속을 하거나 enum 으로 타입을 나누거나 결국 또 하나의 메인 로직에서 처리를 하고 싶죠. 객체 지향에 대한 학습의 결과인지, 개발자의 본능(?) 인지 적은 코드로 코드를 작성하기를 원하게 됩니다. 지속 가능한 개발을 위해서 지양해야 하는 부분은, 겉보기에 비슷하다는 이유로 묶을 생각부터 하지 말자는 겁니다. 교통 앱을 예로 들면) 화면 A - 지하철 3호선 노선을 보여주는 화면 화면 B - 지하철 4호선 노선을 보여주는 화면 화면 C - 서울 732 버스 노선을 보여주는 화면 * 지하철 노선을 보여주는 화면과 버스 노선을 보여주는 화면은 UI적으로 완전 동일하다고 가정합니다. 유지 보수 불가 판정받는 케이스) 노선을 보여주는 공통점이 있고 UI가 똑같네, 노선ViewController를 만들고 type으로 metro 와 bus를 두자. 2주 뒤 > 지하철 역을 클릭하면 해당 역의 배차정보 보여주세요 => 정류소(역) 클릭 시 type에 metro 분기 들어감 또 2주 뒤 > 지금 간선버스 노선만 제공하는데 이제 광역버스 노선도 지원할거에요 > 광역버스 노선은 UI가 달라요 => 멘탈 나가기 시작, 광역버스 지원을 위해 광역노선ViewController 만듦 => 간선버스는 노선ViewController의 type으로, 광역버스는 광역노선ViewController 를 사용하는 기형적 구조가 시작됨 단 2번의 과정만에 멘탈 나가고, 앞으로 1번만 추가 기능 얘기 나오면 앱 갈아엎자는 얘기 나오기 시작합니다 🚬 그럼 가장 Best Practice는 무엇이었을까요? A/B 는 묶을 수 있고, C는 코드의 중복이 발생하더라도 별개의 코드로 분리하는거라고 생각합니다. 적은 코드를 쓴다고 역량있는 개발자가 아닙니다. 중복 코드가 있다고 형편 없는 개발자도 아니고요. 앞으로의 확장성, 각 기능들의 연관성에 대해서 깊게 고민해보고 정말 꼭! 필요할 때 상속, 프로토콜 등을 씁시다.

복잡도를 낮추고 유지보수를 가능하게 하는 코드를 작성해야합니다. 아래 4가지 케이스가 있습니다. 1. 복잡도 ⬆️ 임팩트 ⬆️ 2. 복잡도 ⬆️ 임팩트 ⬇️ 3. 복잡도 ⬇️ 임팩트 ⬆️ 4. 복잡도 ⬇️ 임팩트 ⬇️ 어떤 case가 Best, Worst일까요? case 1. 상황에 따라 할 수도, 안할 수도 있습니다. case 2. Worst 입니다. 어려운 기능을 복잡하게 만들었는데 임팩트가 없다? 시간낭비에 case 3. Best 입니다. 적은 일로 큰 임팩트를 냅니다. case 4. 2번 다음으로 최악입니다. 임팩트 없는 일은 시간 낭비입니다. case 2, 4번을 마주하게 되면 어떻게 해야하나요? 둘 중 하나입니다. 더 임팩트가 있는 다른 일을 찾거나 임팩트 있는 방향으로 전환할 수 있도록 피드백을 드리거나 다른 대안을 제시해야합니다. 어떻게 보면 당연한 얘기지만 어려운 일입니다. 특히, 1~2년 정도의 주니어 개발자의 경우 주는대로, 정해지는 대로 빨리 만들기 위해서만 노력하는 경우가 많은 것 같습니다. 저도 그랬습니다 😇 정해진 대로 빨리 만드는 것이 역량인 줄 잘못 알고 일했을 때, 번아웃, 현타 정말 많이 왔습니다. 복잡도 때문에 많은 시간을 투자해서 일해야 했고, 결국 버그는 발견되고, 임팩트는 없으니 성과도 없고. 성과평가(?) 없죠. 결론은 적게 일하고, 많이 법시다.