현재 버전

잘 짜여진 코드에 대한 기준에는 약간의 주관적 요소도 있음을 알아두시구요. 아는 만큼 보이며 아는게 많아도 상호간 상황에 따라 서로 다르게 판단 할 수도 있습니다.


제가 느끼는 잘 짜여진 코드라 함은 아래와 같습니다.


1. 변경이 쉽다. 

ㅡ 변경함에 있어서 해당요소의 경계가 명확하다.

ㅡ 변경함에 있어서 주변소스의 변경은 제로화한다. 


2. 반복이 없다

ㅡ 반복되는 부분을 하나로 만든다.


3. 이름짓기를 잘한다.

ㅡ 추상층이 높아 질 수록 보편적으로 사용하는 키워드를 사용하며, 가급적 GoF패턴의 명칭들은 그 의도와 비슷한 경우에만 사용. (자바쪽에 특히 오용된것들이 많습니다 )


4. 해당언어의 이디엄과 추구하는 방향에 맞춰 코딩한다.

ㅡ 예를들어 자바 코드짜는데 C처럼 짜면안되겠죠. 마찬가지로 코틀린 코드 짜는데 자바처럼 짜면 후지다라는 느낌이 듭니다.


5. 팀이 정한 컨벤션에 일치한다.

ㅡ 예외처리(가까이서 처리? 멀리서 처리? 등)나 로깅의 경우 답이 없기 때문에 일치화가 중요

ㅡ 탭사용규정,줄바꿈규정 등등


6. 바퀴를 재발명하지 않는다.

ㅡ 이미 잘 짜여진 기술이 있고, 변경 필요가 없다면 있는것을 사용해서 의사소통 비용줄임. 예를 들어 JVM에서 프록시 패턴을 굳이 스스로 만들기 보단 다이나믹 프록시 사용. 스프링지원기술들 사용

물론 발명할 필요성은 추후에 검토 합니다. C++의 STL이나 자바의 컬렉션이나 보편적 성능일뿐이지 특정상황에선 엄청느리니까요


7. 후임자가 큰 실수 할 여지를 줄인다

ㅡ 제약 상황을 많이 만들어 넣어서 후임자가  잘못하면 가급적 컴파일 타이밍에 에러를 내게 합니다.

8.추상화가 잘 된 코드 (오버엔지니어링 이슈가 있음)


9.잘 알려진 패턴이 잘 적용된 코드


10. 시대흐름에 맞는 코드 

ㅡ 모던C++, 모던자바


11.테스트 친화적 코드




이런것들이 잘 녹여진 코드를 보면 감동이 있죠.



수정 이력

2022-05-07 21:01:50 에 아래 내용에서 변경 됨 #22

잘 짜여진 코드에 대한 기준에는 약간의 주관적 요소도 있음을 알아두시구요. 아는 만큼 보이며 아는게 많아도 상호간 상황에 따라 서로 다르게 판단 할 수도 있습니다.


제가 느끼는 잘 짜여진 코드라 함은 아래와 같습니다.


1. 변경이 쉽다. 

ㅡ 변경함에 있어서 해당요소의 경계가 명확하다.

ㅡ 변경함에 있어서 주변소스의 변경은 제로화한다. 


2. 반복이 없다

ㅡ 반복되는 부분을 하나로 만든다.


3. 이름짓기를 잘한다.

ㅡ 추상층이 높아 질 수록 보편적으로 사용하는 키워드를 사용하며, 가급적 GoF패턴의 명칭들은 그 의도와 비슷한 경우에만 사용. (자바쪽에 특히 오용된것들이 많습니다 )


4. 해당언어의 이디엄과 추구하는 방향에 맞춰 코딩한다.

ㅡ 예를들어 자바 코드짜는데 C처럼 짜면안되겠죠. 마찬가지로 코틀린 코드 짜는데 자바처럼 짜면 후지다라는 느낌이 듭니다.


5. 팀이 정한 컨벤션에 일치한다.

ㅡ 예외처리(가까이서 처리? 멀리서 처리? 등)나 로깅의 경우 답이 없기 때문에 일치화가 중요

ㅡ 탭사용규정,줄바꿈규정 등등


6. 바퀴를 재발명하지 않는다.

ㅡ 이미 잘 짜여진 기술이 있고, 변경 필요가 없다면 있는것을 사용해서 의사소통 비용줄임. 예를 들어 JVM에서 프록시 패턴을 굳이 스스로 만들기 보단 다이나믹 프록시 사용. 스프링지원기술들 사용

물론 발명할 필요성은 추후에 검토 합니다. C++의 STL이나 자바의 컬렉션이나 보편적 성능일뿐이지 특정상황에선 엄청느리니까요


7. 후임자가 실수 할 여지를 줄인다

ㅡ 제약 상황을 많이 만들어 넣어서 후임자가  잘못하면 가급적 컴파일 타이밍에 에러를 내게 합니다.

8.추상화가 잘 된 코드 (오버엔지니어링 이슈가 있음)


9.잘 알려진 패턴이 잘 적용된 코드


10. 시대흐름에 맞는 코드 

ㅡ 모던C++, 모던자바


11.테스트 친화적 코드




이런것들이 잘 녹여진 코드를 보면 감동이 있죠.


2022-05-07 21:01:03 에 아래 내용에서 변경 됨 #21

잘 짜여진 코드에 대한 기준에는 약간의 주관적 요소도 있음을 알아두시구요. 아는 만큼 보이며 아는게 많아도 상호간 상황에 따라 서로 다르게 판단 할 수도 있습니다.


제가 느끼는 잘 짜여진 코드라 함은


1. 변경이 쉽다. 

ㅡ 변경함에 있어서 해당요소의 경계가 명확하다.

ㅡ 변경함에 있어서 주변소스의 변경은 제로화한다. 


2. 반복이 없다

ㅡ 반복되는 부분을 하나로 만든다.


3. 이름짓기를 잘한다.

ㅡ 추상층이 높아 질 수록 보편적으로 사용하는 키워드를 사용하며, 가급적 GoF패턴의 명칭들은 그 의도와 비슷한 경우에만 사용. (자바쪽에 특히 오용된것들이 많습니다 )


4. 해당언어의 이디엄과 추구하는 방향에 맞춰 코딩한다.

ㅡ 예를들어 자바 코드짜는데 C처럼 짜면안되겠죠. 마찬가지로 코틀린 코드 짜는데 자바처럼 짜면 후지다라는 느낌이 듭니다.


5. 팀이 정한 컨벤션에 일치하는지

ㅡ 예외처리(가까이서 처리? 멀리서 처리? 등)나 로깅의 경우 답이 없기 때문에 일치화가 중요

ㅡ 탭사용규정,줄바꿈규정 등등


6. 바퀴를 재발명하지 마라

ㅡ 이미 잘 짜여진 기술이 있고, 변경 필요가 없다면 있는것을 사용해서 의사소통 비용줄임. 예를 들어 JVM에서 프록시 패턴을 굳이 스스로 만들기 보단 다이나믹 프록시 사용. 스프링지원기술들 사용

