B_log

제목에서 무슨 내용인지 유추하기 가장 힘들었던 챕터였어요. 개발을 하며 때로는 패키지를 구매하고, 또 오픈 소스를 이용하는 경우가 많아요. 사내 다른 팀이 제공하는 컴포넌트를 사용하기도 해요. 이 챕터는 소프트웨어 경계를 깔끔하게 처리하는 기법과 기교를 살펴봐요. 1. 외부 코드 사용하기 패키지나 프레임워크 제공자는 적용성을 최대한 넓히려 애써요. 더 많은 환경에서 돌아가야 더 많은 고객이 구매하기 때문이에요. 반면에 사용자는 자신의 요구에 집중하는 인터페이스를 바라요. 이 차이 때문에 문제가 생길 소지가 많아요. 2. 경계 살피고 익히기 외부에서 가져온 패키지를 사용하고 싶다면 어디서 어떻게 시작해야 좋을까요? 곧바로 우리 쪽 코드를 작성해 외부 코드를 호출하는 대신 먼저 간단한 테스트 케이스를 작성해..

🌌 GitHub API 활용하기 GitHub User 받아오기 GitHub 사용자를 받아오기 위해 GitHub API 활용하려고 해요. Entity를 구현하기 위해서는 데이터가 어떤 형태로 넘어오는지 확인해야 하기 때문에 공식문서를 확인해요. 공식 문서: https://docs.github.com/en/rest/reference/search#search-users 공식 문서의 일부를 가져올게요. 우선 GitHub API이므로 base URL은 "https://api.github.com" 일거에요. 여기에 endpoint로 /search/users가 붙겠네요. 즉, 기본 URL 형태는 "https://api.github.com/search/users"가 돼요. 여기에서 중요한 것이 Parameter에요. ..

로그를 재정렬하는 문제예요. 현업 프로젝트 코드에서도 로그는 거의 모든 부분에서 수집하기 때문에 그걸 처리하는 센스를 보는 문제라고 할 수 있어요. 난이도가 쉬운 문제인데 책에서 주어진 정보가 매우 부족하고 조건이 부실해서 책을 기준으로 문제를 풀었더니 예외처리에 시간이 오래 걸렸어요. 에서 제공하는 문제 정보는 항상 조건에 대한 정보가 부실하다고 느껴요. 반례의 상황 등에서요. 오히려 풀이를 보면서 "이렇게 풀이하는 걸 보면 문제 조건이 이렇게 제한될 수밖에 없구나"라고 판단했어요. 에 나오는 풀이 상으로는 숫자 로그는 숫자만 나오고, 문자 로그는 문자만 나와요. 혼용될 수 없지만 조건에 없었어요(그래도 덕분에 혼용되는 조건이라는 발전된 문제를 생각해볼 수 있었고 아래 고민 섹션에 코드를 올렸어요). ..

1. 오류 코드보다 예외를 사용하라 얼마 전까지만 해도 예외를 지원하지 않는 프로그래밍 언어가 많았어요. 오류 플래그를 설정하거나 호출자에게 오류 코드를 반환하는 방법이 전부였어요. 하지만 이렇게 코드를 작성하면 호출자 코드가 복잡해지고 코드 블록 depth가 깊어져요. 그래서 try / catch 등의 예외 처리를 하는 것이 더 깔끔해요. 오류 발생시 처리하는 코드와 예외 처리가 분리되기 때문이에요. 나의 생각: 사실 Swift는 Optional의 존재로 오류 처리가 한결 더 수월한 것 같아요. 현업 코드에서 오히려 try / catch를 거의 못 봤던 것 같아요. 오류가 발생하기 가장 쉬운 부분 중 하나가 네트워킹일 텐데 그 부분마저도 Optional 처리가 되기 때문에 오류 처리 대응이 쉽게 되었던..

