[주간 회고] 22.01. 3주차 🥕 🍳

일기 형태로 작성되었습니다.

 

월요일

오늘은 프로세스 메모리 구조 중 스택 프레임과 힙 메모리를 논리적인 관점에서 자바로 구현했다. 보통 사용자가 프로그램을 실행하면 프로세스가 생성되고 이에 따른 프로세스 메모리가 생긴다. 이 과정은 OS가 관리하는데 이를 직접 프로세스의 컴파일된 어셈블리 코드가 있다고 가정하고 프로세스의 시작점(e.g. main 함수)부터 시작하여 여러 함수들이 스택에 쌓이고 사라지며 그 안에 동적 할당이 있다면 힙에 할당하고 해제하는 시나리오대로 구현했다. 생각하지 못했던 점은 C언어를 사용할 때 malloc()에 메모리 크기만 정해주면 동적 할당이 쉽게 사용했지만 이를 실제로 구현하기엔 상당히 어려운 일이라는 것을 알았다. 동적 할당된 메모리의 위치는 어디에 두어야 하며 해제된 위치를 어떻게 재사용할 것인지에 대한 의문들이다. 또한 내가 구현한 free() 함수는 스택 프레임에 동적 할당된 값의 주소만 삭제해주었는데 이를 OS에서 해당 메모리에 대한 액세스 권한을 넘겨줘야 재사용할 수 있겠구나란 생각도 하게 되었다. JAVA의 경우 메모리 관리를 C와는 다르게 사용자가 직접 해제하기보다는 JVM에서 GC를 통해 관리하기 때문에 사용자 입장에서 스트레스를 덜 받는다. GC에 관해서는 다음 기회에 정리해봐야겠다.

 

화요일

JK의 '주니어 개발자 성장을 위한 7가지 학습 태도'란 주제로 아침을 시작했다. 간단히 요약하자면 개발 과정을 즐기기, 다양한 사람들과 함께하기, 이미 만들어진 고품질의 코드를 분석하기보다는 직접 만들어보기, 남들과 비교하지 말고 자존감을 키우기, 결과만 보지 말고 과정을 중요히 생각하기, 실수를 회고하며 개선해가는 과정을 반복하기, 답은 하나가 아니니 배우고 만든 것을 공유하고 타인의 여러 정답을 보고 배워라! 의 7가지 태도였다. 저번주에 작성한 자바 객체의 메모리 크기는 얼마일까? (OOPs, Java Object Header, JOL 사용하기) 🤖 글에 잘못된 부분이 있었다. 동료 '로니'의 피드백으로 올바르게 고치고 이해할 수 있었다. 빠른 피드백은 올바른 방향을 알려준다. 피드백을 두려워하지 말자.! 알려준 로니에게도 감사하다 

 

수요일

오전에 프로그래머스 코딩 테스트 문제를 풀고 소프트웨어 품격 스터디 준비를 했다. 오후엔 썸머와 썸머의 친구 법규를 만났다. 오랜만에 옛 동료를 만나니 시간 가는 줄 모르고 떠들었다. 썸머와는 함께 '루돌프'라는 '위시 리스트' 주제의 웹 프로젝트를 기획했다. 개발을 시작하려 했으나 내가 코드 스쿼드를 시작하여 썸머 혼자 개발을 하고 있다. 썸머가 지금까지 만들었던 결과를 보니 두근댔다. 디자인뿐만 아니라 핵심 되는 기능까지 벌써 혼자 만들었다. 나도 빨리 조인해야겠다. 6개월만 기다려주세요 썸머..  

 

목요일

오늘은 함수형 프로그래밍 패러다임을 가볍게(?) 보며 자바의 람다와 스트림을 공부했다. 패러다임이란 용어는 말 그대로 한 시대, 사회 전체가 공유하고 있는 이론이나 방법 등의 체계라고 볼 수 있다. 프로그래밍 세상에서도 마찬가지다. 시대마다 이론과 방법론이 다르고 어떤 가치에 집중하느냐에 따라 패러다임이 달라진다. 프로시저 패러다임, 객체지향적 패러다임, 함수형 패러다임 등 다양하다. 이번엔 함수형을 맛보며 이전 객체지향적으로 작성되었던 로직 중 for-loop 문을 스트림으로 변경해보았다. 구현을 끝내니 어떤 방법이 더 좋은가에 대한 의문이 들었다. 'homoefficio'님의 글 for-loop를 Stream.forEach()로 바꾸지 말아야 할 3가지 이유에서 그 힌트를 얻었다. 본문 내용 중 'Java 개발자는 많은 연습을 통해 언제 함수형 프로그래밍을 쓰는 것이 좋은지, 어떨 때 객체지향/절차형 방식을 고수하는 것이 좋은지 직관적으로 이해할 수 있어야 한다. 충분한 양의 연습이 동반된다면, 두 가지를 잘 혼용해서 우리가 만드는 SW를 개선할 수 있을 것이다.'이다.

객체지향이든 함수형이든 잘 알고 적재적소에 써야 한다. 현재 두 가지 모두 익숙하지 못하다. 충분한 연습이 필요하다. OOP에 먼저 집중해야겠다.

 

