느림의미학

기존 컴포넌트를 리팩토링 해야 하는 일이 생겼다. 기존에 보이고 있었던 화면이므로 사용자가 보기엔 차이가 없어야 하지만 코드는 새롭게 쓰여진다. 이때 가져야 할 마음가짐으로는 보이는것과 동작하는것에 만족하면 안된다는 것이다. UI나 기능은 *당연히* 동작 해야 하는것이고 리팩토링을 한다면 현재 팀의 문화에 100% 적합하게 코드를 작성해야 한다. 리팩토링을 하면서 코드를 가져와서 기존의 코드가 곳곳에 녹여져 있는 경우가 많을 텐데 이때에도 이 코드가 현재 팀의 코드 스타일과 맞는지, 생각하며 가져와야 한다. 그렇지 않다면 내가 새로 만들었지만 만들자마자 레거시로 전락하게 된다. 레거시를 리팩토링 하는것인데 새롭게 레거시를 바로 만들어 버리는 것이여서 리팩토링의 의미가 많이 퇴색되어 버린다. 그리고 만약 ..

오늘은 어제 글을 쓰다가 곁가지로 빠질 뻔 했던 내용인 커뮤니케이션에 대해 간단히 생각을 정리 하려 한다. 언제 내가 이러한 것들을 까먹을지 알 수 없기 때문에.. 사실 지식이 아니라 경험이긴 하지만 이때의 생각들을 적어두면 나중에 다시 봤을때 또 다른 영감과 그때는 다르게 생각할 수 있겠다 라는 생각이 들어서.. 기업들의 채용공고문을 보면 종종 보이는 커뮤니케이션 능력이 좋은 사람. 이러한 조건을 거는 경우가 있다. 이러한 조건은 사실 수치적으로 표현을 할 수 없는것이기 때문에 지원자가 저 커뮤니케이션 좋아요~ 이렇게 주장한다면 사실 그것을 검증할 방법이 명확히 있을까? 있을것 같긴 하다. 그들이 제시하는 커뮤니케이션이란 무엇이고, 그것을 검증할만한 질문들을 마련해 둘 수 는 있겠다. "이런 상황에선 ..

오늘은 생각이 많아져서 블로그를 이렇게 찾아와서 글을 남긴다. ㅋㅋ 예전에 학생때 글을 쓰던 블로그인데 2년반만에 돌아온것 같다.. 사실 완벽주의 성향이 있어서 완벽주의라 해야하나. 조금더 깔끔하게 조금더 재대로된 글로만 블로그를 다시 단장을 하고 싶어서 깃헙페이지로 블로그를 운영해보려고 시도도 하고 티스토리도 다시만들고 방황의 방황을 했던것 같다. 어느 순간 블로그라는게 내 포트폴리오의 일부로 생각하게 되면서 '아 잘 꾸며 놓고 좋은 글로 채워놔야지' 이런 생각에 쓸 글의 주제를 고심하고 글 하나하나 정성들여 쓰려고 하다보니 (물론 그것도 중요하지만) 지금 시점에 나에겐 벅차다는 느낌을 받았다. 그래서 그냥 남들이 볼 수 있지만, 보는것을 크게 생각하지 않고, 생각이 많은 내가 자유롭게 글을 적는 공간..

객체지향이라는 말 정말 많이 들어봤다. 나도 공부한답시고 글 하나를 포스팅 했지만 과연 이거 하나로 공부가 된것일까? 그것은 아닌것 같다 라는 생각이 들었다. 객체지향은 무엇인가 부터 관련된 여러 키워드들 상속, 다형성 뭐.. 캡슐화 추상화.. SOLID란 등등 많은 키워드 들이 있다.. 근데 결국엔 이것을 어떻게 사용해야 하는지.. 그것을 터득 해야 한다고 생각한다. 상속은 무엇이고.. 다형성은 무엇인지.. 아는것이 무엇이 중요한것인가. 이게 왜 필요하고 어떻게 적용하는지 깨닫는게 먼저라고 생각된다. 그 후 현재 사용되고 있는 프레임워크나 라이브러리에서 이개념을 어디에서 사용하고 있는지 살펴보는것이 중요하다. 우리가 사용하는 프레임원크나 라이브러리들은 정말 훌륭한 개발자들이 만든 코드이다. 따라서 그러..

오늘은 애플 개발자 계정을 드디어 구입했다. 돈이아까워서 앱이 다 완성이 되면 사야지 했지만 이러한 생각은 내가 개발을 하는데 더 시간만 늦추는 것이라 생각되어 조금 손해를 보더라도 내가 공부하자라는 의미로 바로 구매했다 13만원이라는 가격이 작진 않지만 내가 더 많은 것들을 해주는데 아쉬움은 없었다. 혼자 개발을 하다보니 아무래도 일정이 늘어지고 피쳐들도 내 마음대로 마음 내키는대로 작업하기 일수다. 이러한 점을 개선하는 방법이 필요하다고 생각된다. 큰 프로젝트 기간과 세부기간 그 세부기간들에 특징들을 잘 정리하고 그 계획대로 프로젝트를 진행하는게 필요하다고 느꼈다. 프로젝트 계획을 어떻게 진행할지 많은 툴들을 검색해봤는데 일단 깃헙에 있는 Project를 Kanban을 이용해보려 한다.

