B_log

☀️ 기상 모니터링 애플리케이션 만들기 현재 기상 조건(온도, 습도, 기압)을 추적해서 아래 결과를 표시하는 앱을 만들어 보려고 해요 :] 1. 현재 조건 2. 기상 통계 3. 간단한 기상 예보 기상 모니터링이므로 당연히 이 항목들은 모두 실시간으로 갱신돼야 해요. 여기에 더해 추가 요구 사항이 있어요.. 다른 개발자가 직접 날씨 디스플레이를 만들어서 바로 넣을 수 있도록 확장 가능해야 합니다. 나중에 새로운 디스플레이를 손쉽게 추가할 수 있도록 해주세요. 🤖 시스템 파악하기 이 시스템은 총 3가지로 구성되어 있어요. 1. 기상 스테이션 ➡️ 실제 기상 정보를 수집하는 물리 장비(데이터를 제공하는 부분) 2. 기상 스테이션으로부터 오는 정보를 추적하는 객체 ➡️ WeatherData 객체 3. (제공되는..

🔥 헤드퍼스트 디자인패턴 시작하기 "헤드퍼스트 디자인패턴"은 Java를 기반으로 쓰인 책이지만, 여기서는 Swift로 구현하며 내용을 정리해 볼게요! 항상 그렇지만 이 글은 개인적인 정리의 목적으로 작성하는 것이기 때문에 책을 직접 읽어보기를 추천드려요 :] 🐥 오리 시뮬레이션 게임 만들기 SimUDuck이라는 오리 게임을 만들어볼게요 :] 방법 1. 일반적인 상속 구조 사용하기 일반적인 표준 객체지향 기법을 사용하여 Duck이라는 Super class를 만들고, 상속을 통해 여러 오리를 만들어요. (private, final 등 세세한 설정 등은 생략할게요) 각 오리들은 부모 클래스(Duck)의 메서드를 override 하여 사용해요. 🚨 추가 요구 사항 발생 ➡️ 오리는 날 수 있어야 합니다 여기서 ..

후기 개발 문서를 읽으며 블로깅을 한 개 처음이라 어설픈 게 많았어요. 책의 내용을 요약해서 올리는 글은 많다고 생각이 들고, 그것만으로 부족하다고 생각이 들어서 책을 읽으며 들었던 제 생각을 첨언하기 시작했어요. 블로그는 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가 되지 않는 문화였기 때문에 정말 많은 것을 배웠다고 생각해요. 코드를 모두 구현하고 그 코드에서 일부 기능을 가져와 테스트를 만드는 것이 아니라 테스트 코드에서 기능을 먼저 정의하고 문제를 발생시킨 뒤, 정상적으로 통과하는 테스트를 만들어요. 그 로직을 프로젝트 코드에 담아 작성함으로써 팀원들이 믿고 사용할 수 있는 기능이란 확신을 줄 수 있었어요. 아직 많이 부족하기 때문에 더 어려웠겠지만 테스트를 하는 단위를 정의하는 것, 그리고 테스트..

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