금요일

이전 22.01.13.목 - 초보의 OOP 설계와 구현기에서 하드 코딩된 값을 static final int LINE_VERTEX = 2라는 방식으로 가독성을 높였지만 타입 안전성 문제가 있기 때문에 'enum'을 적용해 보았다. 또한 어제 공부했던 람다가 자바에선 클래스밖에 없는데 어떻게 구현되어있을까?를 정리했다.(링크첨부)

22.01.21 - 자바의 'enum'과 'lambda'를 클래스로 이해해보기 🔎

22.01.21 - 자바 enum에서 ordinal 메서드 사용하지마...(세요) 🚫

 

 

토요일

코드스쿼드 멤버 '반스'를 만났다. 내가 프로젝트를 어떻게 시작하고 끝내는지 A-Z로 라이브 코딩이 보고 싶다고 했다. 약간의 부담이 되었지만 설명을 하며 나를 되돌아 보는 시간이었다. 이전 개발에는 방법론이 있는 것은 아니었다. 설계가 없거나 요구사항을 구현하는데 급급했다. 올해부터 좋은 코드 작성을 위해 OOP나 TDD 설계 방법을 연습하고 있다. (어디 가서 TDD 한다고 말하기 민망할 정도의 실력이지만..) 구현체에 대한 설계를 처음부터 완벽하게 할 수 없다고 느끼기 때문에 핵심 로직의 객체에 대한 테스트 코드를 만드고 이를 통과하는 코드를 구현 후 리팩터링 한다. 이 과정을 반복하며 코드 설계를 바꾸어 간다. 반스는 이런 방식을 처음 봤다고 놀랐지만 아직 부족한 내 실력이 민망했다. 하지만 반스에게 설명하고 난 뒤에 든 감정이 있다. 즐거움이었다. 이젠 코딩이 재미있다고 느낀다. (쿨럭)

저녁에는 책 '소프트웨어의 품격' 스터디를 했다. 오늘 주제는 '시간 복잡도'가 주제였다. 제리가 리더를 맡아 진행해주었다. 그의 설명은 부족함 하나 없는 시간이었다. 이번 주제는 망치 한 대 맞은 기분이었다. 이전에 시간 복잡도를 생각할 때는 코딩테스트에서 시간 복잡도를 줄이기 위해서 자료구조나 알고리즘을 적용했다. 하지만 코딩테스트의 문제는 단 하나의 메서드의 시간 복잡도를 줄이기 위해 노력했다는 것이다. 실무적인 측면에서 메서드 간 연결이 되어있고 이를 고려해야한다. 어떤 메서드는 사용자 입장에서 조금만 호출되고, 어떤 메서드는 많이 호출된다. 메서드의 관계와 호출 횟수에 맞춰 설계해야 한다는 것이다. 예를 들어 A 메서드와 B 메서드는 연결되어 있다. A와 B의 시간 복잡도는 트레이드 오프 형태를 띤다. A가 상수시간이라면 B는 선형 시간이고, B를 상수로 만든다면 A가 선형시간이 된다. 먼 미래를 봤을 때 B를 더 많이 사용한다면 B를 상수시간으로 만들고 A를 선형시간으로 구현해야 한다. '은총알은 없다.'라는 격언이 생각난다.

자세한 내용 아래 참고 

22.01.20 - 실제 함수 사이에 최적의 시간 복잡도는 무엇일까? 🤖

 

일요일

단골 카페에서 주간 회고를 쓰고 산책을 했다. 일주일을 되돌아보니 이번 주는 컨디션이 좋지 못했다. 가장 큰 이유는 운동이었다. 체력이 떨어지니 금방 지쳐버린다. 정말 해야겠다.!

 

요리 이야기 
평일에 재택을 한다. 건강을 위해 배달음식을 안 먹고 요리 하는 편이다. 혼자 지내다 보니 야채를 먹기 부담스러웠는데 유럽 냉동 야채에 도전해봤다. 그린빈, 미니당근, 미니 양배추, 컬리 플라워를 각 1kg씩 4kg을 구입했다. 가격은 1kg당 약 4천원으로 저렴하다.

이미 자숙이 되어있어 조리하기 간편하다. 아침으로 계란 프라이와 올리브 오일을 두르고 소금 후추만 넣고 구워 먹는다. 개인적으로 미니 양배추는 물기가 많아 별로였지만 그린빈과 미니 당근은 식감이 살아있어 훌륭했다. (컬리 플라워는 실수로 라이스로 구입해 먹기 애매해졌지만..)

 

구운 야채에 소스를 곁들이면 더 좋다.

발사믹 비네그레트 소스

깔끔한 맛 : 화이트 발사믹 1T + 다진마늘 1t + 페페론치노 1개 부순 것

익숙한 맛 : 일반 발사믹 2T + 올리브오일 1T + 꿀 or 설탕 1t + 후추

 

개인적으로 깔끔한 맛을 선호한다. 화이트 발사믹의 새콤함과 페페론치노의 매콤한 조합이 좋다. 

계란, 그린빈, 미니당근, 컬리플라워 라이스, 발사빅 소스