전체 글

초보 개발자의 지식 공유의 장
재사용(reusability)성은 프로그래밍 언어의 핵심이라고 할 수 있음 System.out.println, 각종 정렬 함수, http client 구현이 안되어 있다면? T_T 재사용성은 힘이 있는 만큼 굉장히 위험하기도 함 A, B의 공통 부분을 추출한다면, 이후 공통 부분을 수정할 일이 있을 경우 한꺼번에 수정 가능 그러나, 세상일은 우리가 원하는대로 일어나지 않음 A를 대상으로 수정한 것이 B에서 문제가될 수 있고, B를 대상으로 수정한 것이 A에서 문제가될 수 있음 따라서 재사용성을 고려하는 일은 생각보다 어렵고, 다양한 오류를 발생시킬 수 있음 [Effective Kotlin. 19] knowledge를 반복하여 사용하지 말라 프로젝트에서 이미 있던 코드를 복사해서 붙여넣고 있다면, 무언가가..
아키텍처란? 시스템 아키텍처는 시스템의 동작 여부와 거의 관련이 없다. (아무런 역할을 하지 않는다는건 아니다.) 형편 없는 아키텍처를 갖춘 시스템도 그런대로 잘 동작한다. 이런 시스템은 운영보다는 배포, 유지보수, 계속되는 개발 과정에서 어려움을 겪는다. 유지보수는 모든 측면에서 봤을 때 비용이 가장 많이 발생한다. 유지보수 중 가장 큰 비용은 탐사와 이로 인한 위험부담에 있다. 탐사? 기존 소프트웨어를 파헤쳐서 어디를 고치는게 최선/최적일지 결정하는 비용 이러한 변경사항을 반영할 때 의도치 않은 결함이 발생할 가능성이 존재하며, 이로 인한 위험부담 비용이 추가됨 시스템을 컴포넌트로 분리하고, 안정된 인터페이스를 두어 서로 격리하면 비용을 줄일 수 있음 선택사항 열어 두기 소프트웨어는 두 가지 가치 행..
Expression intersect : 교차하다. Their interests intersected, leading to fruitful collaboration. the best of both worlds : 최상의 상황 Working from home allows me to have the best of both words. I can spend time with my family and build my career. intertwine : 뒤엉키다 lucaraive : 수익성이 좋은, 이익이 있는 I have a lucrative job that allows me to travel around the world down the line : 향후에, 나중에 We might face some chal..
SOLID원칙이 벽과 방에 벽돌을 배치하는 방법이라면, 컴포넌트 원칙은 빌딩에 방을 배치하는 방법을 설명해준다. 큰 빌딩과 마찬가지로 대규모 소프트웨어 시스템은 작은 컴포넌트들로 만들어진다. 컴포넌트는 시스템의 구성 요소로 배포할 수 있는 가장 작은 단위다. 자바의 경우 jar 파일이 컴포넌트 컴포넌트 응집도 어떤 클래스를 어느 컴포넌트에 포함시켜야 할까? 소프트웨어 엔지니어링 원칙의 도움이 필요하다. 컴포넌트 응집도와 관련된 세 가지 원칙 REP : 재사용/릴리스 등가 원칙 (Reuse/Release Equivalence Principle) CCP : 공통 폐쇄 원칙 (Common Closure Principle) CRP : 공통 재사용 원칙 (Common Reuse Principle) REP: 재사용..
FTP File Transfer Protocol FTP는 Active / Passive 2개의 모드가 존재 연결을 제어하는 Command 포트 데이터를 전송하는 Data 포트 존재 Active 클라이언트에서 21 포트로 접속 후 자신이 사용할 데이터 포트를 서버에 미리 알려줌(1027 포트를 사용하겠다.) 요청에 응답 서버는 클라이언트가 알려준 1027 포트로 접속 시도 요청에 응답 Active 모드는 서버가 클라이언트에 접속을 하기 때문에 클라이언트에 방화벽 정책이 허용되지 않은 상황이라면 FTP 접속이 정상적이지 않음 Passive Passive는 Active 모드의 단점을 해결하기 위한 모드 데이터 포트는 서버 설정에서 변경할 수 있으며, 특별히 지정하지 않는다면 1024 ~ 65535번 중 임의의..
코틀린의 프로퍼티는 자바의 필드와 비슷해보이지만 완전히 다른 개념 // kotlin val name: String? = null // java String name = null; 공통점 : 데이터를 저장 프로퍼티는 더 많은 기능이 존재 기본적으로 프로퍼티는 사용자 정의 세터/게터를 가질 수 있음 var name: String? = null get() = field?.toUpperCase() set(value) { if (!value.isNullOrBlank()) { field = value } } field 식별자 : 프로퍼티의 데이터를 저장해 두는 백킹 필드(backing field)에 대한 레퍼런스 백킹 필드는 세터와 게터의 디폴트 구현에 사용되며 따로 만들지 않아도 디폴트로 생성 됨 val을 사용해..
개발자가 코드를 작성하는 데는 1분 걸리지만, 이를 읽는 데는 10분이 걸린다 - 로버트 마틴 프로그래밍은 쓰기보다 읽기가 중요 항상 가독성을 생각하며 코드릴 작성할 필요가 있음 인식 부하 감소 kotlin을 처음 접하게 되면 코드가 간결해지는 몇 가지 마법들을 만나게 된다. 이 몇가지 마법들을 알게되면 활용을 하고 싶어지고, 코드를 계속 간결하게 만들고 싶은 욕망에 사로잡히게 되는데 가독성 측면에서 생각해볼 필요가 있음 무엇이 더 좋을까? // 구현 A if (person != null && person.isAdult) { view.showPerson(person) } else { view.showError() } // 구현 B person?.takeIf { it.isAdult } ?.let(view:..
withData는 중첩 테스트기 때문에 outer test에서 사용해야 한다. FreeSpec // error "test" { withData(1,2,3) { //.. } } // ok "test" - { withData(1,2,3) { //.. } } ShouldSpec context("test") { withData(1,2,3) { // .. } } Spyk - recordPrivateCalls 속성을 이용하면 private 메소드를 손 쉽게 mocking할 수 있다. kotest private 메소드 mocking val target = spyk(Service(), recordPrivateCalls = true) "test" { every { target["validate"](obj) } retur..
계층이 잘 분리되면 좋은점? 어떤 계층에서 작업할 때 해당 계층만 생각하면 된다는 점. 즉, 전체를 이해할 필요가 없어지는 것 어셈블리 언어, JVM 바이트 코드가 무엇인지 몰라도 프로그래밍할 수 있음 추상화 레벨 높은 레벨로 갈수록 프로세서(물리 장치)로부터 멀어짐 높은 레벨일수록 걱정해야 하는 세부적인 내용들이 적어지지만(단순함을 얻는다.), 제어력을 읽어버림 c언어는 메모리 관리를 직접 할 수 있으나, 자바는 가비지 컬렉터가 자동으로 관리 해줌 메모리 사용을 최적화하는 것이 힘듬 높은 레벨(고수준)일 수록 비즈니스 핵심 로직에 가까움 추상화 레벨 통일 코드도 추상화를 계층처럼 만들어 사용할 수 있는데, 이를 위한 기본적인 도구가 함수 class CoffeeMachine { fun makeCoffee..
setup dependency 추가 tasks.withType().configureEach { useJUnitPlatform() } // Test Framework testImplementation('io.kotest:kotest-runner-junit5:5.5.4') // Assertions Library testImplementation('io.kotest:kotest-assertions-core:5.5.4') Kotest intellij plugin 설치 Testing Style kotest는 10개의 레이아웃을 제공하며, 이 중 하나를 상속받아서 사용 가능 여러 테스트 프레임워크에서 영감을 받아 작성된 레이아웃도 존재 사용하면 편할 것 같은 레이아웃을 몇 개 살펴보면 Should Spec Beha..
깡냉쓰
평범한 개발자 노트