fbfbf1의 등록된 링크

키자드에 등록된 총 1413개의 포스트를 확인하실 수 있습니다.

Naver Blog

[서평] 혼자 공부하는 컴퓨터 구조 + 운영체제 강민철 지음

한빛미디어에서 새로 출판한 혼자 공부하는 컴퓨터 구조 + 운영체제입니다. 책 표지는 혼공 시리즈를 그대로 따라갑니다. 책 왼쪽 아래에 보면 전공자를 위한 필수 용어 + 비전공자를 위한 쉬운 그림이라고 써져 있는데 정말 그림도 쉽게 나와서 이해하기도 쉽고 필수 용어들도 다 잘 되어있는 것 같습니다. 책만 보기 힘들면 유튜브 강의도 있으니 같이 보시는 걸 추천드립니다. 독자의 한 마디만 봐도 이 책이 얼마나 쉽게 설명한 지를 알 수 있습니다. 저도 처음에는 비전공자를 위한 책이니 쉬운 내용만 담겨 있겠지라고 생각했지만 읽어보니까 전공 수업에서 배웠던 내용들이 그대로 수록되어 있습니다. 전공 수업에서 어렵게 설명했던 내용들이 여기서는 쉬운 그림과 함께 쉽게 설명해 줘서 좋았습니다. 책 그림도 잘 보이고 귀여우며 책 가독성도 좋습니다. 한 챕터의 마지막에는 마무리가 있어서 복습하기 좋습니다. 중요한 개념들에는 꼭 그림이 다 들어가 있어서 이해하기 쉽게 만들었습니다. 뒷부분에서 배울 내용들은

원문보기 내부링크
Naver Blog

12월 셋째 주

블챌이 끝나니 확실히 쓰기가 귀찮아지네.. 롯데몰에 있는 편백나무찜 먹어봤다. 요거는 전골 이게 편백나무찜 맛있다. 건강한 맛 오랜만에 헬스장도 갔다.. 회사 점심 회식! 오랜만에 회 먹었다! 튀김도 있고 뭐 먹을 게 많이 있었다! 회 먹고는 빵집! Our 빵집이었는데 괜찮다 커피도 마시고 빵도 많이 먹고 회사에서 캔미팅 비용을 지원해 줬기에 캔미팅 비용으로 케이크까지 샀다. 이 케이크랑 한 개 더 있다. 나는 이미 점심에 먹은 걸로 당이 충분했기에 한 입도 안 먹었다. 샤롯데에 스위니토드 보러 갔다. 아마 중3 때 학교에서 보러 간 루나틱이 한국에서 본 마지막 뮤지컬일 거다. # 스위니토드 무슨 내용인 지도 모르고 갔다가 뮤지컬 시작하기 전에 구글에 쳐봐서 내용 파악했다. 사람들 많다! 샤롯데 내부도 고급스럽다. 나는 1층 객석에서 봤다. 자리 좋아서 잘 보였다.! 공연 시간은 2시간 50분.. 근데 너무 재미있어서 3시간짜리 인지도 몰랐다!! 꼭 보자!! 너무 재밌다. 배우들도

원문보기 내부링크
Naver Blog

2022년 회고

매년 회고 글을 쓸 때마다 드는 생각 "시간 정말 빠르다" 그래도 지금까지와 다른 게 있다면 옛날에는 한 해의 마지막 날이 되었을 때 "아니 뭐 했다고? 벌써 한 해가 끝났을까"라고 생각을 했다. 하지만.. 이번 연도는!! 아주 많을 걸 했어! 내 인생에서 가장 기억에 남고 잘 풀린 연도이다. 이번 연도를 문장으로 나타내면 대학생 끝, 직장인 시작 연애도 시작!!!!!!!!!!! 우왕 내 인생에 이렇게 좋은 일이 한 번에 일어난 적은 처음이다. 가끔 이래도 되나 싶은데 다시 생각해 보고 나는 이래도 된다고 생각하고 넘긴다 ㅎ 원래는 1월부터 12월까지 쓱 정리하는데 이렇게 되면 너무 오래 걸릴 것 같아서 특별한 것만 정리해야겠다. 대학 산업공학과 컴퓨터공학과 대학교 생활도 이제 끝이다. 2016.03 ~ 2023.02 대학생활 재밌게 하고 갑니다~ 저번에는 영어 성적이 없었어가지고 교양 시험이 불합격 떴었는데 이번에 토익 응시하고 성적 등록해서 교양 시험까지 합격으로 변했다. 201

원문보기 내부링크
Naver Blog

12월 마지막 주

엄마랑 정자역에서 만나서 #진대감 갔다. 내부 시설 괜찮다. 다만.. 가격이 엄청 비싸고.. 양은 적다... 물론 맛있긴 함.. 저 위에 사진이 56000원.... 진짜 맛있긴 함.. 다만.. 너무 비싸!!!!!!!! ㅎ 그래서 결국 배고파서 롯데리아 가서 햄버거 2개 ~~~ 먹었다.. 오랜만에.. 내 최애 배달음식인 김치찜 먹었다.. 서울대벤처타운역에 있는 #만푸쿠 먹으러 갔다. 다만 아쉽게도.. 하필 연어 음식은 안된다고 했다 ㅠ 그래서 연어 서비스로 2조각 받고.. 김치전이랑.. 새우튀김도 서비스로 받았다.. 장어텐동 먹어봤는데 먹을만하다. 다음에는 연어로 먹어보고 싶다. 밥 먹고는 그림 그리러 갔다. 내부 깔끔하다. 한 번에 2시간.. 나는 고양이 그림 그렸다. 밑그림이 있어서 색칠만 하면 된다. 생각보다 오래 걸린다. 정말 이거 그리면서 예체능 쪽으로 갔으면 망했을 거다고 생각했다. 그래도 나름 다 그리고 보니까 괜찮다. 배경색을 분홍색으로 한 게 신의 한 수! 짜잔~! 분

원문보기 내부링크
Naver Blog

[1년 전 오늘] 네이버 부스트캠프 AI Tech 3기 합격

2022.1.4. 1년 전 오늘 네이버 부스트캠프 AI Tech 3기 합격 인생은 정말 아무도 모른다. 이걸 추합으로 붙을 줄은 몰랐네요.. 나도 다른 사람들 쓰는 것처럼 써봐야지. 정보 - 전공자(주전공 : 산공, 복수전공 : 컴공) - ai 관련 통계, 수학, 이론 수업 많이 들었고 따로 공부도 많이 했습니다. 동아리 활동도 하고 - 22년 기준 4학년 됩니다. - 백준 플래티넘 5, 약 690문제 정도 풀... 류리상자 진짜 아직도 궁금하다. 이거 참가했으면 지금 어떤 삶을 살고 있을까 너무 궁금해

원문보기 내부링크
Naver Blog

Synchronized 동시성 문제 해결

