튼튼발자 개발 성장기🏋️

동기 지난번에 개발자라면 누구나 꿈꾸지만 높은 연봉만큼 일이 너무 많다는 소문이 자자한 기업 xx에서 오퍼가 왔다. 그 곳으로 이직할 생각은 없었으나, 해당 기업 면접을 한 번도 본적이 없었기 때문에 그 기업은 어떤 것에 관심이 있고 어떤 인재를 추구하는지 궁금해서 면접을 보았다. 약 1시간 30분동안 대용량 트래픽과 그에 따른 WAS 혹은 DB서버, 앱서버 관리 및 장애대응에 대한 이야기로 가득했다. 개발 경력 4년동안 운영업무와 DB관리를 해본적이 없는 나는 굉장히 창피할정도로 무식(?)했다. 해당 포지션이 데브옵스가 아닌데도 개발적인 내용보다 운영 내용이 많았던 것 같다. 면접이 끝나고 운영 지식을 쌓아볼까 해서 책을 구매하여 매일 한 챕터씩 읽기로 했다. 본 도서는 일본기업 "하테나"에서 근무했던..

요즘 큰 프로젝트가 한참 개발 중이라서 책 볼 틈이 읎다ㅠㅠ (핑계일 수도 있다..ㅋㅋ) 그래도 시간 짬 내서 보려고 노력중👍 이제 정말 내가 읽기에는 어려운 챕터까지 왔다. 이번 챕터는 5번은 읽은 것 같다..ㅠㅠ 클래스는 사실 미로같은 놈이다. 다 아는 것 같으면서도 무지함을 깨닫고 이쁘게 작성한 듯 하면서도 개떡같이 작성하게 바로 클래스.. 우린 담당 서비스를 개발 할 때도 있지만, 추가개발 할 때도 있다. 추가 개발은 변경이 아닌, 확장이다. 클래스는 확장성을 고려하여 범용적이고 수정하기 간편하게 작성되야한다는 것은 상식. 그러나 응집도와 관련해서 생각을 하지 못했다. 너무 어려운 챕터다.. 두 번 보자. 세 번 보자. 이해 될 때까지 보자...😡

존경하는 어느 팀장님께서 추천해주신 또 다른 책. 경력을 쌓는 방식과 관점을 만들어주고 시야를 넓혀준다. 그러나 모두 공감대를 형성하지 않았고 때때로 비판하고 "왜?"라고 되묻는다. 때론 겸허히 수긍한다. 제목을 처음 보았을 때 팀장님께서 갑자기 왠 소설책을 추천해주시길래 당황했던 기억이 난다..ㅎㅎ 도입부부터 인도의 IT 이야기로 시작하기에 정말 소설을 읽는 줄 알았다..하핳 이 책 저자가 말하고 싶은 것은 "진정 개발자가 되고 싶으면 노력해라."인데 어떻게 노력해야하는지에 대해서 서술하였다. 연구하고, 투자해라. 그리고 실행에 옮기고 이제 마음껏 자기PR을통해 자신을 마케팅하라. 사실 이 모든게 대학생 때 끝내는 것이아니라 평생 연구하고 투자해야한다고 생각한다. 기술은 나날이 발전하고 새로운 기술이 ..

TDD는 상당히 어려운 부분인 것 같다. 이전에도 TDD에 대해서 여러가지 알아보았는데 너무 깊게 들어갔는지 이해도 할 수 없었고 어떻게 해야할지고 모르겠어서 포기하고 말았다👊 짧게나마 다시 TDD 관련 글을 보았다. 쉽게 설명되어 잘 읽혔지만 새발의 피인 것을 우째😥 TDD 주제 하나로 책 한 권을 낼 수 있는데 여긴 고작 한 챕터로 다루고 있다. 언젠간 꼭 TDD를 아주 잘 설명한 책이 있다면 읽어보고 말테다! 가장 핵심은 테스트 코드 또한 깨끗하고 보기 좋아야 본 코드가 수정이되거나 새 기능이 추가되어도 테스트 코드도 쉽게 작성할 수 있다. 즉 가독성이 최우선이라 할 수 있다. FIRST 조건을 잘 되새김질 해보며 이해를 도와보자🤟

