Victoree's Blog

이 페이지는 GURU 사이트 [what-is-refactoring] How to refactor의 번역을 담고 있습니다. 리팩토링 하는 방법 리팩토링은 일련의 작은 변경으로 수행되어야 하며, 각 변경으로 기존 코드가 약간 개선되고 프로그램은 여전히 작동중인 상태로 유지되어야 합니다. 올바르게 리팩토링되기 위한 체크리스트 1. 코드가 깨끗해져야 합니다. 리팩터링 후에도 코드가 똑같이 더러운 상태로 남아 있으면... 미안하지만, 당신은 인생의 한 시간을 낭비했습니다. 왜 이렇게 되었는지 알아내려 노력해보세요. 작은 변화들로 리팩터링을 하는 것에서 벗어나 많은 리팩터링을 하나의 큰 변화로 혼합할 때 이런 일이 종종 발생합니다. 이럴 때 정신을 잃기 쉬운데, 특히 시간 제한이 있다면 더욱 그렇습니다. 또 매우 ..

이 페이지는 GURU 사이트 [what-is-refactoring] When to refactor의 번역을 담고 있습니다. When to refactor When to refactor Rule of Three When you’re doing something for the first time, just get it done. When you’re doing something similar for the second time, cringe at having to repeat but do the same thing anyway. When you’re doing something for the thi refactoring.guru 리팩토링의 시기 1. 세 가지 규칙 처음에는 그냥 하세요. 비슷한 일을 두 번째..

이 페이지는 GURU 사이트 [what-is-refactoring] Technical Debt의 번역을 담고 있습니다. Technical debt Technical debt Everyone does their best to write excellent code from scratch. There probably isn’t a programmer out there who intentionally writes unclean code to the detriment of the project. But at what point does clean code become unclean? The metapho refactoring.guru Technical Debt 모든 사람들은 처음부터 훌륭한 코드를 쓰기위해 최선을..

이 페이지는 GURU 사이트 [what-is-refactoring] Clean Code의 번역을 담고 있습니다. Clean code Clean code The main purpose of refactoring is to fight technical debt. It transforms a mess into clean code and simple design. Nice! But what’s clean code, anyway? Here are some of its features: Clean code is obvious for other programmers. And I’m not refactoring.guru Clean Code 리팩토링을 하는 주 목적은 기술 부채와 싸우기 위함입니다. 리팩토링은 엉망인 코..

함수 플래그 인수는 추하다 왠만하면 잘못되었을 확률이 큼 join_funding_channel() 한 함수에서 두 가지 작업을 하고 있음 (채널 추가 && 채널 추가 여부 확인) id 값을 kakao_account_id, talk_user_id 두 가지를 지원하고 있는데, 하나만 지원하도록 kakao_account_id 인 경우는 함수 밖에서 처리하고 인풋으로 넘기면 되지 않을까.. 인수가 3개 이상이 되면,, 캡슐화 시키는 게 나을까요? 보통 같이 응집되어 붙어다니는 이유가 있음 클래스나 하나의 오브젝트로 감싸는 방법도 좋음 (케바케) core나 앱의 utils에 type을 만들어서 관리하는 방법도 있음 물고있는 컨넥션이 있을 때는 클래스로 구성해서 분리해도 좋음 굳이 특정 값을 들고 있을 필요가 없을..

코드 리뷰 시간을 줄이기 위해 클린코드라는 책을 읽고, 매주 책 내용에 대한 토의 및 개발한 코드 중 개선할 부분을 찾아보기로 하였다. 1장. 깨끗한 코드 Software 유연해서 소프트웨어라지만 아니다! models 같이 low한 영역일수록 고치기가 더 어려워짐 코드는 항상 클린한 상태를 유지하도록! 더러운 코드에 기능만 붙이다가 어느 순간 기능을 추가할 수 없는 코드로 변질 -> 몰락 넷스케이프 흥행과 몰락 추상화는 어려워 Minter 앱 개발 당시, Queue -> Serial Pool로 변형 클래스의 상속이나 캡슐레이션 같은 추상화말고 기능적인 측면에서 어떤 부분을 추상화시킬지는 항상 고민하면서 구현해야 한다 2장. 의미있는 이름 data라는 변수를 툭 사용하지 말것 # data = { not_v..