<div id="readability-page-1" class="page"><div><h2 id="요약">요약</h2>
<p>컴포넌트 파편화에대해 부정적인 생각을 가지고 있었으나 실제 개발 후 유지보수 과정에서 한 컴포넌트에 너무 많은 코드가 포함됨으로 유지보수 관리에 불편함을 겪어 적절한 컴포넌트와 규칙의 필요성을 깨닫고 개선 중.</p>
<h2 id="문제발생">문제발생</h2>
<p>Chart app은 식물의 환경 데이터(온,습,co2 등)를 재배사들에게 Chart를 통해 시각화 해주는 서비스다..</p>
<p> 처음 설계할 때, 실시간 기능을 위해 백엔드와 소통에 websocket 활용을 결정했고 효율성을 위해 해당 앱의 모든 api req과 res를 websocket 하나의 객체를 이용하기로 결정.</p>
<p> 효율성을 생각했을때 당시에 옳은 결정이였다. 그러나 해당 프로젝트는 기획과 요구사항이 명확하지 않은 상태였기에 추가적인 기능이 예상보다 늘어났고 이는 코드에 예상치 못한 코드들이 추가되는 복잡함을 만들었다.</p>
<p> 이 때문에 현재 websocket 객체를 가지고 있는 하나의 컴포넌트의 코드의 길이가 길어지게 되었고 유지보수 및 디버깅을 하기 어려워졌다.</p>
<p> 그리고 최근 Chart app에 치명적인 버그를 발견했고 해당 버그의 원인을 찾아내는데 '클라이언트 코드에는 문제 없다' 라는 말을 자신있게 할수가 없었다. </p>
<p> 그렇게 이 치명적인 버그는 모든 가능성을 열어놓고 버그 시나리오를 좁혀나가 찾아냈고(노가다...) 결국 백엔드 코드 안에 있는 websocket 객체와 관련된 문제로 확인됐다.(사실 백엔드 코드도 제가 짠. ..)</p>
<p> <img src="https://velog.velcdn.com/images/2taesung/post/5f186eb8-92fb-476a-8410-877c7260b6de/image.png"></p>
<p> 아무튼 ... 원래 나는 컴포넌트를 작게 쪼개는 것을 별로 선호하지는 않았었다. atom이라는 작은 단위로 쪼개는 atomic design이라는 말도 있지만 실제로 이렇게 쪼갠 시스템에서 생산성 향상을 경험해본적이 없기 때문이다. </p>
<p>  이 디자인을 정확히 경험해본 사람이 리드해보질 않았기 때문에 이러한 논쟁을 하다가 시간만 가고 프로그래밍을 시작하는데 시간만 걸렸던 경험이 있었다.</p>
<p> 이것은 제가 서비스 개발 후 유지보수를 제대로 해본 경험이 없어 생긴 오해였다. 여전히 atom 단위로 컴포넌트를 쪼개는 것(파편화라는 표현도 있던데...)까지 필요한지는 아직 의문이지만 </p>
<p> 이번 경험을 통해 최적의 컴포넌트 분리를 선택해야 개발 이후에 유지보수에 효과적이라는 사실을 깨닫게 되었습니다. 그리고 이것은 상당히 비용이 들어가는 단위로도 쪼개는 것도 가치가 있다는 것을.</p>
<h2 id="향후-개선-방향">향후 개선 방향</h2>
<p> 현재 해당 서비스는 React.js 환경에서 Next.js /TS 환경으로 마이그레이션을 계획하고 있다. 계속 미뤄오고 있다가 충분히 참고할 만한 레퍼런스를 발견해 해당 레퍼런스 코드를 참고하며 환경을 구성해볼 생각이다.</p>
<ul>
<li>atomic design을 레퍼런스로 하여 개발팀 내부의 컴포넌트 규칙을 정하고 문서화</li>
<li>현재 사용하고 있는 디자인 라이브러리 rsuite를 기반으로 커스텀 디자인시스템 컴포넌트화</li>
<li>디자인팀과 해당 컴포넌트 협의 및 최종 약속</li>
<li>Next.js /TS 환경 적용 테스트 서버에 해당 컴포넌트 시스템 적용</li>
</ul>
<p>디자인시스템 개선시 참고하게 된 글</p>
<p><a href="https://jojoldu.tistory.com/694">https://jojoldu.tistory.com/694</a></p>
<p><a href="https://velog.io/@velopert/%EC%9B%90%ED%8B%B0%EB%93%9C-%EC%9A%94%EC%A6%98-%ED%94%84%EB%A1%A0%ED%8A%B8%EC%97%94%EB%93%9C-%EA%B0%9C%EB%B0%9C-%EC%96%B4%EB%96%BB%EA%B2%8C-%ED%95%98%EC%A7%80-%EC%B0%B8%EA%B4%80-%ED%9B%84%EA%B8%B0">https://velog.io/@velopert/%EC%9B%90%ED%8B%B0%EB%93%9C-%EC%9A%94%EC%A6%98-%ED%94%84%EB%A1%A0%ED%8A%B8%EC%97%94%EB%93%9C-%EA%B0%9C%EB%B0%9C-%EC%96%B4%EB%96%BB%EA%B2%8C-%ED%95%98%EC%A7%80-%EC%B0%B8%EA%B4%80-%ED%9B%84%EA%B8%B0</a></p></div></div>

