Categories
Development

Declarative UI 찬양

Flutter 쓰기 시작한지 1년이 되간다. 초반 두세달은 Declarative UI 적응하고 Dart 적응하고 Flutter 적응하느라 러닝커브가 심했지만 익숙해질수록 고통없이 빠르게 화면을 찍어낼 수 있게됐다. 곰곰히 생각해보니 이건 숙련도의 문제라기보다 선언적 UI의 긍정적 부수효과인 거였다.

Kotlin Anko 쓸때도 왜 이렇게 기분이 좋은지 잘 몰랐다. 그저 이름과 발음이 내 취향이라 그런줄로만 알았는데 지나고나서 생각해보니 비슷한 효과였다.

이름을 짓느라 시간을 허비하지 않아도 된다!

대충 지은 이름은 그 존재를 인식하는 것만으로도 굉장히 불쾌한데, 요즘처럼 가져다 써야하는 라이브러리가 백만개쯤 되면 얘네들 때문에라도 자꾸 이름 짓기를 강요받게 되고, 그러다보면 서로 어울리지 않는 애들이 모여 collocation 엉망진창 되고 코드를 읽는자도 그에 동화되서 머리속이 더러워진다. 이름 지은 애들끼리 하이러키 똥망되고 족보 꼬이면 코드 볼 때마다 고통받는 것이다. 논리적으로 서로 딱히 연결될 이유가 없음에도 불구하고 레퍼런스가 필요하다는 이유로 불필요한 이름 짓느라 얼마나 괴로웠는지 말도 못한다.

불필요한 참조를 만들지 않아도 되는 모든 것들에게 감사한다. 파이썬의 list comprehension 도 그래서 행복하고, Rx도 구독 핸들러만 들고 있으면 독립된 다른 공간에서 복작복작해서 최종 결과물만 콜백으로 주니까 나는 이름을 안지어도 되는 거다. 백앤드면 하나하나 다 의미있는 경우가 많겠지만 내가 왜 padding wrapper 따위한테 이름을 지어줘야하냔말이다. 키스토로크 하나하나가 아깝다.

선언적 UI 트리내에 동적으로 변경해야하는 부분이 있으면 React.createRef 같은 것을 쓰거나 잦은 화면갱신를 피하기 위해 별도 state를 가지는 컴포넌트를 새로 만들어야하는데 아니 변수명 짓기도 싫다는데 클래스명을 지으란 말입니까. 물론 어떤 화면에서 잦게 변경되는 부분이 있다면 논리적으로 별개의 것일 확률이 높고 그렇다면 분리하는게 맞지만 살다보면 안그런 경우도 많은 것이다. 이런 상황에서 이름 안짓고 성능도 떨어지지 말라며 BLoC 가 또 나를 구원해줬다.

추적해야할 레퍼런스가 적고 생존주기가 짧을수록 행복해진다. 다음 글에서는 이 글을 까는 글을 써야겠다.