22년 연말부터 연초(라기엔 벌써 22일이 되어버린)까지의 생각을 마구 써놓은 글..
생각날때마다 말머리를 적어 놓고, 글에 살을 붙이고, 짜깁고, 생각나는대로 휘갈긴,
읽는 사람을 배려하여 쓴 글이 아니고, 여러 고민과 생각들을 글로써 풀어낸 것이라.. 글이 쉬이 읽히지는 않을 수 있습니다.. ^ㅁ^
한마디로 그냥 의식의 흐름대로 주저리주저리 한 글임 ㅎㅎ
요즘.. 이런저런 고민이 참 많이 생긴다.
또 내가 해결하지 못 할 고민은 하지 말라는 말이 있는데, 해결하지 못 할 고민은 아니다.
뭐랄까.. 정답이 없는 고민들인 것 같다.
개중에 이제 완전 개발 관련된 고민들을 읊어 보자면,
요즘 일하는 데에 플러터를 쓰니까 플러터 관련이 많이 나오긴 한다.
예를 들면 가장 기초적이고 단순한 고민으로는 상위 Widget에 Padding을 넣는 쪽이 나을 지, 하위 Widget에 Padding을 넣는 쪽이 나을 지.. 도 고민이고
DB와 통신할 때 단일 commit으로 묶을 지.. 여러 번 변경사항적용을 할 지..
근데 이건 단일 commit이 맞는 것 같긴 한데, 그렇게 하면 함수를 여러 개로 동작마다 분리할 수 없다는 게 굉장히 슬픈 일이여서.
또 안 묶자니 performance적인 면에서도 그렇고, 중간에 오류가 난다면 재화만 소모가 되고 뒷 내용은 정상적으로 적용이 안 되는 일이 일어날 수도 있으니까.. 묶는게 맞는데 참 맘에 안 든다. 어떻게 깔끔하게 해결할 방법이 없을까? 싶은 생각도 자주 한다.
또 뭐 생각하자면 화면.. 그러니까 UI를 구성할 때, 위젯들을 어느 정도로 함수로 분리할 지도 정말 고민이 되는 부분이다.
버튼 하나, 텍스트 하나까지 각각의 Function으로 분리해서 가자니 하위 위젯의 Function으로 넘겨줘야 하는 Argument가 너무 많아지고 중복되는 문제가 있고..
그렇다고 한 Function에 구겨 넣자니 코드도 너무 길어져서 가독성도 안 좋고, 죽음의 피라미드(..) 처럼 생긴 코드가 완성되는 것을 볼 수 있다. 이건 뭐 Declarative UI를 표방하는 Flutter의 특성상 어쩔 수 없다고 생각하긴 하는데, 그래도 너무 탭이 깊어지면.. 보기도 힘들어서 적절한 단계에서 계속 분리 분리 분리 하고있긴 하다..
명확하게 무슨 “작동”을 하는 일련의 과정! 이면 그냥 망설임 없이 다 함수로 빼버리긴 하는데. 근데 이건 또 위젯을 return하는놈이니.. 나눈다고 능사가 아닌 듯 하다.
결국 메소드로 나눌 만큼은 나누고, Argument 개수를 관리하는 게 가장 중요한 듯.
그 유명한 로버트 C.마틴의 Clean Code 책에서 나온 구절이 있는데,
The ideal number of arguments for a function is zero (niladic). Next comes one (monadic), followed closely by two (dyadic). Three arguments (triadic) should be avoided where possible. More than three (polyadic) requires very special justification-- and they shouldn't be used anyway.
뭐 대충 가장 이상적인 argument(매개변수) 개수는 0개고, 그 다음이 1개, 그 다음이 2개, 3개는 특별한 이유 없으면 넘지 마라.. 뭐 그런 말이다.
여느 구절이 그렇듯, 앞뒤 맥락을 같이 읽어봐야 더욱 정확하게 뜻을 파악할 수 있겠지만, 일단 매개변수를 최대한 줄여야 한다는 점에서는 나도 완전히 동의한다.
물론 3개를 넘겨 사용하지 말라는 것에는 완전히 동의하지는 않는다. Clean Code라는 책 자체가 Java를 기준으로 작성한 책이기도 하고.. 다른 언어와 프레임워크들에 완벽하게 적용할 수는 없다고 본다.
그래도 저자가 진짜로 전하고 싶었던 것은 ‘argument가 3개가 넘으면 안 된다’ 라는 말이 아닌, ‘무조건 필요한, “must” 가 아닌 argument들은 다 빼라, argument의 개수를 최대한 줄이고, 하나의 method의 역할을 최대한 줄여라’ 와 같은 말들이 아니였을까 싶다.
요즘 일할 때 기능 변경사항 같은 것들이 있어 이미 작성했던 코드를 보다 보면, 또 옛날의 내가, 아니면 다른 사람이 작성해 놓은 함수들에 많은 argument가 주저리주저리 달려 있는 것들을 보곤 한다.
그쪽을 건드리게 되면, 볼 때마다 필요없는 것들은 쳐내고, 공통되는 주제의 꼭 필요한 매개변수들은 List나 Map(python의 dictionary와 같은 Data Type) 같은 것들로 묶어서 전달하는 등, 최대한 고쳐보려고 노력한다..
근데 분명 한 3달전의 내가 짠 코드인데, 왜 저따구로 짰는지 도통 이해할 수 없는 경우가 많긴 하다.
3달전보다 성장했다는 뜻인지, 아니면 내가 3달전에 코드를 진짜 개판으로 짜놨던 건지 ㅋㅋ;
뭐 이런저런 생각이지만 결국, 이것들이 하나의 생각에서 파생된 고민들이긴 하다.
어떻게 하면 가독성 높고, 깔끔한 코드를 짤 수 있을까.. 하는 생각.
그런 생각들에서 위에 언급했던 로버트 C.마틴씨의 Clean Code를 도서관에서 빌려 놓긴 했다.
시간 날 때마다 종종 조금씩 읽곤 하는데.. 두껍기도 하고, 시간도 그리 많지 않아서 여간 다 읽는 것이 쉽지만은 않다.
그래도 이런 클린 코드에 대한 정보들을 습득하고 난 이후로는 코드를 보는 시각이 조금 달라진 느낌이긴.. 함.
결국 깔끔한 코드라는 것은 개인적으로는 코드의 가독성이 중요한 것 같다.
코드의 간결함이 아닌 가독성. 짧은 게 능사가 아니라는 것이다.
예를 들면 대표적으로는 뭐 if문의 중첩 문제 같은 것들이 있는데,
이건 뭐 guard clause로 바꾸던가, 함수를 따로 빼던가, 아무튼 깊이가 적은.. Nesting이 적은 쪽으로 바꾸는 쪽이 언제나 낫지 않겠나. 가독성을 높일 수 있도록.
물론 그 측면에서 코드의 formatting도 중요하다고 생각한다.
가독성이 낮아지지 않는 선에서 한 줄에 담을 수 있도록, 하지만 한 줄에 너무 꽉 담으면 읽기 힘드니, 또 가독성을 해치지 않는 선에서는 줄을 나눠가며 쓸 수 있도록.
method를 분화시킬 때도 마찬가지로, 뭐 “하나의 함수는 하나의 역할(행동, action)만 해야 한다.” 라는 말이 있다.
근데 이 ‘one action’ 이라는 게 굉장히 추상적인 말이라고 생각한다. 이렇게 생각해보면 저거 좀 책임감 없는 말인듯 ㅋㅋ;
예를 들면 User의 Nickname을 변경하는 일을 해야 한다고 해 보자.
그럼 ‘유저의 닉네임을 변경하는 행동’ 도 하나의 행동이니까 이것 자체로 changeUserNick() 이라는 하나의 method로 끝낼 수 있는 것이 아닌가?
그런데 그 안에서 또 여러 가지 행동들이 존재한다. 'User Model에서 data를 변경시키는 일' 이라던가, '변경된 User Model의 Data를 불러와 DB에 update시키는 일' 이라던가, 'User의 원래 닉네임을 불러와 바꿀 닉네임과 대조시키는 일', '바꿀 닉네임의 글자수가 적절한지, 비속어가 포함되지는 않았는지 체크하는 일(validation)'이라던가.. 등등
이 정도만 적었지만 그 안에서도 또 굉장히 많은 action들이 필요하다.
그런 의미에서 나누려면 끝도 없이 나눌 수 있는 저 수많은 action들을 합쳐서 '하나의 action' 이라고 결정짓고, 그 기준대로 함수를 나누는 것은 결국 직접 해야 할 일이다.
그런 의미에서 저 말이 좀 짜증난다. 아니 하나의 역할이 정확히 뭔지는 알려줘야 될 거 아님 ㅋㅋ
뭐 결국 가독성 높은 코드, 깔끔한 코드를 짜는 것은 이런 수많은 고민들을 하고 나서야, 비로소 자신만의 기준을 찾고 해결될 수 있다고 본다. 이쪽으로 가도 장단이 있고, 저쪽으로 가도 장단이 있다. 결국 그 사이의 줄타기가 아닐까.
그런 의미에서 요즘 들어 뼈저리게 느끼는 것이 또 하나 있다. 결국 깔끔한 코드를 작성하다 보면 자연스럽게 따라올 수 있는 결과라고 생각하는데, 언제나 확장성을 항상 염두에 두고 코드를 짜야 한다는 것을 정말 몸소 느낀다.
위에서 말했듯 함수로 여러 개 계속 분리해 놓고, argument가 계속 많아지니까, 기능을 변경하거나 리팩토링할 때 그것들을 타고타고 들어가면서 고칠쳐야 하는데, 너무 빡세다.
근데 그래도 어떨 때는 재사용성을 생각하면 자르고 자르고 자르는 게 낫다.
예를 들면 Row 내에서 둘의 위치를 뒤집고 싶을 때.. 아무래도 둘 다 class 밖으로 Extract해 놨으면 둘의 위치만 바꾸면 되고, 또 그 위젯이나 함수를 다시 사용하고 싶을 때 그대로 불러와서 사용하면 되니까.. 그런 점은 나중에 편하다. 고치게 될 때나 복잡해지는 거지.
뭐 그런 면에서 수정할 일이 생길 때마다 적정선까지 되는 대로는 리팩토링을 꾸준히 해주는 중이다.
이거 뭐 대충 복붙해서 고칠 순 있겠지만.. 나중에 또 이런일이 발생하면? 더 복잡해지고 빡세진다. 지금 한 번에 해두는 게 낫다.
그래서 한번에 깔끔하고 다시 손댈 일 없게, 나중에 수정하기 더 쉽고 편하도록 하는게 낫다. 정말로.
근데 이러면 리팩토링에 시간이 오래 걸리기 때문에.. 이건 뭐 기능을 하나 구현하거나 버그를 픽스하는 행동이 아니다 보니, 처리하게 되는 티켓(지라 티켓)이 따로 존재하는 것도 아니고, 일 별로 안 하는 것 처럼 보이게 되는 게 좀 억울하긴 하다. ㅎㅎ;
가독성있는, 깔끔한 코드에 대해서 정말 의식의 흐름대로 많이도 주저리주저리 읊은 것 같다.
한 3개월 뒤의 내가 보면 또 생각이 달라질 지도.
이제 다른 얘기를 해 보자면, 위에서 몇 번 나온 단어가 있는데, 능사라는 말이 좀 나왔다.
능사.. 능사라고 하니 또 요즘 하는 생각 중 하나는, 프로젝트를 하는 것, 여러 프로젝트를 돌리는 것이 언제나 능사인가? 라는 생각도 종종 한다.
돌린다는 표현 자체부터가 좋은 느낌은 아니긴 하지만, 사실인걸.
일단 프로젝트를 ‘돌린다’ 라니. 무슨 말인가 하면,
뭐 개발자 취업이든, 개발자 역량 성장이든, 여러 글(에세이든, 취업후기든, 뭐든..)들을 보면, 종종.. 아니 거의 대부분 보이는 말이 있다.
“(사이드) 프로젝트 하세요” 하는 말이 굉장히 많이 보인다.
나는 프로젝트를 하는 것 자체는 굉장히 좋고, 긍정적이라고 생각한다.
일단 기본적으로, 개발 공부를 할 때 나는 "Study to Make" 보다는 "Make to Study"가 실현되어야 한다고 생각하는 사람이다.
뭔가를 만들면서 그에 대한 궁금증이나 필요한 공부를 하나씩 뽑아내고, 차근차근 깊게 들어가면서 익히는 것이 더 즐겁고 빠른 성장을 도모할 수 있다고 생각한다.
그렇다고 비슷한 프로젝트를 여러 번 반복하는 것은 정말 최악의 행동인 것 같다.
또, 하나의 프로젝트를 하더라도 그냥 무언가를 만들었어요! 짜잔! 하는 것도 마찬가지.
뭔가를 만들고, 기능하게 하는 것은 솔직히 과장 한트럭 보태서 구글링하면 중학생도 해내고도 남는다.
결국 새로운 프레임워크를 도입해 보았다면 그것에 대해 공부했다던가, 아니면 어떤 디자인 패턴을 사용했다는 것에 그치지 않고 프로젝트 규모가 커진다면 어떻게 확장되어 적용될 수 있는가에 대해 고민하고, 사용자의 입장에서 어떤 식으로 작동하는 지에 대해 생각하고, UI는 어떤 식으로 구성되는 것이 더 좋은 UX를 이끌어 낼 수 있을지.. 등등
이런 주제들이든, 어떤 주제든 결국 무언가에 대해 깊게 생각해 보는 것이 무조건 필요하다고 생각한다.
그 과정이 없다면 그건 그냥 모양새가 예쁜 대학교 팀플 하나에 불과하다. 그것조차 안하는 것보다는 낫지만.
또 별건 아닌데, 커밋 메시지 본문에 자세하게 쓰는거에 살짝 맛들렸다.
원래는 제목에 간단하게 쓰고 끝내려고 하는데.. 그걸로 표현이 다 안되는 경우가 너무 많아서 그냥 가끔 변경점 다 적어버린다.
일하는거 뭐 contributor 3명짜리 프로젝트긴 해서 누가 읽겠냐마는, 그냥 연습한다는 생각으로 적는다.
근데 이것도 커밋단위같은거 생각하느라 항상 고민이다.
one action = one commit으로 생각하긴 하는데, 여기서도 one action의 기준이 문제란 말이지.
또 간단한 1~2줄짜리 변경사항 같은 것들은 따로 커밋하기도 별로 내키지 않는다. 머리로는 해야 된다는 걸 알고는 있는데, 이런거 하나하나 따로 커밋하면 커밋로그 너무 늘어지고 깔끔하지도 않게 된단 말야..
그래서 이거 커밋 로그를 어떻게 해야 깔끔하게 관리할 수 있는 지 항상 생각하게 된다. 아무리 봐도 잘 모르겠음.
아니면 push하기 전에 한번 squash해서 그냥 압축해버리는 쪽이 나은가 싶기도.
또 개발 관련해서 요즘 생각이 드는 것중에 마지막은 이거 같은데..
실력의 성장에 조금 정체기가 왔다고 느끼는 것 같다.
정량적으로 잴 순 없지만.. 아무튼 그런 느낌.
이게 학교를 다니면서 과제에 치이고 시험에 치이고 팀플에 치여 바쁘게 살면서 다른 공부를 못했음에 그렇게 느끼는 것인 것 같긴 한데.. 뭐..
여태 길지 않은 공부의 과정 중에 Turning Point라고 해야 하나.. 시야가 바뀌게 되는 시점이 한 두세 개 정도 있다고 생각한다. 다 새로운 도전을 하거나, 정말 시간과 노력을 많이 들였던, 속된 말로 빡세게 공부했거나 빡세게 살았던 기간들이다.
그만큼 성장을 했다고 생각하고, 힘들었던 것들은 성장통이라고 생각하면 될까.
공부 시작이 20년 1학기.. 그러니까 컴퓨터공학과 입학 시점이라고 한다면,
첫째는 1학년 2학기(21년 1학기, 상반기)의 최은만 교수님의 자료구조 강의.
이 때 자료구조 수업을 C++로 진행했는데, 그 전까지 나는 기초프로그래밍 강의에서 C언어만 배워 봤지 뭐 다른 건 아는 게 하나도 없었다.
제네릭 타입도 뭔지 모르고, 더군다나 클래스에 대해서도 하나도 몰랐는데 과제 내용엔 그런 것들이 이미 고스란히 녹여져 있었다.
일주일에 하나씩 과제를 내 주셨는데.. 정말 초반 몇 주 동안은 울며 겨자먹기로 구글링하고 C++공부하고 하면서 과제 한 번 하는 데에 밤 한 번 새가면서, 8시간~12시간동안 그 과제 하나를 풀기 위해서 매달려서 구글링하고 찾아보고 공부했던 기억이 난다.
둘째는 2학년 1학기(21년 2학기, 하반기).
이 때는 어드벤처디자인이라고 1학년 팀플과목을 들었는데, 뭐 이것도 좀 할 게 많긴 했지만..
전공전문(3, 4학년 강의)인 소프트웨어공학개론 강의를 신청해서 들었던게 정말.. 다시 생각하면 미친 짓이긴 한데 후회는 안 한다.
이것도 팀플 강의였는데, 뭔가 어플리케이션이나 웹 하나를 클래스다이어그램 이런거 그려가면서 만들고, 애자일 방법론 적용해야가면서 프로젝트 하는 그런 강의였다.
강의도 배워갈 것이 많았다고 생각하고.. 무엇보다 여러 가지를 새로 알게 된 계기가 되었다. 그만큼 새로 알게 되는 것들도 너무 많고 바로바로 적용해서 만들어야 돼서 힘들었지만.
그때 돌아보면 C++이랑 자바 강의 들은거밖에 없는, 프레임워크가 뭔지도 모르는 애 앉혀놓고 flutter랑 firebase로 앱 하나 같이 만들어준 팀원 선배님들 너무 고맙게 생각하고 있다...
셋째는 22년 상반기.
기회가 있어 한 학기 휴학하고 스타트업에서 프리랜서 느낌으로 일하게 되었는데, SwiftUI나 Swift를 이용한 iOS 개발도 경험해 보고, 뭐 이것저것 경험해 보게 돼서 좋았다고 생각한다.
그리고 21년 두 학기 다 너무 힘들게 24학점, 23학점을 수강하면서 너무 힘들게 살았어서, 한 학기 정도 휴학하면서 사는 거 나름 편하고 행복했다.
그리고 이 시기에 이런 경험 해보는 거 굉장히 귀하고 나쁠 거 없다고 생각해서, 휴학하고 이런 길을 밟은 건 좋았다고 생각한다.
지금도 방학 되어서 다시 여기서 일하고 있기도 하고. ^ㅁ^
뭐 그런 터닝 포인트들이 있었고,
다시 원점으로 돌아와서 정체기가 왔다고 느끼는 건 이번 학기에 별다른 일이 없었기 때문일까.
근데 이번 학기도 7전공에 5팀플로 지난 학기들 못지 않게 열심히.. 아니 죽을 듯 아둥바둥 살았다고 생각했는데, 크게 변한 것을 느끼지 못해서일까?
매너리즘에 빠졌다고도 조금 생각이 든다.
지금도 방학중에 일하면서, 그리고 계절학기까지 병행하면서 빡세게 살고 있어도, 항상 Make It을 하는 것은 맞지만, 내가 Get Better해진다고는 생각이 잘 들지 않는다.
뭐 작년 8월쯤을 생각해 보면 성장하지 않았다고 느끼지는 않지만.. 뭔가 곱하기로 성장하고 싶은데 더하기로 성장하는 느낌이랄까.
항상 터닝 포인트들에는 새로움과 즐거움을 찾는 행동이 있었고, 그래서 다시 한 번 전환점을 찾고자 Apple Developer Academy에 지원해서 합격하길 간절히 원했던 것 같기도 하다.
결국 합격했고, 가서 공부할 생각에 싱글벙글 중이긴 한데.. 이건 나중에 후기같은 글로 풀어내기로 하고.
암튼, 결국 뭔가 고민만 많고 해결되는 건 없고 정체기 온 것 같고 이런 하소연 주저리주저리 쓴 거다.
Apple Developer Academy가 뭔가 이런 것들을 타파할 수 있는 기회가 될 수 있었으면 좋겠는 것이 현재 심정이고,
당장에라도 일단 2월까지는 하던 일 계속 할 것이고, 바빠서 3월 전에 뭔가 새로운 것을 시도해 볼 만한 것이 있을 지는 잘 모르겠지만, 준비하고 있다면 언제든 기회가 오겠지, 싶다. 아니면 갑자기 뭔가 하고싶어지면 하겠지. ㅎ