본문 바로가기
[실용주의 프로그래머] 가차 없는 테스트 [실용주의 프로그래머] 가차 없는 테스트 -개발자 대부분은 테스트를 싫어한다.코드가 어디에서 깨지는지 무의식적으로 알고 약한 지점을 피해 다니면서, 살살 테스트하려 한다.실용주의 프로그래머들은 다르다.우리는 당장 버그를 찾아 나서도록 내몰리지만, 그 대신 나중에 다른 사람이 자기 버그를 발견하게 되는 수치를 피할 수 있다. -일찍 테스트하고, 자주 테스트하라. 자동으로 테스트하라. -코드를 작성하자마자 테스트해야 한다. -버그가 빨리 발견될수록 고치는 비용이 적어진다.코드 조금, 테스트 조금은 스몰토크 세계에서는 유명한 격언이다.우리는 제품 코드를 만드는 것과 동시에(혹은 이전에) 테스트 코드를 만듦으로써 그 주문을 우리것으로 할 수 있다. -사실 훌륭한 프로젝트에는 제품 코드보다도 테스트 코드가 더 많.. 2018. 11. 15.
[실용주의 프로그래머] 리팩터링 [실용주의 프로그래머] 리팩터링 -코드가 더 이상 잘 맞지 않아서 장애물에 부딪혔을 때, 사실은 하나로 합쳐져 있어야 할 두 개를 발견했을 때, 어떤 것이든 ‘잘못’ 되었다고 생각될 때, 그것을 변경하는 일을 주저하면 안 된다. 언제나 바로 지금이 최적기다. 어떤 것이라도 코드를 리팩터링해야 할 이유가 될 수 있다. 중복, 직교성이 좋지 않은 설계, 유효기간이 끝난 지식, 성능 -코드를 리팩터링하는 것은 사실 고통 관리(pain management)를 실천하는 것이다.현실을 피하지 말자. 소스코드를 이곳저곳 변경하는 것은 굉장히 고통스러운 작업일 수도 있다.거의 작동하는 수준까지 올려놓은 코드였는데, 이제 완전히 망가져 버린다.코드를 산산조각으로 해체하는 일을 주저하는 개발자들이 많은데, 그 까닭은 그런.. 2018. 11. 5.
[실용주의 프로그래머] 디버깅 [실용주의 프로그래머] 디버깅 -소프트웨어 결함은 요구사항을 오해하는 것에서 코딩 에러에 이르기까지 여러 모습으로 나타난다. 디버깅의 심리 -디버깅은 단지 문제 해결이라는 사실을 포용하고, 그 방식으로 공략하라.다른 사람의 버그를 발견한 후, 그 버그를 만들어낸 부정한 범죄자를 비난하는 데에 시간과 노력을 들이는 수가 있다.하지만 기술의 전당에서는 남을 비난하기보다 문제를 고치는 데에 집중하고 싶어한다. 비난 대신 문제를 해결하라. -버그가 여러분의 잘못인지 다른 사람의 잘못인지는 그리 중요한 게 아니다. 어쨌거나 그 버그는 여러분의 문제로 남는다. 디버깅 사고방식 -디버깅을 시작하기에 앞서서 올바른 사고방식을 갖는 게 중요하다.자신의 자아를 보호하기 위해 매일 사용하는 많은 방어시설을 꺼버려야 한다. .. 2018. 10. 21.
[실용주의 프로그래머] 직교성 [실용주의 프로그래머] 직교성 -설계, 빌드, 테스트 그리고 확장하기에 쉬운 시스템을 만드는 데에 있어 직교성(Orthogonality)은 매우 중요한 개념이다. 직교성이란 -컴퓨팅에서 이 용어는 일종의 독립성(independence)이나, 결합도 줄이기(decoupling)을 의미한다.하나가 바뀌어도 나머지에 어떤 영향도 주지 않으면 서로 직교한다고 할 수 있다. 비직교적인 시스템 직교성의 장점 -시스템의 컴포넌트들이 고도로 상호의존적인 경우, 특정 국지적 부분만 수정하는 방법이란 없다. “” 관련 없는 것들 간에 서로 영향이 없도록 하라. “” -컴포넌트들이 각기 격리(isolate)되어 있으면 어느 하나를 바꿀 때 나머지 것들을 걱정하지 않아도 된다.해당 컴포넌트의 외부 인터페이스를 바꾸지 않는 한.. 2018. 9. 30.
[도서 정리] 안드로이드 앱 성능 최적화 #2 안드로이드 디바이스 랩 만들기 안드로이드 앱 성능 최적화 #2 안드로이드 디바이스 랩 만들기 이 글은 “안드로이드 앱 성능 최적화” 의 일부 내용만 정리한 것입니다.자세한 내용은 책을 구매하여 보세요~-구글에서는 전 세계적으로 활성화된 안드로이드 기기가 14억 대가 넘었다고 발표했다.전 세계에 보급된 전체 스마트폰의 80% 에 해당하는 수치이다. -TestDroid 의 연구에 따르면 상위 20% 기기를 테스트해보려면 12대의 기기가 필요하다.50% 를 테스트해보려면 최소 60대의 기기가 필요하다. 미국 시장으로 한정하더라도 66% 를 테스트해보려면 25대의 기기가 필요하고90% 정도를 테스트해보려면 128대의 기기가 필요하다고 하다. 2.1. 고객들은 어떤 기기를 사용하나요 -2016년 9월 기준 킷캣(KK)은 27.7%, 젤리빈(J.. 2018. 6. 23.
[Effective Java] 메소드 시그니처를 신중하게 설계하자. [Effective Java] 메소드 시그니처를 신중하게 설계하자. - 메소드 이름을 신중하게 짓자. 이름은 항상 표준 작명 규칙을 따라야 한다. 이름에는 일관성이 있어야 한다. 폭넓게 공감 가는 이름을 선택해야 한다. - 편리한 메소드를 만드는데 너무 열중하지 말자. 모든 메소드는 자신의 역할을 해야 한다. 메소드가 너무 많으면, 클래스를 배우고 사용하고 문서화하고 테스트하고 유지하기가 어렵다. 클래스나 인터페이스가 지원하는 각 동작에 대해서 충분한 기능을 수행하는 메소드를 제공하자. - 너무 많은 매개 변수를 피하자. 매개 변수는 네 개 이하를 목표로 하자. 매개 변수가 네 개를 넘으면 시종일관 문서를 참조하지 않고는 그 메소드 API 를 사용할 수 없다. 같은 타입의 매개 변수가 길게 나오면 특히 .. 2017. 1. 12.
[Effective Java] 추상 클래스보다는 인터페이스를 사용하자. [Effective Java] 추상 클래스보다는 인터페이스를 사용하자. - 인터페이스(interface)와 추상클래스(abstract class)는 비슷하지만 다르다. 추상 클래스는 구현된 메소드를 포함할 수 있는 반면 인터페이스는 그렇지 못하다. 추상 클래스로 정의된 타입을 구현하는 클래스는 반드시 추상 클래스의 서브 클래스가 되어야 한다. 인터페이스를 구현하는 클래스의 경우 인터페이스에 정의된 모든 메소드를 구현하기만 하면 된다. 자바는 단일 상속만을 허용하므로 추상 클래스로 타입을 정의할 때 심한 제약이 따른다. - 인터페이스는 추상 클래스에 비해 변경과 적용이 쉽다. - 인터페이스는 믹스인(mixin)을 정의하는 데 이상적이다. 믹스인은 클래스가 자신의 본래 타입에 추가하여 구현할 수 있는 타입으.. 2016. 11. 7.
[Effective Java] 상속을 위한 설계와 문서화를 하자. 그렇지 않다면 상속의 사용을 금지시킨다. 상속을 위한 설계와 문서화를 하자. 그렇지 않다면 상속의 사용을 금지시킨다. - 메소드 오버라이딩으로 인한 파급 효과를 분명하게 문서화해야 한다. 같은 클래스의 다른 메소드들이 호출하는지에 대해 반드시 문서화해야 한다. ( self-use ) - 각각의 public 이나 protected 메소드 및 생성자가 어떤 오버라이드 가능한 메소드를 호출하는지, 어떤 순서로 하는지, 호출한 경로가 다음 처리에 어떤 영향을 주는지에 대해서도 반드시 문서화해야 한다. 오버라이드 가능하다는 것은 final 이 아니면서 public 이나 protected 인 경우를 의미한다. - 관례적으로 오버라이드 가능한 메소드를 호출하는 메소드에는 문서화 주석의 제일 끝에 그런 호출에 대한 설명을 추가한다. 그리고 설명의 시작은 "이.. 2016. 11. 1.
[Effective Java] 클래스와 그 멤버의 접근성을 최소화하자. [Effective Java] 클래스와 그 멤버의 접근성을 최소화하자. - 잘 설계된 모듈과 그렇지 않은 것을 구분 짓는 가장 중요한 잣대는, 모듈 자신의 내부 데이터 및 그 외의 상세한 구현 부분을 다른 모듈로부터 어느 정도로 숨기느냐에 달려 있다. - 모듈은 자신의 API 를 통해서만 다른 모듈과 상호작용한다. 정보 은닉(information hiding) 또는 캡슐화(encapsulation)이 그것이다. - 정보 은닉은 시스템을 구성하는 모듈들 간의 결합도를 낮추어(decoupling) 모듈 별로 개발, 테스트, 최적화, 사용 및 수정이 가능하도록 한다. 또한 이렇게 하면 병행 개발 ( parallel development ) 를 할 수 있어 시스템 개발이 빨라진다. 모듈을 더 빨리 파악할 수 있.. 2016. 10. 17.
반응형