서론잠깐 모임이 중지되었던 독서토론 모임이 다시 열렸다. 원래는 개발과 커뮤니케이션 관련 주제였는데, 이번에는 서비스(제품)라는 확장된 주제였다. 회사에서 개발자들과 소통만 하는게 아니라, 다른 직군의 동료들과도 소통 하기 때문에 오히려 좋다고 생각했다. 한가지 아쉬운(?)점은 나는 이제 제품 개발자가 아니라 플랫폼 개발자다. 뭐 이것도 좋게 생각하면 독서토론을 하면서 제품에 대한 감을 잃지 않을 수 있다. 본론이번 모임은 사람이 너무 많았다.. 그래서 좀 부담되었다. 확실히 나는 친하지 않은 많은 사람들 앞에서 얘기하는게 부담된다. 자리도 빈자리 없이 꽉꽉 채워 앉아야했다. 아이스브레이킹이번에도 역시나 아이스브레이킹이 있었다. 이번에는 6명?정도로 조를 나누고 왼손으로 30초씩 돌아가면서 한명의 얼굴을..
서론지인이 직무 관련 독서토론을 하는 것을 보고 나도 관심이 가서 추천해달라고 했었다. 그렇게 추천을 받고 오랜 시간이 지난 후에야 독서토론에 참여하게 되었다. 이번에는 새로운 질서라는 책을 기반으로 독서토론을 했다. 너무 인상깊게 읽었고 요즘 뜨거운 감자인 AI 관련 주제라서 더 관심이 갔다.본론아이스브레이킹부터 시작했다. 역시 이런 모임에는 아이스브레이킹으로 긴장감을 풀고 시작하는게 좋은 것 같다. 가벼운 게임을 진행했는데 나도 나중에 기회가 된다면 이런식으로 아이스브레이킹을 해봐도 괜찮을 것 같다는 생각이 들었다. 몇 가지 기억나는 질문들만 가볍게 적어보겠다. "이 책에서 꼭 공유하고 싶은 한 줄은 무엇인가요"마음의 이상주의는 이성의 현실주의와 양립할 수 있으며 전자가 후자를 고귀하게 만든다는 것을..
리팩터링 원칙 리팩터링 리팩터링 하는데 정의가 무엇일까? 정의는 다음과 같다. 소프트웨어의 겉보기 동작은 그대로 유지한 채, 여러가지 리팩터링 기법을 적용해서 소프트웨어를 재구성하다. 여기서 겉보기 동작은 그대로 유지한 채. 라는게 중요하다. 성능을 개선하고 기능을 추가하는 거은 리팩터링이 아니다. 우리는 커밋을 할때도 기능 추가와 리팩터링 두 개의 모자를 구분해서 바꿔써야한다. 대부분의 회사에서 하는일은 유지보수다. 그리고 기능추가를 하려고 하는데 코드가 지저분할 경우가 있을 것이다. 그럴때는 먼저 리팩터링을 하자. 대단한 리팩터링을 얘기하는 것이 아니다. 함수가 좀 크다면 함수를 나누고 변수명이 모호하다면 변수명을 바꾸고 이런 기본적인 것들이라도 먼저 적용하면 훨씬 깔끔해진다. 이 이후에 코드를 보면..
벌써 4주차가 끝났다. 벌써 세번째 프로젝트의 절반이 지난것이다. 원래 시작할때는 기능구현을 우선적으로 하자고 했는데 어쩌다보니 기능보다는 구조나 코드에 신경을 많이 썼다. 이번 팀원분은 일단 엄청 꼼꼼하다. 그래서 별생각없이 코드를 짤 수 없다. 원래 생각없이 코드를 짜지는 않지만 설득시키기 위해서는 내가 보다 잘 알아야 한다. 그래서 내가 조금 미흡하게 아는 부분은 설명을 하는데 진땀을 뺐다. 팀원이 프로젝트마다 바뀌는 만큼 다양한 사람들과 협업을 하고 다른 관점에서 볼 수 있기 때문에 도움이 되는 것 같다. 이번 프로젝트는 가계부인데 저번 프로젝트보다 할 작업이 훨~~~~씬 적다. 그래서 그런지 구조에 신경을 많이 썼고 다른 팀들도 마찬가지인 것 같았다. 우선 프론트는 내가 구조를 짜고 백엔드는 팀..