본문 바로가기

프로그래밍/Java12

1주차 1. JVM 이란 Java Virtual Machine Java Byte Code를 OS에 맞게 해석 해주는 역할 JVM의 해석을 거치기 때문에 c언어 같은 네이티브 언어에비해 속도가 느렸지만 JIT(Just In Time)컴파일러를 구현해 이점을 극복 2. 컴파일 하는 방법 javac 파일 이름 3. 실행하는 방법 java 파일 이름 4. 바이트 코드 자바 바이트 코드(Java bytecode)란 자바 가상 머신이 이해할 수 있는 언어로 변환된 자바 소스 코드 5. JIT 컴파일러 JIT(Just-in-Time) 컴파일러는 바이트코드를 컴퓨터 프로세서(CPU)로 직접 보낼 수 있는 명령어로 바꾸는 프로그램 6. JVM 구성요소 Class Loader, Memory, Execution Engine 7. .. 2021. 12. 5.
나쁜 코드 지우기 8 * 일반 G21. 알고리즘을 이해하라 - 대다수 괴상한 코드는 사람들이 알고리즘을 충분히 이해하지 않은 채 코드를 구현한 탓이다잠시 멈추고 실제 알고리즘을 고민하는 대신 여기저기 if문과 플래그를 넣어보며 코드를 돌리는 탓이다 프로그래밍은 흔히 탐험이다 알고리즘을 안다고 생각하지만 실제는 코드가 '돌아갈' 때까지 이리저리 찔러보고 굴려본다.'돌아간다'는 사실은 어떻게 아느냐고? 생각할 수 있는 테스트 케이스를 모두 통과하니까이 방식이 틀렸다는 말이 아니다 사실상 대다수 상황에서는 원하는 대로 함수를 돌리는 유일한 방법이다하지만 '돌아간다'고 말하기는 뭔가 부족하다구현이 끝났다고 선언하기 전에 함수가 돌아가는 방식을 확실히 이해하는지 확인하라테스트 케이스를 모두 통과한다는 사실만으로 부족하다 작성자가 알고.. 2017. 11. 28.
나쁜 코드 지우기 7 * 일반 G17. 잘못 지운 책임 - 소프트웨어 개발자가 내리는 가장 중요한 결정 중 하나가 코드를 배치하는 위치다예를 들어, PI 상수는 어디에 들어갈까? Math 클래스에? 아니면 Trigonometry 클래스에? 아니면 Circle 클래스에? 여기서도 최소 놀람의 원칙을 적용한다 코드는 독자가 자연스럽게 기대할 위치에 배치한다PI 함수는 삼각함수를 선언한 클래스에 넣어야 맞다OVERTIME_RATE 상수는 HourlyPayCalculator 클래스에 선언해야 맞다 때로는 개발자가 '영리하게' 기능을 배치한다 독자에게 직관적인 위치가 아니라 개발자에게 편한 함수를 배치한다예를 들어, 직원이 근무한 총 시간을 보고서로 출력함는 함수가 필요하다 가정하자보고서를 출력하는 함수에서 총계를 계산하는 방법이 있.. 2017. 11. 28.
나쁜 코드 지우기 6 * 일반 G14. 기능 욕심 - 클래스 메서드는 자기 클래스의 변수와 함수에 관심을 가져야지 다른 클래스의 변수와 함수에 관심을 가져서는 안 된다메서드가 다른 객체의 참조자(accessor)와 변경자(mutator)를 사용해 그 객체 내용을 조작한다면메서드가 그 객체 클래스의 범위를 욕심내는 탓이다자신이 그 클래스에 속해 그 클래스 변수를 직접 조작하고 싶다는 뜻이다예를 들어, 다음 코드를 살펴보자 public class HourlyPayCalculator { public Money calculateWeeklyPay(HourlyEmployee e) { int tenthRate = e.getTenthRate().getPennies(); int tenthsWorked = e.getTenthsWorked();.. 2017. 11. 28.
나쁜 코드 지우기 5 * 일반 G7. 기초 클래스가 파생 클래스에 의존한다 - 개념을 기초 클래스와 파생 클래스로 나누는 가장 흔한 이유는 고차원 기초 클래스 개념을 저차원 파생 클래스 개념으로부터 분리해 독립성을 보장하기 위해서다 그러므로 기초 클래스가 파생 클래스를 사용한다면 뭔가 문제가 있다는 말이다일반적으로 기초 클래스는 파생 클래스를 아예 몰라야 마땅하다 물론 예외는 있다 간혹 파생 클래스 개수가 확실히 고정되었다면 기초 클래스에 파생 클래스를 선택하는 코드가 들어간다FSM(Finite State Machine) 구현에서 많이 본 사례다 하지만 FSM은 기초 클래스와 파생 클래스가 굉장히 밀접하며 언제나 같은 JAR 파일로 배포한다일반적으로는 기초 클래스와 파생 클래스를 다른 JAR 파일로 배포하는 편이 좋다 기초 .. 2017. 11. 28.
나쁜 코드 지우기 4 * 일반 G1. 한 소스 파일에 여러 언어를 사용한다 - 오늘날 프로그래밍 환경은 한 소스 파일 내에서 다양한 언어를 지원한다예를 들어, 어떤 자바 소스 파일은 XML, HTML, YAML, Javadoc, JavaScript, 영어 등을 포함한다또 다른 예로, 어떤 JSP 파일은 HTML, 자바, 태그 라이브러리 구문, 영어 주석, Javadoc, XML, JavaScript 등을 포함한다좋게 말하자면 혼란스럽고, 나쁘게 말하자면 조잡하다 이상적으로는 소스 파일 하나에 언어 하나만 사용하는 방식이 가장 좋다 현실적으로는 여러 언어가 불가피하다하지만 각별한 노력을 기울여 소스 파일에서 언어 수와 범위를 최대한 줄이도록 애써야 한다 G2. 당연한 동작을 구현하지 않는다 - 최소 놀람의 원칙(The Prin.. 2017. 11. 23.
나쁜 코드 지우기 3 * 함수 F1. 너무 많은 인수 - 함수에서 인수 개수는 작을 수록 좋다 아예 없으면 가장 좋다 다음으로 하나, 둘, 셋이 차례로 좋다넷 이상은 그 가치가 아주 의심스러우므로 최대한 피한다 F2. 출력 인수 - 출력 인수는 직관을 정면으로 위배한다 일반적으로 독자는 인수를 출력이 아니라 입력으로 간주한다함수에서 뭔가의 상태를 변경해야 한다면 출력 인수를 사용하지 말고 함수가 속한 객체의 상태를 변경한다 F3. 플래그 인수 - bool 인수는 함수가 여러 기능을 수행한다는 명백한 증거다플래그 인수는 혼란을 초래하므로 피해야 마땅하다 F4. 죽은 함수 - 아무도 호출하지 않는 함수는 삭제한다 죽은 코드는 낭비다 과감히 삭제하라소스 코드 관리 시스템이 모두 기억하므로 걱정할 필요 없다 2017. 11. 23.
나쁜 코드 지우기 2 * 환경 E1. 여러 단계로 빌드해야 한다 - 빌드는 간단히 한 단계로 끝나야 한다 소스관리 시스템에서 이것저것 따로따로 체크아웃할 필요가 없어야 한다불가해한 명령이나 스크립트를 잇달아 실행해 각 요소를 따로 빌드할 필요가 없어야 한다온갖 JAR 파일, XML 파일, 기타 시스템에 필요한 파일을 찾느라 여기저기 뒤적일 필요가 없어야 한다한 명령으로 전체를 체크아웃해서 한 명령으로 빌드할 수 있어야 한다 svn get mySystemcd mySystemant all E2. 여러 단계로 테스트해야 한다 - 모든 단위 테스트는 한 명령으로 돌려야 한다 IDE에서 버튼 하나로 모든 테스트를 돌린다면 가장 이상적이다아무리 열악한 환경이라도 셸에서 명령 하나로 가능해야 한다 모든 테스트를 한 번에 실행하는 능력은 .. 2017. 11. 23.
나쁜 코드 지우기 방법 * 주석 C1. 부적절한 정보 - 다른 시스템에 (예를 들어, 소스코드 관리 시스템, 버그 추적 시스템, 이슈 추적 시스템, 기타 기록 관리 시스템에) 저장할 정보는 주석으로 적절하지 못하다예를 들어, 변경 이력은 장황한 날짜와 따분한 내용으로 소스 코드만 번잡하게 만든다일반적으로 작성자, 최종 수정일, SPR(Software Problem Report) 번호 등과 같은 메타 정보만 주석으로 넣는다주석은 코드와 설계에 기술적인 설명을 부연하는 수단이다 C2. 쓸모 없는 주석 - 오래된 주석, 엉뚱한 주석, 잘못된 주석은 더 이상 쓸모가 없다 주석은 빨리 낡는다쓸모 없어질 주석은 아예 달지 않는 편이 가장 좋다 쓸모 없어진 주석은 재빨리 삭제하는 편이 가장 좋다쓸모 없어진 주석은 일단 들어가고 나면 코드에.. 2017. 11. 23.
깨끗한 테스트 코드 - 테스트 코드는 실제 코드 못지 않게 중요하다 - 테스트 코드는 사고와 설계와 주의가 필요하다 - 실제 코드 못지 않게 깨끗하게 짜야 한다 - 테스트 코드를 깨끗하게 유지하지 않으면 결국은 잃어버린다 - 테스트 케이스가 없으면 실제 코드를 유연하게 만드는 버팀목도 사라진다 - 테스트 케이스가 있으면 변경이 두렵지 않다 - 테스트 커버리지가 높을수록 공포는 줄어든다 - 아키텍처가 부실한 코드나 설계가 모호하고 엉망인 코드라도 별다른 우려 없이 변겨할 수 있다 2017. 11. 10.
TDD 법칙 세가지 1. 첫째 법칙 : 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다2. 둘째 법칙 : 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위테스트를 작성한다3. 셋째 법칙 : 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다 위 세 가지 규칙을 따르면 개발과 테스트가 대략 30초 주기로 묶인다 테스트 코드와 실제 코드가 함께 나올뿐더러 테스트 코드가 실제 코드보다 불과 몇 초전에 나온다 이렇게 일하면 매일 수 십개, 수백 개, 매년 수천 개에 달하는 테스트 케이스가 나온다 이렇게 일하면 실제 코드를 사실상 전부 테스트하는 테스트 케이스가 나온다 하지만 실제 코드와 맞먹을 정도로 방대한 테스트 코드는 심각한 관리 문제를 유발하기도 한다 2017. 11. 10.
[Clean Code] 의미 있는 이름 이름을 잘 짓는 간단한 규칙 1. 의도를 분명히 밝혀라 - 좋은 이름을 지으려면 시간이 ㅁ걸리지만 좋은 이름으로 절약하는 시간이 훨씬 많다 - 변수나 함수 그리고 클래스 이름은 다음과 같은 질문에 모두 대답 가능 1. 존재 이유2. 수행 기능3. 사용 방법 - 따로 주석이 필요하다면 의도를 분명히 드러내지 못함 int d; // 경과 시간(단위 : 날짜) 이름 d는 아무 의미도 드러나지 않는다 - 측정하려는 값과 단위를 표현하는 이름이 필요하다 int elaspedTimeInDays;int daysSinceCreation;int daysSinceModification;int fileAgeInDays; - 의도가 드러나는 이름을 사용하면 코드 이해와 변경이 쉬워진다 다음 코드는 무엇을 할까? public .. 2017. 11. 9.

티스토리툴바