개발/자습중
-
읽기 좋은 코드가 좋은 코드다 / 더스틴 보즈웰, 트레버 파우커개발/자습중 2019. 1. 7. 14:55
아직 개발 경력으로는 걸음마는 커녕 바닥을 기어다니는 수준이지만 선배들이 만들어둔 코드를 보면서 항상 누가 봐도 쉽게 눈에 들어도록 최대한 간결하게 코드를 짜는 것을 목표로 하자고 다짐했다. 그런 의미에서 이 책 "읽기 좋은 코드가 좋은 코드다"는 제목에서부터 내가 지향하는 바를 아주 정확하게 저격한다. 분량도 적당하고 내용도 읽기 쉽게 적절한 예시 코드와 함께 제시되어 있어서 무척 맘에 들었다.추천추천 1. 이름에 정보 담아내기 - 변수, 함수 혹은 클래스 등의 이름을 결정할 때는 이름이 일종의 설명문이 된다고 생각하고 이름에 정보를 담아낼 수 있도록 해야 한다. 즉 구체적이고 명확하며 적절한 길이의 이름을 붙여준다. - 생성자는 대문자로, 평범한 함수는 소문자로 표기하거나 jQuery의 결과를 저장하..
-
리팩토링 / 마틴 파울러 - (4) Chapter 03. 코드의 구린내개발/자습중 2018. 2. 13. 10:13
세번째 챕터에서는 어떤 코드가 리팩토링을 해야 하는 '구린내 나는' 코드인지 설명한다. 저자의 말대로 세번째 챕터를 읽자마자 그래! 바로 요 줄부터 저 줄까지 리팩토링을 하면 되겠군!! 할 수 있는 건 아니고대충 이런 느낌이 올 때 리팩토링을 쓸 수도 있겠다 정도의 감은 잡을 수 있다. 아직 경험이 부족해서 그런지 깔끔하게 요약해서 정리하기 어려웠다. 이번 챕터만큼은 한번 읽고 넘어가는 수준에서 정리한다. 저자가 말하는 구린내 목록은 아래와 같다. 1. 중복코드 - 똑같은 코드 구조가 두 군데 이상 있을 때는 그 부분을 하나로 통일 시 프로그램 개선 가능 2. 장황한 메소드 - 메소드에서 하나로 묶으면 좋을 만한 부분들을 찾아내어 메소드로 만들어줌 3. 방대한 클래스 - 기능이 지나치게 많은 클래스 4...
-
리팩토링 / 마틴 파울러 - (3) Chapter 02. 리팩토링 개론개발/자습중 2018. 2. 12. 13:45
두번째 챕터는 본격적으로 리팩토링에 대한 개념을 잡는 시간이다. 리팩토링은 단순히 코드 정리 작업을 의미하지 않는다.리팩토링의 핵심은 소프트웨어를 더 이해하기 쉽게, 수정하기 쉽게 만드는 것이므로 코드 정리 작업보다는 좀 더 광범위한 개념이 될 것이다.또한 기능을 개선하기 위한 작업이 아니므로 리팩토링 전후의 소프트웨어 기능은 변하지 않는다. 따라서 리팩토링은 '성능 최적화'와 상반되는 개념이라고 할 수 있다. 왜냐하면 성능 최적화를 수행할 경우, 필요한 성능을 얻기 위해 어쩔 수 없이 코드가 더 복잡해질 수 있기 때문이다. 리팩토링을 하는 이유와 효과에 대해서는 저자가 언급한 랄프 존슨의 비유로 축약한다."....이러한 최초 단계의 리팩토링은 '우선 창 밖이 보이게 뿌연 유리창부터 닦는 일'과 같다고 ..
-
리팩토링 / 마틴 파울러 - (2) Chapter 01. 맛보기개발/자습중 2018. 2. 9. 14:13
모든 공부는 개념 정리부터 시작한다.이 책도 마찬가지로 첫 장에서 리팩토링의 개념을 짚어보고, 대충 리팩토링이 어떤 것인지 예제를 보여주고 있다.나도 모르는 사이에 리팩토링을 하고 있었다니...! 하고 놀라면서 첫 장을 정리한다. 리팩토링이란 - 겉으로 드러나는 코드의 기능은 바꾸지 않으면서 내부 구조를 개선하는 방식으로 소프트웨어 시스템을 수정하는 과정- 버그가 생길 가능성을 최소화하며 코드를 정리하는 정제된 방법- 코드를 작성하고 난 뒤 설계를 향상시키는 일 기억해둬야 할 점 1. 적절한 테스트 코드를 작성하는 것이 리팩토링의 기본이다. '간단한 수정 → 테스트'를 리듬처럼 반복할 때만 리팩토링을 빠르고 안정적으로 완료 가능 2. 너무 긴 메소드는 분해하여 기능을 재분배해야 한다. 코드를 잘게 쪼개면..
-
리팩토링 / 마틴 파울러 - (1) 발단개발/자습중 2018. 2. 9. 14:00
첫번째 프로젝트에 투입되었을 때는 이미 기존 개발자들이 1차 오픈 대상 기능을 80% 이상 구현해둔 상태였다. 나는 1차 오픈 이후 철수한 프리랜서들이 만들어둔 코드를 유지보수하면서 2차 오픈 대상 기능을 만들어야 했는데,공통 메소드 같은 것들은 거의 다 완성되어 있었기에 편하기도 했고, 남이 짜놓은 소스를 다시 들여다보면서 수정해야 하기도 해서 고생도 많이 했다. 하루는 급작스럽게 조건 처리 로직이 변경되면서 정기배포 2시간 전에 급하게 조건문을 수정해서 배포했다.당연히 테스트할 시간이 부족했지만 부장님이 잘못되면 책임지시겠다는 말을....바보같이 믿고 찝찝해하며 배포를 진행했다.이런 경우는 거의 95%의 확률로 배포 당일날에는 발견하지 못했던 에러를 배포 다음날에 발견한다.이 날도 역시 배포 직후 테..