나는 성격이 참 대충대충 살아가는 성격 같다. 꼼꼼히 따지지 않고 또 내가 무엇을 할때도 어느정도 하다보면 슬슬 한다고 느꼈다 오늘도 느낀것이 청소기를 돌리는데 날이 더워서 그런지 움직이는것만 으로도 땀이 났고 바닥에는 물이 뭍어 있어서 그런지 청소기가 잘 밀리지도 않았다. 결국 나는 좋은 의지로 청소를 시작했지만 중간에 대충 슥슥 하고 마는걸 깨닫고 정신차려서 다시 꼼꼼히 청소를 한 기억이 있다. 또 한번은 엄마가 상추를 씻으라고 시켜서 하나씩 하나씩 씻었는데 마지막에 여러개를 한번에 씻었다. 마지막에 대충 대충 하는 나의 습관이 나온 것이다. 결국 엄마가 상추에서 작은 벌레를 발견해서 나한테 뭐라고 하셨는데 이렇듯 나의 대충대충 하는 습관 어느순간 나타나게 된다. 그냥 하면 됐지. 대충 되면 됐지 라..

오늘 과제 챌린지를 봤다. 자세한 문제 내용을 적을 순 없지만 아무래도 Image 쪽으로 문제가 나왔다. 어느정도 예상은 했었지만 그래도 과제는 항상 볼때마다 떨리는 것 같다. 이게 대량의 Image를 Collectionview 로 표현하는 경우가 많다. feed라고도 하는거 같은데. 프레임드랍을 막기 위해 필요할때마다 이미지를 호출해서 불러와야하고, 또 캐시도 적당히 이루어져야 된다고 알고있다, 이를 라이브러리를 이용해서 하는 경우가 많다 근데 이번에 어느정도 직접 구현을 해야했었는데 이를 잘 해결하지 못한거 같아 아쉬운 마음이 든다. 사실 아쉽다기보단 아에 할줄 몰라서 포기하고 구조에 좀 더 신경써서 구현하긴 했다. 아마 collectionview prepare라던지 image Cache등을 요구했던..

본격적으로 clean swift로 앱을 구현하기 시작했다. Interactor Presentor Router Worker 등으로 나누어서 각자의 역할을 맡아서 신을 관리하는데 유저의 입력을 받는곳은 ViewController와 View에서 먼저 입력을 받는다. 이렇게 입력을 받으면 Interator에게 Business Logic을 맡긴다. 간단한 일은 직접 처리하지만 Worker를 사용해서 무거운 로직을 사용하기도 한다. 이렇게 Business Logic을 처리하면 이를 Presenter에게 연산한 값을 넘겨주는데 Presenter는 이를 View에 표시하기 위한 데이터 형식으로 변환시키는 역할을 한다. 이렇게 Cycle을 이루며 뷰에서 입력을 받으면 출력까지 이어진다. 이는 Clean Swift에서 t..

오늘은 SnapKit을 사용해보았다 어제 Texture를 한번 살펴보고 레이아웃을 도와주는 여러 라이브러를 검색해보다가 SnapKit을 사용해보았다. Texture같은 경우엔 Node라는 View를 Wrapping하고 있는 새로운 클래스를 만들어서 새로운 LifeCycle을 가지고 뷰를 관리 해주고 여러 무거운 작업들을 백그라운드에서 실행 시킴으로서 프레임드랍이 없게 도와주는 조금은 크고 무거운 라이브러리 였다면 SnapKit은 Auto layout을 더 간편하게 사용할 수 있게 도와주는 라이브러리 였다. NSLayoutConstraint.activate([ collectionView.leadingAnchor.constraint(equalTo: view.leadingAnchor), collectionVi..

오늘은 swift의 texture를 사용해보았따. 사용하계된 계기는 당근마켓에서 사용한다길래 과제가 있어 이를 이용할까 해서 공부를 했는데 생각보다 설치에 오래걸려서 아침 오전시간을 다 사용했고 그 후의 점심에 대서야 맛을 좀 볼 수 있었다.. 항상 스스로 생산성이 많지 않다고 느껴서 아쉬웠는데 더 생산성을 높이기 위한 방법으로 학습을 했던거기 때문에 후회는 없다. 여튼 한번 맛을 봤는데 사실 아직 설치를 어떻게 해야할 지도 모르겠다. 설치가 잘 안된다. no such module이라고 뜨는데 이것이 오브젝트 씨로 되어서 된다기보다는 다른 원인이 있을 것 같다라는 생각이 들었다. 여튼 브릿지를 통해 사용해보았는데 음 사실 조금은 복잡? 하다고 생각이 들기도 하였다. 무거운작업들을 백그라운드에서 작업한다고..