taetae98

Observable RxJava의 가장 핵심적인 요소입니다. Observable은 데이터를 흐름에 맞게 만들어서 Observer에게 보내는 역할을 합니다. RxJava는 이벤트를 통한 Observer Pattern을 기반으로 만들어졌습니다. Observable 가장 기본적인 형태, N개의 데이터를 발행할 수 있습니다. onComplete를 통해 완료를 알릴 수 있으며 onError를 통해 에러를 처리할 수 있습니다. onComplete, onError가 호출되면 이후에 발행하는 onNext는 무시합니다. fun observable() { Observable.create { emitter -> emitter.onNext(1) emitter.onNext(2) emitter.onNext(3) emitter.o..

Reactive Programming 데이터의 흐름을 먼저 정의하고 데이터가 반영되었을 때 연관된 작업이 실행횐다. 즉, 이벤트에 반응하여 프로그램이 동작한다. 어떻게 이벤트를 반응할까? Observer 패턴 (이벤트 처리) Iterator 패턴 (이벤트 처리) Functional 프로그래밍 (이벤트 가공) RxJava https://reactivex.io/intro.html ReactiveX is a library for composing asynchronous and event-based programs by using observable sequences. It extends the observer pattern to support sequences of data and/or events and a..

프로그래머라면 형식을 깔끔하게 맞춰 코드를 짜야 한다. 코드 형식을 맞추기 위한 간단한 규칙을 정하고 그 규칙을 착실히 따라야 한다. 팀으로 일한다면 팀이 합의해 규칙을 정하고 모두가 그 규칙을 따라야 한다. 필요하다면 규칙을 자동으로 적용하는 도구를 활용한다. 형식을 맞추는 목적 코드 형식은 중요하다! 너무 중요해서 무시하기 어렵다. 코드 형식은 의사소통의 일환이다. 의사소통은 전문 개발자의 일차적인 의무다. 오늘 구현한 기능이 다음 버전에서 바뀔 확률은 아주 높다. 그런데 오늘 구현한 코드의 가독성은 앞으로 바뀔 코드의 품질에 지대한 영향을 미친다. 원래 코드가 사라질지라도 개발자의 스타일과 규율은 사라지지 않는다. 의사소통할 때 물과 불을 바꿔서 말하면 혼란이 올 것이다. 코드 형식이 다르다면 코드..

주석 사실상 주석은 기껏해야 필요악이다. 우리에게 프로그래밍 언어를 치밀하게 사용해 의도를 표현할 능력이 있다면, 주석은 거의 필요하지 않으니라. 아니, 필요하지 않으리라. 그러므로 주석이 필요한 상황에 처하면 곰곰이 생각하기 바란다. 상황을 역전해 코드로 의도를 표현할 방법은 없을까? 주석을 무시하는 이유? 주석은 너무 자주 거짓말을 하니까. 주석은 오래될수록 코드에서 멀어지고, 그릇될 가능성이 커진다. 이유는 단순하다. 프로그래머들이 주석을 유지하고 보수하기란 현실적으로 불가능하니까. 코드는 변화하고 진화한다. 일부가 옮겨지거나 조각이 나눠지고 합쳐진다. 불행하게도 주석은 언제나 코드를 따라가지 않는다. 주석이 코드에서 분리되어 점점 더 부정확한 고아로 변하는 사례가 너무도 흔하다. 프로그래머들이 주..

클래스 객체지향 프로그래밍에서 핵심적인 요소로 현실 세계의 모델을 프로그래밍 언어로 표현할 때 사용한다. 자바와 선언 방식이 비슷하다. main() { var p1 = new Position(); p1.show(); } class Position { int x = 0; int y = 0; show() { print("x: $x, y:$y"); } } 기본 생성자 생성자를 통해서 객체를 생성할 때 필요한 초기값을 설정할 수 있다. 생성자도 함수처럼 네임드 함수, 선택 매개변수 함수 등의 방법으로 정의할 수 있다. main() { var p1 = new Position(5, 4); p1.show(); } class Position { int x = 0; int y = 0; Position([int x = 0..

작게 만들어라! 함수를 만드는 첫째 규칙은 '작게'다. 함수를 만드는 둘째 규칙은 '더 작게'다. 이 규칙은 근거를 대기가 곤란하다. 함수가 작을수록 더 좋다는 증거나 자료를 제시하기도 어렵다. 하지만 나는 지난 40여년 동안 온갖 크기로 함수를 구현해봤다. 지금까지 경험을 바탕으로 그리고 오랜 시행착오를 바탕으로 나은 작은 함수가 좋다고 확신한다. 개인적인 생각 좋은 함수명과 작은 함수는 주석없이 코드를 읽게 만들어준다. 작은 함수는 재사용이 편리하고, 오류 추적이 쉽고, 테스트가 편하다. 그렇다면 얼마나 짧아야 좋을까? 80년대에는 함수가 한 화면을 넘어가면 안된다고 말했다. 당시 모니터 화면은 가로 80자 세로 24줄이었고 편집기에서 4줄을 관리용으로 사용했습니다. 가로 150자를 넘어서는 안 된다..

cherry-pick git cherry-pick이란 다른 브랜치에 있는 커밋을 선택적으로 내 브랜치에 적용시킬 때 사용하는 명령어 입니다. git cherry-pick git cherry-pick git cherry-pick .. 커밋 해쉬를 통해서 하나씩 하는 방법도 있고, ..을 통해 범위로 설정하는 방법도 있습니다. cherry-pick을 사용하는 이유는 다른 브랜치에서 변경된 부분을 가져오고 싶을 때 주로 사용합니다. cherry-pick이 없으면 변경된 내용을 모두 직접 복사해야 하며 이 과정에서 실수가 발생할 수 있습니다. 또한 제대로 복사가 됐는지 다시 테스트하는 과정이 필요하고 많은 작업을 요구합니다. Abort git cherry-pick --abort 충돌이 발생한 경우 abort 명..

Commit 커밋이란 깃으로 관리하는 형상들에 변경이 일어났을 때 변화에 대한 기록입니다. 커밋을 하면 하나의 체크 포인트가 생성되고 원할 때 언제든지 복구를 할 수 있으며 잘 관리된 커밋 내용은 프로젝트를 파악하는데 큰 도움이 됩니다. git commit -m "메시지를 입력하세요" 기본적으로 커밋할 때는 메시지를 필수로 입력해야 합니다. user@AL01724100 Git-Study % git log --oneline 4229d8e (HEAD -> master) dd zzz da7f725 (cc) 첫번째 c1 55831da * c1 868fa2f c1 09002ce update cc 9240159 update aa, cc a9d0be9 Merge branch 'master' into cc 80687b..