물론 발명할 필요성은 추후에 검토 합니다. C++의 STL이나 자바의 컬렉션이나 보편적 성능일뿐이지 특정상황에선 엄청느리니까요


7. 후임자가 실수 할 여지를 줄인다

ㅡ 제약 상황을 많이 만들어 넣어서 후임자가  잘못하면 가급적 컴파일 타이밍에 에러를 내게 합니다.

8.추상화가 잘 된 코드 (오버엔지니어링 이슈가 있음)


9.잘 알려진 패턴이 잘 적용된 코드


10. 시대흐름에 맞는 코드 

ㅡ 모던C++, 모던자바


11.테스트 친화적 코드


이런것들이 잘 녹여진 코드를 보면 감동이 있죠.


2022-05-07 20:59:48 에 아래 내용에서 변경 됨 #20

잘짠코드에 대한 기준에는 약간의 주관적 요소도 있음을 알아두시구요. 아는 만큼 보이며 아는게 많아도 상호간 상황에 따라 서로 다르게 판단 할 수도 있습니다.


제가 느끼는 잘짠코드라 함은


1. 변경이 쉽다. 

ㅡ 변경함에 있어서 해당요소의 경계가 명확하다.

ㅡ 변경함에 있어서 주변소스의 변경은 제로화한다. 


2. 반복이 없다

ㅡ 반복되는 부분을 하나로 만든다.


3. 이름짓기를 잘한다.

ㅡ 추상층이 높아 질 수록 보편적으로 사용하는 키워드를 사용하며, 가급적 GoF패턴의 명칭들은 그 의도와 비슷한 경우에만 사용. (자바쪽에 특히 오용된것들이 많습니다 )


4. 해당언어의 이디엄과 추구하는 방향에 맞춰 코딩한다.

ㅡ 예를들어 자바 코드짜는데 C처럼 짜면안되겠죠. 마찬가지로 코틀린 코드 짜는데 자바처럼 짜면 후지다라는 느낌이 듭니다.


5. 팀이 정한 컨벤션에 일치하는지

ㅡ 예외처리(가까이서 처리? 멀리서 처리? 등)나 로깅의 경우 답이 없기 때문에 일치화가 중요

ㅡ 탭사용규정,줄바꿈규정 등등


6. 바퀴를 재발명하지 마라

ㅡ 이미 잘 짜여진 기술이 있고, 변경 필요가 없다면 있는것을 사용해서 의사소통 비용줄임. 예를 들어 JVM에서 프록시 패턴을 굳이 스스로 만들기 보단 다이나믹 프록시 사용. 스프링지원기술들 사용

물론 발명할 필요성은 추후에 검토 합니다. C++의 STL이나 자바의 컬렉션이나 보편적 성능일뿐이지 특정상황에선 엄청느리니까요


7. 후임자가 실수 할 여지를 줄인다

ㅡ 제약 상황을 많이 만들어 넣어서 후임자가  잘못하면 가급적 컴파일 타이밍에 에러를 내게 합니다.

8.추상화가 잘 된 코드 (오버엔지니어링 이슈가 있음)


9.잘 알려진 패턴이 잘 적용된 코드


10. 시대흐름에 맞는 코드 

ㅡ 모던C++, 모던자바


11.테스트 친화적 코드


이런것들이 잘 녹여진 코드를 보면 감동이 있죠.


2022-05-07 20:59:12 에 아래 내용에서 변경 됨 #19

잘짠코드에 대한 기준에는 약간의 주관적 요소도 있음을 알아두시구요. 아는 만큼 보이며 아는게 많아도 상호간 상황에 따라 서로 다르게 판단 할 수도 있습니다.


제가 느끼는 잘짠코드라 함은


1. 변경이 쉽다. 

ㅡ 변경함에 있어서 해당요소의 경계가 명확하다.

ㅡ 변경함에 있어서 주변소스의 변경은 제로화한다. 


2. 반복이 없다

ㅡ 반복되는 부분을 하나로 만든다.


3. 이름짓기를 잘한다.

ㅡ 추상층이 높아 질 수록 보편적으로 사용하는 키워드를 사용하며, 가급적 GoF패턴의 명칭들은 그 의도와 비슷한 경우에만 사용. (자바쪽에 특히 오용된것들이 많습니다 )


4. 해당언어의 이디엄과 추구하는 방향에 맞춰 코딩한다.

ㅡ 예를들어 자바 코드짜는데 C처럼 짜면안되겠죠. 마찬가지로 코틀린 코드 짜는데 자바처럼 짜면 후지다라는 느낌이 듭니다.


5. 팀이 정한 컨벤션에 일치하는지

ㅡ 예외처리(가까이서 처리? 멀리서 처리? 등)나 로깅의 경우 답이 없기 때문에 일치화가 중요

ㅡ 탭사용규정,줄바꿈규정 등등


6. 바퀴를 재발명하지 마라

ㅡ 이미 잘 짜여진 기술이 있고, 변경 필요가 없다면 있는것을 사용해서 의사소통 비용줄임. 예를 들어 JVM에서 프록시 패턴을 굳이 스스로 만들기 보단 다이나믹 프록시 사용. 스프링지원기술들 사용

물론 발명할 필요성은 추후에 검토 합니다. C++의 STL이나 자바의 컬렉션이나 보편적 성능일뿐이지 특정상황에선 엄청느리니까요


7. 후임자가 실수 할 여지를 줄인다

ㅡ 제약 상황을 많이 만들어 넣어서 후임자가  잘못하면 가급적 컴파일 타이밍에 에러를 내게 합니다.

8.추상화가 잘 된 코드 (오버엔지니어링 이슈가 있음)


9.잘 알려진 패턴이 잘 적용된 코드


10. 시대흐름에 맞는 코드 

ㅡ 모던C++, 모던자바


11.테스트 친화적 코드


이런것들이 눈에 보이며 잘 작성된 코드를 보면 감동이 있죠.


2022-05-07 13:54:57 에 아래 내용에서 변경 됨 #18

잘짠코드에 대한 기준에는 약간의 주관적 요소도 있음을 알아두시구요. 아는 만큼 보이며 아는게 많아도 상호간 상황에 따라 서로 다르게 판단 할 수도 있습니다.


제가 느끼는 잘짠코드라 함은


1. 변경이 쉽다. 

ㅡ 변경함에 있어서 해당요소의 경계가 명확하다.

ㅡ 변경함에 있어서 주변소스의 변경은 제로화한다. 


2. 반복이 없다

ㅡ 반복되는 부분을 하나로 만든다.


3. 이름짓기를 잘한다.

ㅡ 추상층이 높아 질 수록 보편적으로 사용하는 키워드를 사용하며, 가급적 GoF패턴의 명칭들은 그 의도와 비슷한 경우에만 사용. (자바쪽에 특히 오용된것들이 많습니다 )