2taesung.log

Taesung Lee

요약
컴포넌트 파편화에대해 부정적인 생각을 가지고 있었으나 실제 개발 후 유지보수 과정에서 한 컴포넌트에 너무 많은 코드가 포함됨으로 유지보수 관리에 불편함을 겪어 적절한 컴포넌트와 규칙의 필요성을 깨닫고 개선 중.
문제발생
Chart app은 식물의 환경 데이터(온,습,co2 등)를 재배사들에게 Chart를 통해 시각화 해주는 서비스다..
 처음 설계할 때, 실시간 기능을 위해 백엔드와 소통에 websocket 활용을 결정했고 효율성을 위해 해당 앱의 모든 api req과 res를 websocket 하나의 객체를 이용하기로 결정.
 효율성을 생각했을때 당시에 옳은 결정이였다. 그러나 해당 프로젝트는 기획과 요구사항이 명확하지 않은 상태였기에 추가적인 기능이 예상보다 늘어났고 이는 코드에 예상치 못한 코드들이 추가되는 복잡함을 만들었다.
 이 때문에 현재 websocket 객체를 가지고 있는 하나의 컴포넌트의 코드의 길이가 길어지게 되었고 유지보수 및 디버깅을 하기 어려워졌다.
 그리고 최근 Chart app에 치명적인 버그를 발견했고 해당 버그의 원인을 찾아내는데 '클라이언트 코드에는 문제 없다' 라는 말을 자신있게 할수가 없었다. 
 그렇게 이 치명적인 버그는 모든 가능성을 열어놓고 버그 시나리오를 좁혀나가 찾아냈고(노가다...) 결국 백엔드 코드 안에 있는 websocket 객체와 관련된 문제로 확인됐다.(사실 백엔드 코드도 제가 짠. ..)
 
 아무튼 ... 원래 나는 컴포넌트를 작게 쪼개는 것을 별로 선호하지는 않았었다. atom이라는 작은 단위로 쪼개는 atomic design이라는 말도 있지만 실제로 이렇게 쪼갠 시스템에서 생산성 향상을 경험해본적이 없기 때문이다. 
  이 디자인을 정확히 경험해본 사람이 리드해보질 않았기 때문에 이러한 논쟁을 하다가 시간만 가고 프로그래밍을 시작하는데 시간만 걸렸던 경험이 있었다.
 이것은 제가 서비스 개발 후 유지보수를 제대로 해본 경험이 없어 생긴 오해였다. 여전히 atom 단위로 컴포넌트를 쪼개는 것(파편화라는 표현도 있던데...)까지 필요한지는 아직 의문이지만 
 이번 경험을 통해 최적의 컴포넌트 분리를 선택해야 개발 이후에 유지보수에 효과적이라는 사실을 깨닫게 되었습니다. 그리고 이것은 상당히 비용이 들어가는 단위로도 쪼개는 것도 가치가 있다는 것을.
향후 개선 방향
 현재 해당 서비스는 React.js 환경에서 Next.js /TS 환경으로 마이그레이션을 계획하고 있다. 계속 미뤄오고 있다가 충분히 참고할 만한 레퍼런스를 발견해 해당 레퍼런스 코드를 참고하며 환경을 구성해볼 생각이다.
atomic design을 레퍼런스로 하여 개발팀 내부의 컴포넌트 규칙을 정하고 문서화
현재 사용하고 있는 디자인 라이브러리 rsuite를 기반으로 커스텀 디자인시스템 컴포넌트화
디자인팀과 해당 컴포넌트 협의 및 최종 약속
Next.js /TS 환경 적용 테스트 서버에 해당 컴포넌트 시스템 적용
디자인시스템 개선시 참고하게 된 글
https://jojoldu.tistory.com/694
https://velog.io/@velopert/%EC%9B%90%ED%8B%B0%EB%93%9C-%EC%9A%94%EC%A6%98-%ED%94%84%EB%A1%A0%ED%8A%B8%EC%97%94%EB%93%9C-%EA%B0%9C%EB%B0%9C-%EC%96%B4%EB%96%BB%EA%B2%8C-%ED%95%98%EC%A7%80-%EC%B0%B8%EA%B4%80-%ED%9B%84%EA%B8%B0

한 컴포넌트에 너무 많은 역할을 주게 된 경우.

댓글