2주차는 3대장.. 아니 3발표가 있는 무척 바쁜 주였다. 발표 준비만 해도 분량이 어마어마해서 압박감이 컸는데 여기에 플러스 알파로 다른 팀원들의 발표 분량도(3교양) 모두 읽고 독서록을 작성해야 했다. 그래도 각 팀에서 열심히 준비한 발표를 들으면서 좋은 포인트를 얻어갈 수 있었다.
하지만 무서운건 이번주가 가장 분량이 적은 주라는 사실...😇
[읽기 좋은 코드가 좋은 코드다]
-
개인적으로 뜨끔 했던 부분은 get과 fetch를 무분별하게 썼다는 점. 영어와 안친하다 보니 기분에 따라, 혹은 다른 사람이 썼던 방식 그대로 무분별하게 써왔던 것 같다. 모호한 단어를 생각 없이 쓰기 보다는 어떤 상황에서 어떤 단어가 적절한지 고민하는 과정이 필요하다고 느꼈다.
-
개인적으로 삼항연산자를 잘 쓰지 않는데 그 이유는 (내가 보기에)가독성이 떨어진다고 느꼈기 때문이다. 하지만 코드가 짧아진다는 장점이 있어써 쓰는 것을 권고하는 사람도 있었다. 그렇다면 쓰는게 좋은가? 안쓰는게 좋은가? 다른 사람들도 이 부분에서는 의견이 엇갈릴 것 같은데 한마디로 정리하자면 '정보를 읽고 이해하는데 동일한 시간이 걸리면 짧은 코드, 그렇지 않다면 가독성이 좋은 코드를 작성하라'이다.
-
그렇다면 정보를 읽고 이해하는 주체는 누구인가? 코드라는 것을 생판 처음 보는 사람? 아니면 나와 비슷한 수준의 동료? 가독성을 좋게 한다는 것은 누구를 기준으로 하느냐에 따라 차이가 있겠지만 보편적으로는 나 + 나와 함께 일하는 동료에 맞추는 것이 좋다. 그렇기 때문에 좋은 코드의 완벽한 기준과 정답은 없다고 생각한다. 하지만 보편적으로 읽기 좋은 코드는 누구에게나 가독성이 좋기 마련. 우리는 그 보편성에 팀의 컨벤션을 적절히 섞으면 좋지 않을까 생각한다.
[애자일 마스터]
-
퍼실리테이터님께서 애자일은 방법론이기 보다는 철학에 가까운 개념이라고 한다. 물론 책에서는 방법론적인 부분들을 소개하고 있지만 읽으면 읽을수록 드는 생각은 애자일이란 굉장히 모호하고, 자율에 맡기며, 언제든지 변할 수 있다는 것이다. 그래서 방법론보다는 철학에 가깝다고 하신 것 같다.
-
이 책에서 말하는 애자일의 핵심 포인트는 첫 번째로 '애자일이란 매주 꼬박꼬박 가치를 전달하기 위해 어떻게 해야하는지 고민하는 것'이고 두 번째는 '애자일 프로젝트에서 역할이란 구체적이지 않으며 누구나 여러 가지 역할을 수행할 수 있는 것(개인의 책임감)'이다.
-
언뜻 들으면 이상적이고 완벽해보이지만 개인의 책임감과 열정에 의존하는 방식은 다소 도박이라고 느껴졌다. 굉장히 주관적인 부분이기 때문에 현실적으로 맞출 수 있을까? 하는 의구심은.. 솔직히 책을 읽고 나서도 지울 수 없었다. 하지만 여러 기업에서 추구하는 만큼 매력적인 부분도 있다. 앞으로 진행할 프로젝트에서 어떤 방식으로 애자일을 적용하면 좋을지 고민해 봐야겠다.
❗이 책에서 말하는 '고객'은 제품 관리자(PM, PO)를 의미한다. 그렇기 때문에 고객 = 제품관리자로 이해하고 보면 이해하기 편할 것이다.
[함께 자라기 애자일로 가는 길]
-
이미 많은 개발자 사이에서도 나온 얘기지만 '경력이 그 사람의 실력을 증명하지 않는다'는 개발자라는 영역에서 특히 두드러지는 것 같다. 그렇기 때문에 책에서는 의도적 수련을 늘리라고 이야기한다. 아직 나는 일을 하지 않고 있지만, 공부를 하면서 그저 정해진 커리큘럼과 내용을 따라가기만 했다는 생각이 들었다. 지금이라도 나에게 부족한 점을 찾고 그것을 보완해 나가는 공부를 진행할 계획이다.
도와줘요 퍼실님 그리고 내 동료들..!!! -
개인적으로 놀랐던 부분은 실제 직무와 상관성이 높은 항목이 지능테스트와 작업 샘플 테스트라는 것. 왜 기업에서 적성검사와 코딩테스트를 보는지 알 수 있었던 대목이다. 심지어 더 충격인 건 관심사가 아주 약한 상관성이라는 것.
[SQL 첫걸음]
- 부끄럽게도 지금까지 안드로이드 앱을 혼자 개발하면서 db란 무엇인가에 대해 크게 고민해보지 않았었다. 프론트엔드가 이런 것까지 알아야 해?...는! 절대 아니였고 그냥 안드로이드 하기에도 너무나 벅차고 힘들었기에 자연스럽게 등한시 했던 것 같다. 하지만 안드로이드에도 인앱 db가 있고 나아가 서버 개발자들과 협업하기 위해서는 데이터가 어떻게 적재되고 분류되며, 불러와 지는지 그 흐름을 알 필요가 있다. 이제 막 RDB 시스템에 대해서 첫 발을 뗐고 앞으로는 데이터 흐름과 간단한 쿼리문을 익히는 방향으로 공부할 계획이다.
팀 회고 KPT(Keep - Problem / Try)
이번주에는 팀 회고를 진행했다. 조별과제는 종종 했었지만 팀 회고를 진행하는 것은 이번이 처음이었다. 각 항목에 대해 시간제한을 두고 진행했고 덕분에 필요한 이야기만 타이트하게 진행할 수 있었다. 아래는 figma 툴로 회고를 진행한 결과이다.
하고 나서 느꼈던 점은 팀 회고는 팀 발전에 꼭 필요한 과정이라는 점이다. 평소 회고라는 과정이 꼭 필요하다는 것은 인지하고 있었지만 실행에 옮기는 게 어찌나 귀찮은지.. 블로그가 아니었다면 개인 회고도 제대로 할 수 있었을지 의문이다. 어쨌든 다같이 한 주를 돌아보고 정리할 수 있었던 이 시간이 너무 만족스러웠다. 이 좋은 것을 왜 한번도 안했을까 하는 아쉬움이 든다.
번외
이번 주 마지막 날에는 19명의 교육생들 모두가 각자 개인 프로젝트를 준비해서 발표하는 시간을 가졌다. 여기서 가장 인기가 많은(?) 프로젝트 4개가 실제 협업 프로젝트로 이어지게 되는데... 내가 준비해 간 프로젝트 주제는 '반려견 미팅'이다. 참고로 강아지를 키운 적이 없는 나는 강아지 감수성이 0에 수렴하기 때문에 도박과도 같은 주제였지만 그럼에도 불구하고 마음 한켠에는 몇몇 견주들의 니즈가 있을 거라 생각했다.
허나 뒷풀이 장소에서 백엔드 팀원 한 분께서 나에게 말하길
"사람 만나기도 힘든데 반려견 미팅이라뇨. 저는 함께 서비스를 할 수 없을 것 같습니다.ㅎㅎ"
"그래.. 사람이 먼저다..ㅎ"
유데미 바로가기 : https://bit.ly/3SFlXDy
유데미 STARTERS 취업 부트캠프 공식 블로그 보러가기 : https://blog.naver.com/udemy-wjtb
본 후기는 유데미-웅진씽크빅 취업 부트캠프 2기 - 프론트엔드&백엔드 과정 학습 일지 리뷰로 작성되었습니다.
