IT NOTE

Xcode에서는 프로젝트를 생성할 때 기본적으로 debug와 release의 두가지 빌드 환경을 제공해줍니다. 이번 포스팅의 목표는, Rest API url, 외부 서비스의 API Key 등을 빌드 환경에 따라 동적이게 변경하는 방법을 익히는 것입니다. 먼저 프로젝트를 생성합니다. 왼쪽 navigator의 root 파일 > PROJECT > Configurations를 보면 기본적으로 Debug와 Release가 생성되어 있습니다.여기서 Test 등의 추가적인 Configurations을 생성하실 수 있습니다. 상단에 Build Settings > + 클릭 > Add User-Defined Setting를 선택합니다. Add User-Defined Setting을 누르고 예시로 저는 "REST_API_U..

문자열 리스트가 주어졌을 때 이 문자열들을 하나로 이어 붙이는데 걸리는 시간은? String joinWords(String[] words) {String sentence = "";for (String w : words) {sentense += w;}return sentence;}문자열을 이어붙일 때마다 두 개의 문자열을 읽어 들인 뒤 문자를 하나하나 새로운 문자열에 복사해야 한다.처음에는 1개, 두 번째는 2개, 세 번째는 3개, n번째는 n개를 복사해야 한다.따라서 총 수행 시간은 아래와 같이 된다.StringBuilder가 이 문제를 해결해 줄 수 있다. StringBuilder는 가변 크기 배열을 이용하여 필요한 경우에만 문자열을 복사하게 해준다. String joinWords(String[] wo..

이 글은 "실용주의 프로그래머" 도서를 읽고 내용과 느낌을 정리한 글입니다 :) 실용주의 팀- 깨진 창문을 없애라. : 부지런한 개발자라 해도 품질에 무심한 팀에 배치되면, 귀찮은 문제를 고치는 그의 열정은 줄어들 것이다. : 팀 전체가 상품의 품질에 책임을 져야만 한다. : 깨진 창문의 법칙을 팀원 전체가 이해하도록 격려해라. : 품질은 팀원 전체가 개인적으로 기여할 때만 보장되기 때문이다. - 삶은 개구리는 변하는 환경을 감지하지 못하고 삶아진다. : 환경의 변화(범위의 확장, 시간 척도의 감소, 추가 기능, 새로운 환경 등 애초 합의사항에 있지 않았던 것들)를 감시해라. : 새 요구사항에 대해서는 수치를 보유하라. : 이미 일어난 변화를 거부할 필요는 없다. 단지 그런 일이 벌어지고 있다는 것을 알..

이 글은 "실용주의 프로그래머" 도서를 읽고 내용과 느낌을 정리한 글입니다 :) 요구사항을 수집하지 말고 채굴하라.- 사용자들이 어떤 작업을 현재 어떻게 하느냐를 알아내는 것보다, 왜 그것을 하는지 그 내재적 이유를 알아내는 것이 더 중요하다.- 사용자 요구를 내면 깊이 들어가기 위해, 사용자처럼 생각하고 사용자와 함께 일해보라. 요구사항 문서화- 요구사항을 문서화하라. 단, 지나치게 자세히 서술하지 말라.- 좋은 요구사항 문서는 추상적이다. 단, 모호하게 하라는 말은 아니다. 구체적인 것보다 추상적인 것이 더 오래간다.- 요구사항 != 아키텍쳐 != 설계 != 사용자 인터페이스- 요구사항은 필요다.- 프로젝트 용어사전을 사용하라. 생각의 틀을 벗어나지 말고, 틀을 찾아라- 풀리지 않는 문제와 마주쳤다면..

이 글은 "실용주의 프로그래머" 도서를 읽고 내용과 느낌을 정리한 글입니다 :) 코딩은 기계적인 작업이 아니다.- 프로그램이 정확하고 생산적으로 작동하면서 천수를 누리도록 하기 위해 사려 깊은 생각과 판단을 통한 결정이 필요하다.- 적극적으로 자기 코드에 대해 생각하지 않는 프로그래머는 우연에 맡기는 프로그래밍을 하는 것이다. 우연에 맡기는 프로그래밍- 정말로 제대로 돌아가는 것이 아닐지도 모른다.- 문서화되지 않은 동작은 라이브러리의 다음 릴리스에서 변경될 가능성이 있다.- 불필요한 추가 호출은 코드를 더 느리게 만든다.- 추가로 호출한 루틴 때문에 새로운 버그들이 코드에 들어올 가능성이 있다. 우연에 맡기는 프로그래밍을 하지 말라.- 암묵적인 가정은 재앙의 근원이 된다. 의도적으로 프로그래밍하기- 자..

