Prototype 패턴💡 클래스에서 인스턴스를 생성하는 대신 인스턴스로부터 다른 인스턴스를 생성종류가 너무 많아 클래스로 정리할 수 없는 경우취급할 오브젝트의 종류가 많아서 소스 파일을 많이 작성해야 하는 경우클래스로부터 인스턴스 생성이 어려운 경우복잡한 과정을 거쳐 만들어지는 것으로 클래스로부터 만들기가 매우 어려운 경우사용자 조작으로 만들어진 인스턴스와 같은 것을 다시 만들고 싶은 경우✅ 현재 만든 인스턴스를 일단 저장해두고 만들고 싶을 때 이를 복사하여 생성프레임워크와 생성하는 인스턴스를 분리하고 싶은 경우인스턴스를 생성하는 프레임워크를 특정 클래스에 의존하지 않게 하고 싶은 경우✅ 미리 원형이 될 인스턴스를 등록해두고, 등록된 인스턴스를 복사하여 생성 Prototype(원형)인스턴스를 복사하여 ..
전체 글
`CoroutineContext` : 코루틴을 실행하는 실행 환경을 설정하고 관리하는 인터페이스Coroutine Context 구성 요소`CoroutineName` : 코루틴 이름 설정`CoroutineDispatcher` : 코루틴을 스레드에 할당해 실행`Job`: 코루틴의 추상체로 코루틴을 조작`CoroutineExceptionHandler` : 코루틴에서 발생한 예외 처리 Coroutine Context 구성Coroutine Context 구성키 - 값 쌍으로 구성 요소를 관리`CoroutineContext` 객체 간의 더하기 연산자(+)를 사용하여 객체를 구성val coroutineContext: CoroutineContext = newSingleThreadContext("MyThread") + ..
Things You Should Never Do As A Software EngineerHere are some of the things that software developers should avoid when coding to improve their work performance and mental health.favtutor.comBeing Perfectionist모든 것은 완벽하지 않다. 그래서 나는 “완벽한 코드”도 존재하지 않는다고 확신한다.소프트웨어 개발은 반복적인 프로세스이다. 코드를 짜고, 테스트하고, 피드백을 받고, 리팩토링 하고, 이를 반복한다. 오늘 잘 동작하던 것이 내일 동작하지 않을 수 있다. 따라서 소프트웨어는 유연하고 변경하기 용이해야한다. (이것이 soft-ware 라고..
Clever code is probably the worst code you could writeAnd clear, readable code is probably the hardest code to writeread.engineerscodex.comdef mininumTotal(self, t): return reduce(lambda a,b:[f+min(d,e)for d,e,f in zip(a,a[1:],b)], t[::-1])[0]위 코드는 흔히 “코드 골프”라고 불린다. 취미로는 좋을 수 있지만 “좋은 코드”와는 거리가 멀다.모두들 이것이 좋은 코드가 아니라는 것은 알고있다. 실제 업계에서는 가장 나쁜 코드 중에 하나라고 할 수 있다.반대로 생각해보면 가장 명확한 코드를 작성하는 것이 실제로 가장 어려..
`launch` : 작업 실행 후 결과를 반환하지 않음`async` : 코루틴으로부터 결괏값을 수신 → Deferred 객체 반환 async 사용해 결과값 수신하기async 사용해 Deferred 만들기fun CoroutineScope.async( context: CoroutineContext = EmptyCoroutineContext, // CoroutineDispatcher 설정 가능 start: CoroutineStart = CoroutineStart.DEFAULT, // 지연시작 설정 가능 block: suspend CoroutineScope.() -> T): DeferredDeferred코루틴을 추상화한 객체코루틴으로부터 생성된 결과값을 감싸는 기능을 가짐결과값의 타입은 제네릭 타입 a..
How not to do code reviews - Aviator BlogMany code review processes become bottleneck for the engineering teams. Instead of finding bugs, it hinders progress leading to poor developer experience.www.aviator.coHow not to do code reviews전통적으로, 코드 리뷰는 엔지니어가 동료의 코드를 오류를 찾고 가독성, 효율성, 유지보수성을 보장하기 위해 면밀히 검토하는 것을 포함했다. 이 방식은 특히 대규모 팀에서 병목 현상을 유발했다. 왜냐하면 적합한 리뷰어들이 필요할 때마다 변경을 검토할 여유가 항상 있는 것은 아니기 때문이다. C..