우리가 무언가를 개발 할 때에 모든 것들을 전부 만들지는 않는다. 외부 패키지를 사용할 수도 있고 잘 짜여진 프레임워크를 쓸 수도 있고 오픈 소스를 사용할 수도 있다. 모두가 하나같은 마음을 가지면 좋겠지만 각기 다른 성격과 특성을 가지고 있고 서로 다른 목적이 뚜렷하고 그 목적에 맞게 설계되어 mix하여 사용할 땐 큰 어려움이 따른다. 이를테면 버전이 호환 안되서 잘 따져 보아야 하고, 캡슐화, 독립성 등을 고려해서 구조를 잡아 가는 것이 핵심. 그 외에도 고민해야할 것들이 많을 것 같다. 난 이 책을 읽고 Map이 얼마나 위험하고 귀찮게 하는 녀석인지 깨달았다. Map을 사용할 땐 캡슐화를 고려해보자!!!☝️ 그 이유는 Map(Collection과 같은) 혹은 Object 등 많은 데이터를 포함할 수..

사실 함수를 만들다보면 return이 필요없는데 해야할 때가 종종있다. 설계를 잘 했다면 그럴 일은 없어보이지만...핳핳 그럴때면 null을 return하는 것이 가장 만만하고 예외처리만 잘 해주면 될 것이라 생각했다. 이것은 나의 잘못된 방식🤛🤛🤛. null을 return하지 않고 좋은 방법이 있었다. null을 리턴 해놓고 그것에 대해 예외처리를 한 들, 나중에 어떤 화살로 돌아올지는 아무도 모른다. null을 왜 반환하면 안되는지 궁금하다면 꼭 책을 읽어보자!!! (뼈저리게 느낄 수 있음 주의ㅋㅋ) 예외를 잘 던지면 코드가 이쁘고 절 읽을 수도 있으며 이해도를 상당히 높일 수 있다. 이 책을 읽고 예외 던지는 '신의 한수'를 알아냈다. 꼭 읽자. 두 번읽자 세 번읽자. 그러나 적용하려면 연습과 더 ..

조금씩 책의 내용이 어려워지고 있다. 한 문장을 무려 10번 읽고 되새김질 해보기도 한다.ㅠㅠ 최근 나는 싱글톤을 사용하여 개발한 적이 있는데 싱글톤 특징을 제대로 살리지 못하는 실수를 하고 말았다...😥 바로 생성자를 자동생성 생성자로 두었던 것... 알고 있으면서도 알아차리지 못했던게 더 괴씸하다!!! 경솔한 나의 생각때문에 큰 오류를 범할 뻔했다. java에서 access level을 둔 이유가 다 있다. 그것을 잘 활용하여 지켜주어야 한다..🙄 잘 생각해보면 protected는 거의 써본적이 없는 것 같고 변수는 private, 메소드는 public을 많이 사용하는데 이런거 하나하나 생각하면서 코드를 작성해야한다는걸 몸소 느끼며 깨달았다. 너무 익숙해지지 말자. 코딩에 당연한건 없다! 난 이 책을..

누구나 자신만의 코딩 스타일이 있는 법🤘 대학생 때는 나만의 스타일로 코딩을 했다. 심지어 툴 마저도 내가 커스터마이징 해서 눈이 덜 필로하게 어두운 색상으로 알아보기 쉬운 syntax 색상을 설정하기도 했다😊 취업을 했다면 자신의 스타일을 잊자. 내가 소속해 있는 조직에 룰이 있을텐데 그 룰을 파괴하는 흉악범(?)이 되지 말자🧛‍♂️ 팀 룰이 아무리 맘에들지 않거나 옳지 않아도, 따르지 않고 자신의 스타일대로 코딩하면 그것이 흉악범이지 무엇이겠는가!!!👹 나의 경우에는 서비스 별로 코드 스타일이 달라서 각 서비스 소스에 따라서 알맞게 코딩한다. 이것이 참 사소하면서도 나를 힘들게 한다. 한 번에 여러 서비스를 개발하다 보면 분명 스위칭을 하게 되는데.. 그것이 더디거나 꼬여버리면 전혀 다른 특성을 띄는..