요청이 동시에 여러 개 들어오면 어떻게 될까? @Transactional을 사용해도 다른 스레드에서 사용 가능 @Service @RequiredArgsConstructor public class StockService { private final StockRepository stockRepository; @Transactional public synchronized void decrease(Long stockId, Long quantity) { final Stock stock = stockRepository.findById(stockId).orElseThrow(); stock.decrease(quantity); stockRepository.saveAndFlush(stock); } } @Test void stock_decrease() { stockService.decrease(1L, 10L); final Stock stock = stockRepository.findById(1L).or

원문보기 내부링크
Naver Blog

Pessimistic Lock 이용 동시성 문제 해결

Lock 동시성 문제를 DB에서 제공하는 방법으로 해결할 수 있다. Pessimistic Lock DB에서 데이터에 Lock을 걸어서 정합성을 맞추는 방법 Pessimistic Lock을 사용하게 되면 다른 트랜잭션에서는 Lock이 해제되기 전에 데이터를 가져갈 수 없게 된다. 다만 데드락이 걸릴 수 있기에 주의해야 한다. Row나 table 단위임 Lock을 사용하기 위해서 @Lock 어노테이션 사용 Lock을 위한 서비스를 만들어준다. 테스트를 돌려보면 성공하게 된다. 충돌이 빈번하게 일어나면 Optimistic Lock 보다 성능이 좋고 Lock을 잡기에 데이터 정합성이 어느 정도 해결할 수 있다. 별도의 Lock을 잡기에 성능 감소가 있을 수 있다. 출처 : 재고시스템으로 알아보는 동시성이슈 해결방법(최상용) - 인프런 재고시스템으로 알아보는 동시성이슈 해결방법 - 인프런 | 강의 동시성 이슈란 무엇인지 알아보고 처리하는 방법들을 학습합니다., - 강의 소개 | 인프런...

원문보기 내부링크
Naver Blog

소주톤 얼레벌레 크리스마스 후기

소주톤 : 얼레벌레크리스마스 | Festa! Festa에서 당신이 찾는 이벤트를 만나보세요. festa.io GDSC KR 채널에 올라와서 할까 말까 고민하다가 큰 맘 먹고 신청해서 한 해커톤 다른 해커톤과 다르게 굉장히 짧다. 6시간동안 다 해야된다.!! 어린이 대공원역에 있는 엘리스 Lab 서울특별시 성동구 아차산로17길 48 성수낙낙 2층 엘리스 랩에서 해커톤 했다. 시설 깔끔하고 좋다! 여기는 행사 하는 곳! 아! 실제 코딩하는 곳을 안 찍었네 코딩 하는 곳도 진짜 좋다. 소문난 주니어 해커톤이라서 소주톤이다! 이렇게 귀여운 명찰을 준다. 행사 소개 하고 자기 소개, 아이스 브레이킹 하고 팀빌딩 했다. 나는 팀빌딩 시작하자마자 마이크 써서 팀 모집했다. 백엔드 한 분이 나한테 오셔서 백엔드 2명 되고 그 다음으로 기획자랑 디자이너분이 마이크 잡아서 팀 모으길래 바로 달려갔다! 때마침 앱 개발자님도 오셔가지고 5명이서 팀 이뤘다! 주제는 기획자 분이 생각하신 크리스마스 mbti

원문보기 내부링크
Naver Blog

11월 마지막 주

블챌도 마지막이구나! 연어가 땡겨서 또 연어시장 갔다 언제 먹어도 연어시장은 맛있다!! 지금 이 순간에도 또 먹고 싶다. 인터넷에서 투움바 파스타 글 보고.. 아 투움바 파스타 먹고 싶다는 생각이 들었는데 ㅎ 아웃백 가서 투움바 파스타를 먹을 수는 없어서.. CU 가서 뭐 맛있는 거 없나~ 둘러보다가 발견한 투움바! 먹을만하다! 먹고.. 후식까지!! 이게 6000원이야!! 하나당 500원짜리!! 친구가.. 크리스마스라고 준 exe 프로그램 ㅎ 맥북에서는 안돼서 윈도우에서 해봤다. 신입사원 cheer up 프로그램이 있어서 출근한 회사! 점심으로 사 먹은 아 뭐였더라 아무튼 맛있는 거 에그 햄버거! 멕시칸 랩!! 멕시칸 랩 존맛~ ㅎ cheer up 프로그램에서 뭘 하나 했더니 칵테일 만들기였다! 게임 열심히 해서 재료도 많이 모았다! 첫 번째는.. 회사 사람들을 위해서 만든 칵테일 두 번째는 회사 신입 사원분들을 위한 칵테일 음하하하!! 2번째 칵테일로 우리 팀이 맛 평가 1등을 해

원문보기 내부링크
Naver Blog

[2022 마이 블로그 리포트] 올해 활동 데이터로 알아보는 2022 나의 블로그 리듬

ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ 또 내가 Top3네.. 2022년 내 인생 최고의 한해다~ 2022 마이 블로그 리포트 2022년 올해 당신의 블로그 리듬을 알아볼 시간! COME ON! campaign.naver.com

원문보기 내부링크
Naver Blog

12월 첫째 주

공릉동 내가 찜한 닭.. 언제 먹어도 맛있다. 이날은 특히 더 맛있었다! 후식으로 설빙~ 회사에서 네일 받았다 ㅎ 팀원분이 받아보라고 하셔서 한 번 받아봤는데 아주 마음에 ㅡㄷㄴ다!! 아주 깔끔해졌다! 회사 점심으로 먹은 도쿄스테이크의 채끝살 스테이크 존맛탱구리~ 일하다가 사내 카페로 와서 먹은 베이글.. 이걸 왜 이제야 먹어봤을까.. 너무 맛있다! 이날은 저녁까지 회사에서 먹고 갔다.. 수요일에는.. 산업공학과 캡스톤경진대회가 있었다.. 조그마한 곳에서 발표한다. 우리 조가 만든 포렌식 관점에서의 Element 인스턴스 메시지 분석! 같이 하시는 분은 유능한 인재라서 이날 대만에 학회 참석하러 가서.. Zoom으로 참석하셨다.. 내가 계속 발표하느라 쉽지 않았다 ㅠ 끝나고 받은 먹거리들 샐러디랑 에그 타르트!! 오렌지 주스!! 점심으로 먹었다! 샐러디 멕시칸랩 존맛탱 에그타르트는 그럭저럭 결과가 그다음 날 바로 나왔다. 금상 받았다!!!! 우와아아아아!!!! 하지만 인간의 욕심은

원문보기 내부링크
Naver Blog

대학생활 끝

과제까지 제출 완료..!!!!!!!!! 대학생활 끝이다!!!!!!!!!!!! 안녕!!!!!!! 드디어 끝났다!!!!!!!!!!!!!!!!!!!!!!... 아 이거 제출하니.. 좀 싱숭생숭하네.. 일이나 하러 가야지..

원문보기 내부링크
Naver Blog

금상 받았다.

끼야후 오늘 시상식했다. 시상식 시간이 길면 어쩌나 했는데 후딱 끝났다! 두 번째로 상 받았다! ㅎ 팀원 분 들어갈 때 나는 사진찍었다 ㅋㄷㅋㄷ ㅋㅋㅋㅋㅋ 엘리베이터에서도 한 컷!!! 대학생활동안 금상 1개 은상 1개 받았네 상 하나도 못 받을 줄 알았는데 2개씩이나~ 이야후!

원문보기 내부링크
Naver Blog

12월 둘째 주

회사에서 나눠준 신년 달력 및 다이어리 키크니가 그림 그렸다. 색깔 잘 뽑혀서 마음에 든다! 이 날은 일이 많아서 10시쯤에 퇴근했다. 퇴근하고 종로 3가 가서 치킨 먹었다!! 아주 좋은 일이 있었다!! CTO 팀 송년회에서 문제 맞춰서 가습기 받았다. 차량용.. 난 차가 없는데!! ㅎㅎ 금상도 받았고.. 서울 감자탕도 먹었다. 종강하고 학교도 한 번 놀러갔다. 빕스갔다. 와인이 무한이었는데 난 와인은 아직도 잘 못 마시겠어가지고 2잔 정도만 마셨다. 빕스.. 생각보다 먹을 게 없다. 아쉽다 아쉬워.. 디저트는 맛있게 먹었고.. 카프리제를 제일 많이 먹었다.. 빕스 먹고는 건대 호수 구경갔다. 건대 넘모 좋다. 상권도 좋고 호수도 크고.. 집 앞 카페에 있는 강아지 ㅎㅋ 오랜만에 이삭 토스트! 2개 먹었다! 이번엔 참맛 갔다. 서울 감자탕이나 참맛이나 비슷비슷하다. 하남 스타필드 갔다왔ㄷㅏ. 가는 길 너무 추웠다. 입구 들어서면 피카추가 있다! 대왕 피카추도! 골전도 이어폰 너무 신

원문보기 내부링크
Naver Blog

[1년 전 오늘] 진짜 종강

2021.12.20. 1년 전 오늘 진짜 종강 17일 날 시험이 끝났지만 19일 11시 59분까지가 팀플 마감일이었다.. 미루고 미루다가 18일부터 시작했다가 잘못하면 못 할 뻔했다.. 이번 학기 팀플 3개 있었는데 후.. 정말 쉽지 않았다,, 정말롴ㅋㅋㅋㅋㅋㅋㅋㅋㅋ 팀플 3개 다 잘 마무리한 것 같다. 2개는 팀원들도 잘 만나서 별로 스트레스 없었는데 1개는 정말 팀원이... 류리상자 1년 전의 나.. 고생 많이 했구나 역시 사망년인가.. 1년 전에 이렇게 썼는데.. 취업은 1학기 끝나자마자 하고.. 대학원은 가지 않고.. 밥은 너무나 잘 먹어서 살이 찌고 있고.. 결국 백엔드 개발자를 하고 있다! 인생 정말 알 수 없다! 좋은 방향으로 잘 풀려서 다행이다. 1년 뒤의 나는 뭘 하고 있으려나

원문보기 내부링크
Naver Blog

크리스마스 트리 테스트

해커톤에서 크리스마스 트리 테스트 만들어보았습니다. 크리스마스 트리 성향테스트 sojuton tree-test-28875.web.app 한 번씩 해주시면 감사합니다 ㅎ

원문보기 내부링크
Naver Blog

명동 나들이

한 달 만에 출근했다! 오랜만에 출근하면 피곤하긴 한데 확실히 집중은 잘 되긴 한다. 퇴근하고는 명동 #딘타이펑 갔다.!! 대기는 한 10분 정도 했다. 세트 A 시켰다! 멘보샤! 나는 멘보샤가 왜 이리 좋지! 탄탄면!.. 흠 비주얼이 그냥 못생겼다.. 맛은 좀 애매하다.. 볶음밥 샤오룽바오! 육즙은 인정이다. 한 입 베어 물면 육즙 쏟아진다.. 다만 맛은.. 엄청 맛있지는 않다. 먹을만한 느낌 요거는 초콜릿 샤오룽바오.. 진짜 딱 이 느낌이다. 한 입 먹으면 초콜릿이 온몸을 감싸는 느낌 엄청 달다 ㅋㅋㅋㅋㅋ 이거 먹는 바람에 입맛이 사라져버려서 명동에서 길거리 음식도 못 먹었다. 구원자 다이소가 보이네요 ㅎ 꺄후~! 오랜만에 오는 명동.. 한국인이 은근 없다. 외국인 천국!! 역시.. 겨울이라.. 트리도 있다!ㅈ 명동예술극장. 오스트리아에서 본 극장이 생각났다. 길거리를 이쁘게 장식했다. 롯데 백화점 구경 갔다!! 차넬 CHANEL == 채널! 고정! 롯데 백화점에서 밀고 있는 크

원문보기 내부링크
Naver Blog

청담동 케이하우스

#청담동 #케이하우스 케이하우스 서울특별시 강남구 도산대로90길 16 케이하우스 청담동 케이하우스에 킹크랩 먹으러 갔다!! 단체석이라 안쪽으로 들어갔다. 기본 세팅은 위와 같다. 킹크랩 먹었다. 1인당 23만 원이다!! 메뉴 순서는 위에 적힌 그대로 나온다. 전채요리부터 시작!! 나는 4번째 감태튀김이 젤 맛있었다. 다른 것들도 맛있다. 시금치 게살무침... ㅎ 초딩입맛이라 나랑 안 맞았다. 오쯔꾸리 광어, 방어, 농어다. 킹크랩 나오기 전에 새우튀김, 꽈리고추 튀김이 같이 나온다. 참고로 당연히 음식은 직원분들이 다 서빙해서 자리까지 다 가져다주고 다 먹은 그릇들도 바로바로 치워주고 물도 다 마셨으면 계속 계속 채워준다!! 가면 먹기만 하면 된다!! 대망의 킹크랩!!!!! 킹크랩은 찌는데 30분 정도 걸린다!! 그럼 위의 사진처럼 나오고.. 와인을 뿌리고 불을 붙인다! 불타오르네!! 크.. 총 6마리 나왔다. 2인당 1마리로 보면 된다! 몸통이랑 다리 다 손질해 주신다. 먹기 편하

원문보기 내부링크
Naver Blog

강남 나들이

오랜만에 강남역! 저녁으로 쉑쉑버거!! 나는 스모크 햄버거 ... 무난하다.. 치즈감자는 맛있다! 그다음으로 #키이스케이프 오랜만에 방탈출!! 내부 자체는 조그맣다.. 그래서 괜찮을까? 싶었는데 너무 마음에 들었다 ㅎㅎ 테마도 이쁘게 꾸몄고.. 난이도도 적당하다!! 10분 남기고 성공했다!! 스토리도 마음에 든다.. 방탈출하고는 #곱창고 한우모듬곱창 시켰다..) 잘 익어가는 중.. 맛은 양호하다.. 볶음밥은 맛있다!!! 갬성 글귀.. 오랜만에 술도 마시고 ㅎ 같이 마신 사람의 손.. 엄청 빨갛다 ㄷ ㅏ 먹고 미니스탑 아이스크림.. 믹스 아이스크림으로 시켰는데.. 초콜릿이 나왔다.. 과연 누가 잘못한 것일까. 다 먹고 인생네컷 찍었다!! 원래 영화볼까 하다가.. 강남역 온 건데!! 아주 재밌게 놀았다!!

원문보기 내부링크
Naver Blog

11월 넷째 주

오랜만에 출근도 했었고 명동도 갔다 오고 킹크랩도 먹고! 먹고 2차로 가서 치킨도 먹고! 김치전도 먹고! 팔찌를 가지고 싶어서 무신사에서 하나 장만했다. 헝헝 할머니들이 만들어서 파는 팔찌이다. 파는 수익 중 일부는 기부하고 이런 편지까지 ㅠ 팔찌도 이쁘다 이거 보고 울 뻔 ㅠ 공릉동 #솔직하다 에서 스프카레도 먹어봤다. 처음 먹어보는데 맛있다. 쉑쉑버거도 먹어주고! 방 탈출도 하고! 에버랜드도 갔다 왔다.! 아쉽게도 불꽃놀이는 하지 않아서 퍼레이드까지 보고 왔다. 에버랜드 포스팅은 따로 해야지 이제 대학생활 마지막 시험 기간이다,, 시험기간 + 해커톤 + 외부 교육 + 밀려오는 일 아주 기대되는구만!! 빨리 시험 기간부터 끝났으면!!

원문보기 내부링크
Naver Blog

[서평] 적정 소프트웨어 아키텍처 리스크 주도 접근법(조지 페어뱅크스 지음)

적정 소프트웨어 아키텍처 - 리스크 주도 접근법 책입니다. 표지.. 외국 감성이 느껴지네요 뒷장에서는 내용이 간략히 요약되어 있습니다. 소프트웨어 개발을 시작할 때 볼만한 가이드북 리스크는 무엇인고, 아키텍처의 설계 원칙은 어떻게 적용하고 해결하는지 책 앞 부분에 추천사나 지은이, 옮긴이의 말을 보면 소프트웨어 개발을 "시작할 때" 보면 좋은 책인 걸 알 수 있습니다. 즉 실제 개발을 하기 전에 설계를 할 때 보면 좋은 책입니다. 책 자체의 가독성은 딱 소프트웨어 설계 책 느낌입니다. 무난 무난합니다. 그림보다는 글 위주로 채워져 있습니다. 그림은 별로 없지만 글 자체가 굉장히 자세히 써져 있습니다. 아무래도 글 위주이다 보니 책 중간중간에 예제를 넣어서 이해를 하기 쉽게 만들어줬습니다. 예제를 보면서 흐름에 따라가면서 읽으면 책이 전달하고자 하는 내용을 잘 알 수 있습니다. 순서대로 어떻게 적용시켜야 되는지 알 수 있게 구성을 만들었습니다. 글로만 이해하기 어려운 부분은 그림도 넣

원문보기 내부링크
Naver Blog

SK Tech Summit 첫 번째 날 후기

11월 8일 ~ 9일 그랜드 워커힐 호텔에서 열리는 SK Tech Summit에 가봤다. https://sktechsummit.com/ SK TECH SUMMIT SK 그룹의 새로운 기술적 성취와 의미 있는 경험을 공유합니다. 지금 바로 등록하세요! sktechsummit.com 오랜만에 세미나도 가보고 싶어서 신청해 봤다. 워커힐 좋다.. 입구 들어가면 바로 등록하는 곳이 있다. 이쁜 전시회 이름 명찰이랑 기념품 준다. 여기도 이쁘다 워커힐 호텔 거의 다 쓰는 느낌 4층 임직원 전시는 휴게 공간 있고 조그맣게 전시공간 있다. 키노트 들으러 갔는데 들어가자마자 우와했다!! 엄청 좋다!! 사람들도 많이 있다! 동영상도 찍어보고.. 먹을거리도 있다.. 이거 맛있었다 합격 안내 로봇도 있는데 귀엽다 기념품에는.. 스티커랑 친환경(?) 물이다. ㅋㅋㅋㅋ 요거는 통역기! 키노트 발표자분 중에서 구글에서 일하시는 분도 있어서 통역기가 필요했다. 실시간으로 통역 되는 거 처음 들어보는데 통역사분

원문보기 내부링크
Naver Blog

11월 둘째 주

광나루역에 있는 탐앤 탐스 투썸인가? sk tech summit 갔다 왔다. 이건 썼으니 패스! 군자역 #이이요 저번에 가려다가 줄이 길어서 못 갔는데 tech summit 갔다가 혹시나 싶어서 가봤는데 다행히 줄 없어서 바로 먹었다. 이건 야끼돈부리 연어마끼.. 이이요 합격이다 합격!!! 우동까지 준다!!! 송파나루역 #피자네버슬립스 피자 먹고 싶어서 한 번 가봤다. 진짜 페퍼로니 존맛탱 무조건 더블 페퍼로니 먹어야 된다. 포테이토 피자는.. 음 엄청 맛있는 건 아니고.. 먹을만했다. #광장시장 종로3가역에 있는 광장시장 놀러 갔다 왔다. 이건 따로 포스팅 해야징 청계천도 걸었다. 아! "When it rains heavily, the path will be closed." 계단에 이렇게 적혀 있길래 순간 명언인 줄 알았는데 ㅎ 그냥 비가 내리면 산책로가 침수되어 출입을 통제한다는 의미였다. 머쓱 ㅎ DDP도 가보고.. 좀 구경했다. 오늘은 치킨 먹고 싶어서 치킨 먹었다. 올릴 사

원문보기 내부링크
Naver Blog

광장시장 나들이 (부촌육회, 박가네 빈대떡, 찹쌀꽈배기)

광장시장 서울특별시 종로구 창경궁로 88 종로 5가 역에 있는 광장시장에 갔다 왔다. 원래는 망원시장 가려다가 멀어서 중간에 급선회했다. 입구 딱 갔을 때 우와 했다. 천장에 걸려있는 국기도 이뻤고 음식이 엄청 많았다. 아주 돌아다니면서 계속 이곳저곳 보면서 침 삼켰다. 사람들이 다 술을 마시길래 왜 술을 마실까 0.75초 정도 고민하다가 바로 납득했다. 내가 간 곳은 육회로 미슐랭을 받은 #부촌육회 웨이팅이 좀 있어서 포기할까 하다가 이 정도는 기다릴 수 있을 것 같아서 기다렸다. 한 20분 정도 기다렸다. 매년 미슐랭 받은 게 신기하다 메뉴는 위와 같다. 보통 육회 + 육회 비빔밥 먹는 것 같다. 여기에 탕탕이 추가하거나,, 음식은 진짜 한 3분 안에 바로 나온다. 이건 육회 비빔밥 공깃밥이랑 소스까지 같이 준다. 진짜 존맛탱 미슐랭 받을만하다. 요건 육회 노른자 터트려서 배랑 같이 먹으면 맛있다. 사람들 다 술 마시길래 여기서도 한 0.25초 정도 고민하다가 역시 육회에는 술이

원문보기 내부링크
Naver Blog

[Spring] 트랜잭션 동기화

트랜잭션 동기화 Service에서 트랜잭션을 시작하기 위해 만든 Connection Object를 특별한 저장소에 보관해두고, 이후 호출되는 method에서는 저장된 Connection을 가져다가 사용하게 하는 방식 작업 스레드마다 독립적으로 Connection 오브젝트를 저장하고 관리하기에 다중 사용자를 처리하는 서버의 멀티 스레드 환경에서도 충돌이 날 염려가 없다. 흐름도 UserService는 Connection을 생성한다. Connection을 트랜잭션 동기화 저장소에 저장해고 Connection의 SetAutoCommit(false)를 호출해 트랜잭션을 시작시킨 후에 DAO 기능을 이용하기 시작 첫 번째 update() 메서드가 호출되고, update() 메서드 내부에서 이용하는 JdbcTemplate 메서드에서는 가장 먼저 트랜잭션 동기화 저장소에 현재 시작된 트랜잭션을 가진 Connection 오브젝트가 존재하는지 확인한다. 2번의 메서드 시작 부분에서 저장해둔 Conn

원문보기 내부링크
Naver Blog

11월 셋째 주

마라탕.. 엄청 맛있었던 게 있었다 베라.. 요즘 식비 아끼려고.. 쿠팡에서 사는 중 카레! 고등어! 오랜만에 먹는 일상다반 가격이 너무 올랐다 귀여운 고양이 ㅎ 미스터피자 방문포장 60% 할인! 더빛남 쌀국수! 웨이팅 없이 바로 갔다! 치이킨! 롯데몰 앞 트리 구경!! 트리 이쁘다! 롤렉스가 16530원 ㄷㄷ 하나 살까 하다가 내 갤럭시 워치가 더 비싸서 그냥 안 샀다 ㅎ 롯데몰에 있는 환장하는 레이싱.. 이쁘게 꾸몄다! 다꾸 스티커 파는 곳이 있어서 구경갔다 귀여운 거 많아서 몇 개 샀다! 귀엽 난 자취방이 넘 휑한 거 같아서 고양이로 샀다 고양이 스티커도.. 고양이로 유명 짤들 패러디 했다 ㅎ 당신은 몇 개를 알고 있나요~ 완전 귀엽다!! 카페도 갔다! 인스타 갬성 카페 에그타르트 맛있고 까놀레 맛있다 안에는 요렇게~ 캡틴! 미니언즈! 소원 이벤트 하길래 소원 적어서 우체통에! 요즘 목도리.. 아는 사람 결혼식 갔다. 멀어서 갈까 고민하다가 갔다. 친구들이랑~! 모자이크 처리를

원문보기 내부링크
Naver Blog

Test Double

Test Double 테스트를 진행하기 어려운 경우 테스트를 진행할 수 있도록 만들어주는 객체를 의미한다. 즉 테스트하려는 객체와 연관된 객체를 사용하기 어려울 때 연관된 객체를 대신해 줄 수 있는 객체를 테스트 더블이라고 한다. Dummy 가장 기본적인 테스트 더블 인스턴스화된 객체가 필요하지만 기능은 필요하지 않는 경우에만 사용한다. Dummy 객체의 메서드가 호출되었을 때 정상 동작은 보장하지 않는다. 객체는 전달되지만 사용하지 않는 객체. -> 동작하지 않아도 테스트에는 영향을 미치지 않는 객체를 Dummy 객체 Fake 원래 객체의 단순화된 버전 로직이나 객체 내부에서 필요로 하는 다른 외부 객체들의 동작을 간단히 구현한 객체 동작을 구현하기에 사용할 수는 있지만 실제로 사용할 수는 없다. 실제 객체와 동일한 역할을 하도록 만들어 사용하는 객체 Stub Dummy 객체가 실제로 동작하는 것처럼 보이게 만들어 놓은 객체이다. 인터페이스 또는 기본 클래스가 최소한으로 구현된 상

원문보기 내부링크
Naver Blog

템플릿 메서드 패턴

템플릿 메서드 패턴 상속을 통해 슈퍼 클래스의 기능을 확장할 때 사용하는 방법 변하지 않는 기능은 슈퍼 클래스에 만들어둔다. 자주 변경되고 확장할 기능은 서브 클래스에서 만든다. 슈퍼클래스에서는 미리 추상 메서드 또는 Override 가능한 메서드를 정의해두고 이를 활용해서 코드의 기본 알고리즘을 담고 있는 템플릿 메서드를 만든다. 슈퍼클래스에서 디폴트 기능을 정의해두거나 비워뒀다가 서브 클래스에서 선택적으로 오버라이드 할 수 있도록 만들어둔 메서드를 Hook 메서드라고 한다. 서브 클래스에서는 추상 메서드를 구현하거나, 훅 메서드를 오버라이드 하는 방법을 이용해 일부 확장한다. 먼저 SuperClass는 abstract class로 만든다. superMethod는 변하지 않는 기능이기에 super Class에서 구현해 준다. hookMethod는 기본 메서드로 구현을 한다. 이걸 SubClass가 다시 오버라이드 해서 재사용하면 된다. 또한 abstractMethod를 구현해서 S

원문보기 내부링크
Naver Blog

팩토리 메서드 패턴

팩토리 메서드 패턴 팩토리 메서드는 부모 클래스에서 객체를 생성할 수 있는 인터페이스를 제공하지만 자식 클래스들이 생성될 객체의 유형을 변경할 수 있도록 하는 생성 패턴이다. 부모 클래스에서는 서브 클래스에서 구현할 메서드를 호출해서 필요한 타입의 오브젝트를 가져와서 사용한다. 이 메서드는 주로 인터페이스 타입이기에 오브젝트를 리턴하므로 자식 클래스에서 어떤 클래스의 오브젝트를 만들어 리턴할지는 슈퍼 클래스에서는 알지 못한다. 즉 서브 클래스에서 오브젝트 생성 방법과 클래스를 결정할 수 있도록 미리 정의해둔 걸 팩토리 메서드라고 하고, 이 방식을 통해서 오브젝트 생성 방법을 나머지 로직, 즉 슈퍼클래스의 기본 코드에서 독립 시키는 방법을 팩토리 메서드 패턴이라고 한다. 구현 먼저 부모 클래스를 만든다. Sport를 상속받는 Soccer Sport를 상속받는 BaseBall를 만든다. 팩토리 메서드 패턴에서 사용할 SportFactory를 만들어준다. 그다음 SportFactory를

원문보기 내부링크
Naver Blog

전략 패턴

전략 패턴 자신의 기능 Context에서, 필요에 따라 변경이 필요한 알고리즘을 인터페이스를 통해 통째로 외부로 분리시키고 이를 구현한 구체적인 알고리즘 클래스를 필요에 따라 바꿔서 사용할 수 있게 해주는 디자인 패턴 여기서 알고리즘은 독립적인 책임으로 분리가 가능한 기능 디자인 패턴의 꽃이며,, 개방 폐쇄 원칙의 실현에도 가장 잘 들어 맞는다. Context는 Strategy의 메서드를 호출해서 사용하는 클래스이다. Strategy는 전략을 사용하기 위한 인터페이스 ConcreteStrategyA, B,C 는 : Strategy 인터페이스를 실제로 구현한 클래스. 구현 전략 패턴에서는 인터페이스를 이용해서 구현한다. 즉 인터페이스를 이용해서 각 전략에 맞게 사용할 수 있게 한다. AttackStrategy는 전략 패턴에서 Strategy이다. AttackStrategy를 구현한 CatAttackStrategy Cat은 ConcreteStrategy이다. DogAttackStrate

원문보기 내부링크
Naver Blog

Spring application context

Bean 스프링이 제어권을 가지고 직접 만들고 관계를 부여하는 오브젝트를 Bean이라고 부른다. Spring이 IoC 방식으로 관리하는 오브젝트 스프링이 직접 생성과 제어를 담당하는 오브젝트만을 Bean이라고 부른다. Spring Bean 스프링 컨테이너가 생성과 관계 설정, 사용 등을 제어해 주는 제어의 역전이 적용된 오브젝트 Bean Factory Spring의 IoC를 담당하는 핵심 컨테이너를 가리킨다. Bean을 등록, 생성, 조회하고 돌려준다. 또한 빈을 관리하는 기능을 담당한다. Spring에서는 Bean의 생성과 관계 설정 같은 제어를 담당하는 IoC 오브젝트를 Bean Factory라고 부른다. 보통은 Bean Factory를 좀 더 확장한 application context를 더 많이 사용한다. Application context Bean Factory를 확장한 IoC Container Bean을 등록하고 관리하는 기본적인 기능은 Bean Factory와 동일하다.

원문보기 내부링크
Naver Blog

11월 첫째 주

"블로그 챌린지 쉬는 주인 거 알고 있음" 예비군 갔다 왔다. 오랜만에 입어보는 전투복.. 자신감 급상승 예비군 갔는데 해병대 안 보여서 잘못 온 줄 알았다. 예비군 가서.. 수분 크림 3개 샀다.. 흑 더 살껄!!! 예비군은 4시간만 하고 끝났다!! 개이득!! 예비군 끝날 때쯤 누가 말 걸길래 봤는데 같은 해병대였다. 어디 과냐고 내가 물어봤는데 나랑 같은 산공과여서 얘기 많이 나눴다. 구글에서 후원 받으면서 창업하고 있는 아주 멋있는 사람이었다!! 공릉에 있는 지동 가봤다. 옛날에는 카페인 줄 알았는데 ㅋㅋㅋ 닭갈비 파는 곳~ 우삼밥~ 병원 갔다가 들린 김가네 김밥이랑~ 떡만둣국~ 군자역에서 공부하러 갔다. 뭐 먹을까 하다가 연어시장 있길래 또 갔다.. 장소 자체는 군자역이 좋은데 맛은 석계역이 더 좋다 먹고 스벅으로 공부하러 갔다. 잠실 롯백 디저트 팝업 스토에서 파는 벨라쿠키!! 카카오 맛인데 맛있다!! 고척에 한국 시리즈 3차전 보러 갔다!! 이태원 사건 이후로 경찰이랑 안

원문보기 내부링크
Naver Blog

10월 셋째 주

블챌 하면서 모은 스티커.. 모든창문 쫓아내자! 활짝열어 바이러스! 군자역에 있는 스터디카페에서 공부하다가 유가네 닭갈비 먹으러 왔다! 닭갈비 존맛탱 치즈도 맛있었다. 구일역에 야구 보러 가야 돼서 정말 오랜만에 출근했다. 점심으로 먹은 샐러드! 야구장 가기 전에 애플파이도 사 갔다! 고척 야구장! 2번째 방문! 아 야구장에서 많이 먹었는데 사진을 안 찍었다. 오징어 맛있다. 키움 vs KT 전 보러 갔다. 완전 노잼에 답답했다. 1회전에 KT한테 2점 내주고 그 뒤로 두 팀 다 득점 없이 게임 그대로 끝났다. 가을 야구 한 번 보러 가면 돈 많이 깨지는데 진짜 너무 노잼이라서 짜증 났다. 으이구!! 그 뒤로 더 짜증 나는 건 2경기 더 했는데 키움이 다 이겼다. 심지어 나 보러 간 그다음 날에는 아예 9점씩이나 내버려서 Kt 박살 내버렸다. 진짜 너무하다 키움 오랜만에 바른치킨 먹었다. 바른치킨 순살 존맛탱 포장해서 먹으면 뭔가.. 치킨이 퍽퍽한 살만 있었던 느낌이었는데 매장에서

원문보기 내부링크
Naver Blog

10월 마지막 주

스터디 카페에서 열심히 공부하는 중~ 왜 이렇게 돼지 같지 ㅎ 스터디 카페에서 공부하다가.. 오랜만에 라면이 먹고 싶어져서.. 라면 먹으러 갔다. 역시 라면은 존맛탱.. 저녁으로는 노브랜드 버거 도전해 봤다. 미안하다.. 롯데리아 하위 호환이다.. 미안.. 너는 누구니..? 족제비..? 엔티엔즈 사서 집에서 먹었다. 내 최애 디저트 우오아!!! 키움 LG 2차전 보러 갔다!!! 잠실이라서 그런지 사람 엄청 많았다. 특히 LG 팬들 진짜 많다. 나는 다행히 키움 응원석이라서.. 주변에 LG가 거의 없어서 좋았다. 진짜 압도적으로 이길 줄 알았는데 7 대 6까지 따라 잡힌 거 보고 엄청 조마조마했는데 마지막 LG의 고마운 병살타~~ 이때 분위기 엄청났다.. 역시 스포츠는!!! 직관을 해야 돼!! ㅎㅎ 이 뒤에도.. 키움이 LG 계속 이겨서 결승 갑니다~ 내 최애 동영상.. 잠실구장에서 울려펴지는 응원가.. 경기할 때 부르는 것보다 나갈 때 부르는 게 더 재밌었다. 야구장에서.. KFC,

원문보기 내부링크
Naver Blog

안국역 나들이

안국역 주변.. 확실히 이쁘다. 공릉에서 살다가 여기로 가보니 완전히 다른 세상 느낌~ 나왔을 때의 분위기부터 다르다~ 꽃이 꽃을 찍는 중 ~ 꽃이 꽃을 찍는 중 ~ (2) 먼저 국립현대미술관 갔다.. 휴.. 다행히!!!!! 아직 대학생이라서!!!! 무료로 볼 수 있었다..!!!!!! 요즘 핫한 전시물.. 인스타를 한다면 한 번쯤은 봤을거다. 진짜 공 한 번도 안 떨어진다. 처음에는 공만 보다가 나중에는 밑에서 받쳐주는 사람 봤는데 뭔가.. 굉장히 고통스러워 보였다. 이건 뭔지 모르겠지만 이쁘다. 요건 무한한 공간이다.. 진짜 신기하다 ㅎ 방주를 나타낸 거라는데!! 30분마다 한 번씩 움직여서 구경해 봤다. 뭘 나타내려는 걸까.. 나는 개발자라서 그런지.. 과연 이걸 어떻게 구현했을까.. 밖에 생각이 안 든다. 앞에서 보면.. 뭔가 거미 같다 이거 실제로 보면 이쁘다. 집에 가져갈 뻔~ 붉은색 무언가.. 차 전등 가져와서 만든 것.. 오우 .. 실제로 보면 좀 무섭다. 엄청 큰 얼굴

원문보기 내부링크
Naver Blog

[1년 전 오늘] 9만이다

2021.11.2. 1년 전 오늘 9만이다 어느새 9만을 넘겨버렸다! 이번 연도안에 10만 가는게 목표인데 과연 갈 수 있을까.. 두 달 남았으니 하루에 될 것 같기도하고 아슬아슬하게 안될 것 같기도 하고ㅋㅋㅋㅠ 류리상자 엇 지금은 17만이다.. 1년만에 8만이 증가했네.. 빠르다!! 20만 가자!!

원문보기 내부링크
Naver Blog

Junit 5 Annotation 정리

BeforeAll, BeforeEach, AfterAll, AfterEach, Disabled beforeAll, AfterAll은 모든 테스트를 실행할 때 각각 한 번씩만 수행됨 static으로 선언해야 됨 afterEach, beforeEach는 각각의 테스트가 실행이 될 때 수행됨 Disabled는 테스트를 사용하지 않을 때 @DisplayName, @DisplayNameGeneration 기본적으로는 메서드 이름이 테스트 이름이 됨 @DisplayName으로 테스트 이름을 만들 수 있음 -> 보통 이거 사용 충분 Assertion assertEquals -> 실패했을 때 메시지도 적을 수 있음 첫 번째 기댓값, 두 번째 실제 값, 세 번째 실패했을 때 메시지 메시지는 Suppler 이용해서 메시지 작성 가능 람다식으로 만들면 딱 필요한 시점에만 하기에 더 효율적임 람다식으로 안 만들면 성공/실패에 상관없이 메시지를 실행 assertTrue assertAll -> 모든 테스트를

원문보기 내부링크
Naver Blog

Mockito 정리

Mockito Mock : 진짜 객체와 비슷하게 동작하지만 프로그래머가 직접 그 객체의 행동을 관리하는 객체 Mockito : Mock 객체를 쉽게 만들고 관리하고 검증할 수 있는 방법을 제공한다. 과연 모든 걸 Mocking 해야될까? 이미 프로덕션 코드가 있는데 그걸 Mock으로 해야될까? 유닛 테스트가 어디까지일까를 생각해보자. 철저히 Mock을 이용해서 의존성을 다 끊고 메서드 한 개만을 테스트 해야될까? 연관된 행동을 하는 객체들을 하나로 묶어서 이걸 유닛테스트로 보고 테스트를 해야될까? Mock 활용 테스트 Mock을 만드는 방법 Mock이 어떻게 동작해야 하는지 관리하는 방법 Mock의 행동을 검증하는 방법 위의 3가지를 알면 테스트를 쉽게 작성할 수 있다. Mock 없는 경우 Mock StudyRepository studyRepository = Mockito.mock(StudyRepository.class); 2. Mock Annotation 을 사용할 수 있다. @M

원문보기 내부링크
Naver Blog

when().thenReturn 과 doReturn().when()

아무리 봐도 똑같은 메서드인데 왜 두 개나 있을까 싶어서 찾아봤다. when().thenReturn() Strict Mode when.thenReturn은 메서드를 실제 호출하고 mock 객체 리턴 값 반환 그렇기에 메서드 작업이 오래 걸릴 경우 끝날 때까지 기다려야 함 또한 실제 메서드를 호출하기에 해당 메서드에 문제가 생기면 발견할 수 있다. doReturn().when() Lateinit Mode doReturn.when.method는 실제 메서드를 호출하지 않고 mock 객체 리턴 값 반환 실제 메서드를 호출하지 않기에 메서드가 문제가 생겨도 알 수가 없다. 뭘 쓸까? 찾아보니 대부분의 경우 when.thenReturn을 쓰고 이게 가독성이 더 좋다고 한다. 하지만 void형을 test 할 때는 doReturn을 써야 된다. 위와 같은 InterFace가 있고 이 인터페이스의 리턴 값이 void인 Work 메서드를 테스트한다고 해보면 위와 같이 when.then은 컴파일 에러

원문보기 내부링크
Naver Blog

10월 1주 차

제일 가지고 싶었던.. 별 수호자 징크스가 떴다.. 징크스.. 스킨 거의 다 모아간다. 일~월요일 부산 갔다. 이거에 대한 포스팅은 따로 해야지 바로 부산 락페스티벌!! 야후~~~ 인생 첫 락페스티벌인데 굉장히 만족스럽게 즐겼다.. 물론 이번 락페는 좀 운영적 미숙함, 공연 중단, 자원봉사자 태도, 단수.. 등 뭐가 문제가 많았는데 난 그냥 재밌게 즐겼다. 최근에 다리가 계속 저려서 신경외과에 가보니 허리에 문제가 생겼다고 한다. 허리 디스크일까 봐 엄청 걱정했는데 다행히 그건 아닌 것 같고.. 확실한 건 이제 관리를 해야 된다는 거다. 그래서 허리에 좋다는 장비들 다 구매하고.. 척추의 신! 정선근 Tv 도 보면서 허리 잘 관리한다. 병원 갔다 온 이후로 완전 바른 자세로만 살고 있다. 헬스도 바로 등록했다. 허리에 무리 가지 않게 조심하면서 할 거다. 붕어방에는 다양한 동물들이 산다.. 대따 큰 왜가리도 산다. 하늘이 이뻐서 인스타 갬성으로 한 번 찍어봤다. 갬성 아니면 말구~

원문보기 내부링크
Naver Blog

실전! 스프링 데이터 JPA 완강 후기

인프런 김영한 강사의 실전! 스프링 데이터 JPA 강의 이름 그대로 spring data jpa 가르쳐준다. CRUD 사용법, JPA -> Spring data jpa 넘어가는 과정 spring data Jpa의 여러 가지 기능들, jpa의 영속성 개념들에 대해서 알려준다. 나는 이미 spring data jpa을 좀 사용해 봐서 모든 내용이 새롭지는 않았지만 들으면서 몇몇 기능들은 처음 보는 거라서 유용하게 배웠고 flush, proxy, 영속성 개념 다시 정립할 수 있었다. spring data jpa을 배우고 싶으면 들으면 좋다. 다만 jpa를 한 번도 안 해봤으면 약간 어려울 수도..?

원문보기 내부링크
Naver Blog

[공릉] 경성초밥 갔다 옴

경성초밥 서울특별시 노원구 공릉로 119-5 초밥이 먹고 싶어서 어디 갈까 고민하다가 공릉에 있는 스시쟁이, 로지스시는 가봐서 이번에는 경성초밥 가봤다. 공릉경성초밥이지만 태릉입구역에서 더 가까울 것 같다. 나는 운 좋게 웨이팅 없었다. 내부는 그렇게 크지 않다. 음.. 다만 약간 아쉬운 게 있다면 가격이 비싸다 ㅎ 초밥을 시켰을 때 우동이나 간단한 스끼다시라도 주면 좋을 것 같긴 하다. 모둠초밥 20000원, 특초밥 28000원이다. 모둠초밥이랑 특초밥 시켰다. 초밥은 맛있다. 공릉에서 먹은 초밥 중에서 제일 맛있는 것 같긴 하다. 특초밥 구성은 사진과 같다. 가면 계란찜 준다. 나는 초밥이 한 번에 다 나올 줄 알았는데 오마카세 느낌으로 준다.. 광어! 도미뱃살 존맛탱 연어는.. 뭐 당연히 맛있다. 광어 지느러미.. 새우장! 나는 새우가 맛있다.. 참다랑어 생각보다 크다! 도미! 관자! 장어 성게알! 전복! 이것도 생각보다 크다. 다른 곳에 비해서 맛있긴 하다 확실히,, 회도 크

원문보기 내부링크
Naver Blog

[공릉] 웅파이 갔다 옴

웅파이 공릉숲길점 서울특별시 노원구 동일로182길 63-1 1층 공릉 철길에 있는 웅파이 EUNPIE! 가게만 보면 미국 느낌 난다. 메뉴는 다음과 같다. 이미 만들어져 있기에 가서 주문하면 바로 나온다. 내부는 다음과 같다. 그렇게 크지 않다! 아기자기한 미국 식당 느낌 나는 비프 파이랑 양송이 파이 먹었다. 양송이 파이는 진짜 양송이 수프 맛이고 비프는.. 음.. 케첩이 곁들어진 비프 느낌 맛있다. 파이 먹고 싶으면 갈만한 것 같다.

원문보기 내부링크
Naver Blog

10월 둘째 주

산책 겸 철길 걷다가 발견한 플리마켓 노원 걷기 대회랑 같이 한 것 같다. 내 자취방은 우풍이 굉장히 심하고.. 보일러가 없는 것과 다름 없기에.. 난방텐트를 사봤다.. 사진 꺼보다 돈 2배 더 주고 좋은 걸로 샀다. 오랜만에 쭈꾸미 먹으러 갔다.. 역시.. 내 최애 쭈꾸미.. 언제 먹어도 맛있다. 치즈폭탄 계란찜!! 집에 커튼이 있지만 달기 귀찮아서 다이소에서 5천원 주고 간단히 설치할 수 있는 블라인드 샀다. 나는 갠적으로 굉장히 만족한다. 암막 기능은 없지만 어쨌든 밤에 더 어둡고 아침에도 햇빛을 어느정도 막아줘서 좋다. 뭐 붙이는 암막 시트도 있다고 하는 데 이러면 아예 햇빛을 못 볼 것 같아서 안 샀다. 아침에는 요렇다. 적당히 햇빛 들어오고 좋다. 산책하다가 소방차랑 경찰차가 많아서 뭐지 싶었다. 네코정쪽에서 연기가 나길래 불 난 줄 알았는데 친구말로는 아니었다고 한다. 뭐지!? 낭만 한강.. 회식 가다가 한강 나오길래 쓱 봤는데 너무 이뻐서 바로 찍었다. #일일향 나의

원문보기 내부링크
Naver Blog

어린이 대공원 가봄

인생 처음으로 가본 어린이 대공원.. 어른이라서 못 들어가면 어쩌지 했는데 다행히 들어갈 수 있었다^^ 날씨 좋군요~ 어린이 대공원답게.. 대부분 가족 단위이다. 가장 먼저 보이는 수목원으로 들어갔다.. 쓱쓱 보고 나왔다.. 어린이 대공원은 보이는 곳 아무 곳이나 들어가 보면 다 동물이 있다.. 미어캣!! 옆모습.. 어떤 미어캣은.. 유리 가까이 와서 망 보고 그랬다.. 눈 감은 수달!!!!! 사막 여우.. 이때 갔을 때 잠시 .. 사막 여우 집에 떨어진 밤송이 치우느라.. 사람 들어가 있어서 사막 여우들이 안으로 들어가 있었다. 요것은.. 제주 말인가..! 얘네 둘은 계속 이러고만 있었다.. 개코원숭이 저기서 뛰어서 넘어오면 어쩌나 했는데 사이에 보면 절벽(?) 같은 게 있다. 원로해보이는 원숭이.. 긴팔원숭이.. 실제로 보면 좀 무섭다 지능이 엄청 높은 원숭이라고 하는데.. 뭔가 사람이 원숭이를 보는 게 아니라 원숭이가 사람을 구경하는 느낌이 들었다.. 코끼리도 보고.. 코끼리

원문보기 내부링크
Naver Blog

[여의도] 여의도 불꽃 축제 갔다 옴

2022년 10월 8일 3년 만에 열린 여의도 불꽃 축제 갔다 왔다. 일본, 이탈리아, 한화순으로 했는데 (대한민국이라고 쓰는 건 한화한테 실례다) 한화 압도적이다.. 3년간 모은 원기옥 터트렸다.. 당연히 여의도 주변에서 밥을 먹는 건 힘들 거라고 생각해서 상왕십리에서 밥 먹었다. 슬로우 캘리 먹으려다가 ㅎ 가는 길에 누구나 홀딱 반한 닭이 있길래 자연스럽게 들어갔다ㅋㅋㅋㅋㅋㅋ 바베큐 존맛탱 소스 존맛탱 감자튀김 존맛탱 왕십리로 가서 5호선 타고 갔다. 지하철 자체에 사람 엄청 많을 줄 알았는데 생각보다 없어서 띠용했다. 출퇴근 지옥철이 훨씬 힘든 느낌 마포에서 많이 내리기도 했다. 여의나루역에서 나오니 사람들이 쏟아져 나오긴 했는데 내가 생각했던 것보다는 적었다. 나는 아예 사람들 사이에 엄청 낑겨서 물 흐르듯이 갈 줄 알았는데 그냥 자연스럽게 걸어갔다. 여의나루역.. 너무 깊다!! 3번 출구로 나왔는데 사람 많았다. 2016년에 탄핵 집회하러 갔을 때의 느낌 물론 그때보단 적었

원문보기 내부링크
Naver Blog

[Refactoring] 내부자 거래

내부자 거래 어떤 모듈이 다른 모듈의 내부 정보를 지나치게 많이 알고 있는 코드 냄새, 그로 인해 지나치게 강한 결합도가 생길 수 있다. 적절한 모듈로 함수 옮기기와 필드 옮기기를 사용해서 결합도를 낮출 수 있다. 여러 모듈이 자주 사용하는 공통적인 기능은 새로운 모듈을 만들어 잘 관리하거나, 위임 숨기기를 사용해 특정 모듈의 중재자처럼 사용할 수도 있다. 상속으로 인한 결합도를 줄일 때는 슈퍼 클래스 또는 서브 클래스를 위임하는 방법을 사용할 수 있다. public class Ticket { private LocalDate purchasedDate; private boolean prime; public Ticket(LocalDate purchasedDate, boolean prime) { this.purchasedDate = purchasedDate; this.prime = prime; } public LocalDate getPurchasedDate() { return purcha

원문보기 내부링크
Naver Blog

[Refactoring] 슈퍼 클래스 추출하기

거대한 클래스 어떤 클래스가 너무 많은 일을 하다 보면 필드도 많아지고 중복 코드도 보이기 시작한다. 클라이언트가 해당 클래스가 제공하는 기능 중에 일부만 사용한다면 각각의 세부 기능을 별도의 클래스로 분리할 수 있다. 클래스 추출하기를 사용해 관련 있는 필드를 한곳으로 모을 수 있다. 상속 구조를 만들 수 있다면 슈퍼 클래스 추출하기 또는 타입 코드를 서브 클래스로 교체하기를 적용할 수 있다. 클래스 내부에 산재하는 중복 코드는 메서드를 추출해서 제거할 수 있다. 슈퍼클래스 추출하기 두 개의 클래스에서 비슷한 것들이 보인다면 상속을 적용하고, 슈퍼클래스로 필드 올리기와 메서드 올리기를 사용한다. 대안으로는 클래스 추출하기를 적용해 위임을 사용할 수 있다. 우선은 간단히 상속을 적용한 이후, 나중에 필요하다면 슈퍼 클래스를 위임으로 교체하기를 적용한다. public class Department { private String name; private List<Employee> sta

원문보기 내부링크
Naver Blog

[Refactoring] 서로 다른 인터페이스의 대안 클래스들

비슷한 일을 여러 곳에서 서로 다른 규약을 사용해 지원하고 있는 코드 냄새 대안 클래스로 사용하려면 동일한 인터페이스를 구현하고 있어야 한다. 함수 선언 변경하기와 함수 옮기기를 사용해서 서로 동일한 인터페이스를 구현하게끔 코드를 수정할 수 있다. 두 클래스에서 일부 코드가 중복되는 경우에는 슈퍼클래스 추출하기를 사용해 중복된 코드를 슈퍼클래스로 옮기고 두 클래스를 새로운 슈퍼클래스의 서브 클래스로 만들 수 있다. 서로 다른 인터페이스의 대안 클래스들 public class OrderProcessor { private EmailService emailService; public void notifyShipping(Shipping shipping) { EmailMessage emailMessage = new EmailMessage(); emailMessage.setTitle(shipping.getOrder() + " is shipped"); emailMessage.setTo(shipp

원문보기 내부링크
Naver Blog

[Refactoring] 레코드 캡슐화하기

데이터 클래스 데이터 클래스 : Public 필드 또는 필드에 대한 getter와 Setter만 있는 클래스 코드가 적절한 위치에 있지 않기 때문에 이러한 냄새가 생길 수 있다. 예외적으로 단계 쪼개기에서 중간 데이터를 표현하는 데 사용할 레코드는 불변 객체로 데이터를 전달하는 용도로 사용할 수 있다. public field를 가지고 있다면 레코드 캡슐화하기를 사용해 getter or setter를 통해서 접근하도록 고칠 수 있다. 변경되지 않아야 할 필드에어는 세터 제거하기를 적용할 수 있다. getter와 setter가 사용되는 메서드를 찾아보고 함수 옮기기를 사용해서 데이터 클래스로 옮길 수 있다. 메서드 전체가 아니라 일부 코드만 옮겨야 한다면 함수 추출하기를 선행해서 옮길 수 있다. 레코드 캡슐화하기 변하는 데이터를 다룰 때는 레코드보다는 객체를 선호한다. 여기서 레코드란 public field로 구성된 데이터 클래스를 말한다. 데이터를 메서드 뒤로 감추면 객체의 클라이언트

원문보기 내부링크
Naver Blog

[Refactoring] 상속 포기

상속 포기 서브 클래스가 슈퍼클래스에서 제공하는 메소드나 데이터를 잘 활용하지 않는다는 것은 해당 상속 구조에 문제가 있다는 뜻이다. 기존의 서브 클래스 또는 새로운 서브클래스를 만들고 슈퍼클래스에서 메소드와 필드 내려주면 슈퍼 클래스에 공동으로 사용하는 기능만 남길 수 있다. 서브 클래스가 슈퍼클래스의 기능을 재사용하고 싶지만 인터페이스를 따르고 싶지 않은 경우에는 슈퍼클래스 또는 서브클래스를 위임으로 교체하기 리팩토링을 적용할 수 있다. 아주 심각한 코드는 아니다. 간단하게 리팩토링을 할 수 있다. public class Employee { protected Quota quota; protected Quota getQuota() { return new Quota(); } } Employ가 부모 클래스이다. public class Salesman extends Employee {} 간단하다 Quota가 클래스가 Saleman에서 많이 사용되고 있으면 Saleman으로 내린다. pu

원문보기 내부링크
Naver Blog

[Refactoring] 어서션 추가하기

어서션 추가하기 당연히 이 값이 있을 것이다라고 생각할 때 사용 종종 코드로 표현하지 않았지만 기본적으로 가정하고 있는 조건들이 있다. 그런 조건을 알고리즘으로 파악하거나 주석을 읽으면서 확인할 수 있다. 그러한 조건을 Assertion을 사용해서 보다 명시적으로 나타낼 수 있다. Assertion은 If나 switch문과 달리 항상 true이길 기대하는 조건을 표현할 때 사용한다. 프로그램이 Assertion에서 실패한다면 프로그래머의 실수로 생각할 수 있다. Assertion이 없어도 프로그램이 동작해야 한다. (자바에서는 컴파일 옵션으로 assert 문을 사용하지 않도록 할 수 있다. 특정 부분에선 특정한 상태를 가정하고 있다는 것을 명시적으로 나타냄으로써 의사소통적인 가치를 지니고 있다. package me.whiteship.refactoring._24_comments._43_introduce_assertion; public class Customer { private Dou

원문보기 내부링크
Naver Blog

인프런 코딩으로 학습하는 리팩토링 강의 완강

9월 14일부터 10월 6일까지 해서 강의 완강 제대로 들은 건 9월 26일부터.. 이 강의는 마틴 파울러의 리팩토링 2판 강의를 자바로 설명해 주는 강의이다. 자바 백엔드 개발자라면 필수다.. 정말 정말 필수다!! 특히 혼자 공부하는 사람들, 개발 경험이 별로 없는 사람들, 개발자 준비하는 사람들, 취준생, 대학생, 신입, 주니어 코드 리뷰를 어떻게 해야 될지 모르겠는 사람들한테 강추다!! 그냥 무조건 듣자!! 리팩토링에 대한 정말 많은 케이스들을 알려주면서 그걸 코드로 다 보여준다. 나는 이 강의를 들으면서 많이 배웠다. 어떻게 코드를 작성해야 되는지 어느 정도 감을 잡을 수 있게 되었다. 이 강의 들으면서 코드 리뷰도 한 번 해봤는데 전보다 확실히 시야가 넓어진 것 같다. 계속 복습하고 실제 코드에 적용하면서 체화할 수 있도록 노력해야겠다!

원문보기 내부링크
Naver Blog

[Refactoring] 반복문을 파이프라인으로 바꾸기

최근에는 반복문에 비해서 더 나은 대안책이 생겼다. 반복문을 파이프라인으로 바꾸는 리팩토링을 적용하면 필터나 맵핑과 같은 파이프라인 기능을 사용해서 보다 빠르게 어떤 작업을 하는 지 파악할 수 있다. 반복문을 파이프라인으로 바꾸기 컬렉션 파이프라인(자바의 Stream) 고전적인 반복문을 파이프라인 오퍼레이션을 사용해 표현하면 코드를 더 명확하게 만들 수 있다. 필터 : 전달받은 조건의 true에 해당하는 데이터만 다음 오퍼레이션으로 전달 맵 : 전달 받은 함수를 사용해 입력 값을 원하는 출력값으로 변환해서 다음 오퍼레이션으로 전달 public class Author { private String company; private String twitterHandle; public Author(String company, String twitterHandle) { this.company = company; this.twitterHandle = twitterHandle; } static p

원문보기 내부링크
Naver Blog

[Refactoring] 계층 합치기

성의없는 요소 여러 프로그래밍적인 요소를 만드는 이유 나중에 발생할 변화를 대비해서 해당 함수 또는 클래스를 재사용하려고 의미있는 이름을 지어주려고 가끔 그렇게 예상하고 만들어 놓은 요소들이 기대에 부응하지 못 하는 경우가 있는데 그런 경우에 해당 요소들을 제거해야 한다. 관련 리팩토링 기술 함수 인라인 클래스 인라인 불필요한 상속 구조는 계층 합치기를 사용할 수 있다. 그냥 필요없는 요소들 계층 합치기 상속 구조를 리팩토링 하는 중에 기능을 올리고 내리다 보면 하위 클래스와 상위 클래스 코드에 차이가 없는 경우가 발생할 수 있다. 그런 경우에 그 둘을 합칠 수 있다. 하위 클래스와 상위 클래스 중에 어떤 것을 없애야 하는가? 둘 중에 보다 이름이 적은 적절한 쪽을 선택하지만, 애매하다면 어느쪽을 선택해도 문제 없다. public class Reservation { private LocalDateTime startDateTime; private LocalDateTime endDate

원문보기 내부링크
Naver Blog

[Refactoring] 죽은 코드 제거하기

추측성 일반화 나중에 필요할 것 같아서 만들었지만 결국에는 쓰이지 않는 코드가 발생한 경우 죽은 코드 제거하기 사용하지 않는 코드가 애플리케이션 성능이나 기능에 영향을 끼치지는 않는다. 하지만, 해당 소프트웨어가 어떻게 동작하는지 이해하려는 사람들에게는 꽤 고통을 줄 수 있다. 실제로 나중에 필요해질 코드라 하더라도 지금 쓰이지 않는 코드라면 삭제해야 한다. 나중에 정말로 다시 필요해진다면 git과 같은 버전 관리 시스템을 사용해 복원할 수 있다. 정리 출처 : 코딩으로 학습하는 리팩토링 - 백기선

원문보기 내부링크
Naver Blog

[Refactoring] 특이 케이스 추가하기

임시 필드 클래스에 있는 어떤 필드가 특정한 경우에만 값을 갖는 경우 어떤 객체의 필드가 특정한 경우에만 값을 가진다는 것을 이해하는 것은 일반적으로 예상하지 못하기에 이해하기 어렵다. null, empty 등 관련 리팩토링 클래스 추출하기를 사용해서 해당 변수들을 옮길 수 있다. 함수 옮기기를 사용해서 해당 변수를 사용하는 함수를 특정 클래스로 옮길 수 있다. 특이 케이스 추가하기를 적용해 특정한 경우 해당하는 클래스를 만들어 해당 조건을 제거할 수 있다. 특이 케이스 추가하기 어떤 필드의 특정한 값에 따라 동일하게 동작하는 코드가 반복적으로 나타난다면, 해당 필드를 감싸는 특별한 케이스를 만들어 해당 조건을 표현할 수 있다. 이러한 메커니즘을 특이 케이스 패턴이라고 부르고 Null Object 패턴을 이러한 패턴의 특수한 형태라고 볼 수 있다. package me.whiteship.refactoring._16_temporary_field._36_introduce_special_c

원문보기 내부링크
Naver Blog

[Refactoring] 위임 숨기기

메시지 체인 레퍼런스를 따라 계속해서 메소드 호출이 이어지는 코드이다. 예) this.member.getCredit().getLevel().getDescription() 해당 코드의 클라이언트가 코드 체인을 모두 이해해야 한다. 체인 중 일부가 변경된다면 클라이언트의 코드도 변경해야 한다. 관련 리팩토링 위임 숨기기를 사용해 메시지 체인을 캡슐화를 할 수 있다. 함수 추출하기로 메시지 체인 일부를 함수로 추출한 뒤 함수 옮기기로 해당 함수를 적절한 곳으로 이동할 수 있다. 위임 숨기기 캡술화란 어떤 모듈이 시스템의 다른 모듈을 최소한으로 알아야한다는 것이다. 그래야 어떤 모듈을 변경할 때, 최소한의 모듈만 그 변경에 영향을 받을 것이고, 그래야 무언가를 변경하기 쉽다. 처음 객체 지향에서 캡슐화를 배울 때 필드를 메소드로 숨기는 것이라 배우지만, 메소드 호출도 숨길 수 있다. person.department().manager() -> person.getManager() 이전의 코드는

원문보기 내부링크
Naver Blog

[Refactoring] 중재자 제거하기

위임 숨기기의 반대에 해당하는 리팩토링 무조건 캡슐화는 옳지 않다!! 필요한 캡슐화의 정도는 시간에 따라 그리고 상황에 따라 바뀔 수 있다. 캡슐화의 정도를 중재자 제거하기와 위임 숨기기 리팩토링을 통해 조절할 수 있다. 위임하고 있는 객체를 클라이언트가 사용할 수 있도록 getter를 제공하고, 클라이언트는 메시지 체인을 사용하도록 코드를 고친 뒤에 캡슐화에 사용했던 메서드를 제거한다. Low of Demeter를 지나치게 따르기보다는 상황에 맞게 활용하도록 하자. 디미터의 법칙, 가장 가까운 객체만 사용한다. 중재자 제거하기 public class Department { private Person manager; public Department(Person manager) { this.manager = manager; } public Person getManager() { return manager; } } Department class public class Person { p

원문보기 내부링크
Naver Blog

[Refactoring] 슈퍼클래스를 위임으로 바꾸기

객체지향에서 상속은 기존의 기능을 재사용하는 쉬우면서 강력한 방법이지만 때로는 적절하지 않은 경우도 있다. 서브 클래스는 슈퍼클래스의 모든 기능을 지원해야 한다. stack이라는 자료 구조를 만들 때 List를 상속받는 것이 좋을까? 서브 클래스는 슈퍼클래스 자리를 대체하더라도 잘 동작해야 한다. 리스코프 치환 원칙 서브 클래스는 슈퍼클래스의 변경에 취약하다. 그렇다면 상속을 사용하지 않는 것이 좋은가? 상속은 적절한 경우에 사용한다면 매우 쉽고 효율적인 방법 따라서 우선 상속을 적용한 이후에 적절치 않다고 판단이 된다면 그때 리팩토링을 적용하자. 슈퍼클래스를 위임으로 바꾸기 public class CategoryItem { private Integer id; private String title; private List<String> tags; public CategoryItem(Integer id, String title, List<String> tags) { this.id =

원문보기 내부링크
Naver Blog

[Refactoring] 기능 편애

어떤 모듈에 있는 함수가 다른 모듈에 있는 데이터나 함수를 더 많이 참조하는 경우에 발생한다. 예) 다른 객체의 getter를 여러 개 사용하는 메서드 관련 리팩토링은 다음과 같다. 다른 모듈에 있는 걸 많이 참조한다면 위치가 잘못된 것이기에 함수 옮기기를 통해서 적절한 위치로 옮긴다. 함수의 일부분만 다른 곳의 데이터와 함수를 많이 참조한다면 함수 추출하기로 함수를 나눈 다음에 함수를 옮길 수 있다. 만약에 여러 모듈을 참조하고 있다면, 그중에서 가장 많은 데이터를 참조하는 곳으로 옮기거나, 함수를 여러 개로 쪼개서 각 모듈로 분산 시킬 수도 있다. 데이터와 해당 데이터를 참조하는 행동을 같은 곳에 두도록 하자. 기능 편애 package me.whiteship.refactoring._09_feature_envy; public class Bill { private ElectricityUsage electricityUsage; private GasUsage gasUsage; publi

원문보기 내부링크
Naver Blog

[Refactoring] 데이터 뭉치

항상 뭉쳐 다니는 데이터는 한곳으로 모아두는 것이 좋다. 여러 클래스에 존재하는 비슷한 필드 목록 여러 함수에 전달하는 매개변수 목록 관련 리팩토링 기술 클래스 추출하기를 통해서 여러 필드를 하나의 객체나 클래스로 모을 수 있다. 매개변수 객체 만들기 또는 객체 통째로 넘기기를 사용해서 메서드 매개변수를 개선할 수 있다. 데이터 뭉치 public class Employee { private String name; private String personalAreaCode; private String personalNumber; public Employee(String name, String personalAreaCode, String personalNumber) { this.name = name; this.personalAreaCode = personalAreaCode; this.personalNumber = personalNumber; } public String personalPh

원문보기 내부링크
Naver Blog

[JPA] saveall 사용 시 주의사항

문제점 테스트 코드를 짜던 도중.. 며칠 동안 내가 예상한 결과랑 다르게 나오는 상황이 발행했다. 처음에는 내가 쿼리를 잘못짠 줄 알았지만 아니었고 그다음에는 혹시 자료형 때문인가 싶었는데 아니었다. 그렇게 문득 든 생각이 혹시 데이터가 잘못 들어간건가라는 생각이 들었다. 그래서 지금 db에서 확인을 해보았고 원래대로라면 90개가 들어야가야 되는데 단 10개 밖에 들어가지가 않았다. 뭔가 문제일까 싶어서 로그를 보다가... 내가 생각했을 때는 saveall를 했으면 insert into 쿼리만 나와야되는데 보니까 select 쿼리도 나가고 update 쿼리도 나가는거였다. select 쿼리는 뭐 db에 저장하는 거랑은 상관없긴 했는데 select가 일어나는 것 자체가 쿼리를 더 날리는 거니 이것도 문제이고 update 쿼리는 왜 나가는지도 모르겠고 딱 봐도 insert 대신 update가 발생해서 9개 밖에 저장이 안되는 것 같았다. 바로 saveall 관련해서 구글링을 해보았다.

원문보기 내부링크
Naver Blog

[Refactoring] 기본형을 객체로 바꾸기

기본형 집착 애플리케이션에서 다루고 있는 도메인에 필요한 기본 타입을 만들지 않고 프로그래밍 언어가 제공하는 기본 타입을 사용하는 경우가 많다. 예) 전화번호, 좌표, 돈, 범위, 수량 원시 타입 (int, boolean, double) 등을 사용하면 기능을 만들기 어렵다. 기본형으로 단위 또는 표기법을 표현하기 어렵다. 관련 리팩토링 기술 기본형을 객체로 바꾸기 타입 코드를 서브 클래스로 바꾸기 조건부 로직을 다형성으로 바꾸기 클래스 추출하기 매개변수 객체 만들기 기본형을 객체로 바꾸기 개발 초기에는 기본형으로 표현한 데이터가 나중에는 해당 데이터와 관련 있는 다양한 기능을 필요로 하는 경우가 발생한다. 예) 문자열로 표현하던 전화번호의 지역 코드가 필요하거나 다양한 포맷을 지원하는 경우 예) 숫자로 표현하던 온도의 단위를 변환하는 경우 기본형을 사용할 데이터를 감싸줄 클래스를 만들면 필요한 기능을 추가할 수 있다. public class Order { private String

원문보기 내부링크
Naver Blog

[Refactoring] 단계 쪼개기

서로 다른 일을 하는 코드를 각기 다른 모듈로 분리한다. 어떤 것을 변경해야 할 때, 그것과 관련 있는 것만 신경 쓸 수 있다. 여러 일을 하는 함수의 처리 과정을 각기 다른 단계로 구분할 수 있다. 전처리 -> 주요 작업 -> 후처리 컴파일러 -> 테스트 읽어오기 -> 실행 가능한 형태로 변경 서로 다른 데이터를 사용한다면 단계를 나누는 데 있어 중요한 단서가 될 수 있다. 중간 데이터를 만들어 단계를 구분하고 매개변수를 줄이는데 활용할 수 있다. 데이터를 기반으로 구별하자!!! 데이터를 기반으로 프로세스를 쪼개자. 단계 쪼개기 public class PriceOrder { public double priceOrder(Product product, int quantity, ShippingMethod shippingMethod) { final PriceData priceData = getPriceData(product, quantity); return applyShipping(pri

원문보기 내부링크
Naver Blog

[Refactoring] 함수 옮기기

모듈화가 잘 된 소프트웨어는 최소한의 지식만으로 프로그램을 변경할 수 있다. 관련 있는 함수나 필드나 모여있어야 더 쉽게 찾고 이해할 수 있다. 하지만 관련 있는 함수나 필드가 항상 고정적인 것은 아니기에 때에 따라 옮겨야 할 필요가 있다. 함수를 옮겨야 하는 경우 해당 함수가 다른 문맥에 있는 데이터를 더 많이 참조하는 경우 해당 함수를 다른 클라이언트(클래스)에서도 필요로 하는 경우 함수를 옮겨갈 새로운 문맥(클래스)이 필요한 경우에는 "여러 함수를 클래스로 묶기" 또는 클래스 추출하기를 사용한다. 함수를 옮길 적당한 위치를 찾기가 어렵다면, 그대로 두어도 괜찮다. 함수 옮기기 package me.whiteship.refactoring._07_divergent_change._25_move_function; public class Account { private int daysOverdrawn; private AccountType type; public Account(int day

원문보기 내부링크
Naver Blog

[Refactoring] 클래스 추출하기

클래스가 다루는 책임이 많아질수록 클래스가 점차 커진다. 클래스를 쪼개는 기준 데이터나 메서드 중 일부가 매우 밀접한 관련이 있는 경우 일부 데이터가 대부분 같이 바뀌는 경우 데이터 또는 메서드 중 일부를 삭제한다면 어떻게 될까? 하위 클래스를 만들어 책임을 분산 시킬 수도 있다. 클래스 추출하기 public class Person { private String name; private String officeAreaCode; private String officeNumber; public String telephoneNumber() { return this.officeAreaCode + " " + this.officeNumber; } public String name() { return name; } public void setName(String name) { this.name = name; } public String officeAreaCode() { return officeA

원문보기 내부링크
Naver Blog

[Refactoring] 필드 옮기기

Shotgun Surgery 어떤 한 변경 사항이 생겼을 때 여러 모듈을 (여러 함수 또는 여러 클래스를) 수정해야 하는 상황. 하나의 일로 여러 곳을 손보는 경우 뒤엉킨 변경과 유사하지만 반대의 사황이다. 뒤엉킨 변경은 여러 가지 이유로 하나의 클래스를 손보는 경우 ex) 새로운 결제 방식을 도입하려면 여러 클래스의 코드를 수정해야 한다. 변경 사항이 여러 곳에 흩어진다면 찾아서 고치기도 어렵고 중요한 변경 사항을 놓칠 수 있는 가능성도 생긴다. 관련 리팩토링 기술 함수 옮기기 또는 필드 옮기기를 사용해서 필요한 변경 내역을 하나의 클래스로 모을 수 있다. 비슷한 데이터를 사용하는 여러 함수가 있다면 여러 함수를 클래스로 묶기를 사용할 수 있다. 단계 쪼개기를 사용해 공통으로 사용되는 함수의 결과물들을 하나로 묶을 수 있다. 함수 인라인과 클래스 인라인로 흩어진 로직을 한곳으로 모을 수 있다. 필드 옮기기 좋은 데이터 구조를 가지고 있다면, 해당 데이터에 기반한 어떤 행위를 코드로

원문보기 내부링크
Naver Blog

[Refactoring] 함수 인라인

함수 추출하기의 반대에 해당하는 리팩토링 추출하기 : 함수로 추출해 함수 이름으로 의도를 표현하는 방법 인라인 : 다시 가져오는 거임 함수 본문이 함수 이름만큼 또는 그보다 더 잘 의도를 표현하는 경우가 있다. 함수 리팩토링이 잘못된 경우에 여러 함수를 인라인 하여 커다란 함수를 만든 다음에 다시 함수 추출하기를 시도할 수 있다. 단순히 메서드 호출을 감싸는 우회형 메서드라면 인라인으로 없앨 수 있다. 상속 구조에서 오버라이딩 하고 있는 메서드는 인라인 할 수 없다. 함수 인라인 public class Rating { public int rating(Driver driver) { return moreThanFiveLateDeliveries(driver) ? 2 : 1; } private boolean moreThanFiveLateDeliveries(Driver driver) { return driver.getNumberOfLateDeliveries() > 5; } //moreThan

원문보기 내부링크
Naver Blog

[Refactoring] 클래스 인라인

클래스 추출하기와 반대에 해당하는 리팩토링 리팩토링을 하는 중에 클래스의 책임을 옮기다 보면 클래스의 존재 이유가 빈약해지는 경우가 발생할 수 있다. 두 개의 클래스를 여러 클래스로 나누는 리팩토링의 경우, 우선 클래스 인라인을 적용해서 두 클래스의 코드를 한곳으로 모으고 그런 다음에 클래스 추출하기를 적용해서 새롭게 분리하는 리팩토링을 적용할 수 있다. 클래스 인라인 음.. 이 부분 예제는 어차피 합치는 거나 다름없다. package me.whiteship.refactoring._08_shotgun_surgery._29_inline_class; public class Shipment { private TrackingInformation trackingInformation; public Shipment(TrackingInformation trackingInformation) { this.trackingInformation = trackingInformation; } public Tr

원문보기 내부링크
Naver Blog

9월 마지막 주

점심으로 먹은 서브웨이 2개.. 에그마요랑 로스트 치킨 59년 만에 달보다 밝은 목성이다. 나는 몰랐는데 친구가 단톡방에 말해줘서 낭만 좀 챙길 겸 구경하러 갔다. 알고 보니 다음에 목성을 볼 수 있는 건 2100년 이후라고 해서 좀 오래 봤다. 목성.. 이때 진짜 밝기는 했다. 언제 목성 봐보냐.. 내 학교생활 처음으로 동학 가봤다. 다행히 졸업하기 전에 가본다. 몇 번 가보려고 했는데 갈 때마다 사람 많아서 못 갔는데.. 드디어 갔다!! 동학주 먼저 시키고.. 칠면조 바로 시켰다. 엄청 기대했는데!! 음.. 맛있긴 하다 ㅎ 그리고 해물파전이랑 감자전도 시켰는데 오우 나는 전이 너무 맛있었다. 음식 나오고 한 컷.. 물론 이것만 시키지는 않았다. 칠면조도 추가하고 전도 2번 정도 더 시키고 술도 더 시키고.. 엄청 많이 나올 줄 알았는데 4명이서 12만 원.. 이 정도면 괜찮다. 아 전 또 먹고 싶네 법인.. 카드..를 발급.. 받았습니다.. 호오!!!! 영롱하다!! 9월 28일에

원문보기 내부링크
Naver Blog

[Refactoring] 파생 변수를 질의 함수로 바꾸기

파생 변수란 어디선가 계산된 데이터 불변 값이 파생변수에는 리팩토링을 적용할 필요가 없다. 변경할 수 있는 데이터를 최대한 줄이도록 노력해야 한다. 계산해서 알아낼 수 있는 변수는 제거할 수 있다. 계산 자체가 데이터의 의미를 잘 표현하는 경우도 있다. 해당 변수가 어디선가 잘못된 값으로 수정될 수 있는 가능성을 제거할 수 있다. 계산에 필요한 데이터가 변하지 않는 값이라면 계산의 결과에 해당하는 데이터 역시 불변 데이터이기에 해당 벼수는 그대로 유지할 수 있다. 파생 변수를 질의 함수로 바꾸기 package me.whiteship.refactoring._06_mutable_data._21_replace_derived_variable_with_query; public class Discount { private double discountedTotal; private double discount; private double baseTotal; public Discount(double

원문보기 내부링크
Naver Blog

[Refactoring] 여러 함수를 변환 함수로 묶기

관련 있는 여러 파생 변수를 만들어내는 함수가 여러 곳에서 만들어지고 사용된다면 그러한 파생 변수를 변환 함수를 통해 한 곳으로 모아둘 수 있다. 소스 데이터가 변경될 수 있는 경우에는 여러 함수를 클래스로 묶기를 사용하는 것이 적절하다. 소스 데이터가 변경되지 않는 경우에는 두 가지 방법을 모두 사용할 수 있지만, 변환 함수를 사용해서 불변 데이터의 필드로 생성해 두고 재사용할 수도 있다. 여러 함수를 변환 함수로 묶기 변환 함수를 사용한다. 클래스 3개에서 똑같은 메서드가 사용되고 있기에 이 부분을 변환 함수로 바꿔본다. public class Client2 { private double base; private double taxableCharge; public Client2(Reading reading) { this.base = baseRate(reading.month(), reading.year()) * reading.quantity(); this.taxableCharge

원문보기 내부링크
Naver Blog

[Refactoring] 참조를 값으로 바꾸기

레퍼런스 객체와 값 객체를 구별하자. 변하는 값을 변하지 않는 값으로 레퍼런스 객체는 객체 내부의 값이 바뀔 수 있다. 밸류는 객체의 동일성을 안에 있는 값으로 판별한다. 값 객체는 객체가 가진 필드의 값으로 동일성을 확인한다. 값 객체는 변하지 않는다. 어떤 객체의 변경 내역을 다른 곳으로 전파시키고 싶으면 레퍼런스, 아니면 값 객체를 사용한다. 레퍼런스는 바뀐 값 그대로 사용할 수 있다. 참조를 값으로 바꾸기 public class Person { private TelephoneNumber officeTelephoneNumber; // 레퍼런스 //이걸 VO로 바꾸고 싶다! public String officeAreaCode() { return this.officeTelephoneNumber.areaCode(); } public void officeAreaCode(String areaCode) { this.officeTelephoneNumber.areaCode(areaCode);

원문보기 내부링크
Naver Blog

[Spring boot] @CreationTimeStamp null after update

@Column(name = "CREATE_DT") @CreationTimestamp private LocalDateTime createDt; 기존에 createDt를 사용할 때 @CreationTimestamp을 사용해서 insert 할 때 자동으로 값이 생성되게 했다. 하지만 이 방식에는 문제가 존재하는데.. 똑같은 걸 한 번 더 save 하면 createDt가 null로 바뀌어버린다.. 처음 POST를 날리면 잘 들어가지만.. 한 번 더 날리면 null로 바뀐다. @CreationTimestamp column sets to null when I update it from POST method I'm trying to set a field in my database to write the date when a row is modified. To do that, I'm using the anotations provided by Hibernate. When I create the ro

원문보기 내부링크
Naver Blog

[서평] 이것이 자바다 개정판 - 신용권, 임경균 지음

2015년에 초판이 발간된 이것이 자바다 책이 2022년에 완전 컬러판으로 업그레이드해서 개정판이 나왔습니다!! 책 앞 부분은 위와 같이 생겼습니다. 뒷부분은 다음과 같습니다. 기존 책에 비해서 많은 내용이 보강되었습니다. Java 17 문법까지 추가되었고 데이터베이스 관련한 부분도 추가가 되었습니다. 기존 책도 많이 유명하고 좋았지만 이번 개정판은 확실히 책도 더 깔끔해지고 많은 내용을 담았습니다. 참고로 책은 984 페이지입니다. 책은 총 20개의 챕터로 구성되어 있습니다. 자바로 할 수 있는 웬만한 건 다 들어가 있다고 보면 됩니다. 기본기부터 해서 java 8 문법 java 17문법 자바를 활용한 데이터베이스, 네트워크 등 다 들어가 있습니다. 참고하시면 될 것 같습니다. 이 부분이 새롭게 추가된 부분입니다. 책은 굉장히 깔끔하게 구성되어 있습니다. 자바를 시작하기 위해서 이클립스를 다운 받는 부분인데 설치 과정에서 어려움을 느끼지 않도록 설정 부분까지 다 그림으로 나와있고

원문보기 내부링크
Naver Blog

[Refactoring] 질의 함수와 변경 함수 분리하기

눈에 띌만한 사이드 이펙트 없이 값을 조회할 수 있는 메서드는 테스트하기도 쉽고, 메서드를 이동하기도 편하다. 명령-조회 분리(command-query separation) 규칙 : 어떤 값을 리턴하는 함수는 사이드 이펙트가 없어야 한다. 값 조회, 변경 함수를 구분해서 만들자. 눈에 띌만한 사이드 이펙트 캐시는 중요한 객체 상태 변화는 아니다. 따라서 어떤 메서드 호출로 인해, 캐시 데이터를 변경하더라도 분리할 필요는 없다. 질의 함수와 변경 함수 분리하기 public class Billing { public double getTotalOutstandingAndSendBill() { // 조회를 하고 이메일을 보내는 2가지 일을 하고 있음 double result = customer.getInvoices().stream() .map(Invoice::getAmount) .reduce((double) 0, Double::sum); sendBill(); return result; } p

원문보기 내부링크
Naver Blog

[Refactoring] 매개변수 객체 만들기

같은 매개변수들이 여러 메소드에 걸쳐서 나타난다면 그 매개변수들을 묶은 자료 구조를 만드는 것이 좋다. 이렇게 자료구조를 만들면 해당 데이터간의 관계를 보다 명시적으로 나타낼 수 있다. 함수에 전달할 매개변수 개수를 줄일 수 있다. 도메인을 이해하는데 중요한 역할을 하는 클래스로 발전할 수도 있다. 매개변수 객체 만들기 private double getRate(int totalNumberOfEvents, Participant p) { long count = p.homework().values().stream() .filter(v -> v == true) .count(); double rate = count * 100 / totalNumberOfEvents; return rate; } private String getMarkdownForHomeWork(int totalNumberOfEvents,Participant p, double rate) { return String.format(

원문보기 내부링크
Naver Blog

[Refactoring] 객체 통째로 넘기기

여러 파라미터가 있는 경우 -> 한 개의 오브젝트, 레코드일 때, 객체를 통째로 넘겨서 파라미터를 줄일 수 있다. 이건 오브젝트가 있는 경우 사용한다. 이 리팩토링을 사용하기 전에 의존성을 고려해야 한다. 메서드의 위치가 적절하지 않을 수 있다. 객체 통째로 넘기기 package me.whiteship.refactoring._03_long_function._09_preserve_whole_object; import java.util.HashMap; import java.util.Map; public record Participant(String username, Map<Integer, Boolean> homework) { public Participant(String username) { this(username, new HashMap<>()); } public void setHomeworkDone(int index) { this.homework.put(index, true); }

원문보기 내부링크
Naver Blog

[Refactoring] 함수를 명령으로 바꾸기

함수를 독립적인 객체인, Command로 만들어서 사용할 수 있다. 커맨드 패턴에 관련한 내용 -> 디자인 패턴임 오퍼레이션 하나를 인스턴스 하나로 만드는 패턴 복잡해질 수 있다. 부가적인 기능으로 Undo 기능을 만들 수도 있다. 더 복잡한 기능을 구현하는데 필요한 여러 메서드를 추가할 수 있다. 상속이나 템플릿을 활용할 수도 있다. 복잡한 메서드를 여러 메서드나 필드를 활용해 쪼갤 수도 있다. 대부분의 경우 커맨드보다는 함수를 사용하나, 커맨드 말고 다른 방법이 없는 경우 사용 함수의 분리를 고민해 보자, 더 복잡해질 것 같다. 함수를 명령으로 바꾸기 기존 함수를 private method로 뺀다. private void extracted(List<Participant> participants) throws IOException { try (FileWriter fileWriter = new FileWriter("participants.md"); PrintWriter writer

원문보기 내부링크
Naver Blog

[Refactoring] 조건문 분해하기

여러 if 문에 따라서 달라지는 코드를 작성하게 되면 긴 함수가 만들어질 수 있다. 조건과 액션 모두 의도를 표현해야 한다.! 함수 추출하기와 동일한 리팩토링이지만 의도만 다를 뿐이다. 조건문 분해하기 private Participant findParticipant(String username, List<Participant> participants) { Participant participant; if (participants.stream().noneMatch(p -> p.username().equals(username))) { participant = new Participant(username); participants.add(participant); } else { participant = participants.stream().filter(p -> p.username().equals(username)).findFirst().orElseThrow(); } return part

원문보기 내부링크
Naver Blog

[Refactoring] 반복문 쪼개기

하나의 반복문에서 여러 개의 작업을 하는 코드들이 있다. 해당 반복문을 수정할 때 여러 작업을 모두 고려하면서 코딩을 해야 한다. 반복문을 여러 개로 쪼개면 보다 쉽게 이해하고 수정할 수 있다. 성능 문제를 야기할 수 있겠지만, 리팩토링과 성능 최적화는 별개의 작업이다. 리팩토링을 마친 이후에 성능 최적화 시도 가능 반복문 쪼개기 for (GHIssueComment comment : comments) { Participant participant = findParticipant(comment.getUserName(), participants); participant.setHomeworkDone(eventId); if (firstCreatedAt == null || comment.getCreatedAt().before(firstCreatedAt)) { firstCreatedAt = comment.getCreatedAt(); first = participant; } } 기존의 for 문

원문보기 내부링크
Naver Blog

[Refactoring] 조건문을 다형성으로 바꾸기

여러 타입에 따라 각기 다른 로직으로 처리해야 하는 경우에 다형성을 적용해서 조건문을 명확하게 분리할 수 있다. 반복되는 switch 문을 각기 다른 클래스를 만들어서 제거할 수 있다. 공통으로 사용되는 로직은 상위 클래스에 두고 달라지는 부분만 하위 클래스에 둠으로써, 달라지는 부분만 강조할 수 있다. 당연히 모든 조건문을 다형성으로 바꿔야 하는 것은 아니다!! 복잡한 경우, 달라지는 부분에만 고려하는 것이 좋다! 조건문을 다형성으로 바꾸기 package me.whiteship.refactoring._03_long_function._13_replace_conditional_with_polymorphism; import java.io.FileWriter; import java.io.IOException; import java.io.PrintWriter; import java.util.Comparator; import java.util.List; public class StudyPri

원문보기 내부링크
Naver Blog

[Refactoring] 매개변수를 질의 함수로 바꾸기

어떤 함수에 매개변수가 많을수록 함수의 역할을 이해하기 어려워진다. 매개변수가 많으면 과연 그 함수가 한 가지 일을 하고 있는 게 맞는가를 의심해 보자! 함수를 쪼개자! 불필요한 매개변수는 없는가! 하나의 매개변수로 다른 매개변수를 추론할 수 있는가! 하나의 Object로 뭉칠 수 있는 매개변수 목록은 없는가! 어떤 매개변수를 다른 매개변수를 통해서 알아낼 수 있으면! "매개변수를 질의 함수로 바꾸기" 기존 자료구조에서 세부적인 데이터를 가져와서 여러 매개변수로 넘기는 대신, 객체 통째로 넘기기! 일부 매개변수들이 대부분같이 넘겨진다면, 매개변수 객체 만들기! 매개변수가 플래그로 사용된다면, 플래그 인수 제거하기! 여러 함수가 일부 매개변수를 공통적으로 사용한다면 여러 함수를 클래스로 묶기를 통해서 매개변수를 질의 함수로 바꾸기 함수의 매개변수 목록은 함수의 다양성을 대변하고, 짧을수록 이해하기 좋다. 어떤 한 매개변수를 다른 매개변수를 통해 알아낼 수 있으면 중복 매개변수라 생각할

원문보기 내부링크
Naver Blog

[Refactoring] 플래그 인수 제거하기

플래그는 보통 함수에 매개변수로 전달해서, 함수 내부의 로직을 분기하는 데 사용한다. 플래그를 사용한 함수는 차이를 파악하기 어렵다. bookConcert(customer, false), bookConcert(customer, true) bookConcert(customer), premiumBookConcert(customer) 과연 여기서 Boolean 값이 하는 게 무엇일까! 조건문 분해하기를 활용할 수 있다. 함수 추출이 주를 이룬다. 플래그 인수 제거하기 package me.whiteship.refactoring._04_long_parameter_list._15_remove_flag_argument; import java.time.LocalDate; public class Shipment { public LocalDate deliveryDate(Order order, boolean isRush) { if (isRush) { int deliveryTime = switch (or

원문보기 내부링크
Naver Blog

[Refactoring] 변수 캡슐화하기

전역 데이터는 아무곳에서나 변경될 수 있다는 문제가 있음 어떤 코드로 인해 값이 바뀐 것인지 파악하기 어렵다. 클래스 변수(필드)도 비슷한 문제를 겪을 수 있다. 변수 캡슐화하기를 적용해서 접근을 제어하거나 어디서 사용하는지 파악하기 쉽게 만들 수 있다. 변수 캡슐화하기 메소드는 점진적으로 새로운 메소드로 변경할 수 있으나, 데이터는 한 번에 모두 변경해야 한다. 데이터 구조를 변경하는 작업을 그보다는 조금 더 수월한 메서드 구조 변경 작업으로 대체할 수 있다. 데이터가 사용되는 범위가 클수록 캡슐화를 하는 것이 더 중요해진다. 함수를 사용해서 값을 변경하면 보다 쉽게 검증 로직을 추가하거나 변경에 따른 후속 작업을 추가하는 것이 편리하다. 불변 데이터의 경우에는 이런 리팩토링을 적용할 필요가 없다. public class Thermostats { public static Integer targetTemperature = 70; public static Boolean heating

원문보기 내부링크
Naver Blog

[Refactoring] 변수 쪼개기

데이터를 변경하다 보면 예상치 못했던 결과나 해결하기 어려운 버그가 발생한다. 함수형 프로그래밍 언어는 데이터를 변경하지 않고 복사본을 전달한다. 다른 프로그래밍 언어는 데이터 변경을 허용하고 있다. 따라서 변경되는 데이터 사용 시 발생할 수 있는 리스크를 관리할 수 있는 방법을 적용하는 것이 좋다. 관련 리팩토링 변수 캡슐화하기를 통해서 데이터를 변경할 수 있는 메서드를 제한하고 관리할 수 있다. 변수 쪼개기를 사용해 여러 데이터를 저장하는 변수를 나눌 수 있다. 코드 정리하기를 사용해 데이터를 변경하는 코드를 분리하고 피할 수 있다. 함수 추출하기로 데이터를 변경하는 코드로부터 사이드 이펙트가 없는 코드를 분리할 수 있다. 질의 함수와 변경 함수 분리하기를 적용해서 클라이언트가 원하는 경우에만 사이드 이펙트가 있는 함수를 호출하도록 API를 개선할 수 있다. 가능하다면 세터 제거하기를 적용한다. 계산해서 알아낼 수 있는 값에는 파생 변수를 질의 함수로 바꾸기를 적용할 수 있다.

원문보기 내부링크
Naver Blog

[Refactoring] 코드 정리하기

관련 있는 코드끼리 묶여있어야 코드를 더 쉽게 이해할 수 있다. 다른 리팩토링을 하기 위한 전처리 과정 함수에서 사용할 변수를 상단에 미리 정의하기보다는 해당 변수를 사용하는 코드 바로 위에 선언하는 것이 좋다. 관련 있는 코드끼리 묶은 다음, 함수 추출하기 (Extract Function)를 사용해서 더 깔끔하게 분리가 가능하다. 코드 정리하기 인텔리제이 기준 option + shift + 화살표 누르면 코드 자유자재로 이동 가능.. 헐 대박이다!!!!!! private void printReviewers() throws IOException { GitHub gitHub = GitHub.connect(); GHRepository repository = gitHub.getRepository("whiteship/live-study"); GHIssue issue = repository.getIssue(30); // Get reviewers Set<String> reviewers = ne

원문보기 내부링크
Naver Blog

[Refactoring] 메서드 올리기

중복 코드는 당장은 잘 동작하더라도 미래에 버그를 만들어 낼 빌미를 제공한다. 여러 하위 클래스에 동일한 코드가 있다면 메서드 올리기를 적용할 수 있다. 상위 클래스도 메서드를 올리는 것이다. 비슷하지만 일부 값만 다른 경우 함수 매개변수화하기 리팩토링을 적용한 후에 이 메서드 올리기 사용 가능 하위 클래스에 있는 코드가 상위 클래스가 아닌 하위 클래스 기능에 의존하고 있다면 필드 올리기를 적용한 이후에 이 방법을 적용할 수 있다. 두 메서드가 비슷한 절차를 따르고 있다면, "템플릿 메서드 패턴" 적용을 고려할 수 있다. 메서드 올리기 DashBoard를 상속받는 class A public void printParticipants(int eventId) throws IOException { // Get github issue to check homework GitHub gitHub = GitHub.connect(); GHRepository repository = gitHub.getR

원문보기 내부링크
Naver Blog

[Refactoring] 임시 변수를 질의 함수로 바꾸기

긴 함수가 있을 때 사용하는 리팩토링 기술 긴 함수 vs 짧은 함수 작은 함수가 코드량이 적어서 좋기는 하다. 주석을 남기기보다는 함수를 만들어서 함수의 이름으로 의도를 표현하자. 긴 함수가 있을 때는 함수 추출하기로 해결 가능하다. 함수를 분리할 때 해당 함수로 전달해야 할 매개변수가 많아진다면 아래의 리팩토링을 고려해 볼 수 있다. 임시 변수를 질의 함수로 바꾸기 매개변수 객체 만들기 객체 통째로 넘기기 조건문 분해하기를 사용해서 조건문을 분리할 수 있다. 같은 조건으로 여러 개의 Switch 문이 있다면, 조건문을 다형성으로 바꾸기를 사용할 수 있다. 반복문 안에서 여러 작업을 하고 있어서 하나의 메서드로 추출하기 어렵다면, 반복문 쪼개기를 적용할 수 있다. 임시 변수를 질의 함수로 바꾸기 임시 변수를 만드는 표현식을 함수로 만들자! 변수를 사용하면 반복해서 동일한 식을 계산하는 것을 피할 수 있고, 이름을 사용해 의미를 표현할 수도 있다. 긴 함수를 리팩토링할 때, 그러한 임

원문보기 내부링크
Naver Blog

[Effective Java] 멤버 클래스는 되도록 static으로 만들라.

멤버 클래스는 되도록 static으로 만들라. 중첩 클래스 중첩 클래스란 다른 클래스 안에 정의된 클래스를 말한다. 중첩 클래스는 자신을 감싼 바깥 클래스에서만 쓰여야 하고 그 외의 쓰임새가 있다면 톱레벨 클래스로 만들어야 한다. 중첩 클래스 종류 정적 멤버 클래스 비정적 멤버 클래스 익명 클래스 지역 클래스 4가지로 나뉜다. 1번을 제외한 나머지는 inner class (내부 클래스)에 해당한다. 각각이 왜 쓰이고 언제 사용하는지 알아보자. 정적 멤버 클래스 정적 멤버 클래스는 다른 클래스 안에 선언되고, 바깥 클래스의 private 멤버에도 접근할 수 있다는 점만 제외하고는 일반 클래스와 똑같다. 정적 멤버 클래스는 다른 정적 멤버와 똑같은 접근 규칙을 적용받는다. private으로 선언하면 바깥 클래스에서만 접근할 수 있다. 정적 멤버 클래스는 바깥 클래스와 함께 쓰일 때만 유용한 public 도우미 클래스로 쓰인다. public class Calculator { public

원문보기 내부링크
Naver Blog

[Effective Java] 톱레벨 클래스는 한 파일에 하나만 담으라.

톱레벨 클래스란? A top level class is a class that is not a nested class. 중첩 클래스가 아닌 클래스이다. 일반적으로 사용하는 클래스. 톱레벨 클래스는 한 파일에 하나만 담으라. 소스 파일 하나에 톱레벨 클래스를 여러 개 선언하는 건 아무런 득도 없고 위험을 감수해야 한다. 한 클래스를 여러 가지로 정의할 수 있게 되고 어느 것을 사용할지는 어느 소스 파일을 먼저 컴파일 하느냐에 따라 달라진다. public class Main { public static void main(String[] args) { System.out.println(Utensil.NAME + Dessert.NAME); } } 메인 클래스 하나를 담고 있고 메인 클래스는 다른 톱레벨 클래스 Utensil과 Dessert를 참조한다. class Utensil { static final String NAME = "pan"; } class Dessert{ static fina

원문보기 내부링크
Naver Blog

[Effective Java] 지역변수의 범위를 최소화하라

지역변수의 범위를 최소화하라 지역변수의 유효 범위를 최소로 줄이면 코드 가독성과 유지 보수성이 높아지고 오류 가능성은 낮아진다. 자바에서는 문장을 선언할 수 있는 곳이면 어디서든 변수를 선언할 수 있다. 지역변수의 범위를 가장 좋은 방법은 가장 처음 쓰일 때 선언하기이다. 사용하지 않는 데 미리 선언해두면 코드가 어수선해지고 가독성이 떨어진다. 거의 모든 지역변수는 선언과 동시에 초기화해야 한다. 초기화에 필요한 정보가 충분하지 않다면 충분해질 때까지 선언을 미뤄야 한다. try-catch 문은 규칙에서 예외다. 변수를 초기화하는 표현식에서 검사 예외를 던질 가능성이 있다면 try 블록 안에서 초기화해야 한다. 변숫값을 try 블록 바깥에서도 사용해야 한다면 try 블록 앞에서 선언해야 한다. 반복문 반복문은 변수 범위를 최소화해준다! 반복문에서는 loop variable의 범위가 반복문의 몸체, for 키워드와 몸체 사이의 괄호 안으로 제한된다. 그렇기에 반복 변수의 값을 반복문이

원문보기 내부링크
Naver Blog

7월 마지막 주

정보처리기사 본 날에 먹은 아침.. 아 과연 합격할 수 있을까! 제발요! 점심인가 저녁으로 먹은 KFC 넘모 맛있어 자취방에서 나오다가 본.. 고양이.. 발만 쪼끔 나온 게 넘 귀엽다 오랜만의 학식.. 역시 돈 아낄 거면 학식이 최고다.. 이날 정처기 본 날이었나 공릉 풍경이 이뻐서 찍어보았다. 흑흑 2학년 1학기 ~ 4학년 1학기까지 한 국제학생회가 끝났다. 2학기까지 해서 6학기 하고 졸업할까 하다가.. 더 이상은 못 할 것 같아서 그만두었다. 그래도 나름 재밌게 즐겼다. 요즘 운동도 열심히 한다. 러닝하고 맨몸 운동! 집 앞에 있던 화난 고양이! 진짜 3개월 만에 롤을 해봤다. 들어가 보니 시간의 상점이 있길래 까봤는데 내가 좋아하는 챔피언 3개 있길래 바로 질렀다. 중간에 르블랑 스킨이 화려하면서 이쁘다. 런데이로 100km 뛰었다. 다만 함정이 있다면.. 이 runday.. 1년정도 됐다 크흠.. 오랜만에 아소코 가서 연어 덮밥 먹었다. 연어는 언제 먹어도 맛있다. 건대입구

원문보기 내부링크
Naver Blog

[Effective Java] 전통적인 for 문보다는 for-each 문을 사용해라.

전통적인 for 문보다는 for-each 문을 사용해라. 스트림이 제격인 작업이 있고 반복이 제격이 작업이 있다. for(Iterator<Element> i = c.iterator() ; i.hasNext();){ Element e = i.next(); } for(int i = 0;i<a.length;i++){ } 위 두 코드 while 문보다는 낫지만 더 좋은 방법이 있다. 반복자(iterator)와 인덱스 변수 모두 코드를 지저분하게 할 뿐이고 진짜 필요한 건 원소들이다. 위의 2개처럼 쓰게 되면 사용되는 요소 종류가 늘어나기에 오류가 생길 가능성이 높아진다. 1회 반복에서 반복자가 세 번 등장하고 인덱스는 a[i]까지 하면 4번 접근이 된다. 잘못 사용하면 컴파일러가 잡아준다는 보장도 없고 컬렉션이나 배열이냐에 따라 코드 형태가 상당히 달라지기에 주의해야 한다. 위의 문제들은 for-each 문을 사용하면 모두 해결된다. 반복자와 인덱스 변수를 사용하지 않으니 코드가 깔끔해지고

원문보기 내부링크
Naver Blog

GDSC SeoulTech 2기 Core Member를 모집합니다!

c GDSC Seoultech 2기 Core Member를 모집합니다 지원 기간 8월 1일 ~ 8월 7일 20시까지! GDSC Seoultech이 돌아왔습니다! Google Developer Student Clubs은 구글 개발자 기술에 관심이 있는 대학생들을 위한 커뮤니티입니다. 개발자로서 성장하는 것에 관심이 있는 모든 학우들을 환영합니다. 22-23 시즌 GDSC는 2022.08~2023.08 1년 동안 활동합니다. 서울과학기술대학교의 두번째 GDSC! 함께 성장할 열정 가득 Core 를 모집합니다! (일반 멤버는 8월 중순 모집 예정입니다.) 자세한 사항은 아래 노션을 참고해주세요! :) ️ 노션 ️ https://puffy-dumpling-10f.notion.site/GDSC-Seoultech-Core-Recruiting-b9c0e4f9af3844e4ad813054d8ac9752 ️ 1기 인터뷰 보러가기 ️ https://puffy-dumpling-10f.notion.s

원문보기 내부링크
Naver Blog

[Effective Java] 박싱된 기본 타입보다는 기본 타입을 사용하라.

박싱된 기본 타입보다는 기본 타입을 사용하라. 자바의 데이터 타입은 기본 타입과 참조 타입으로 나뉜다. 기본 타입에는 대응하는 참조 타입이 있고 이걸 박싱된 기본 타입이라고 한다 int, double, boolean (기본 타입) -> Integer, Double, Boolean (박싱된 기본 타입) 기본 타입과 박싱된 기본 타입의 차이 기본 타입은 값만 가지고 있으나 박싱된 기본 타입은 값에 더해 식별성(identity)란 속성을 갖는다. 즉 박싱된 기본 타입의 두 인스턴스는 값이 같아도 서로 다르다고 식별될 수 있다. 기본 타입의 값은 언제나 유효하나, 박싱된 기본 타입은 유효하지 않은 값 null을 가질 수 있다. 기본 타입이 박싱된 기본 타입보다 시간과 메모리 사용면에서 더 효율적이다. 위의 세 가지 차이 때문에 주의하지 않고 사용하면 문제가 발생할 수 있다. 잘못된 구현 Comparator<Integer> naturalOrder = (i,j) -> (i < j) ? -1 :

원문보기 내부링크
Naver Blog

[Effective Java] 다른 타입이 적절하다면 문자열 사용은 피하라.

다른 타입이 적절하다면 문자열 사용은 피하라. 이번 아이템에서는 문자열을 쓰지 않아야 할 사례에 대해서 알아본다. 문자열은 다른 값 타입을 대신하기에 적합하지 않다. 입력받을 데이터가 진짜 문자열일 때만 데이터를 문자열로 받는 것이 좋다. 받은 데이터가 수치형이라면 int, float, BigInteger 등 적당한 수치 타입으로 변환해야 한다. 기본 타입이든 참조 타입 이든 적절한 값 타입이 있다면 그것을 사용하고 없으면 새로 작성! 문자열은 열거 타입을 대신하기에 적합하지 않다. 상수를 열거할 때는 문자열보다는 열거 타입이 월등히 낫다. 문자열은 혼합 타입을 대신하기에 적합하지 않다. 여러 요소가 혼합된 데이터를 하나의 문자열로 표현하는 것은 좋지 않다. String compoundKey = className + "#" + i.next(); 두 요소를 구분해 주는 문자 '#"이 두 요소 중 하나에 쓰였다면 혼란스러운 결과를 초래 각 요소를 개별로 접근하려면 문자열을 파싱 해야 해

원문보기 내부링크
Naver Blog

[Effective Java] 문자열 연결은 느리니 주의하라.

문자열 연결은 느리니 주의하라. 문자열 연결 연산자로 문자열 n 개를 잇는 시간은 n^2에 비례한다. String은 불변이라서 두 문자열을 연결할 경우 양쪽의 내용 모두 복사해야 하기에 성능 저하가 반드시 발생한다. StringBuilder 성능을 포기하고 싶지 않다면 String 대신 StringBuilder를 사용하자. public String statement2(){ StringBuilder b = new StringBuilder(numItems() * LINE_WIDTH); for(int i = 0;i< numItems();i++) b.append(lineForItem(i)); return b.toString(); } String을 사용했을 때와 몇 배의 성능 차이가 난다. 핵심 정리 성능에 신경 써야 한다면 많은 문자열을 연결할 때는 문자열 연결 연산자(+)를 피하자. 대신 StringBuilder의 append 메서드를 사용하라. 문자열 배열을 사용하거나, 문자열을 연결하

원문보기 내부링크
1 2 3 4 5 6 7 8 9 10