모르면 배우면 된다

얼마 전에 자바스크립트 20년차 개발자처럼 주석 쓰는 법! 이라는 영상을 봤다. https://www.youtube.com/watch?v=ORmnc-hLrYs 핵심은 /** */를 활용해서 @return, @param 등을 다는 거였다. 함수 위에 이런 주석을 달아두면, 실제 함수를 사용하는 곳에서 쉽게 주석 내용을 확인할 수 있다는 게 엄청난 강점이었다. 특히 공통으로 사용하는 함수 같은 건 필수일 듯. 요즘 퇴사한 분들의 코드를 매일매일 분석하고 있는데, 코드 정리 + 주석 달기를 하며 파악 중이다. 확실히 파악 속도가 빠르고, 문서화는 덤이다. 나름 재밌음! /** * 업무구분에 따라 번호 다르게 보여주기 * @param {string} param */ const onDvsCdChange = (pa..

팀을 옮기고 다른 사람이 작성한 프론트/백 코드를 빠르게 파악할 필요가 있었다. 내가 택한 방법은 '문서화'였다. 보통 문서화 하면 귀찮은 거 라는 편견(..)이 있는데, 코드를 파악할 때 무척 유용한 방법이었다. 엄청 실력있는 개발자분들은 코드가 바로바로 머릿속에 들어올지 모르지만 나 같이 작고 귀여운 개발자에겐 무리다! 그래서 한땀한땀 정리하고 기록하며 코드를 파악하는 과정이 필요했다. 사내에 화면별 개발 문서가 있다면 저어엉말 좋겠지만, 없는 상황도 왕왕 존재한다. 이에 코드 파악으로 고통을 겪고 계신 주니어 개발자분들을 위해, 내가 진행했던 프로세스를 공유한다. 별건 아니지만! 그냥 작고 귀여운 주니어 개발자지만! 그냥 이렇게 한 사람도 있구나, 하고 참고하시면 좋을 것 같다. 도움이 된다면 기쁠..

타입스크립트 스터디를 한 달 동안 진행했다. 기간 : 2022년 7~8월 한 달 목표 : TypeScript란 무엇인가, 어떻게 사용하는가 가볍게 훑어보기! 진행한 이유 : JD를 살펴보니 요즘 TS를 사용하는 곳이 많아서, 한번 찍어먹어보자 싶었음. 공부기록 : https://github.com/justdoitho1/studyingTypeScriptTogether/tree/main/okdol

