변경에 대해 의사소통하기

 프로젝트를 진행하면서 내 코드가 조원에 의해 수정되거나, 조원의 코드를 내가 수정하는 경우가 빈번했다. 항상 소통방식이나 코드 수정에 대해서 고민하여 조심스럽게 해야한다는 생각이 들어, 좋은 아티클과 에세이가 있어서 간단히 기록해두기 위해서 글을 쓴다.

---

소프트웨어 변경에 대해 이야기하는 방법

 

원작자가 불쾌하지 않고 개선하는 방법, 나의 코드 수정이 불편하지 않은 편안한 문화를 위한 조언. 대상에 따른 소통법

 

1. 이전의 상태는 어땠나요?

 문제영역의 틀을 잡아야한다. 

=>문제영역의 설명 대상을 파악하기

   문제영역에 직접적이고, 오래 근속한 사람을 대상으로는 간단한 설명.

   신입사원이나, 처음 코드를 접하는 사람에게 설명한다면, 더 깊고 자세하게 정보를 설명해야함.                                       

 

 

2. 왜 미흡했나요?

 무엇이 누락되었는지, 잘못되었는지, 로직이 지나치게 복잡하진 않은지, 추가로 발생되는 문제가 있는지에 대해 설명해야한다.

현재 존재하는 코드는 그것이 만들어질 당시의 지식과 제약, 그리고 여러 절충의 결과임을 기억해야 한다. 또한 이런 코드들은 사용자의 검증과, 피드백을 통해 새로운 가설들을 세우고, 리펙토링된 결과일 것이다. 이를 보고 수정을 하기 위해서는 실수를 지적하는 것이 아닌 미흡한 부분을 끊임없이 발전시키기 위한 방향으로 이뤄져야할 것이다.

 

=>생각해보면 좋을 질문

• 미흡함을 발견한 과정
• 코드가 작성된 순간의 절충과 제약
• 절충이 더 이상 허용될 수 없는 이유
• 개선할 수 있는 방법

 

3. 무엇을 변경했나요?

  제품의 고객 관점으로부터 변경 사항을 제시해야 합니다. 고객이 기술수준이 높은 경우에만 기술적인 세부 정보를 제시해야한다. 

고객들은 웹사이트가 함수 기반의 리엑트 컴포넌트인지 클래스 기반의 리엑트 컴포넌트인지엔 관심이 없다. 고객들은 페이지 랜더링 속도, 접근성 개선, 오류 해결 등에 대해서 관심을 둔다. 결국 고객을 대상으로한 변경사항 설명에서는 기술적 세부사항을 발표의 주요초점으로 둬선 안될 것이다.

 

(리팩토링 같은 경우는, 최종 사용고객에게는 2차영향을 주고, 결과적인 해를 변경하지 않은 채, 소프트웨어 방정식의 요인을 변경하는 특징을 가지고 있다. 이런 리팩토링에 대한 설명부분에 있어서는, 다른 엔지니어들을 대상으로, 어떻게 변경되었는지에 대해 그 배경과 과정 등에 대해서 상세하게 설명하는 과정이 필요하다.) 

 

시간이 있다면 변경 전후를 모두 설명하고, 시간이 부족하다면 변경 후에 집중하여 설명할 수 있도록 해야한다.

 

=>설명 대상과 시간적 제약에 따라 설명이 달라질 필요가 있다.

 

 

4. 무엇이 더 나아지기를 기대하나요?

   실험가설의 설정 "우리는 {새로운 가설} 때문에 {변경}이 {미흡한 점}을 개선할 것으로 기대합니다."

=> 가설의 타당성을 검증하는 절차를 통해 가설이 잘못된 것으로 판명되더라도, 이러한 변경의 시도는 가치가 있을 것이고, 여기서 받은 데이터를 기반으로 가설을 수정하거나, 새로운 가설을 세우는 과정이 가능해진다. 최선의 경우에는 가설이 맞았고, 이를 통해 사용자의 경험이나, 코드의 로직을 개선할 수도 있을 것이다.  

 

데이터와 학습의 맥락에서 변경 사항을 꾀어내는 것은, 수정사항에 대해 타당한 이유를 가질 수 있는 방법이다. 단순히 다른 사람의 조언을 들었을때, 레퍼런스가 많아서와 같은 이유들은 가설의 맥락이나 데이터의 맥락과 궤를 같이 하지 않는다. 내가 만들었기에 내 변경사항이 좋을 것이라는 주장 또한 데이터에 기반하지 않은 이유이다. 변경 뿐만 아니라 새로 도입하는 기술에 있어서도 이러한 가설을 바탕으로 이유를 검증해 나가면 코드와 서비스가 비록 실패하더라도 유의미할 수 있는 길인듯 하다. (물론 성공한다면, 결과가 수반된 더할 나위 없이 좋은 과정일 것이다. )

---

변경에 대해 의사소통하기라는 번역글을 접하고 난후, 한번 짠 코드에 몰입했던 나의 태도를 반성하게 하는 에세이를 접하게 되었다.

 

 https://hajoeun.blog/more-important-than-my-code (하조은 님)의 에세이를 보고 내 생각을 정리한 내용이다.

 

  내코드를 다른 조원이 수정할 때, 내가 시간 많이 들여서 짜낸 코드인데, 아깝다라는 생각이 든 적이 몇번 있었다. 하나하나가 포토폴리오에 들어갈 코드라는 생각이 들고, 뭔가 조금씩 배워갈수록 애정이 커지는 느낌이 들었다. 

 

  코드는 서비스를 위해 존재한다라는 말이 정말 많이 와닿았다. 가끔 서비스가 잘 돌아가게 하는 것이 아닌, 내가 이미 짜놓은 코드를 살리면서 서비스의 오류를 살리는 법에 대해서 고민하고 있지 않은가라는 생각이 들기도 했다. 에세이에서 나오듯이 적절한 타이밍에 고객에게 좋은 서비스 경험을 전달하는 것이 내가 만족하는 코드를 작성하는 것보다 더 중요할텐데, 가끔은 내 코드를 지키기 위해 행동하는 모습들이 있었던 것 같다.

 

 개발 속도를 위해서는, 그리고 코드의 통일성을 위해서 나의 코드를 포기할 수 있는 용기도 필요하다. 과도한 코드 완벽주의를 지양하고, 코드의 퀄리티와 서비스 개발 속도의 균형을 유지할 수 있는 개발자가 되어야 한다. 리팩토링도 분명 필요하다. 하지만 이전의 코드 리팩토링을 위해 서비스 개발 속도를 희생해서는 안된다.

 

에세이에서 코드와 거리를 두는 몇가지 노하우를 제공해주셨다.

• PR을 날린 순간 팀의 코드라 생각하기
• 기계처럼 단순히  (구조개선, 파일이름 변경도 필요하겠지만, 우선 기능이 중요하다. 기능부터 깔끔하게 끝낸 후, 리팩토링을 하자)
• 개발자의 업무범위 다시 정의하기 (요구 사항 분석, 설계, 구현, 테스트, 배포, 장애발생 상황, 고객피드백과 서비스 개선 등 개발자의 업무는 광범위 하다. 구현단계에 매몰된 개발자는 코더일뿐이다.)

---

Reference

 번역본 https://ykss.netlify.app/translation/how-to-talk-about-software-changes/

(번역) 소프트웨어 변경에 대해 이야기하는 방법

원문 https://betterprogramming.pub/how-to-talk-about-software-changes-82dfb39cfaa

How to Talk About Software Changes

하조은님의 에세이 https://hajoeun.blog/more-important-than-my-code