이 글은 "실용주의 프로그래머" 도서를 읽고 내용과 느낌을 정리한 글입니다 :) 결합도 줄이기- 코드의 의존성 증가는 변화가 코드에 미치는 영향을 크게 만들기 때문에 문제가 된다. - 의존 관계가 큰 경우 다음과 같은 징후가 발견된다. : 단위 테스트를 링크하기 위한 명령어가 테스트 프로그램 자체보다 긴 대규모 c 혹은 c++ 프로젝트 : 한 모듈의 간단한 수정이 이와 관계없는 모듈을 통해 시스템 전역에 퍼저나가는 경우 : 개발자가 수정한 부분이 시스템에 어떤 영향을 미칠지 몰라 코드의 수정을 두려워하는 경우 디미터 함수 법칙- 디미터 함수 법칙은 프로그램에서 모듈간 결합도를 최소화하려 시도한다.- 디미터 법칙은 코드를 더 적응성 있고 강하게 만들어 주지만 '주계약자'로서의 대가를 치러야 한다. 즉, 주..

이 글은 "실용주의 프로그래머" 도서를 읽고 내용과 느낌을 정리한 글입니다 :) 완벽한 소프트웨어는 만들 수 없다.- 이것을 기정 사실로 받아들이지 않는다면, 불가능한 꿈을 뒤쫓으며 시간과 노력을 낭비하게 될 것이다.- 이 암울한 현실을 어떻게 장점으로 바꿀 수 있는가가 본 장의 주제다.- 우리는 다른 사람의 코드와 접촉하고, 적절하거나 혹은 그렇지 못한 입력을 받는다. 그래서 방어적으로 코딩하도록 가르침 받았다.- 실용주의 프로그래머들은 자기 자신 역시 믿지 않는다. 따라서 그들은 '계약에 의한 설계'를 이용한다. 계약에 의한 설계- 프로그램의 정확성을 보장하기 위해 모듈들의 권리와 책임을 문서화하고 검증하는 것이 DBC(계약에 의한 설계: Design By Contract)의 핵심이다.- 선행조건(p..

이 글은 "실용주의 프로그래머" 도서를 읽고 내용과 느낌을 정리한 글입니다 :) 장인이 되어라- 장인처럼 자신의 도구 상자에 주기적으로 뭔가를 추가하게 될 것을 예상하라- 일을 하는데 더 나은 방법이 없는가 늘 주변을 살펴라- 신참들의 실수는 특정 통합 개발 환경(IDE) 같은 전동도구 하나만 고집하는 실수를 저지른다. IDE가 강제하는 편리함의 울타리 바깥에서도 능숙하게 작업할 수 있어야 한다. 유일한 방법은 기본 도구 세트를 늘 쓸 수 있도록 예리하게 유지하는 것이다. 프로그래머의 기본 재료는 지식이다.- 지식을 저장하는 최고의 포맷이 일반 텍스트(plain text)이다.- 일반 텍스트는 우리가 원하는 거의 모든 도구를 이용해서, 지식을 조작할 수 있게 해준다. 지식을 일반 텍스트로 저장하라.- 일..

이 글은 "실용주의 프로그래머" 도서를 읽고 내용과 느낌을 정리한 글입니다 :) 중복의 해악- 인공지능을 무력화 하는 방법은 두 개의 모순적인 지식을 제공하는 것이다. == 동일한 원리가 우리의 코드를 무너뜨리는데 효과적이다.- 우리는 지식을 수집하고 조직하고 유지하며 통제한다. 또한 명세서에 지식을 문서화하고 실행 코드에서 지식이 생명력을 갖게한다. 불행히도 지식은 고정적이지 않다. 이 때문에 유지보수는 애플리케이션이 출시 되었을 때 시작되는 것이 아니라 프로그래머들은 늘 유지보수 모드에 있다.- DRY(Don't Repeat Yourself)를 따르지 않는다면 유지보수의 악몽에 시달릴 것이다.- DRY를 따르지 않는다면, 남은 방법은 똑같은 것이 두 군데 이상에 표현하는 것이고 이것은 단지 언제 잊어..

이 글은 "실용주의 프로그래머" 도서를 읽고 내용과 느낌을 정리한 글입니다 :) 프로그래머는 생각보다 소통이 중요한 직업이다.- 프로그래머는, 사용자가 시키고 싶은 일을 컴퓨터가 하게끔 만들기 위해 애매모호한 요구사항을 포착해서 단순한 기계가 그것을 잘 수행하도록 노력하는 사람이다.- 프로그래머는, 다른 프로그래머가 이해할 수 있도록 자신의 작업을 문서로 만들려고 노력한다.- 프로그래머는, 다른 사람들이 자신이 한 것을 바탕으로 또 다른 것을 만들 수 있도록 자신의 작업을 설계하도록 노력한다. 카이젠은 개인에게도 적용될 수 있다.- 매일같이 기술을 다듬고, 새로운 도구를 추가하며 지속적으로 개량하라.- 카이젠(Kaizen) : 지속적으로 조금씩 자주 개량하는 것을 의미하는 일본어로 일본 제조업의 생산성과..