IT/책읽는 개발자 (10) 썸네일형 리스트형 개발자의 글쓰기 - (2장. 개발 시간을 줄여주는 이름 짓기와 주석 쓰기) http://www.yes24.com/Product/Goods/79378905 개발자의 글쓰기 - YES24 오직 개발자를 위한 글쓰기의 모든 것을 담았다!이 책은 개발자의 글쓰기 능력을 종합적으로 향상하기 위한 책이다. 코드 안에서는 함수와 변수 이름을 짓는 것부터 주석 쓰는 법, 에러 메시지 www.yes24.com 2장 개발 시간을 줄여주는 이름 짓기와 주석 쓰기 01. 네이밍 컨벤션, 이유를 알고 쓰자 개발자의 가장 큰 고민은 이름 짓기 이름을 잘못 지어서 코드를 이해하기 어렵고, 자기가 이름을 지어놓고도 나중에는 그 이름이 무엇을 뜻하는지 모를 때도 많다. 잘만 하면 코드를 짜기도 쉽고 이해하기도 쉽다. 또한 다른 개발자 및 외부와 소통도 쉽고 문서를 대신할 수도 있다. 이름 짓기는 창조가 아니.. [레거시 코드 활용 전략] CH7 코드 하나 바꾸는 데 왜 이리 오래 걸리지? 2020/02/03 - [IT/책읽는 개발자] - [레거시 코드 활용 전략] CH1 소프트웨어 변경 2020/02/04 - [IT/책읽는 개발자] - [레거시 코드 활용 전략] CH2 피드백 활용 2020/02/06 - [IT/책읽는 개발자] - [레거시 코드 활용 전략] CH3 감지와 분리 2020/02/07 - [IT/책읽는 개발자] - [레거시 코드 활용 전략] CH4 봉합 모델 CH5 는 단순한 테스트 도구와 관련된 이야기라 다루지 않습니다~ 2020/02/10 - [IT/책읽는 개발자] - [레거시 코드 활용 전략] CH6 고칠 것은 많고 시간은 없고 - 1 2020/02/15 - [IT/책읽는 개발자] - [레거시 코드 활용 전략] CH6 고칠 것은 많고 시간은 없고 - 2 ch 7 - 코드 .. [레거시 코드 활용 전략] CH6 고칠 것은 많고 시간은 없고 - 2 2020/02/03 - [IT/책읽는 개발자] - [레거시 코드 활용 전략] CH1 소프트웨어 변경 2020/02/04 - [IT/책읽는 개발자] - [레거시 코드 활용 전략] CH2 피드백 활용 2020/02/06 - [IT/책읽는 개발자] - [레거시 코드 활용 전략] CH3 감지와 분리 2020/02/07 - [IT/책읽는 개발자] - [레거시 코드 활용 전략] CH4 봉합 모델 CH5 는 단순한 테스트 도구와 관련된 이야기라 다루지 않습니다~ 2020/02/10 - [IT/책읽는 개발자] - [레거시 코드 활용 전략] CH6 고칠 것은 많고 시간은 없고 - 1 ch 6 - 고칠 것은 많고 시간은 없고 - 2 포장 메소드 기존 메소드에 동작을 추가하는 것은 아주 간단하다. 하지만 이것이 항상 옳은 .. [레거시 코드 활용 전략] CH6 고칠 것은 많고 시간은 없고 - 1 2020/02/03 - [IT/책읽는 개발자] - [레거시 코드 활용 전략] CH1 소프트웨어 변경 2020/02/04 - [IT/책읽는 개발자] - [레거시 코드 활용 전략] CH2 피드백 활용 2020/02/06 - [IT/책읽는 개발자] - [레거시 코드 활용 전략] CH3 감지와 분리 2020/02/07 - [IT/책읽는 개발자] - [레거시 코드 활용 전략] CH4 봉합 모델 CH5 는 단순한 테스트 도구와 관련된 이야기라 다루지 않습니다~ ch 6 - 고칠 것은 많고 시간은 없고 - 1 현실적으로 레거시에서는 잘 하지 않았던 행위들을 공부하고 있을 수 있다. 또한 테스트 코드를 작성 및 코드 변경에 많은 시간이 필요한 작업이다. 그렇기 때문에 정말로 '가치'가 있는지 궁금할 때가 있다. 실제로.. [레거시 코드 활용 전략] CH4 봉합 모델 2020/02/03 - [IT/책읽는 개발자] - [레거시 코드 활용 전략] CH1 소프트웨어 변경 2020/02/04 - [IT/책읽는 개발자] - [레거시 코드 활용 전략] CH2 피드백 활용 2020/02/06 - [IT/책읽는 개발자] - [레거시 코드 활용 전략] CH3 감지와 분리 ch 4 - 봉합 모델 봉합 단위 테스트를 위해 개별 클래스를 추출하려고 하면 수많은 의존 관계를 제거할 필요가 있다. '좋은' 설계를 기반하고 있다 하더라도 많은 작업이 수반된다. 많은 작업 중 하나인 '봉합'이라는 개념을 알아보자. 우선 봉합은 코드를 직접 편집하지 않고도 프로그램의 동작을 변경할 수 있는 위치를 말한다. 아래 예제를 보자 public class MailSender { public void sen.. [레거시 코드 활용 전략] CH3 감지와 분리 2020/02/03 - [IT/책읽는 개발자] - [레거시 코드 활용 전략] CH1 소프트웨어 변경 2020/02/04 - [IT/책읽는 개발자] - [레거시 코드 활용 전략] CH2 피드백 활용 ch 3 - 감지와 분리 이상적인 환경이라면 변경 작업을 하기 전 특별히 할 일이 없다. 테스트를 하고 싶은 대상을 테스트 코드 내에서 객체를 생성해 작업을 하면 끝이다. 하지만 불행하게도 클래스들의 의존 관계들 때문에 이것은 거의 불가능하다. 의존관계를 제거해야 하는 이유는 무엇일까? 크게 두 가지로 볼 수 있다. 감지 : 코드 내에서 계산된 값에 접근하여 변경이나 값을 확인할 수 없을 때 분리 : 코드를 테스트 코드 내에서 실행할 수 없을 때 코드 분리를 위해 예제 코드 public class Network.. [레거시 코드 활용 전략] CH2 피드백 활용 이전글 : 2020/02/03 - [IT/책읽는 개발자] - [레거시 코드 활용 전략] CH1 소프트웨어 변경 ch 2 - 피드백 활용 시스템을 변경하는 방법에는 크게 두가지가 있다. 수정 후 기도하기 보호 후 수정하기 일반적인 개발 방법에서는 1번이 많이 사용된다. 1번 같은 경우 코드 변경 대상 코드를 이해하고, 계획을 세운 후 변경 작업에 들어간다. 변경을 완료하고 나서는 제대로 동작하고, 의도하지 않는 영향이 있는지 조사한다. 결과적으로 작업 결과를 확인하고 검토하는 시간이 추가로 들어가게 된다. 얼핏 보기에는 이는 매우 '신중'하고 '전문'적인 방식처럼 보인다. 그러나 아무리 신중해도 이것이 안전성에 비례한다는 보장은 없다. '보호 후 수정하기' 방법은 조금 다른 방식으로 코드를 변경한다. 변경.. [레거시 코드 활용 전략] CH1 소프트웨어 변경 레거시 코드 활용 전략 (재출간판) 국내도서 저자 : 마이클 C. 페더스(Michael C. Feathers) / 심윤보,이정문역 출판 : 에이콘출판사 2018.09.28 상세보기 ch 1 - 소프트웨어 변경 소프트웨어를 변경하는 이유 새로운 기능 추가 버그 수정 설계 개선 자원 이용의 최적화 1.기능 추가와 버그 수정 지금 하는 것이 버그 수정? or 기능 추가? 고객 관점 : 내가 원하는 건 A 기능이 아니라 B기능 이야 → 버그 수정 개발자 관점 : B라는 새로운 기능 기술 및 개발 관점에서 버그 수정 / 기능 추가 보다 더 중요한 것은 ? → 동작 변경 새로운 동작을 추가하는 것과 기존 동작을 변경하는 것에는 큰 차이가 있음 기존 코드 변경 → 동작 변경 새로운 코드 추가 → 동작 추가 그러나 대.. [한달 한권] 소프트웨어 장인 소프트웨어 장인 국내도서 저자 : 산드로 만쿠소 / 권오인역 출판 : 길벗 2015.09.25 상세보기 1. 내가 이 책을 선택한 이유 현재 나는 많은 것이 바뀌는 상황에 있다. 외부적으로나 내부적으로 말이다. 외부적으로는 새로운 직장으로 옮긴 지 6개월 정도가 지났고, 담당하는 서비스에도 어느 정도 익숙해졌다. 그리고 담당한 서비스를 더욱 발전시키고 가치를 더하고 싶은 상황이다. 내부적으로는 많은 것을 바꾸기 위해 시도하고 있다. 스스로 느끼기에는 어느 정도 드라이브만 더 건다면 한 단계 더 성장할 수 있을 것 같은 느낌이 드는 상황이다. 이러한 상황에서 어떤 책을 읽어야 할까라고 고민하던 도중 해당 책을 골랐다. 순전히 제목이 큰 역할을 했다. 내가 지금 모든 상황에서 필요한 건 장인정신이 아닐까라는.. [한달 한권] 함께 자라기 오늘의 책 : 함께 자라기 링크 : 네이버 책 애자일 ? 함께 협업하는 방법과 자라는 방법을 통해 불확실한 환경에서 애자일을 완성해 나가는 방법을 알게 만든 책이다. 이 책을 읽지 전에는 나 또한 '애자일을 하는 방법이 뭘까?', '애자일을 하려면 필요한 도구는?' 등과 같은 생각을 했다 하지만 불확실한 환경을 위한 애자일에 완벽한 준비사항은 애초부터 없었던 것인것 같다. 학습과 협력을 통해 그러한 불확실에 대비하고 빠른 피드백을 전달 할 수 있는 애자일은, 어쩌면 많은 시도를 통해 스스로 만들어 나가야 하는 과정일 것이다. 책 속에서 애자일에 씨앗이라는 문구를 아래와 같이 말하고 있다. 고객에게 매일 가치를 전하라. 고객에게 진짜 고객은 누구인가 ? 매일 어떻게 점진적으로 가치를 전할 것인가? 어떻게 .. 이전 1 다음
