일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | |
7 | 8 | 9 | 10 | 11 | 12 | 13 |
14 | 15 | 16 | 17 | 18 | 19 | 20 |
21 | 22 | 23 | 24 | 25 | 26 | 27 |
28 | 29 | 30 | 31 |
- 회고
- 초보iOS개발자
- 스유
- 알고리즘
- 12회차
- 글또9기
- 글또
- JavaScript
- SwiftUI
- 개발회고
- Swift알고리즘
- 왕초보
- 개인앱
- 수정중
- 유데미
- github
- 클린코드
- git
- 비동기
- 리액트입문
- Postman
- iOS개발
- 글또10기
- ViewBuilder
- Swift
- 글또x코드트리
- 글쓰기
- RxSwift
- UIKit
- ios
- Today
- Total
목록2024/01 (4)
playground_avec coding

팀프로젝트 파일 내 포함된 코드나 다른 사람들의 코드를 보면 꽤 테스트 코드를 설정해준 프로젝트들이 많았다. 예전부터 TDD(Test Driven Development - 테스트 주도 개발) 라고 자주 들어봤는데, 어떻게 Xcode 에서 적용해볼지 막막했다. 마침 클린코드 책을 읽으면서 단위테스트라는 챕터를 읽었다. 테스트는 왜 하는지에 대한 의문을 가졌다. 코드의 유지보수성, 재사용성, 유연성이 프로덕트를 보존하고 강화할 수 있어서 라는데 사실 개발을 공부하는 초보 입장에서는 와닿지 않는다. 테스트 코드를 작성한다의 의미 무엇을 구현할 지 알고 있다. 어떤 기능인지 명확하게 알고 있다. 요구 사항을 파악하고 있다. ( 22년도 12월쯤 야곰의 원티드 프리온보딩에서 TDD 특강에 대해 들었던 적이 있었다..
보호되어 있는 글입니다.
TDD( Test Driven Development) 과거 인식 클래스, 메서드를 공들여 구현하고는 → 엉망진창 테스트 코드로 돌아가기만 하면 아무 코드나 급조해서 붙여 넣음. → 일회성코드에 불과 TDD 법칙 세가지 첫째, 실패하는 단위테스트 작성할 때까지 실제 코드를 작성하지 않는다. 둘째, 컴파일은 실패하지 않으면서, 실행이 실패하는 정도로만 단위테스트 작성 셋째, 현재 실패하는 테스트 통과할 정도로만 실제 코드 작성 ⛔️ 그러나, 방대한 테스트 코드는 심각한 관리 문제를 유발하기도 함. 깨끗한 코드 유지하기 밥 아저씨 사례 그냥 테스트만 구현하고 돌아가면 지저분한 코드여도 상관 없다! ⛔️ 막 쓰는 테스트 코드에 대한 위험성 코드가 지저분해질수록 변경도 어렵다! 테스트 코드 복잡할수록 실제 코드 ..

글또에서 한 달 가량 활동하면서 느낀 짧은 개인 회고 글또에 들어간 지 한 달 좀 더 지난 것 같다. 개발과 커리어, 고민, 성장, 좋은 책 등 다양한 인사이트(시각)들을 얻을 기회가 많아졌다. 여러 툴의 정보와 다른 기술 직군들의 고민을 같이 나눠볼 수 있고, 경험이 있는 경력자분들의 조언이나 인생선배님들의 조언 또한 접할 수 있어서 좋았다. 다른 기술직군 개발자분들의 글을 큐레이션과 채널 탐색을 통해 쉽게 접근할 수 있게 된 것도 좋다. 뿐만 아니라 다양한 채널 합류를 하면서 연대감도 느꼈다. 최근 들어간 데일리 크리에이또와 모닝또, 자료 공유 등의 채널은 실행력과 긍정적인 동기부여도 서로 나눌 수 있다는 점이 가장 좋다. 특히 모각글(zoom에서 모여서 각잡고 글쓰기)은 글을 모여서 쓰거나 의식하고..