🦉 위젯이 전부다 : 플러터 앱 개발 첫걸음

이직한지 6개월

• 이번 회사에 와서 플러터를 쓰기 시작했다.
• 1인 개발자인 회사에서 ios, aos 모두 개발해야 한다는 얘기를 들었을 때
• 아 크로스 플랫폼 프레임웤한번 써봐야겠다는 생각이 들었고
• 플러터, 리액트네이티브 중 고민하다가 플러터를 선택했다.
• 뭐 여차저차한 이유는 재껴놓고...

• "플러터는 iOS, 안드로이드, 웹, 데스크톱에서 실행할 멋진 앱을 만들 수 있는 도구모음이다."
• "구글이 플러터를 통해 이루려는 미션은 '더 나은 모바일 개발 방법의 창출'이다. 이 미션에서 빠진점에 주목하기 바란다. 구글이 소유한 안드로이드는 물론 iOS, 웹에 관한 언급도 없다. 플러터의 목표는 모든 기기에 대한 더 나은 개발방법의 창출이다."
• "유일하게 플러터만 동작과 표현이 두 개의 언어로 나뉘지 않고 하나의 언어로 합쳐져 있다... UI도 코드로"

---

첫번째 개발책

• 원래 개발할 때 책은 잘 참고 안하고 보통 강의영상 메인으로 하나 결제해두고,
• 유튭과 구글링으로 개발을 하는지라 요 책이 완독한 첫번째 개발책이 되었다.
• 의도치 않게 플러터 개발 시작한지 6개월 후 첫 책을 읽게됨..
  (물론 이전에 '해커와 화가'라는 명저를 읽은적은 있지만 그거는 순정 개발책은 아닌지러 노카운트 ㅋㅋ)
• 읽으면서 플러터라는 프레임웤? 플랫폼? 전반이 연결되는 경험을 했고
• 뚜렷이 어떤 점이 개선되었다고 구체적으로 말할 수는 없지만
• 개발 자체에 대한 통제력이 커졌음은 느낀다.
• 그것을 구체적으로 어떻게 표현할 수 있을지 앞으로 계속 고민해야 한다고 생각하구

• "이 책은 초보자가 원하는 내용은 물론 그 이상을 담고 있다. 플러터 자체를 설명할 뿐 아니라 플러터가 존재하는 이유까지도 설명한다."
• "랩 페인은 얼리어답터이자 커뮤니티의 원년 멤버로서 플러터에 관한 세계 최고의 권위자 중 한명이다. 랩은 엔지니어를 대상으로 작성하는 엔지니어로 고맙게도 다른 사람이 쉽게 이해할 수 있는 즐거운 문체로 책을 쓰는 사람이다."

---

비슷한 문제에는 비슷한 해결책

• 웹 개발, 앱 개발.. 다른 어플리케이션을 개발하지만
• 크게 보자면 비슷한 문제들을 고민하게 된다.
  • 어떻게 사용자에게 화면을 보여줄지 고민하고,
  • 어떻게 화면에 나올 데이터를 관리할지 고민하고,
  • 어떻게 화면과 데이터를 상호작용하게 할지 고민한다.
• 비슷한 문제 상황에는 비슷한 해결책이 나오기 마련.
• 조금 더 효율적이고 조금 덜 효율적일 수는 있어도 그것이 풀어주는 문제는 비슷하다.