1. 자료 추상화 수많은 개발자가 아무 생각 없이 변수를 get / set 하는 메서드를 생성해 외부로 노출해요. 하지만 경우에 따라서 객체가 포함하는 자료를 표현할 때 더 좋은 방법이 있을 수 있어요. 자료를 표현할 가장 좋은 방법을 심각하게 고민해야 해요. 아무 생각 없이 조회/설정 함수를 추가하는 것이 가장 나빠요. 2. 자료/객체 비대칭 객체 지향 코드에서 어려운 변경은 절차적인 코드에서 쉬우며, 절차적인 코드에서 어려운 변경은 객체 지향 코드에서 쉬워요. 복잡한 시스템을 짜다 보면 새로운 함수가 아니라 새로운 자료 타입이 필요한 경우가 생기는 데, 이때는 클래스와 객체 지향 기법이 가장 적합해요. 반면, 새로운 자료 타입이 아니라 새로운 함수가 필요한 경우도 생길 경우에는 절차적인 코드와 자료구..

5장은 팀에서 정할 컨벤션을 만들 때 유용한 주제라고 생각해요. 또한 현재 저는 개인 작업을 하고 있는데, 혼자 하는 작업이더라도 형식을 정해놓는 것이 좋은 것 같아요. 저자가 말하는 원활한 소통을 장려하는 코드 형식에 대해서 이야기 해볼게요. 1. 적절한 행 길이를 유지하라 세로 길이부터 살펴보면, 자바에서 파일 크기는 클래스 크기와 밀접해요. 클래스 크기는 이후 다른 챕터에서 다루고 여기서는 파일 크기만 논해요. JUnit 등의 프로젝트 7개를 봤을 때 평균 파일 크기는 65줄이에요. JUnit에서 가장 긴 파일은 400줄 정도예요. 대다수가 200줄 미만이죠. 반면에 Tomcat과 Ant는 절반 이상이 200줄을 넘고 수천 줄을 넘는 경우도 있어요. 일반적으로 한 파일에서 줄 수가 적은 것이 많은 ..

이 글을 보러 들어오신 분들은 문제를 알고 오신 분들이기 때문에 팰린드롬에 대해 추가적인 설명을 하지는 않을게요! 주어진 문자열이 팰린드롬인지 확인하는 문제예요. 다만 주어진 문자열에서 대소문자는 구별하지 않고, 영문자와 숫자만 대상으로 해요. 즉, 특수문자나 공백 문자열 등은 대상에서 제외되겠죠? 📝 풀이 어떤 알고리즘을 사용하든 전처리 작업이 필요할 거예요. 책에서는 이것을 for문을 통해서 처리하거나 정규표현식을 통해 처리하는데 저는 조금 다르게 전 처리했어요. 우선 책에서 한 전처리 방법이에요. # 반복문 사용 strs = [] for char in s: if char.isalnum(): strs.append(char.lower()) # 정규표현식 사용 s = re.sub('[^a-z0-9]', ..

🎯 목표 - 알고리즘 문제풀이 실력 되찾기 오랜만에 알고리즘을 다시 시작하면서, 난이도가 쉬운 문제들을 풀려고해요. 우선 파이썬 알고리즘 인터뷰에 나오는 문제 순서대로 Leet Code의 문제들을 풀면서 감을 찾을 계획이에요. 알고리즘 풀이에 관한 글들로 이 블로그를 시작했어요. 처음에는 단순히 블로그에 내 풀이들을 모아놓는다는 개념이었는데, 이 블로그의 방문자 대다수가 알고리즘 풀이 정답을 보기 위해 온다는 것을 알게 되었어요. 점차 읽는 사람들을 위한 글을 쓰는게 중요하다고 생각되었고, 단순히 문제풀이 정답을 써놓는 것이 아니라 문제풀이를 하며 든 생각이나 고민, 그리고 새로 배우게된 점을 쓰게 되었어요. 또한 문제가 어떻게 변형될 수 있다는 지점이 생기면 그 부분도 더 적극적으로 기록해보려고 해요...