4. 해당언어의 이디엄과 추구하는 방향에 맞춰 코딩한다.

ㅡ 예를들어 자바 코드짜는데 C처럼 짜면안되겠죠. 마찬가지로 코틀린 코드 짜는데 자바처럼 짜면 후지다라는 느낌이 듭니다.


5. 팀이 정한 컨벤션에 일치하는지

ㅡ 예외처리(가까이서 처리? 멀리서 처리? 등)나 로깅의 경우 답이 없기 때문에 일치화가 중요

ㅡ 탭사용규정,줄바꿈규정 등등


6. 바퀴를 재발명하지 마라

ㅡ 이미 잘 짜여진 기술이 있고, 변경 필요가 없다면 있는것을 사용해서 의사소통 비용줄임. 예를 들어 JVM에서 프록시 패턴을 굳이 스스로 만들기 보단 다이나믹 프록시 사용. 스프링지원기술들 사용

물론 발명할 필요성은 추후에 검토 합니다. C++의 STL이나 자바의 컬렉션이나 보편적 성능일뿐이지 특정상황에선 엄청느리니까요


7. 후임자가 실수 할 여지를 줄인다

ㅡ 제약 상황을 많이 만들어 넣어서 후임자가  잘못하면 가급적 컴파일 타이밍에 에러를 내게 합니다.

8.추상화가 잘 된 코드 (오버옌지니어링 이슈)

9.잘 알려진 패턴이 잘 적용된 코드

10. 시대흐름에 맞는 코드 

ㅡ 모던C++, 모던자바

11.테스트 친화적 코드


이런것들이 눈에 보이며 이런 코드는 감동스러워 지더군요. 


2022-05-07 12:56:45 에 아래 내용에서 변경 됨 #17

잘짠코드에 대한 기준에는 약간의 주관적 요소도 있음을 알아두시구요. 아는 만큼 보이며 아는게 많아도 상호간 상황에 따라 서로 다르게 판단 할 수도 있습니다.


제가 느끼는 잘짠코드라 함은


1. 변경이 쉽다. 

ㅡ 변경함에 있어서 해당요소의 경계가 명확하다.

ㅡ 변경함에 있어서 주변소스의 변경은 제로화한다. 


2. 반복이 없다

ㅡ 반복되는 부분을 하나로 만든다.


3. 이름짓기를 잘한다.

ㅡ 추상층이 높아 질 수록 보편적으로 사용하는 키워드를 사용하며, 가급적 GoF패턴의 명칭들은 그 의도와 비슷한 경우에만 사용. (자바쪽에 특히 오용된것들이 많습니다 )


4. 해당언어의 이디엄과 추구하는 방향에 맞춰 코딩한다.

ㅡ 예를들어 자바 코드짜는데 C처럼 짜면안되겠죠. 마찬가지로 코틀린 코드 짜는데 자바처럼 짜면 후지다라는 느낌이 듭니다.


5. 팀이 정한 컨벤션에 일치하는지

ㅡ 예외처리(가까이서 처리? 멀리서 처리? 등)나 로깅의 경우 답이 없기 때문에 일치화가 중요

ㅡ 탭사용규정,줄바꿈규정 등등


6. 바퀴를 재발명하지 마라

ㅡ 이미 잘 짜여진 기술이 있고, 변경 필요가 없다면 있는것을 사용해서 의사소통 비용줄임. 예를 들어 JVM에서 프록시 패턴을 굳이 스스로 만들기 보단 다이나믹 프록시 사용. 스프링지원기술들 사용

물론 발명할 필요성은 추후에 검토 합니다. C++의 STL이나 자바의 컬렉션이나 보편적 성능일뿐이지 특정상황에선 엄청느리니까요


7. 후임자가 실수 할 여지를 줄인다

ㅡ 제약 상황을 많이 만들어 넣어서 후임자가  잘못하면 가급적 컴파일 타이밍에 에러를 내게 합니다.

8.추상화가 잘 된 코드

9.잘 알려진 패턴이 잘 적용된 코드

10. 시대흐름에 맞는 코드 

ㅡ 모던C++, 모던자바

11.테스트 친화적 코드


이런것들이 눈에 보이며 이런 코드는 감동스러워 지더군요. 


2022-05-07 12:49:51 에 아래 내용에서 변경 됨 #16

잘짠코드에 대한 기준에는 약간의 주관적 요소도 있음을 알아두시구요. 아는 만큼 보이며 아는게 많아도 상호간 상황에 따라 서로 다르게 판단 할 수도 있습니다.


제가 느끼는 잘짠코드라 함은


1. 변경이 쉽다. 

ㅡ 변경함에 있어서 해당요소의 경계가 명확하다.

ㅡ 변경함에 있어서 주변소스의 변경은 제로화한다. 


2. 반복이 없다

ㅡ 반복되는 부분을 하나로 만든다.


3. 이름짓기를 잘한다.

ㅡ 추상층이 높아 질 수록 보편적으로 사용하는 키워드를 사용하며, 가급적 GoF패턴의 명칭들은 그 의도와 비슷한 경우에만 사용. (자바쪽에 특히 오용된것들이 많습니다 )


4. 해당언어의 이디엄과 추구하는 방향에 맞춰 코딩한다.

ㅡ 예를들어 자바 코드짜는데 C처럼 짜면안되겠죠. 마찬가지로 코틀린 코드 짜는데 자바처럼 짜면 후지다라는 느낌이 듭니다.


5. 팀이 정한 컨벤션에 일치하는지

ㅡ 예외처리(가까이서 처리? 멀리서 처리? 등)나 로깅의 경우 답이 없기 때문에 일치화가 중요

ㅡ 탭사용규정,줄바꿈규정 등등


6. 바퀴를 재발명하지 마라

ㅡ 이미 잘 짜여진 기술이 있고, 변경 필요가 없다면 있는것을 사용해서 의사소통 비용줄임. 예를 들어 JVM에서 프록시 패턴을 굳이 스스로 만들기 보단 다이나믹 프록시나 CGLIB 사용. 스프링지원기술사용

물론 발명할 필요성은 추후에 검토 합니다. C++의 STL이나 자바의 컬렉션이나 보편적 성능일뿐이지 특정상황에선 엄청느리니까요


7. 후임자가 실수 할 여지를 줄인다. 제약 상황을 많이 만들어 넣어서 후임자가  잘못하면 가급적 컴파일 타이밍에 에러를 내게 합니다.

8.추상화가 잘 된 코드

9.선대의 패턴이 잘 적용된 코드

10. 시대흐름에 맞는 코드 

11.테스트 친화적 코드


이런것들이 눈에 보이며 이런 코드는 감동스러워 지더군요. 


2022-05-07 12:44:49 에 아래 내용에서 변경 됨 #15

잘짠코드에 대한 기준에는 주관적 요소가 있음을 알아두시구요. 아는 만큼 보이며 아는게 많아도 상호간 상황에 따라 서로 다르게 판단 할 수도 있습니다.