• "pubspec.yaml 파일에는 프로젝트에 관한 온갖 종류의 유용한 정보가 들어있다. 프로젝트에 새로 합류한 개발자가 가장 먼저 살펴봐야 하는 파일이다. 자바스크립트 개발자라면 다트 프로젝트의 package.json 파일이라 생각하면 이해하기 쉽다."
• "플러터가 아주 작은 변화 하나까지 화면에 적용해서 초당 수백번씩 다시 렌더링 한다면 속도가 엄청나게 느려질 것이다. 플러터는 대신 변경사항을 엘리먼트 트리의 복사본에 반영한다. 그런 다음 주기적으로 현재 엘리먼트 트리와 변경사항을 적용한 엘리먼트 트리를 비교해서 다시 렌더링할 부분을 결정한다. 즉 꼭 필요한 부분만 다시 렌더링한다. 하지만 가끔 플러터가 엘리먼트 트리 안의 위젯을 제대로 찾지 못할 떄가 있다. 데이터를 바꿨는데 위젯이 이상한 위치에 등장하거나 화면 위의 데이터가 바뀌지 않거나 스크롤 위치가 어긋난다면 코드를 통해 직접 키를 설정해야 한다. 대부분 키를 미리 걱정할 필요는 없다. 키가 필요한 상황은 매우 드물어서 다음 내용을 이해하는 정도면 충분하다."
• "build메서드는 항상 이렇게 거대한 중첩 표현식 하나를 리턴한다. 이 큰 위젯 안에 위젯을 넣고, 또 그안에 위젯을 넣어가며 정교한 커스텀 위젯을만들 수있다."
• "플러터 세계에서는 컴포넌트를 위젯이라고 한다... 컴포넌트화가 바로 이 책의 플러터 프로젝트를 통해 체험할 사고과정이다... 위젯을 합쳐서 커스텀 위젯을 만들고, 커스텀 위젯을 합쳐서 더 복잡한 커스텀 위젯을 만든다. 완전한 앱이 만들어질 때까지 이 과정을 계속해야 한다."
• "- "화면 = f(데이터), 앱의 데이터가 바뀌면 거기에 맞게 화면도 바뀐다... 상태(state)란 위젯이 살아있는 동안 바뀔 수 있는 위젯 안의 데이터를 말한다."

---

이 책의 훌륭한 점

• 이 책을 읽으면서 즐거웠던 경험!
• 복잡한 개발문제를 비유를 활용해서 이해쉽게 풀어줄 때
• 그럴 때 마음 깊숙한 곳에서 감탄과 함께 쾌감도 느껴졌다.
• 이 책의 몇가지 포인트에서 그런 부분을 느낄 수 있었고
• 그것들을 보며 나도 그러한 비유들을 많이 만들어야 겠다는 생각이 들었다.
• 누군가에 설명해줄때나, 나 스스로의 이해를 단단하게 만들떄!

• "gestureDector는 엄청나게 많은 이벤트를 지원하므로 당황스러울 수 있다... gestureDector는 이런 제스처를 모두 gestureArena라는 경기장에 넣는다. 지어낸 말이 아니다. 이 경기장에서 마지막 까지 남는 제스처가 승자다. 리스터가 없는 제스처는 경기장에서 쫓겨난다."
• "자신이 사용할 수 있는 공간을 전부 채우려는, 즉 욕심이 많은 위젯이 있다. 이런 위젯은 자신을 제한할 부모가 필요하다. 이런 위젯이 제약없이 방치하는 부모 밑에 있다면 플러터는 개발자의 의도를 이해할 수 없어서 혼란에 빠진다. 직설적으로 말하면 플러터가 레이아웃을 처리하는 방법을 제대로 이해하지 못할 때 나타나는 증상이다."
• "플러터는 위젯트리에 들어있는 각 위젯의 크기를 정해야 한다. 그렇게 하려고 각 위젯에 원하는 크기를 묻고 해당 위젯의 부모에게 괜찮은지 확인하는 과정을 거친다. 플러터는 루트에서 시작해서 트리를 타고 내려간다. 먼저 루트위젯의 제약을 확인한다. 위아래, 양옆으로 어디까지 커질 수 있지? 그리고 결과를 기억한 뒤에 모든 자식을 찾는다... 가지의 끝을 리프레벨이라고 한다...
• "각 자식은 부모가 허용하는 한도 안에서 원하는 높이와 너비를 얻는다. 그리고 모든 자식이 최종 크기를 얻기 전까지 부모는 최종크기를 얻지 못한다... 최대한 커지려는 자식이 있는데 멈추라고 말하는 부모가 없다면 자식의 높이에 제한이 없어서 플러터가 혼란에 빠진다."

---

책을 읽어서 얻은 것들

• 요 책을 읽으면서, 첫 개발책인 만큼 왜 개발책을 읽어야 할까 고민했는데,
• 나름으로 정리하는 생각은 다음과 같다.
  • 여러 문제상황에 쓸 수 있는 기술(키워드)들을 인덱싱 해두고 문제가 닥쳤을 때 꺼내어 쓰기 위해서!
  • 그리고 미시적으로 분절되어있는 실전용 기술들을 이어붙여서 거시적인 맥락을 이해하기 위해서!
• 요 두가지를 알게된것이 무척 값지다 생각하고~
• 매달 서너권의 개발책을 읽는 루틴을 만들기 위해 총력을 다할것을 다짐!