한동안 트위터에서 핫했던 구글 엔지니어는 이렇게 일한다. 마침 트친님이 이 책을 같이 읽지 않겠냐 스터디를 제안하여 매주 토요일마다 함께 감상을 나누었다. 매주 2장씩 읽었고, 약 한 달 반이 지난 현재 12장 단위테스트까지 읽었다. 구글 엔지니어는 이렇게 일한다 [세 줄 평가] - 구글의 개발 문화를 살펴보며 '다른 기업은 이렇게도 하는구나'를 느낄 수 있다. 그러나 구글이라고 다 정답은 아니다. 각 조직 특성에 맞는 문화가 있을 것. 또 돈도 많고 사람도 많은 '구글'이라서 적용할 수 있는 문화도 있다. - 시니어급이 보면 더 좋을 거 같은 책. 팀 관리자가 참고할 만한 내용이 많고, 또 직접 본인이 변화를 빠르게 추진할 수 있는 위치니까. (주니어도 제안할 수 있는 조직이 있긴 하겠지만 시니어만큼 ..

SI에서는 왜 유지보수와 개발 인력을 따로 둘까? 개발 속도가 중요해서 그런 걸까? 자기가 유지보수할 코드라고 생각하면 더 신중하게 코드를 짜지 않을까? 유지보수를 생각하면서 코드를 짜는 건 중요한 거 같다. 요즘 매일매일 다른 사람의 코드를 보고 결함을 수정하는데 공부 많이 된다 예전에는 힘들었는데...새로운 화면 보면 겁부터 먹었다. 이제는 뭐.. 하면 되지라는 생각이 듦. 새로운 화면인 만큼 소스파악에 시간은 걸리지만.. 그거는 어쩔 수 없음. 아니 그냥 대충 개발새발 할 수는 없잖햐 1년 안에 두 개의 팀을 겪었다. 뭐 현재 팀으로 와서 200~400줄 되는 sql 분석하고 몸통 박치기 하니까 뭐든 할 수 있을 것 같다는 생각이 든다. 모르면 배우면 된다. 시간이 걸릴 뿐... 여러 환경을 겪어보..

1. 개발도서를 읽는 것은 어떤 의미를 가지는가... 개발 독서를 한다는 것. 100km 가야할 길을 10km로 줄여준다. 아! 책에서 본 게 이거구나 아! 책에서 이렇게 하라고 했지 이런 기억 남는 게 제일 큰 소득인듯 부딪히며 깨지는 것도 좋은데 책으로 미리 명문화된 경고문을 머릿속에 박아두는 것도 좋네.. 2. 개발자는 만난 오류만큼 성장한다 특히 많이 배우는 오류 : 에러메시지가 안 나는 오류. 하나하나 다 뜯어봐야 한다. SQL 하면서 조져진 나. 3.문제가 생기는 것을 두려워하지 말기. 어차피 문제는 언젠가 어디에선가 발생한다. 문제가 생기면 해결하면 되지! 라고 생각하기 그게 정신건강에 좋다. 문제가 생기지 않게 최대한 노력하되 문제가 생기면 차분히 해결하기 4. MSA의 필요성 이전까지는 ..

1. 코드리뷰가 필요하다 개발을 하면 할수록 코드리뷰가 필요하다는 생각이 든다. 코드가 제대로 된 결과를 내보이고 있는지 조직적인 검증이 필요하다 안 그럼 또 오류나고 또 고치고 또 오류나고 또 고치고 코드는 넝마가 되고 기능적으로 문제가 없는지, 유지보수에 알맞는 코드인지 여러 사람의 검증이 필요해 보인다. 내가 짠 코드를 정말... 정말 검증 없이 운영에 반영해도 되겠어 ? 나 1년차 주니어인데. 글고 코드리뷰가 없으니까 코드의 발전이 더디다. 팀을 옮기고 나서, 그나마 동기들끼리 했던 리뷰도 사라짐. ㅎㅎ 다른 사람 코드를 매ㅐㅐㅐ일매일매일매일 읽기는 하는데, 아무래도 내 코드에 대한 직접적인 리뷰를 받을 수가 없는 상황이다. 선임은 너무바쁘고 ,,, 시간 제한은 빡세게 두면서, 코드 리뷰는 하지도..

실용주의 프로그래머를 완독 했습니다! 완독 !== 완벽 이해 지만, 사수 없는 SI에서 개발 중인 저에게 '어떻게 개발해야 하는가'를 생각하게 해주는 책이었습니다. 최근 관성적으로 개발하고 계신다면, 사수가 없는 곳에서 일하고 있다면, 이 책을 추천합니다. 핵심은 이겁니다. 실용주의 프로그래머들은 책임을 회피하지 않는다. 1차 후기는 여기서 ! 참고로 저는 구판을 읽어서, 신판과 구성이 조금 다릅니다. https://dev-dev-dev-dev.tistory.com/33 [실용주의 프로그래머] 개발 은하수를 여행하는 히치하이커를 위한 안내서 🎖읽게 된 이유 최근 이런 고민이 있었습니다. '구현에만 초점을 맞추고 일하는 것 같다. 더 나은 코드에 대한 고민이 부족하다. 개발자로서 이게 맞나?' 그런 차에,..

요즘 실용주의 프로그래머나 구글 엔지니어는 이렇게 일한다 등 개발 관련 책을 읽다 보면 '테스트'가 엄청나게 중요하다고 강조한다. 책을 읽다 보면 오 내가 꽤 테스트를 잘 해왔구나 싶으면서도, 부족한 면이 많다는 생각이 들었다. 이에 지금까지 내가 해왔던 테스트 방법을 공유하고, 내게 필요한 개선점을 기록하기 위해 이 글을 남긴다. 일단 테스트 주도 개발 (TDD)나 JUnit, SpringBootTest 이런 내용은 아니다. 기능을 만들며, 일어날 수 있는 다양한 경우의 수를 고려하는 테스트 방식에 대해 이야기하고자 한다. 현재 프로젝트에서 front와 back을 모두 하고 있다. 화면 하나를 맡아서 개발하는 경우가 많았기 때문에, 다양한 경우의 수를 고려해야 했다. 화면을 전반적으로 테스트할 때는 아..

온보딩 프로세스 문서를 만들기로 한 이유 프로젝트 투입 후 일주일 동안 뭘 해야할지 몰랐다. 가지고 온 Java 책만 주구장창 읽었다. 여긴 어디 나는 누구... 계정이 생기고 내 컴퓨터가 설치됐지만 뭘 봐야할지 잘 모르겠어서 혼란스러웠다. 프로젝트 투입 직후... 아무도 내게 관심이 없어서...며칠 동안 좀 외로웠다. 마음 속으로 '날 챙겨주지 않는군.. 책이나 봐야겠다 또르르..' 하고 있었음. (당시 날 안쓰럽게 본 다른 팀 선임 한 분이 챙겨주긴 했지만 전반적으로 분위기가 차가웠다. 이후에 차례로 소개받은 동기들과 프리랜서분들이 잘 챙겨줘서 빠르게 적응할 수 있었다.) 그래서 신규 유지보수 인력이 투입됐을 때 나와 같은 멘붕을 겪지 않도록 온보딩 문서를 만들어야겠다고 생각했다. 이미 컨플루언스에 ..