본문 바로가기

전체 글

 (117)
Essay. #3 .... ㅎㅎ 그렇다 계획은 다시 한번 물거품이 되었다. 사실 쓰려고 하면 쓸 수 있었지만 내가 세운 계획은 너무 무리였다. 주기를 한 주로 줄여서 쓰는 것도 지금 상황에서는 조금 무리인 거 같다. 물론 회사 코드 베이스를 익히고 관련된 일을 하면서 파이썬이나 리액트에 대해 공부하지만, 예전처럼 내가 주제를 잡고 쓰기에는 애매한 거 같다. 아니면 내가 너무 급하게 일처리를 하는 거 같기도 하다. 모르는 게 있으면 뭔가 조금 시간을 투자해서 봐야 되는데 해결하기에만 급급한 거 같기도 하고.. 리드님도 중간에 모르는 게 있을 때 시간이 조금 들겠지만 더 정확히 공부를 하고 진행하는 게 당연히 더 효율적이라고 하셨다. 지금은 관련된 지식에 대해 깊게 공부하지 않는 거 같다. GraphQL이나 Django에 대..
This Week. 2.14 ~ 2.18 회사에 출근하고 거의 테스트 코드 리팩터링을 했다. 기존에 fixture 들로 짜인 코드들을 FactoryBoy라는 파이썬 라이브러리를 사용해서 리팩터링 했는데, 이게 내가 너무 조급한 건지 모델이랑 코드가 복잡해서 그런지 생각보다 어려웠다. 팩토리 보이 자체가 어렵다기보다는 결국에 이게 지금 서비스의 모델을 기반으로 테스트 모델들을 만들어줘서 결국 모델이 복잡하니까 더 헷갈렸다. 또 너무 조급해서 그런지 코드만 쳐다보고 있어서 시간을 효율적으로 못쓴 거 같다. 팩토리 보이를 쓰면 중복되는 테스트 코드량도 줄고 또 테스트 코드 작성하면서 서비스 전반적으로 파악할 수 있는 거 같다. relatedfactory이니 post_generation이니 구체적인 개념은 사실 공식문서에 더 정확히 나와서 공식문서를 ..
Essay. #2 그렇다 결국 내가 계획했던 블로그 글쓰기 계획은 첫 출근과 함께 무너졌다. ㅎㅎ 핑계 아닌 핑계로 거의 2주가 다되어 가는데 블로그 정리할 시간이 없었다. 회사 코드 베이스 익히는 시간도 있었고, 지금도 계속 익히고 있지만.. git도 내가 쓰던 방식이랑 너무 달랐고 내가 모르는 게 너무 많고 또 익숙하지 않았다. 초반에 그리고 지금도 거의 테스트 코드를 보면서 리팩터링을 위주로 하고 있다. 작은 태스크를 하기는 했는데, 그것도 생각보다 오래 걸렸다. 마음이 조급해서 그런지 회사에 오래 있으면서 공부를 해도 뭔가 집중이 잘 안 되고 생각보다 코드 구조 파악하기가 너무 어려웠다. 리드님이 너무 조급해할 필요 없다고 하셨는데, 그게 맘처럼 잘 안 되는 거 같다. 아무튼 할 얘기가 많지만 이쯤 해 두고 계획을..
Book. 수학이 필요한 순간 이 책은 정글 들어가기 전에 읽다가 다 못 읽어서 끝나고 다시 읽게 되었다. 일단 너무 재밌게 읽었다 수학 관련 책을 읽고 싶어서 산 책이었는데 대략 300 pg 정도로 비교적 짧은 책이었고 내용도 수학을 잘 모르는 독자들을 최대한 배려해서 쓰신 거 같아서 빠져들어서 읽은 거 같다. 책은 대화 형식으로 질문과 답변을 통해 이야기가 진행이 되는데, 수학이 무엇인지에 대해 이야기 하면서 시작이 된다. 우리가 일반적으로 수학에 대해 갖고 있는 오해들과 관점에 대해서 설명하면서 다양한 예시를 보여준다. 각 장을 통해서 수학이 무엇인지 또 수학적인 사고가 무엇인지를 알려준다. 3,4,5 강을 읽어보면 우리가 흔히 현실에서 만날 수 있는 문제들과 윤리적, 사회적 문제들, 쉽게 답을 내릴 수 없는 문제들을 수학적인 ..
This Week. 2.1 ~ 2.6 이번 주는 리팩터링만 읽은 거 같다. 알고리즘들을 조금씩 풀고 있기는 한데, 기본적인 문제들을 다시 보는 중이다. 오늘은 타입 스크립트 복습도 하고 리팩터링도 복습할 겸 리팩터링 예시 코드를 타입 스크립트로 바꿔봤다. 막상 개념적으로 알고 있던 것들 바꾸려니까 익숙하지가 않아서 힘들었다. 특히 객체들 타입 정하는 게 생각보다 깔끔하게 하기가 힘들다. 실제로 실무에서는 밑에 처럼 하면 안 될 텐데 어떤 식으로 타입들을 작성해야 깔끔한지 아직 잘 감이 안 온다. 다른 코드들 좀 많이 봐야겠다. 기존 코드는 https://kspsd.tistory.com/103 여기에 있다. import type {play,playValue} from "./plays.js" import type {performance ,inv..
Refactoring. 리팩터링이 필요한 경우 저번 장에서도 간단하게 언제 리팩터링이 필요한지 간단하게 정리했지만 3장에서는 필요한 경우를 좀 더 디테일하게 다룬다. 이 부분은 익숙해질 때까지 자주 와서 읽어야겠다. 시작해 보자 코드를 명료하게 표현하는 데 가장 중요한 요소 하나는 이름이다. 함수, 모듈, 변수, 클래스 등은 그 이름만 보고도 각각이 무슨 일을 하고 있는지 어떻게 사용해야 하는지 명확히 알 수 있도록 신경 써서 이름을 지어야 한다. 마땅한 이름이 떠오르지 않는다면 설계에 더 근본적인 문제가 숨어 있을 가능성이 높다. 그래서 혼란스러운 이름을 잘 정리하다 보면 코드가 훨씬 간결해질 때가 많다. 다음으로 필요한 경우는 코드가 중복되는 경우다. 코드가 중복되면 각각을 볼 때마다 서로 차이점은 없는지 주의 깊게 살펴봐야 하는 부담이 생긴다...
Refactoring. 리팩터링 원칙 2장에서는 리팩터링 전반에 적용되는 원칙을 정의, 리팩터링 시기, 고려해야 할 문제 등을 통해 알아본다. 먼저 책에서 정의 하는 리팩터링 정의를 보자. 명사로는 소프트웨어의 겉보기 동작은 그대로 유지한 채, 코드를 이해하고 수정하기 쉽도록 내부 구조를 변경하는 기법. 동사로는 소프트웨어의 겉보기 동작은 그대로 유지한 채, 여러 가지 리팩터링 기법을 적용해서 소프트웨어를 재구성하다.라고 나와있다. 보통 많은 사람이 코드를 정리하는 작업을 모조리 '리팩터링'이라고 표현하는데 앞선 정의를 따르면 특정한 방식에 따라 코드를 수정하는 것만이 리팩터링이다. 누군가 리팩터링하다가 코드가 깨져서 며칠간 고생했다라고 한다면 리팩터링 잘못한 거라고 한다. 앞에서 래픽터링을 정의할 때 '겉보기 동작'이란 표현을 썼는데, 이..
Refactoring. 계산 단계와 포맷팅 분리, 다형성 활용한 코드 재구성 저번 리팩토링 글에 이어서 1장 나머지 부분을 정리하려고 한다. 먼저 기존에 작성된 코드를 단개 쪼개기라는 방법을 통해 재구성해야 한다. 근데 이전에 리팩터링 한 결과의 코드는 statement 안에 중첩 함수로 들어가 있다. 이대로 기능을 추가하면 코드를 그대로 복사해서 HTML버전을 만들게 될 거다. 그래서 여기서 목표는 텍스트 버전과 HTML 버전 함수 모두가 똑같은 계산 함수들을 사용하게 만들고 싶다. 따라서 statement 함수의 로직을 두 단계로 나눌 것이다. 첫 단계에서는 statmnet에 필요한 데이터를 처리하고, 다음 단계에서는 앞서 처리한 결과를 텍스트나 HTML로 표현하도록 한다. 일단 기존 코드를 다음과 같이 수정한다 mport plays from "./plays.js" impor..

티스토리툴바