Data Makes Our Future

Java Code Conventions 코드를 작성하면서 대부분 이런 고민을 해보았을 것이다. "여기를 띄어 써야 깔끔할까?", "여기는 줄 바꿈을 해야 깔끔할까?" 등등.. 맞춤법이 틀린 것 처럼 코드가 찝찝하게 느껴진 적이 있지 않은가!! . 그렇다면.. 코우드 컨붼션(Code Conventions)이 필요한 때이다. ✏✏✏ . Google Java Style Guide 를 읽어보면서 참고할만한 내용만 간략하게 정리해 보았다. 캠퍼스 핵데이 Java 코딩 컨벤션 도 참고해보면 좋을 듯하다. . 추가로 Code Convention에 참고가 될만한 Clean Code 내용들을 간략하게 남겨보았다. Source File 모든 소스 파일은 UTF-8로 인코딩하기 Unix는 새 줄 문자를 LF(Line Fee..

| 14. 점진적인 개선- Sources and Reference * 깨끗한 코드를 짜려면 먼저 지저분한 코드를 짠 뒤에 정리해야 한다.* (일단 프로그램이 돌아간다고 다음 업무로 넘어가지 말고) 깔끔한 작품을 내놓으려면 단계적으로 개선해야 한다.- 테스트 주도 개발(Test-Driven Development, TDD) 기법을 사용해보자. 1. 소프트웨어 설계는 분할만 잘해도 품질이 크게 높아진다2. 적절한 장소를 만들어 코드만 불리해도 설계가 좋아진다.3. 관심사를 분리하면 코드를 이해하고 보수하기 훨씬 더 쉬워진다. || Args 사용법- 123456789101112// 간단한 Args 사용법 (명령행 인수 구문분석기)public static void main(String[] args) { try {..

| 13. 동시성-"객체는 처리의 추상화다. 스레드는 일정의 추상화다" - James O. Coplien || 동시성이 필요한 이유?- 동시성은 결합(coupling)을 없애는 전략 (무엇what 과 언제when 를 분리)- 무엇과 언제를 분리하면 애플리케이션 구조와 효율이 극적으로 나아진다.ex) 많은 사용자를 동시에 처리하면 시스템 응답 시간을 높일 수 있음ex) 정보를 나눠 여러 컴퓨터에서 돌리면 대량의 정보를 병렬처리할 수 있음 ||| 동시성과 관련한 일반적인 미신과 오해1. 동시성은 항상 성능을 높여준다?- 때로 성능을 높여준다.- "대기 시간이 아주 길어 여러 스레드가 프로세서를 공유할 수 있거나, 여러 프로세서가 동시에 처리할 독립적인 계산이 충분히 많은 경우에만"2. 동시성을 구현해도 설계..

| 12. 창발성(創發性)- || 창발적 설계로 깔끔한 코드를 구현하자 - 대다수는 Kent Beck이 제시한 "단순한 설계 규칙" 네 가지가 소프트웨어 설계 품질을 크게 높여준다고 믿는다..- 다음 규칙을 따르면 설계는 '단순하다'고 말할 수 있다. - Kent Beck1. 모든 테스트를 실행한다.2. 중복을 없앤다.3. 프로그래머 의도를 표현한다.4. 클래스와 메서드 수를 최소로 줄인다. || 단순한 설계 규칙 1: 모든 테스트를 실행하라- 철저한 테스트로 모든 테스트 케이스를 항상 통과하는 시스템은 '테스트가 가능한 시스템'이다.- 테스트가 가능한 시스템을 만들려고 애쓰면 설계 품질이 더불어 높아진다. (하나만 수행하는 클래스, SRP 준수 클래스)- 테스트 케이스 작성이 쉬워지려면 DIP 원칙 적..

| 시스템-- 시스템 수준에서도 깨끗함을 유지하는 방법 || 시스템 제작과 시스템 사용을 분리하라 - 소프트웨어 시스템은 (애플리케이션 객체를 제작하고 의존성을 서로 연결하는) 준비 과정과 (준비 과정 이후에 이어지는) 런타임 로직을 분리해야 한다. ||| Main 분리- 시스템 생성과 시스템 사용을 분리하는 한 가지 방법 - 생성과 관련한 코드는 모두 main이나 main이 호출하는 모듈로 옮기고, 나머지 시스템은 모든 객체가 생성되었고 모든 의존성이 연결되었다고 가정-> Application은 main이나 객체가 생성되는 과정을 전혀 모른다. ||| 팩토리- 객체가 생성되는 시점을 Application이 결정할 필요가 생길 경우 Abstract Factory 패턴 사용 - 객체를 생성하는 시점은 Ap..

| 10. 클래스- || 클래스 체계- 클래스를 정의하는 표준 자바 관례 (순차적인 추상화 단계)1. 변수 목록- static public- static private- 비공개 인스턴스 변수2. 공개 함수3. 비공개 함수 ||| 캡슐화- 때로 변수나 유틸리티 함수를 protected로 선언하여 테스트 코드에 접근을 허용하는 방법도 있다.- 하지만, 그 전에 비공개 상태를 유지할 온갖 방법을 강구하고 캡슐화를 풀어주는 결정은 언제나 최후의 수단으로! || 클래스는 작아야 한다! - 클래스를 만들 때 첫 번째 규칙은 크기, 클래스는 작아야 한다. (두 세 번째 규칙도 크기다...)- 함수와 마찬가지로 '작게'가 기본 규칙- 함수는 물리적인 행 수로 크기를 측정했다면, 클래스는 맡은 책임을 센다. * 클래스 ..

| 9. 단위 테스트 || TDD 법칙TDD(Test Driven Development )는 실제 코드를 짜기 전에 단위 테스트부터 짜라고 요구한다. 1. 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다.2. 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다.3. 현재 실패하는 테스트를 통화할 정도로만 실제 코드를 작성한다. - 하지만, 실제 코드와 맞먹을 정도의 방대한 테스트 코드는 심각한 관리 문제를 유발하기도 한다.. || 깨끗한 테스트 코드 유지하기- 테스트 코드는 실제 코드 못지 않게 중요하다. * 테스트는 유연성, 유지보수성, 재사용성을 재공한다.- 테스트 케이스가 있으면 변경이 쉬워진다! || 깨끗한 테스트 코드* 깨끗한 테스트 코드를 만들려면 "가..

| 8. 경계 - 소프트웨어 경계를 깔끔하게 처리하는 기법과 기교 || 외부 코드 사용하기- 외부 코드(인터페이스)가 변할 가능성이 거의 없다고 여길 수 없다. 외부 코드가 변하게 되면 수정할 코드가 상당히 많아진다. (자바 5가 제네릭스를 지원하면서 Map 인터페이스가 변했다고 한다..)- java.util.Map 을 예로 보자. 경계 인터페이스인 Map을 class 안으로 숨기면, Map 인터페이스가 변하더라도 나머지 프로그램에는 영향을 미치지 않는다. Class 안에서 객체 유형을 관리하고 변환해주자. 123456789public class Sensors { private Map sensors = new HashMap(); public Sensor getById(String id) { return ..