제가 느끼는 잘짠코드라 함은


1. 변경이 쉽다. 

ㅡ 변경함에 있어서 해당요소의 경계가 명확하다.

ㅡ 변경함에 있어서 주변소스의 변경은 제로화한다. 


2. 반복이 없다

ㅡ 반복되는 부분을 하나로 만든다.


3. 이름짓기를 잘한다.

ㅡ 추상층이 높아 질 수록 보편적으로 사용하는 키워드를 사용하며, 가급적 GoF패턴의 명칭들은 그 의도와 비슷한 경우에만 사용. (자바쪽에 특히 오용된것들이 많습니다 )


4. 해당언어의 이디엄과 추구하는 방향에 맞춰 코딩한다.

ㅡ 예를들어 자바 코드짜는데 C처럼 짜면안되겠죠. 마찬가지로 코틀린 코드 짜는데 자바처럼 짜면 후지다라는 느낌이 듭니다.


5. 팀이 정한 컨벤션에 일치하는지

ㅡ 예외처리(가까이서 처리? 멀리서 처리? 등)나 로깅의 경우 답이 없기 때문에 일치화가 중요

ㅡ 탭사용규정,줄바꿈규정 등등


6. 바퀴를 재발명하지 마라

ㅡ 이미 잘 짜여진 기술이 있고, 변경 필요가 없다면 있는것을 사용해서 의사소통 비용줄임. 예를 들어 JVM에서 프록시 패턴을 굳이 스스로 만들기 보단 다이나믹 프록시나 CGLIB 사용. 스프링지원기술사용

물론 발명할 필요성은 추후에 검토 합니다. C++의 STL이나 자바의 컬렉션이나 보편적 성능일뿐이지 특정상황에선 엄청느리니까요


7. 후임자가 실수 할 여지를 줄인다. 제약 상황을 많이 만들어 넣어서 후임자가  잘못하면 가급적 컴파일 타이밍에 에러를 내게 합니다.

8.추상화가 잘 된 코드

9.선대의 패턴이 잘 적용된 코드

10. 시대흐름에 맞는 코드 

11.테스트 친화적 코드


이런것들이 눈에 보이며 이런 코드는 감동스러워 지더군요. 


2022-05-07 12:41:32 에 아래 내용에서 변경 됨 #14

잘짠코드에 대한 기준에는 주관적 요소가 있음을 알아두시구요. 아는 만큼 보이며 아는게 많아도 상호간 상황에 따라 서로 다르게 판단 할 수도 있습니다.


제가 느끼는 잘짠코드라 함은


1. 변경이 쉽다. 

ㅡ 변경함에 있어서 해당요소의 경계가 명확하다.

ㅡ 변경함에 있어서 주변소스의 변경은 제로화한다. 


2. 반복이 없다

ㅡ 반복되는 부분을 하나로 만든다.


3. 이름짓기를 잘한다.

ㅡ 추상층이 높아 질 수록 보편적으로 사용하는 키워드를 사용하며, 가급적 GoF패턴의 명칭들은 그 의도와 비슷한 경우에만 사용. (자바쪽에 특히 오용된것들이 많습니다 )


4. 해당언어의 이디엄과 추구하는 방향에 맞춰 코딩한다.

ㅡ 예를들어 자바 코드짜는데 C처럼 짜면안되겠죠. 마찬가지로 코틀린 코드 짜는데 자바처럼 짜면 후지다라는 느낌이 듭니다.


5. 팀이 정한 컨벤션에 일치하는지

ㅡ 예외처리(가까이서 처리? 멀리서 처리? 등)나 로깅의 경우 답이 없기 때문에 일치화가 중요

ㅡ 탭사용규정,줄바꿈규정 등등


6. 바퀴를 재발명하지 마라

ㅡ 이미 잘 짜여진 기술이 있고, 변경 필요가 없다면 있는것을 사용해서 의사소통 비용줄임. 예를 들어 JVM에서 프록시 패턴을 굳이 스스로 만들기 보단 다이나믹 프록시나 CGLIB 사용. 스프링지원기술사용

물론 발명할 필요성은 추후에 검토 합니다. C++의 STL이나 자바의 컬렉션이나 보편적 성능일뿐이지 특정상황에선 엄청느리니까요


7. 후임자가 실수 할 여지를 줄인다. 제약 상황을 많이 만들어 넣어서 후임자가  잘못하면 가급적 컴파일 타이밍에 에러를 내게 합니다.

8.추상화가 잘 된 코드

9.선대의 패턴이 잘 적용된 코드

10. 시대흐름에 맞는 코드 

11.테스트 친화적 코드


정도가 눈에 보이며 그런 코드는 감동스러워 지더군요. 


2022-05-07 12:22:39 에 아래 내용에서 변경 됨 #13

잘짠코드에 대한 기준에는 주관적 요소가 있음을 알아두시구요. 아는 만큼 보이며 아는게 많아도 상호간 상황에 따라 서로 다르게 판단 할 수도 있습니다.


제가 느끼는 잘짠코드라 함은


1. 변경이 쉽다. 

ㅡ 변경함에 있어서 해당요소의 경계가 명확하다.

ㅡ 변경함에 있어서 주변소스의 변경은 제로화한다. 


2. 반복이 없다

ㅡ 반복되는 부분을 하나로 만든다.


3. 이름짓기를 잘한다.

ㅡ 추상층이 높아 질 수록 보편적으로 사용하는 키워드를 사용하며, 가급적 GoF패턴의 명칭들은 그 의도와 비슷한 경우에만 사용. (자바쪽에 특히 오용된것들이 많습니다 )


4. 해당언어의 이디엄과 추구하는 방향에 맞춰 코딩한다.

ㅡ 예를들어 자바 코드짜는데 C처럼 짜면안되겠죠. 마찬가지로 코틀린 코드 짜는데 자바처럼 짜면 후지다라는 느낌이 듭니다.


5. 팀이 정한 컨벤션에 일치하는지

ㅡ 예외처리(가까이서 처리? 멀리서 처리? 등)나 로깅의 경우 답이 없기 때문에 일치화가 중요

ㅡ 탭사용규정,줄바꿈규정 등등


6. 바퀴를 재발명하지 마라

ㅡ 이미 잘 짜여진 기술이 있고, 변경 필요가 없다면 있는것을 사용해서 의사소통 비용줄임. 예를 들어 JVM에서 프록시 패턴을 굳이 스스로 만들기 보단 다이나믹 프록시나 CGLIB 사용. 스프링지원기술사용

물론 발명할 필요성은 추후에 검토 합니다. C++의 STL이나 자바의 컬렉션이나 보편적 성능일뿐이지 특정상황에선 엄청느리니까요


7. 후임자가 실수 할 여지를 줄인다. 제약 상황을 많이 만들어 넣어서 후임자가  잘못하면 가급적 컴파일 타이밍에 에러를 내게 합니다.

