프로그램 작성 NOT TO-DO

anonymous·2022년 4월 30일

일단 분석 이해가 안되면 각 줄을 띄워 넣고 조금씩 기능 별로 연결

ANTI - 객체지향 프로그래밍

객체지향의 모습을 지키지 않는 방법

데이터와 함수를 각자 따로 갖고 세부 내용은 개방하고 재사용이 어렵게 함
모두 public 형태로 만들어서 어떤 함수/클래스든 쉽게 접근 가능
부모 자식 개념 없이 중복과 의존관계는 전혀 만들지 않고 사용.
기능, 객체 확장에는 함수와 함수 명칭를 매번 따로 만들고 각각의 자료형을 갖고 최대한 코드 수 길게

역객체지향 기법 추구

구체화

공통적인 성질이 있는 객체는 절대 상위 객체 정의 하지 않고 하위 부부형 객체

추상화

객체를 사물 있는 그대로 최대한 구체적으로 복잡하게 표현

캡슐오픈

자료와 행위는 하나로 묶고 구현 내용도 전부 공개

세분화

서로 관련 있는 여러 개의 객체를 각각의 객체

ANTI-SOLID

Multi Responsibility

각각의 소프트웨어 부품은 다중 책임

Closed-Open Principle

기존의 코드를 변경하지 않고 기능을 수정하거나 추가할 수 없다. 무조건 기존 코드를 변경해야 추가/수정이 가능.

Liskov Anti-Subsitution Principle

자식 클래스는 부모 클래스에서 가능한 행위 수행 불가. 다 제각각

Interface Unification Principle

하나의 일반적인 인터페이스로 모든 기능을 구현

Dependency Keeper Principle

의존 관계를 맺을 때 상위 모듈은 변화하기 쉬운 하위 모듈에 의존한다. 상위 클래스는 구체적인 클래스와 관계

기술 부채 높이는 코드 작성 방법

현황 파악 없이 일단 있는대로 생각나는대로 작업하기.
최초 개발시 나만 알 수 있는 코드, A, B등의 코드를 사용해서 변수/함수/클래스명을 작성하고 1달 후 1년 , 5년 후에도 무슨 의미인지 나는 단번에 파악할 수 있을 거라고 맹신하면서 작성하자. 다른 사람은 내 코드를 읽지 않을거고 수정하기 최대한 어렵게
고객사 요구사항, 상사의 요구사항은 잘못됐고 내가 하고 싶은대로만 개발
널 체크는 무조건 뺀다 데이터는 항상 있을거다.
데이터 타입에 대한 고려 없이 일괄적인 데이터 타입과 자료구조를 사용
유닛 테스트를 작성하지 않거나 기능을 테스트할 수단/또는 방법을 최대한 직관적이지 않게 만듬
공통 요소는 전혀 만들지 않고 전부 구체적인 클래스 함수로 만들어서 추가/수정 요구사항에 대응하기 어렵게
공통 요소로 모두 묶어서 의존성을 최대한 만들어 추가/수정 요구사항에 대응하기 어렵게
즉 결합도(의존도)는 최대한 높고 , 응집도(독립도)는 최대한 낮게 구현한다.
예) 웹 개발의 경우 모든 기능에 대한 이벤트 바인딩은 클래스가 기준이고 클래스도 동일 명칭으로 최대한 많이 사용한다. ID는 절대 사용하지 않아서 특정 클래스에 다른 이벤트를 주는 경우 부모 태그에서 부터 자식 태그로 최대한 정밀하게 태그 경로를 찾아가게한다.
오류가 발생할 만한 요소에 exception 처리, 로그 처리는 절대 하지 말자.
충분한 테스트 없이 커밋하고 에러는 나중에 대응하자
TO-DO로 지키기 위해서 최대한 많은 시간을 갖고 코드를 작성한다. 마감 따위는 무시하자 그리고 코드 작성이 끝난 후에는 절대로 다시 안보고 정리하지 않는다.
함수 생성 불규칙을 최대한 따른다.