B_log

이 챕터에서는 높은 추상화 수준, 즉, 시스템 수준에서도 깨끗함을 유지하는 방법을 살펴봐요. 시스템 제작과 시스템 사용을 분리하라 제작(construction)과 사용(use)은 매우 다른 개념이에요. 소프트웨어 시스템은 준비 과정과 (준비 과정 이후 이어지는) 런타임 로직을 분리해야 해요. 시작 단계는 모든 앱이 풀어야 할 관심사예요. 대다수 앱은 준비 과정 코드를 주먹구구식으로 구현할 뿐만 아니라 런타임 로직과 마구 뒤섞어요. // 책 예시를 그대로 Swift로 표현 func getService() -> Service { if service == nil { service = MyServiceImpl(...) } return service } // Swift 식 코드 func service() -> S..

이번 챕터는 자바 관례에 대한 글이 될 것 같아요. Java로 개발을 할 때에는 아래 규칙들을 지키려고 노력을 하고, Swift로 iOS 개발을 할 때에는 보다 깔끔한 코드를 위해 참고하는 정도로 이해할 생각이에요. 1. 클래스 체계 가장 먼저 변수 목록이 나와요. public static 변수가 먼저 나오고, 그 후에 private static변수가 나와요. 그 후에 private 인스턴스 변수가 나와요. 순서로 보면 public ➡️ private, static ➡️ instance 변수 순서로 나와요. 변수 목록 다음에는 공개 함수가 나와요. 비공개 함수는 자신을 호출하는 공개 함수 직후에 넣어요. 즉, 추상화 단계가 순차적으로 내려가요. class SomeClass { static let some..

나의 생각 현업에서 TDD를 경험하지 전까지는 TDD가 단순히 필요한 기능을 확인하는 테스트를 작성하는 것이라고 생각했어요. 하지만 운이 좋게 팀에 TDD에 관심이 많은 분이 계셨었고, 팀 전체적으로 TDD를 했으며 테스트 코드를 작성하지 않으면 PR Approve가 되지 않는 문화였기 때문에 정말 많은 것을 배웠다고 생각해요. 코드를 모두 구현하고 그 코드에서 일부 기능을 가져와 테스트를 만드는 것이 아니라 테스트 코드에서 기능을 먼저 정의하고 문제를 발생시킨 뒤, 정상적으로 통과하는 테스트를 만들어요. 그 로직을 프로젝트 코드에 담아 작성함으로써 팀원들이 믿고 사용할 수 있는 기능이란 확신을 줄 수 있었어요. 아직 많이 부족하기 때문에 더 어려웠겠지만 테스트를 하는 단위를 정의하는 것, 그리고 테스트..

책에 나온 문제에 추가적인 조건을 더해야 문제를 풀 수 있어요. case-insensitive란 대소문자를 구별하지 않는다는 뜻이에요. 그리고 결과는 항상 소문자로 반환해요. 📝 풀이 책의 풀이와 달라요. 제가 생각하기에 더 빠른 속도의 알고리즘이에요(O(N^2) -> O(N)). 문제의 조건에 위배되는 입력을 할 경우 무한 루프에 빠질 수 있어요. 문제의 조건에 맞는 입력을 했다는 가정하에 풀이했어요. def my_solution(paragraph: str, banned: [str]) -> str: from collections import Counter import re banned_dict = dict(Counter(banned)) paragraph_dict = Counter([word for wo..

제목에서 무슨 내용인지 유추하기 가장 힘들었던 챕터였어요. 개발을 하며 때로는 패키지를 구매하고, 또 오픈 소스를 이용하는 경우가 많아요. 사내 다른 팀이 제공하는 컴포넌트를 사용하기도 해요. 이 챕터는 소프트웨어 경계를 깔끔하게 처리하는 기법과 기교를 살펴봐요. 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 처리가 되기 때문에 오류 처리 대응이 쉽게 되었던..