8.추상화가 잘 된 코드

9.선대의 패턴이 잘 적용된 코드

10. 시대흐름에 맞는 코드 

11.테스트 친화적 코드


정도가 눈에 보이며 그런 코드는 존경스러워 지더군요. 


2022-05-07 11:57:10 에 아래 내용에서 변경 됨 #12

잘짠코드에 대한 기준에는 주관적 요소가 있음을 알아두시구요. 아는 만큼 보이며 아는게 많아도 상호간 상황에 따라 서로 다르게 판단 할 수도 있습니다.


대게 잘짠코드라 함은


1. 변경이 쉽다. 

ㅡ 변경함에 있어서 해당요소의 경계가 명확하다.

ㅡ 변경함에 있어서 주변소스의 변경은 제로화한다. 


2. 반복이 없다

ㅡ 반복되는 부분을 하나로 만든다.


3. 이름짓기를 잘한다.

ㅡ 추상층이 높아 질 수록 보편적으로 사용하는 키워드를 사용하며, 가급적 GoF패턴의 명칭들은 그 의도와 비슷한 경우에만 사용. (자바쪽에 특히 오용된것들이 많습니다 )


4. 해당언어의 이디엄과 추구하는 방향에 맞춰 코딩한다.

ㅡ 예를들어 자바 코드짜는데 C처럼 짜면안되겠죠. 마찬가지로 코틀린 코드 짜는데 자바처럼 짜면 후지다라는 느낌이 듭니다.


5. 팀이 정한 컨벤션에 일치하는지

ㅡ 예외처리(가까이서 처리? 멀리서 처리? 등)나 로깅의 경우 답이 없기 때문에 일치화가 중요

ㅡ 탭사용규정,줄바꿈규정 등등


6. 바퀴를 재발명하지 마라

ㅡ 이미 잘 짜여진 기술이 있고, 변경 필요가 없다면 있는것을 사용해서 의사소통 비용줄임. 예를 들어 JVM에서 프록시 패턴을 굳이 스스로 만들기 보단 다이나믹 프록시나 CGLIB 사용. 스프링지원기술사용

물론 발명할 필요성은 추후에 검토 합니다. C++의 STL이나 자바의 컬렉션이나 보편적 성능일뿐이지 특정상황에선 엄청느리니까요


7. 후임자가 실수 할 여지를 줄인다. 제약 상황을 많이 만들어 넣어서 후임자가  잘못하면 가급적 컴파일 타이밍에 에러를 내게 합니다.

8.추상화가 잘 된 코드

9.선대의 패턴이 잘 적용된 코드

10. 시대흐름에 맞는 코드 

11.테스트 친화적 코드


정도로 판단하면 되지 않을 까 합니다.


2022-05-07 11:53:39 에 아래 내용에서 변경 됨 #11

잘짠코드에 대한 기준에는 주관적 요소가 있음을 알아두시구요. 아는 만큼 보이며 아는게 많아도 상호간 상황에 따라 서로 다르게 판단 할 수도 있습니다.


대게 잘짠코드라 함은


1. 변경이 쉽다. 

ㅡ 변경함에 있어서 해당요소의 경계가 명확하다.

ㅡ 변경함에 있어서 주변소스의 변경은 제로화한다. 


2. 반복이 없다

ㅡ 반복되는 부분을 하나로 만든다.


3. 이름짓기를 잘한다.

ㅡ 추상층이 높아 질 수록 보편적으로 사용하는 키워드를 사용하며, 가급적 GoF패턴의 명칭들은 그 의도와 비슷한 경우에만 사용. (자바쪽에 특히 오용된것들이 많습니다 )


4. 해당언어의 이디엄과 추구하는 방향에 맞춰 코딩한다.

ㅡ 예를들어 자바 코드짜는데 C처럼 짜면안되겠죠. 마찬가지로 코틀린 코드 짜는데 자바처럼 짜면 후지다라는 느낌이 듭니다.


5. 팀이 정한 컨벤션에 일치하는지

ㅡ 예외처리(가까이서 처리? 멀리서 처리? 등)나 로깅의 경우 답이 없기 때문에 일치화가 중요

ㅡ 탭사용규정,줄바꿈규정 등등


6. 바퀴를 재발명하지 마라

ㅡ 이미 잘 짜여진 기술이 있고, 변경 필요가 없다면 있는것을 사용해서 의사소통 비용줄임. 예를 들어 JVM에서 프록시 패턴을 굳이 스스로 만들기 보단 다이나믹 프록시나 CGLIB 사용. 스프링지원기술사용

물론 발명할 필요성은 추후에 검토 합니다. C++의 STL이나 자바의 컬렉션이나 보편적 성능일뿐이지 특정상황에선 엄청느리니까요


7. 후임자가 실수 할 여지를 줄인다. 제약 상황을 많이 만들어 넣어서 후임자가  잘못하면 가급적 컴파일 타이밍에 에러를 내게 합니다.

8.추상화가 잘 된 코드

9.선대의 패턴이 잘 적용된 코드

10. 시대흐름에 맞는 코드 


정도로 판단하면 되지 않을 까 합니다.


2022-05-07 11:49:09 에 아래 내용에서 변경 됨 #10

잘짠코드에 대한 기준에는 주관적 요소가 있음을 알아두시구요. 아는 만큼 보이며 아는게 많아도 상호간 상황에 따라 서로 다르게 판단 할 수도 있습니다.


대게 잘짠코드라 함은


1. 변경이 쉽다. 

ㅡ 변경함에 있어서 해당요소의 경계가 명확하다.

ㅡ 변경함에 있어서 주변소스의 변경은 제로화한다. 


2. 반복이 없다

ㅡ 반복되는 부분을 하나로 만든다.


3. 이름짓기를 잘한다.

ㅡ 추상층이 높아 질 수록 보편적으로 사용하는 키워드를 사용하며, 가급적 GoF패턴의 명칭들은 그 의도와 비슷한 경우에만 사용. (자바쪽에 특히 오용된것들이 많습니다 )


4. 해당언어의 이디엄과 추구하는 방향에 맞춰 코딩한다.

ㅡ 예를들어 자바 코드짜는데 C처럼 짜면안되겠죠. 마찬가지로 코틀린 코드 짜는데 자바처럼 짜면 후지다라는 느낌이 듭니다.


5. 팀이 정한 컨벤션에 일치하는지

ㅡ 예외처리(가까이서 처리? 멀리서 처리? 등)나 로깅의 경우 답이 없기 때문에 일치화가 중요

ㅡ 탭사용규정,줄바꿈규정 등등


6. 바퀴를 재발명하지 마라

ㅡ 이미 잘 짜여진 기술이 있고, 변경 필요가 없다면 있는것을 사용해서 의사소통 비용줄임. 예를 들어 JVM에서 프록시 패턴을 굳이 스스로 만들기 보단 다이나믹 프록시나 CGLIB 사용. 스프링지원기술사용

