경계 오픈소스, 라이브러리 같은 경우는 외부코드 해당하며, 우리가 만든 코드는 외부코드랑 병합을 해야함 우리코드, 외부코드를 깔끔하게 통합시키기 위해서는 경계를 지켜야함 경계 짓는 방법 우리코드를 보호하기 외부코드와 호환하기 외부라이브러리 테스트 우리 코드를 보호하기 우리코드를 보호하는 방법중에는 캡슐화를 잘 사용하는 것 캡슐화 : 객체의 실제 구현을 외부로부터 감추는 방식 안좋은 예시 Map sensors = new HashMap(); Sensor s = sensors.get(sensorId); Map 인터페이스가 제공하는 불필요한 기능이 노출하게 됨 외부코드가 함부로 호출하면 sensor 데이터가 손상될 수 있고, 의도와 벗어남 좋은 예시 public class Sensors { private Map..

자료구조 VS 객체 자료구조와 객체 사용은 상황에 맞게 선택해서 사용하면 됨 자료구조 객체 데이터 그 자체 비즈니스 로직과 관련 자료를 공개함 자료를 숨기고, 추상화, 자료를 다루는 함수만 공개 변수 사이에 조회 함수와 설정 함수로 변수를 다룬다고 해도 객체가 되는 것은 아님 추상 인터페이스를 제공해 사용자가 구현을 모른 채 자료의 핵심을 조작할 수 있음 자료구조를 사용하는 절차적인 코드는 기본 자료구조를 변경하지 않으면서 새 함수를 추가하기 쉬움 절차적인 코드는 새로운 자료구조를 추가하기 어려움, 모든 함수를 고쳐야함 객체지향 코드는 기존 함수를 변경하지 않으면서, 새 클래스를 추가하기 쉬움 객체지향 코드는 새로운 함수를 추가하기 어려움, 추가하려면 모든 클래스를 고쳐야함 ' 객체 - 디미터의 법칙 모..

적절한길이 유지 코드 길이가 200라인을 넘어간다면, 클래스가 여러개의 일을 하고 있을 가능성이 높음 (SRP에 위배) 현업에서는 대부분의 코드들도 200라인을 유지 함 밀접한 개념은 가까이 행 묶음은 완결된 생각 하나를 표현하기 때문에, 개념은 빈 행으로 분리 변수는 사용되는 위치에서 최대한 가까이 선언해야함 Java Class 선언형식 static 변수 : public -> protected -> package -> private instance 변수 : public -> protected -> package -> private 생성자 메서드 순서 : public 메서드에서 호출되는 private 메서드는 그아래에 둠, 가독성 위주로 그룹핑을 해야함 형식 맞추기 즉 코드 컨벤션은 팀 코딩 컨벤션을 정..

주석을 최대한 쓰지 말자 주석은 나쁜 코드를 보완하지 못한다 주석은 방치된다 주석은 나쁜 코드를 보완하지 못한다 주석이 추가되는 일반적인 이유는 코드 품질이 나쁘기 때문임 좋은 코드로 주석 없이 의도를 표현 할 수 있음 주석으로 설명하지 말고 코드를 개선하는데 시간을 투자해야함 주석은 방치된다 코드의 변화에 따라가지 못하고, 방치 코드는 컴파일 되어 호출되지만, 주석은 그자리에 방치되고 결국 의미없는 텍스트가 됨 좋은 주석 의도와 중요성을 설명 TODO, FIXME 주석 의도와 중요성 설명 // 사용자로부터 입력 받은 값을 저장할 때 trim으로 공백제거 필요 String name = nameInput.trim(); 의도와 중요한 부분을 설명해주는 것은 좋은 주석 TODO, FIXME TODO : 앞으로..

SOLID (객체지향 설계의 5가지 원칙) SRP 단일 책임원칙 OCP 개방 폐쇄 원칙 LSP 리스코프 치환 원칙 ISP 인터페이스 분리 원칙 DIP 의존성 역전 원칙 SRP 단일 책임원칙 한클래스는 하나의 책임만 가져야함 클래스는 하나의 기능만 가지며, 어떤 변화에 의해 클래스를 변경해야 하는 이유는 오직 하나뿐이어야함 SRP 책임이 분명해지기 때문에, 변경에 의한 연쇄작용에서 자유로워짐 가독성 향상과 유지보수가 용이해짐 실무에서는 쉽지 않지만 늘 상기해야함 OCP 개방 폐쇄 원칙 소프트웨어 요소는 확장에는 열려있고, 변경에는 닫혀있어야함 변경을 위한 비용을 줄이고, 확장을 위한 비용을 가능한 극대화 객체지향의 추상화와 다형성을 활용하면 개방폐쇄원칙을 지킬 수 있음 요구사항의 변경이나 추가사항이 발생하..

의도를 분명하게 이름 사용 변수, 함수명을 의도를 분명하게 하면 코드를 이해하기 쉬워짐 for 문 사용시 i j k 를 사용 X 통일성 있는 단어 사용 똑같은 의미에 대해서는 똑같은 단어를 사용하는 것이 중요함 뜻이 같은 비슷비슷한 단어여도 통일이 안되면 오히려 혼란을 줌 통일성 있는 단어 사용을 위해 팀에서 협의를 하는 것이 좋음 변수명에 타입 금지 1. String addressString -> address 2. int itemPriceAmount -> itemPrice 3. Account[] accountArray -> accounts 4. List accountList -> accounts, accountList 5. public interface IShapeFactory -> ShapeFact..

나쁜코드 성능이 나쁜 코드 : 불필요한 연산이 들어가서 개선의 여지가 있는 코드 의미가 모호한 코드 : 이해하기 어려운코드, 네이밍과 내용이 다른 코드 중복 코드 : 비슷한 내용인데 중복되는 코드 (중복된 코드는 버그를 낳는다고함) 나쁜코드가 나쁜 이유 나쁜 코드는 계속 나쁜코드가 만들어지도록 함 기술부채를 만들어서 수정을 더어렵게 하기 때문에 팀 생산성을 저하 시킴 나쁜 코드로 인하여 새로운 시스템을 만들게 됨 나쁜코드가 만들어지는 이유 촉박한 일정 : 나쁜코드는 하지만 오히려 생산성을 저하시켜서 일정을 못맞추게함 영향 범위가 매우 넓음 (영향 범위가 넓어서 다른부분에 버그가 발생할까봐) : 영향 범위가 넓다고 방치하면 결국 다시 돌아오게됨 클린코드 성능이 좋은 코드 의미가 명확한 코드 / 가독성이 좋..