시뻘건 개발 도전기

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

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 색상을 설정하기도 했다😊 취업을 했다면 자신의 스타일을 잊자. 내가 소속해 있는 조직에 룰이 있을텐데 그 룰을 파괴하는 흉악범(?)이 되지 말자🧛‍♂️ 팀 룰이 아무리 맘에들지 않거나 옳지 않아도, 따르지 않고 자신의 스타일대로 코딩하면 그것이 흉악범이지 무엇이겠는가!!!👹 나의 경우에는 서비스 별로 코드 스타일이 달라서 각 서비스 소스에 따라서 알맞게 코딩한다. 이것이 참 사소하면서도 나를 힘들게 한다. 한 번에 여러 서비스를 개발하다 보면 분명 스위칭을 하게 되는데.. 그것이 더디거나 꼬여버리면 전혀 다른 특성을 띄는..

좋은 주석은 뭐고 나쁜 주석의 차이는 뭔지 곰곰히 생각해보자.. 내 생각은 좋은 주석은 없다. 주석이 없는 주석이 가장 좋은 주석이다. 물론 코드가 개발자 의도를 100% 표현 했다는 가정 하에!☝️ 나의 경우는 내가 짠 코드의 일부분을 혹시나 다른 개발자가 못알아 듣거나 이해를 못할까 걱정이 되어 주석을 사용하곤 한다. 즉 내가 나를 못믿는데 누군가 나를 어떻게 믿을까😥😥😥 대부분의 주석은 쓸때 없는 주석, 주절거리는 주석 등으로 이루어 지지만 난 가장 필요한 주석은 히스토리 주석과 TODO주석이라 생각한다. ☝️소스코드 관리 시스템이 있다 한들, 특정 부분이 수정된 사유와 날짜 등을 파악하려면 시간을 들여야한다. ✌ TODO주석이 있다는 말은 일을 다 못끝냈다는 이야기. 그러나 그 누가 하루만에 개발..

함수는 "한 가지의 일만 해야하며 무슨 일을 하는지 딱 봐도 알 수 있을 정도의 네이밍이 필요하다."라는 것 정도는 알고 있는 사실이다☝️ 그런데 최소한의 인수와 break, continue를 사용하면 좋지 않다는 것이 저자 의견. break, continue는 반복문과 제어문의 쌍을 스무스하고 부드럽게 해주는 장치 역할을 한다고 생각한다. 이 녀석을 사용해야할 때에 사용하지 않는 방법이 있는가? 고민해볼 가치는 있어보인다. 인수를 두지 않고 클래스 혹은 전역 변수를 활용하는 것은 불필요한 자원을 사용하는 것이고 위험부담이 크다고 생각 되기에 공감하지는 않지만, 인수의 수에따른 단위 테스트의 어려움은 어느정도 공감 한다.🤔 처음부터 코드를 잘 짜는 사람은 없다. 코드를 짜기 전에 일단 문단으로 적어 보고..