물론 발명할 필요성은 추후에 검토 합니다. C++의 STL이나 자바의 컬렉션이나 보편적 성능일뿐이지 특정상황에선 엄청느리니까요


7. 후임자가 실수 할 여지를 줄인다. 제약 상황을 많이 만들어 넣어서 후임자가  잘못하면 가급적 컴파일 타이밍에 에러를 내게 합니다.

8.추상화가 잘 된 코드

9.선대의 패턴이 잘 적용된 코드

10. 시대흐름에 맞는 코드 


정도로 판단하면 되지 않을 까 합니다.

(

2022-05-07 11:49:01 에 아래 내용에서 변경 됨 #9

잘짠코드에 대한 기준에는 주관적 요소가 있음을 알아두시구요. 아는 만큼 보이며 아는게 많아도 상호간 상황에 따라 서로 다르게 판단 할 수도 있습니다.


대게 잘짠코드라 함은


1. 변경이 쉽다. 

ㅡ 변경함에 있어서 해당요소의 경계가 명확하다.

ㅡ 변경함에 있어서 주변소스의 변경은 제로화한다. 


2. 반복이 없다

ㅡ 반복되는 부분을 하나로 만든다.


3. 이름짓기를 잘한다.

ㅡ 추상층이 높아 질 수록 보편적으로 사용하는 키워드를 사용하며, 가급적 GoF패턴의 명칭들은 그 의도와 비슷한 경우에만 사용. (자바쪽에 특히 오용된것들이 많습니다 )


4. 해당언어의 이디엄과 추구하는 방향에 맞춰 코딩한다.

ㅡ 예를들어 자바 코드짜는데 C처럼 짜면안되겠죠. 마찬가지로 코틀린 코드 짜는데 자바처럼 짜면 후지다라는 느낌이 듭니다.


5. 팀이 정한 컨벤션에 일치하는지

ㅡ 예외처리(가까이서 처리? 멀리서 처리? 등)나 로깅의 경우 답이 없기 때문에 일치화가 중요

ㅡ 탭사용규정,줄바꿈규정 등등


6. 바퀴를 재발명하지 마라

ㅡ 이미 잘 짜여진 기술이 있고, 변경 필요가 없다면 있는것을 사용해서 의사소통 비용줄임. 예를 들어 JVM에서 프록시 패턴을 굳이 스스로 만들기 보단 다이나믹 프록시나 CGLIB 사용. 스프링지원기술사용

물론 발명할 필요성은 추후에 검토 합니다. C++의 STL이나 자바의 컬렉션이나 보편적 성능일뿐이지 특정상황에선 엄청느리니까요


7. 후임자가 실수 할 여지를 줄인다. 제약 상황을 많이 만들어 넣어서 후임자가  잘못하면 가급적 컴파일 타이밍에 에러를 내게 합니다.


정도로 판단하면 되지 않을 까 합니다.

2022-05-07 09:33:03 에 아래 내용에서 변경 됨 #8

잘짠코드에 대한 기준에는 주관적 요소가 있음을 알아두시구요. 아는 만큼 보이며 아는게 많아도 상호간 상황에 따라 서로 다르게 판단 할 수도 있습니다.


대게 잘짠코드라 함은


1. 변경이 쉽다. 

ㅡ 변경함에 있어서 해당요소의 경계가 명확하다.

ㅡ 변경함에 있어서 주변소스의 변경은 제로화한다. 


2. 반복이 없다

ㅡ 반복되는 부분을 하나로 만든다.


3. 이름짓기를 잘한다.

ㅡ 추상층이 높아 질 수록 보편적으로 사용하는 키워드를 사용하며, 가급적 GoF패턴의 명칭들은 그 의도와 비슷한 경우에만 사용. (자바쪽에 특히 오용된것들이 많습니다 )


4. 해당언어의 이디엄과 추구하는 방향에 맞춰 코딩한다.

ㅡ 예를들어 자바 코드짜는데 C처럼 짜면안되겠죠. 마찬가지로 코틀린 코드 짜는데 자바처럼 짜면 후지다라는 느낌이 듭니다.


5. 팀이 정한 컨벤션에 일치하는지

ㅡ 예외처리(가까이서 처리? 멀리서 처리? 등)나 로깅의 경우 답이 없기 때문에 일치화가 중요

ㅡ 탭사용규정,줄바꿈규정 등등


6. 바퀴를 재발명하지 마라

ㅡ 이미 잘 짜여진 기술이 있고, 변경 필요가 없다면 있는것을 사용해서 의사소통 비용줄임. 예를 들어 JVM에서 프록시 패턴을 굳이 스스로 만들기 보단 다이나믹 프록시나 CGLIB 사용. 스프링지원기술사용

물론 발명할 필요성은 추후에 검토 합니다. C++의 STL이나 자바의 컬렉션이나 보편적 성능일뿐이지 특정상황에선 엄청느리니까요


7. 후임자가 실수 할 여지를 줄인다. 제약 상황을 많이 만들어 넣어서 후임자가 조금 잘 못하면 가급적 컴파일 타이밍에 에러를 내게 합니다.


정도로 판단하면 되지 않을 까 합니다.

2022-05-07 09:32:05 에 아래 내용에서 변경 됨 #7

잘짠코드에 대한 기준에는 주관적 요소가 있음을 알아두시구요. 아는 만큼 보이며 아는게 많아도 상호간 상황에 따라 서로 다르게 판단 할 수도 있습니다.


대게 잘짠코드라 함은


1. 변경이 쉽다. 

ㅡ 변경함에 있어서 해당요소의 경계가 명확하다.

ㅡ 변경함에 있어서 주변소스의 변경은 제로화한다. 


2. 반복이 없다

ㅡ 반복되는 부분을 하나로 만든다.


3. 이름짓기를 잘한다.

ㅡ 추상층이 높아 질 수록 보편적으로 사용하는 키워드를 사용하며, 가급적 GoF패턴의 명칭들은 그 의도와 비슷한 경우에만 사용. (자바쪽에 특히 오용된것들이 많습니다 )


4. 해당언어의 이디엄과 추구하는 방향에 맞춰 코딩한다.

ㅡ 예를들어 자바 코드짜는데 C처럼 짜면안되겠죠. 마찬가지로 코틀린 코드 짜는데 자바처럼 짜면 후지다라는 느낌이 듭니다.


5. 팀이 정한 컨벤션에 일치하는지

ㅡ 예외처리(가까이서 처리? 멀리서 처리? 등)나 로깅의 경우 답이 없기 때문에 일치화가 중요

ㅡ 탭사용규정,줄바꿈규정 등등


6. 바퀴를 재발명하지 마라

ㅡ 이미 잘 짜여진 기술이 있고, 변경 필요가 없다면 있는것을 사용해서 의사소통 비용줄임. 예를 들어 JVM에서 프록시 패턴을 굳이 스스로 만들기 보단 다이나믹 프록시나 CGLIB 사용. 스프링지원기술사용

물론 발명할 필요성은 추후에 검토 합니다. C++의 STL이나 자바의 컬렉션이나 보편적 성능이지 특정상황에선 엄청느리니까요


7. 후임자가 실수 할 여지를 줄인다. 제약 상황을 많이 만들어 넣어서 후임자가 조금 잘 못하면 가급적 컴파일 타이밍에 에러를 내게 합니다.


정도로 판단하면 되지 않을 까 합니다.

2022-05-07 09:31:35 에 아래 내용에서 변경 됨 #6

잘짠코드에 대한 기준에는 주관적 요소가 있음을 알아두시구요. 아는 만큼 보이며 아는게 많아도 상호간 상황에 따라 서로 다르게 판단 할 수도 있습니다.


대게 잘짠코드라 함은


1. 변경이 쉽다. 

ㅡ 변경함에 있어서 해당요소의 경계가 명확하다.

ㅡ 변경함에 있어서 주변소스의 변경은 제로화한다. 


2. 반복이 없다

ㅡ 반복되는 부분을 하나로 만든다.


3. 이름짓기를 잘한다.

ㅡ 추상층이 높아 질 수록 보편적으로 사용하는 키워드를 사용하며, 가급적 GoF패턴의 명칭들은 그 의도와 비슷한 경우에만 사용. (자바쪽에 특히 오용된것들이 많습니다 )


4. 해당언어의 이디엄과 추구하는 방향에 맞춰 코딩한다.

ㅡ 예를들어 자바 코드짜는데 C처럼 짜면안되겠죠. 마찬가지로 코틀린 코드 짜는데 자바처럼 짜면 후지다라는 느낌이 듭니다.


5. 팀이 정한 컨벤션에 일치하는지

ㅡ 예외처리(가까이서 처리? 멀리서 처리? 등)나 로깅의 경우 답이 없기 때문에 일치화가 중요

ㅡ 탭사용규정,줄바꿈규정 등등


6. 바퀴를 재발명하지 마라

ㅡ 이미 잘 짜여진 기술이 있고, 변경 필요가 없다면 있는것을 사용해서 의사소통 비용줄임. 예를 들어 JVM에서 프록시 패턴을 굳이 스스로 만들기 보단 다이나믹 프록시나 CGLIB 사용.

물론 발명할 필요성은 추후에 검토 합니다. C++의 STL이나 자바의 컬렉션이나 보편적 성능이지 특정상황에선 엄청느리니까요


7. 후임자가 실수 할 여지를 줄인다. 제약 상황을 많이 만들어 넣어서 후임자가 조금 잘 못하면 가급적 컴파일 타이밍에 에러를 내게 합니다.


정도로 판단하면 되지 않을 까 합니다.

2022-05-07 09:30:37 에 아래 내용에서 변경 됨 #5

잘짠코드에 대한 기준에는 주관적 요소가 있음을 알아두시구요. 아는 만큼 보이며 아는게 많아도 상호간 상황에 따라 서로 다르게 판단 할 수도 있습니다.


대게 잘짠코드라 함은


1. 변경이 쉽다. 

ㅡ 변경함에 있어서 해당요소의 경계가 명확하다.

ㅡ 변경함에 있어서 주변소스의 변경은 제로화한다. 


2. 반복이 없다

ㅡ 반복되는 부분을 하나로 만든다.


3. 이름짓기를 잘한다.

ㅡ 추상층이 높아 질 수록 보편적으로 사용하는 키워드를 사용하며, 가급적 GoF패턴의 명칭들은 그 의도와 비슷한 경우에만 사용. (자바쪽에 특히 오용된것들이 많습니다 )


4. 해당언어의 이디엄과 추구하는 방향에 맞춰 코딩한다.

ㅡ 예를들어 자바 코드짜는데 C처럼 짜면안되겠죠. 마찬가지로 코틀린 코드 짜는데 자바처럼 짜면 후지다라는 느낌이 듭니다.


5. 팀이 정한 컨벤션에 일치하는지

ㅡ 예외처리(가까이서 처리? 멀리서 처리? 등)나 로깅의 경우 답이 없기 때문에 일치화가 중요

ㅡ 탭사용규정,줄바꿈규정 등등


6. 바퀴를 재발명하지 마라

ㅡ 이미 잘 짜여진 기술이 있고, 변경 필요가 없다면 있는것을 사용해서 의사소통 비용줄임. 예를 들어 다바에서 프록시 패턴을 굳이 스스로 만들기 보단 다이나믹 프록시나 CGLIB 사용.

물론 발명할 필요성은 추후에 검토 합니다. C++의 STL이나 자바의 컬렉션이나 보편적 성능이지 특정상황에선 엄청느리니까요


7. 후임자가 실수 할 여지를 줄인다. 제약 상황을 많이 만들어 넣어서 후임자가 조금 잘 못하면 가급적 컴파일 타이밍에 에러를 내게 합니다.


정도로 판단하면 되지 않을 까 합니다.

2022-05-07 09:28:47 에 아래 내용에서 변경 됨 #4

잘짠코드에 대한 기준에는 주관적 요소가 있음을 알아두시구요. 아는 만큼 보이며 아는게 많아도 상호간 상황에 따라 서로 다르게 판단 할 수도 있습니다.


대게 잘짠코드라 함은

1. 변경이 쉽다. 

ㅡ 변경함에 있어서 해당요소의 경계가 명확하다.

ㅡ 변경함에 있어서 주변소스의 변경은 제로화한다. 


2. 반복이 없다

ㅡ 반복되는 부분을 하나로 만든다.


3. 이름짓기를 잘한다.

ㅡ 추상층이 높아 질 수록 보편적으로 사용하는 키워드를 사용하며, 가급적 GoF패턴의 명칭들은 그 의도와 비슷한 경우에만 사용. (자바쪽에 특히 오용된것들이 많습니다 )


4. 해당언어의 이디엄과 추구하는 방향에 맞춰 코딩한다.

ㅡ 예를들어 자바 코드짜는데 C처럼 짜면안되겠죠. 마찬가지로 코틀린 코드 짜는데 자바처럼 짜면 후지다라는 느낌이 듭니다.


5. 팀이 정한 컨벤션에 일치하는지

ㅡ 예외처리(가까이서 처리? 멀리서 처리? 등)나 로깅의 경우 답이 없기 때문에 일치화가 중요

ㅡ 탭사용규정,줄바꿈규정 등등


6. 바퀴를 재발명하지 마라

ㅡ 이미 잘 짜여진 기술이 있고, 변경 필요가 없다면 있는것을 사용해서 의사소통 비용줄임. 예를 들어 다바에서 프록시 패턴을 굳이 스스로 만들기 보단 다이나믹 프록시나 CGLIB 사용.

물론 발명할 필요성은 추후에 검토 합니다. C++의 STL이나 자바의 컬렉션이나 보편적 성능이지 특정상황에선 엄청느리니까요


7. 후임자가 실수 할 여지를 줄인다. 제약 상황을 많이 만들어 넣어서 후임자가 조금 잘 못하면 가급적 컴파일 타이밍에 에러를 내게 합니다.


정도로 판단하면 되지 않을 까 합니다.

2022-05-07 09:28:38 에 아래 내용에서 변경 됨 #3

잘짠코드에 대한 기준에는 주관적 요소가 있음을 알아두시구요. 아는 만큼 보이며 아는게 많아도 상호간 상황에 따라 서로 다르게 판단 할 수도 있습니다.


대게 잘짠코드라 함은

1. 변경이 쉽다. 

ㅡ 변경함에 있어서 해당요소의 경계가 명확하다.

ㅡ 변경함에 있어서 주변소스의 변경은 제로화한다. 

2. 반복이 없다

ㅡ 반복되는 부분을 하나로 만든다.

3. 이름짓기를 잘한다.

ㅡ 추상층이 높아 질 수록 보편적으로 사용하는 키워드를 사용하며, 가급적 GoF패턴의 명칭들은 그 의도와 비슷한 경우에만 사용. (자바쪽에 특히 오용된것들이 많습니다 )

4. 해당언어의 이디엄과 추구하는 방향에 맞춰 코딩한다.

ㅡ 예를들어 자바 코드짜는데 C처럼 짜면안되겠죠. 마찬가지로 코틀린 코드 짜는데 자바처럼 짜면 후지다라는 느낌이 듭니다.

5. 팀이 정한 컨벤션에 일치하는지

ㅡ 예외처리(가까이서 처리? 멀리서 처리? 등)나 로깅의 경우 답이 없기 때문에 일치화가 중요

ㅡ 탭사용규정,줄바꿈규정 등등

6. 바퀴를 재발명하지 마라

ㅡ 이미 잘 짜여진 기술이 있고, 변경 필요가 없다면 있는것을 사용해서 의사소통 비용줄임. 예를 들어 다바에서 프록시 패턴을 굳이 스스로 만들기 보단 다이나믹 프록시나 CGLIB 사용.

물론 발명할 필요성은 추후에 검토 합니다. C++의 STL이나 자바의 컬렉션이나 보편적 성능이지 특정상황에선 엄청느리니까요

7. 후임자가 실수 할 여지를 줄인다. 제약 상황을 많이 만들어 넣어서 후임자가 조금 잘 못하면 가급적 컴파일 타이밍에 에러를 내게 합니다.

정도로 판단하면 되지 않을 까 합니다.

2022-05-07 09:28:08 에 아래 내용에서 변경 됨 #2

잘짠코드에 대한 기준에는 주관적 요소가 있음을 알아두시구요. 아는 만큼 보이며 아는게 많아도 상호간 상황에 따라 서로 다르게 판단 할 수도 있습니다.


대게 잘짠코드라 함은

1. 변경이 쉽다. 

ㅡ 변경함에 있어서 해당요소의 경계가 명확히 한다.

ㅡ 변경함에 있어서 주변소스의 변경은 제로화한다. 

2. 반복이 없다

ㅡ 반복되는 부분을 하나로 만든다.

3. 이름짓기를 잘한다.

ㅡ 추상층이 높아 질 수록 보편적으로 사용하는 키워드를 사용하며, 가급적 GoF패턴의 명칭들은 그 의도와 비슷한 경우에만 사용. (자바쪽에 특히 오용된것들이 많습니다 )

4. 해당언어의 이디엄과 추구하는 방향에 맞춰 코딩한다.

ㅡ 예를들어 자바 코드짜는데 C처럼 짜면안되겠죠. 마찬가지로 코틀린 코드 짜는데 자바처럼 짜면 후지다라는 느낌이 듭니다.

5. 팀이 정한 컨벤션에 일치하는지

ㅡ 예외처리(가까이서 처리? 멀리서 처리? 등)나 로깅의 경우 답이 없기 때문에 일치화가 중요

ㅡ 탭사용규정,줄바꿈규정 등등

6. 바퀴를 재발명하지 마라

ㅡ 이미 잘 짜여진 기술이 있고, 변경 필요가 없다면 있는것을 사용해서 의사소통 비용줄임. 예를 들어 다바에서 프록시 패턴을 굳이 스스로 만들기 보단 다이나믹 프록시나 CGLIB 사용.

물론 발명할 필요성은 추후에 검토 합니다. C++의 STL이나 자바의 컬렉션이나 보편적 성능이지 특정상황에선 엄청느리니까요

7. 후임자가 실수 할 여지를 줄인다. 제약 상황을 많이 만들어 넣어서 후임자가 조금 잘 못하면 가급적 컴파일 타이밍에 에러를 내게 합니다.

정도로 판단하면 되지 않을 까 합니다.

2022-05-07 09:27:13 에 아래 내용에서 변경 됨 #1

잘짠코드에 대한 기준에는 주관적요소가 있음을 알아두시구요. 아는 만큼 보이며 아는게 많아도 상호간 상황에 따라 서로 다르게 판단 할 수도 있습니다.

대게 잘짠코드라 함은

1. 변경이 쉽다. 

ㅡ 변경함에 있어서 해당요소의 경계가 명확히 한다.

ㅡ 변경함에 있어서 주변소스의 변경은 제로화한다. 

2. 반복이 없다

ㅡ 반복되는 부분을 하나로 만든다.

3. 이름짓기를 잘한다.

ㅡ 추상층이 높아 질 수록 보편적으로 사용하는 키워드를 사용하며, 가급적 GoF패턴의 명칭들은 그 의도와 비슷한 경우에만 사용. (자바쪽에 특히 오용된것들이 많습니다 )

4. 해당언어의 이디엄과 추구하는 방향에 맞춰 코딩한다.

ㅡ 예를들어 자바 코드짜는데 C처럼 짜면안되겠죠. 마찬가지로 코틀린 코드 짜는데 자바처럼 짜면 후지다라는 느낌이 듭니다.

5. 팀이 정한 컨벤션에 일치하는지

ㅡ 예외처리(가까이서 처리? 멀리서 처리? 등)나 로깅의 경우 답이 없기 때문에 일치화가 중요

ㅡ 탭사용규정,줄바꿈규정 등등

6. 바퀴를 재발명하지 마라

ㅡ 이미 잘 짜여진 기술이 있고, 변경 필요가 없다면 있는것을 사용해서 의사소통 비용줄임. 예를 들어 다바에서 프록시 패턴을 굳이 스스로 만들기 보단 다이나믹 프록시나 CGLIB 사용.

물론 발명할 필요성은 추후에 검토 합니다. C++의 STL이나 자바의 컬렉션이나 보편적 성능이지 특정상황에선 엄청느리니까요

7. 후임자가 실수 할 여지를 줄인다. 제약 상황을 많이 만들어 넣어서 후임자가 조금 잘 못하면 가급적 컴파일 타이밍에 에러를 내게 합니다.

정도로 판단하면 되지 않을 까 합니다.