173만명의 커뮤니티!! 함께 토론해봐요.
김영한의 실전 자바 - 중급 1편
안녕하세요. 코드에 익숙해 지는 방법이 궁금하여서 질문을 남깁니다. 저가 문제 풀이를 하다보면은 저가 하던 방식으로 하는경우에는 실패하는 경우가 많더라고요. 그래서 공식 서포터즈님들이나 영한님의 코드를 배껴서라도 풀어야 하는데, 문제는 시간이 흐르면 다시 저의 방식으로 하고 있다는것을 생각하게 됩니다. 이런 경우 어떻게 해야 영한님의 코드나 공식 서포터즈님들의 코드에 최대한 빨리 익숙해 지는 방법은 무었인가요? 계속 따라 치는거 밖에 방법이 없는건가여? 답변 부탁드립니다.
김영한의 실전 자바 - 기본편
접근제어자 문제와 풀이부터 갑자기 멍해지는데 저만 그런가요? 이러다 다음으로 못 갈 것 같은데...
김영한의 실전 자바 - 기본편
아직 중급 2 이상이 안 나온 상황에서 입문 - 기본 - 중급1을 들었다고 할 때, 이 개념은 스스로 학습하고 스프링 넘어갔으면 좋겠다 하시는 개념이 있으실까요???
나도코딩의 자바 기본편 - 풀코스 (20시간)
먼저 강의를 완강했으나 인터페이스 부분외 이런저런 부분에서 확실하게 배워지지않았습니다. 반복해서 시청했는데도 잘 안되네요. 실전에서도 이렇게될까봐 걱정인데 이 강의의 내용을 안보고도 혹은 다른 자료를 참고하지 않을정도로 완벽하게 코드를 짤 수 있을정도로 다시 노력을 해야할지 단순히 하다가 기억이 안나면 자료를 찾는 방향으로 나아갈지 조언을 부탁드립니다.
스프링 핵심 원리 - 기본편
[ 깨달음 ] - 역할과 구현의 효과를 체감 => 역할: BeanDefinition 정보 생성 ==> 구현: 무엇을 가지고 BeanDefinition 생성 - BeanDefinition을 보면 Bean 생성 시 무엇을 정의 할 수 있는지 알 수 있다 => Scope, lazyInit 등등 - factory method를 쓰는 annotation config는 => 빈 정보에 factoryBeanName = config name, factoryMethodName = 생성 method 이름 이 붙음 [ 생각과 느낌 ] - 코드 작성에도 교양이 있으면 낭만이 있다 - 직접 BeanDefinition 을 만들다니 우와
스프링 핵심 원리 - 기본편
[ 배움 ] - ApplicationContext는 BeanFactory의 자식이다 => ApplicationContext는 부가 기능 제공 - ApplicationContext 부가 기능 => 여러 인터페이스의 묶음 ==> 메시지 소스: ===> 메시지의 국제화 등 ==> 환경 변수: ===> 환경 변수 사용 등 ==> 이벤트: ===> 이벤트 발행 등 ==> 리소스: ===> 리소스 파일 열기 등 - 스프링 컨테이너 => 실제 클래스가 아니라 개념이다 [ 생각과 느낌 ] - 인터페이스가 많이 분리된 경우를 많이 봤는데 => 그 이유가 역할의 분리에서 나온 것이었구나 - 환경 변수 어떤 기준으로 쓸까? => 환경에 따라 값을 다르게 하기 위해 사용 ==> 즉, 이 값을 환경 변수로 둬야 할까의 기준은 어떤 환경에 쓰는가에 달라지냐 여부 ===> 예: 환경 별 달라지는 사용 데이터베이스 - 여러 환경을 두려면 => 테스트 등 을 위해 따로 DB 등 서버를 띄워야 하고 ==> 그만큼 많은 하드웨어 리소스도 많이 필요하겠구나
스프링 핵심 원리 - 기본편
[배움] - 부모 타입으로 조회 => 자식 타입들도 끌려 온다 - 모든 자바 객체의 최고 부모 => Object [생각과 느낌] - 코드 내에서도 역활과 구현을 확실히 나타내 주도록 하자 => (부모 class) return (구체 class)
스프링 핵심 원리 - 기본편
[생각과 느낌] - Bean에게는 Name이 있다 - Bean에게는 Type이 있다 - 같은 Type의 Bean은 Name으로 구분한다
스프링 핵심 원리 - 기본편
[ 배움 ] - getClass() 하면 classpath가 출력됨 - isInstanceOf 로 구체 객체 확인 - 타입으로만 조회 가능 - assertThrows 로 예외가 던져지는지 테스트 => 주로 실패에 대한 테스트 시 사용 [ 깨달음 ] - 테스트는 실패 하였을 때 에 대한 case도 필요하다 => 예: 인증 실패에 대한 response는 어떻게 오는지 확인 [ 생각과 느낌 ] - java는 다양한 Exception 에 대한 정의를 해두는 방식으로 현재 어떤 오류가 나는지 사용자에게 알려주고 있다. => Exception 명을 정 할 때 해당 오류에 대한 소개가 나와야 한다.
스프링 핵심 원리 - 기본편
[Spring 적용] - @Bean => method에 적어줌 ==> 컨테이너에 등록됨 - ApplicatonContext 생성 => 컨테이너 생성 ==> new AnnotationConfig...(AppConfig.class); - 컨테이너 통해서 찾아옴 => bean을 가져옴 ==> name: method 이름 ==> type: 반환 type - 실행 시 등록 됨 => @Bean 해둔 것 singleton instance 생성 - 스프링의 어마어마한 장점: => 컨테이너가 관리해서 어마어마 해진다 [생각 및 느낌] - 좋은 개발자는 당연한 것에 의구심을 품는 개발자이다 - 스프링의 개발 시초는 DIP 와 OCP를 지키기 위해서 생긴거구나
스프링 핵심 원리 - 기본편
[스프링 컨테이너 생성] - 컨테이너 생성 과정 => ApplicationContext는 인터페이스 이다 ==> AnnotationConfig (annotation 기반) - 요새 XML 잘 안씀 => Boot 에서 java config 편함 - AppConfig => 우리가 작성한 AppConfig가 컨테이너에 대한 명세 였다 - 주의: 빈 이름은 항상 다른 이름을 부여 해야 한다 => 실무에서는 무조건 단순하고 명확하게 개발 해야 한다 - 스프링 빈 의존관계 설정 - 준비 => MemberServiceImpl은 MemberRepository를 의존함 ==> 이를 생성자로 주입 받음 (의존관계 주입 DI) ===> 스프링에서 알아서 필요한 것들을 순차적으로 생성해 넣어준다 - 스프링 빈 의존관계 설정 - 완료 => 의존관계 주입도 같이 처리 된다 ==> MemoryMemberRepository는 bean으로 동록 하지 않았지만 주입에는 사용 되었다 [생각과 느낌] 재미있다
스프링 핵심 원리 - 기본편
< IoC > - 인터페이스를 사용하는 입장에서는 어떤 것을 쓸지 제어 할 수 없다 => 외부에서 관리함 예: AppConfig vs. OrderServiceImpl < 깨달음 > - 라이브러리와 프레임워크 차이 => 라이브러리: 내가 만든 체계에서 직접 호출한다 => 프레임워크: 내가 만든 것을 알아서 호출한다 < DI > - 정적인 클래스 의존 관계 => import만 보고 쉽게 파악 가능 => 세부 기능이 바뀌어도 바뀌면 안된다 - 동적인 객체 의존 관계 => 실제 실행 봐야 알 수 있음 => 세부 기능에 따라 바뀜 - DI: -- 인스턴스 생성한다 -- 참조하는 값에 넣어준다 < 깨달음 > - 의존 관계는 두가지 이다 => 정적: 클래스 의존 관계 => 동적: 객체 의존 관계 - 툴로 분석 가능 => Intellij: diagram - show diagram - 설계 할 때는 -- 인터페이스 설계 그리고 -- 객체 설계 까지 두루 한다 < IoC, DI 컨테이너 > - 뜻: 객체를 생성하고 연결해주는 역할을 하는 아이 - 예: AppConfig, 스프링, Assembler, Object factory < 깨달음 > - 잘 만든 코드는 코드 블럭을 가지고 조립하는 것이다
스프링 핵심 원리 - 기본편
[와우 포인트] 고칠 때 차이 - 구성 영역, 사용 영역 중 구성 영역만 바꾸면 된다 -- 구성 영역: 대신, 구성 영역이 세세히 다 알아야 한다 -- 사용 영역: 더 이상 손댈 필요가 없다. --- => 스프링 코드 짤 때 AppConfig 코드 외 아무 것도 손대지 않아도 된다 - 개발자가 하는 일 => 최초에 사용 영역만 인터페이스만 사용해서 잘 만드는 것 - OCP 지켜짐 => 구체화를 바꿔도 클라이언트 코드 바꾸지 않아도 된다 ==> 인터페이스를 사용하는 입장의 코드는 더 이상 인터페이스 구현체가 바뀌어도 바꾸지 않아도 된다 - DIP 지켜짐 => 추상화만 의존 ==> 구현은 모름 [팁] - Ctrl + R 하면 기존 실행된 것 실행됨
안녕하세요 백엔드 독학 시 포트폴리오 준비 및 공부 방향을 어떻게 해야 할지 방향이 잡히지 않아 고수분들의 의견을 청하고자 글을 작성하게 되었습니다. 저는 백엔드 개발자를 지망하고 있고 인프런에서 강의를 들으면서 공부하고 있습니다. 현재는 자바 강의 및 김영한 님 스프링, JPA, QueryDSL 강의 및 데이터베이스 강의를 수강하였고 개인적으로 나름 포트폴리오? 하나 만들어보고자 도서 대출 반납 및 게시판 CRUD를 할 수 있는 것을 만들었습니다.(백엔드 부분 자바 코드) 화면도 만들기는 했지만 GPT 선생님의 도움을 빌려 일단 화면이 보일 수 있을 정도만 해놨습니다. 이후 협업을 경험해 보고 싶은데 현재 올라와 인프런에서 사이드 프로젝트 자리가 있으면 지원하고 있지만 뛰어난 분들이 너무 많아 참여가 힘든 것 같습니다. 일단 현재는 docker를 공부 중이며 redis, aws를 공부하려고 합니다. 현재 취업을 위해 팀 프로젝트를 하고 싶은데 어떻게 참여할 수 있을지, 많이 부족하다면 현재 어떤 방향으로 더 공부를 진행해야 할지 방향을 잡기가 힘들어 글을 쓰게 되었습니다. 중소기업에 취직하기 위해서는 JSP을 요구하는 곳도 많아 보이는데 html, css, js를 활용해서 화면도 만들 정도로 공부해야 하는 것 인지도 질문드리고 팀플 구하는 방법 및 공부 방향 및 어떤 것을 더 추가적으로 공부하면 좋을지 댓글 부탁드립니다! 감사합니다. 많은 분들께서 댓글 주시면 경청하도록 하겠습니다!
스프링 핵심 원리 - 기본편
[리펙토링] - 역할들을 드러나게 하는 것 중요 => 인터페이스 반환 하는 부분이 안보임 - 중복 제거 => 같은 구현 클래스를 여러 군데서 넣어주던 중복 제거 [깨달음 점] - 리펙토링에서 것은 중복 제거하고 그런 것들을 하던 이유가 명확해졌다 => 역할과 구현 등 관계를 확인 하고 구조를 편하게 확인 하기 위해서 였다 ==> 앱 컨피그만 보아도 이 프로그램이 뭘 쓰고 있고 어떻게 돌아가는지 짐작이 간다 - intellij extract method 쓰면 refactor 쉽다
스프링 핵심 원리 - 기본편
[문제점] - 클라이언트 (OrderServiceImpl) 고쳐야함 => OCP를 위반함 - OrderServiceImpl이 DiscountPolicy 뿐만 아니라 구현 클래스 FixDiscountPolicy에도 의존하고 있다 => DIP를 위반함 [해결 방법] - 1. DIP 해결 방법: 인터페이스만 의존 하게 한다 -- => 코드 내에서도 객체 할당 X - 객체 할당 X 에서 생기는 NullPointer Exception 문제 해결 방법: -- => 대신 주입할 얘가 필요하다 [강의 느낀점] - 실제 의존 관계 다이어그램에서 화살표를 보니 의존 관계가 확 와닿는다
스프링 핵심 원리 - 기본편
질문: - AppConfig의 역할이 너무 광범위 하지는 않을까요? - member service impl 에 주입하는 구체 클래스는 동적으로 runtime 시 정하는 방법도 있을까요? 깨달음: - final 변수를 만들면 기본 할당 또는 생성자를 통해서 할당 되어야 함 - Command + E: 과거 했던 파일들 다보는 방법 => vim: ls [관심사의 분리] - 공연 => 역할의 구현을 누가 정하는가: 기획자 - 기획자 => AppConfig [AppConfig] - 역할 => 구현 생성 => 역할에 설정 => 기획자로서 역할을 갖는 ROLE에 맞는 구현 ACTOR를 배정함 - 역할에 설정 방법: -- 생성자 주입 [Injection] - Injection => 역할에 구체화를 부여 - DIP를 지킨다 => 구현 클래스를 몰라도 된다. ==> 역할인 인터페이스만 의존한다. - OCP를 지킨다 => (closed) 역할을 사용하는 클라이언트가 구현 클래스를 의지 않해서 구현이 바뀔 때마다 수정할 필요가 없다 => (open) 클라이언트 수정 없이 언제든지 추가 구현 클래스를 만들어서 클라이언트에 적용 할 수 있다 - Dependency Injection => 의존 관계 주입 ==> 클라이언트가 의존하는 것을 클라이언트 외부에서 주입
스프링 핵심 원리 - 기본편
아래와 같이 정리해보았습니다. 혹시 더 필요한 부분이 있을까요? [agile manifesto] 느낀점: - 기준을 제시해주어서 좋다 - 개발 할 때 고려 할 기준: -- 개인의 생각을 중요시하고 상호 교류가 잘 일어나는 것이 중요 -- 문서화 할 시간에 더 나은 제품 -- 고객과 협력에 집중하고 계약 협상에 대한 생각은 나중에 -- 필요에 따른 변화를 우선. 계획에 집착하기보다 [test] 깨달은점: - test 코드 파일 작성 쉽게 가능하다 느낀점: - 아직 SOLID가 안되는 문제점은 말씀해주시지 않았다
스프링 핵심 원리 - 기본편
질문: - Member Repository가 OrderService와 MemberService 사이에 어떻게 공유 될 수 있을지 => 내 생각: final이 영향을 준다? => 실제 답: repository 내 store가 static으로 선언되어서 그렇다 느낀점: - 단위테스트가 중요하다 => 단위테스트로 점점 쌓아 점점 더 크게 테스트하는 것이다 - 이렇게 역할과 구현을 나눠서 개발만 한 것도 잘한 것이다 => 실무에서 이렇게만 해주는 것을 1차 단계로 해보자
스프링 핵심 원리 - 기본편
[수업 노트 공유] 깨달음: 1. 단일 설계 원칙을 잘 지켰다: - "Order 생성 시 DiscountPolicy는 나는 모르겠고~ 할 수 있다. 질문: 1. discountPrice가 최종 할인된 가격 맞을까요? - discount 함수는 얼마나 할인 되는지를 알려주는 함수 아닌가요?
