B_log

문제 풀이 과정의 고민 출력할 문서의 위치를 어떻게 이동시킬지 고민했어요. 방법은 다양할 수 있는데, 출력 위치가 0번 인덱스로 고정되어 있기 때문에 원형 큐처럼 인덱스를 따라 돌게 만들기로 했어요. enumerate를 통해 인덱스와 중요도를 튜플로 묶으면 생각하기 편하긴 하지만 자료의 수가 늘어날수록 성능에 영향을 미치게 되어 정수 하나의 인덱스로 관리하는 게 더 낫다고 판단했어요. 파이썬에서 제공하는 기본 리스트 자료구조의 경우 내부적으로 더블 링크드 리스트이지만 사용 시 스택처럼 작동하기 때문에 pop(0)을 사용하는 것을 피하려고 했어요. 인덱스 1번부터 요소가 존재한다면 전부 시프팅이 일어나기 때문이에요. 그래서 대안으로 생각한 것은 주어진 자료구조를 reverse 해 pop(0)가 아닌 pop..

GitHub 주소 https://github.com/helloworldjay/daumcafesearch 프로젝트의 시작 MVC와 스토리보드만 학습하다가 처음 현업에서 새로운 패턴과 UI도구를 만나고 굉장히 큰 어려움을 겪었어요. MVC만 깊이 이해해도 빠르게 다른 패턴에 적응할 수 있을 줄 알았지만 생각보다 쉽지 않았고, 이것의 원인을 구현력의 부족이라고 판단했어요. 마찬가지로 UI 역시 상대적으로 직관적인 스토리보드로만 작업하다가 Texture라는 Flex Box 기반의 개념으로 UI를 구현하다 보니 그 어려움이 더 크게 느껴졌어요. 갑자기 코드로 작업한다는 것만 해도 접근하기 어려웠는데 라이브러리까지 익혀야 했었으니까요. 현재로서는 VIP(a.k.a. Clean Swift) 패턴과 Texture로 작..

후기 개발 문서를 읽으며 블로깅을 한 개 처음이라 어설픈 게 많았어요. 책의 내용을 요약해서 올리는 글은 많다고 생각이 들고, 그것만으로 부족하다고 생각이 들어서 책을 읽으며 들었던 제 생각을 첨언하기 시작했어요. 블로그는 12장에서 멈췄는데, 13장부터는 JUnit처럼 특정 언어(Java)에 관련된 이야기가 많아 다루지 않았어요. 물론 Java도 틈틈이 볼 예정이라 그때 다시 글을 추가하지 않을까 생각해요. 클린 코드라는 책에 대해 처음 들었던 것이 몇 개월 전인데, 그 때 가장 많이 들었던 후기가 "당연한 이야기를 써놓은 책"이라는 것이었어요. 저 역시도 가볍게 읽을 생각으로 시작했는데, 생각보다 당연하지 않은 이야기도 많았던 것 같아요. 현업의 경험이 없었다면 무비판적으로 책을 이해하려고 했을 것 ..

켄트 백은 단순한 설계 규칙 네 가지를 제시했어요. 이 규칙에 따라 설계하게 되면 코드 구조와 설계를 파악하기 쉬워지고, SRP나 DIP와 같은 원칙을 적용하기 쉬워진다고 생각했어요. 이번 챕터는 이 규칙에 대해 이야기해보려고 해요. 단순한 설계 규칙 1. 모든 테스트를 실행하라 무엇보다 먼저, 설계는 의도한 대로 돌아가는 시스템을 내놓아야 해요. 문서로는 시스템을 완벽하게 설계했지만, 시스템이 의도대로 돌아가는지 검증할 간단한 방법이 없다면 그 가치를 인정받기 힘들어요. 테스트가 불가능한 시스템은 검증도 불가능해요. 검증이 불가능한 시스템을 출시하는 것은 위험한 일이에요. 테스트가 가능한 시스템을 만들려고 애쓰면 설계 품질이 더불어 높아져요. 크기가 작고 목적 하나만 수행하는 클래스가 나와요. SRP를..

이 챕터에서는 높은 추상화 수준, 즉, 시스템 수준에서도 깨끗함을 유지하는 방법을 살펴봐요. 시스템 제작과 시스템 사용을 분리하라 제작(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..