1. 명확한 이름붙이려다 코딩양이 증가하면 해롭다.
명확하게 하려다 이름 길어지면 로직 변경될때마다 이름 다 바꿔야한다
물론 간략하면서 명확하면 좋겠지만 그렇게 할 수 있는 경우 많이 없다
그냥 주석을 붙여라
기획이나 설계 잘하면 로직변경 안할 것 같지?
일하는 중에 스스로 만든 코드에서 로직 변경해야한다는 생각이 안들면
지나치게 쉬운 작업이거나 생각이 없는거다.
보통은 생각은 드는데 마감에 쫓겨 시간이 없거나 워라벨때문에 안고치는거지.
2. 단일 기능 함수만들려다 로직이 파편화되면 더 해롭다.
단일 함수가 10개 있는 것보다 여러 기능하는 함수 하나가 더 동작 파악하기 유리할 때가 있다
그냥 스크롤 한두번 밀면 파악되는 코드와 스크롤 아래위로 열심히 하면서 왔다갔다해야하는 코드 어느쪽이 좋을까?
단일 기능으로 하려는 것은 결국 읽기 쉽게하려는 것인데 의도를 벗어나면서까지 원칙을 지킬 이유는 없다.
재사용이 필요한 함수라면 그래도 분리해야지
3. 예외처리가 이로울때는 케바케
때때로 언어에 따라 예외처리하면 메모리 리와인딩이 망하는 경우가 있다
언어에 따라 리턴값이 bottom을 지원하면 예외가 필요없다
예외처리 제대로 지원하는 언어라도 리턴값보다 퍼포먼스가 느리다
예외처리하면 코드가 지저분해진다.
예외처리하는데 aop를 쓰면 로직 파편화로 인한 한계가 있다
써야할때는 써야하지만 안쓰고 이해가면 안쓰는게 더 좋다.
4. tdd는 기획이나 개발계획이 안바뀔때나 적용가능하다
고객 요구가 수시로 바뀌고 설계변경되는데다 리펙토링 시간까지 안주는 불지옥반도에서는 어렵다.
tdd 하다간 테스트만 작성하다 프로젝트 마감일본다.
명확하게 하려다 이름 길어지면 로직 변경될때마다 이름 다 바꿔야한다
물론 간략하면서 명확하면 좋겠지만 그렇게 할 수 있는 경우 많이 없다
그냥 주석을 붙여라
기획이나 설계 잘하면 로직변경 안할 것 같지?
일하는 중에 스스로 만든 코드에서 로직 변경해야한다는 생각이 안들면
지나치게 쉬운 작업이거나 생각이 없는거다.
보통은 생각은 드는데 마감에 쫓겨 시간이 없거나 워라벨때문에 안고치는거지.
2. 단일 기능 함수만들려다 로직이 파편화되면 더 해롭다.
단일 함수가 10개 있는 것보다 여러 기능하는 함수 하나가 더 동작 파악하기 유리할 때가 있다
그냥 스크롤 한두번 밀면 파악되는 코드와 스크롤 아래위로 열심히 하면서 왔다갔다해야하는 코드 어느쪽이 좋을까?
단일 기능으로 하려는 것은 결국 읽기 쉽게하려는 것인데 의도를 벗어나면서까지 원칙을 지킬 이유는 없다.
재사용이 필요한 함수라면 그래도 분리해야지
3. 예외처리가 이로울때는 케바케
때때로 언어에 따라 예외처리하면 메모리 리와인딩이 망하는 경우가 있다
언어에 따라 리턴값이 bottom을 지원하면 예외가 필요없다
예외처리 제대로 지원하는 언어라도 리턴값보다 퍼포먼스가 느리다
예외처리하면 코드가 지저분해진다.
예외처리하는데 aop를 쓰면 로직 파편화로 인한 한계가 있다
써야할때는 써야하지만 안쓰고 이해가면 안쓰는게 더 좋다.
4. tdd는 기획이나 개발계획이 안바뀔때나 적용가능하다
고객 요구가 수시로 바뀌고 설계변경되는데다 리펙토링 시간까지 안주는 불지옥반도에서는 어렵다.
tdd 하다간 테스트만 작성하다 프로젝트 마감일본다.
해당 댓글은 삭제되었습니다.
클린코드는 책제목이다. 서점도 안다니냐?
온라인 서점에도 있단다. 니가 애초에 책 읽고 다니는 사람이 아닌게지.
그래 모르는거에 만족하면서 부족한점 인정하지말고 오래오래 살아라
그냥 넌 내 글에 댓글달지마. 가끔 니가 쓰는 똥글 보면서 느끼는 감정을 내 글에서 느끼고 싶지 않다.
1번은 걍 ide 쓰면 한 번에 바뀌고 한 번에 정의되는데 대체 왜..?? 손코딩 하심?
그리고 4번은 테스트 코드 못 짜는 사람들 대표적인 변명인데 코드 작성 익숙해지면 기능 추가할 때마다 매번 톰캣 껐다켰다 할 시간에 코드로 p/f 검증하는게 개발속도 압도적으로 빨라짐 이건 장담함
2번 3번은 경우에 따라 맞는 말일 수도 있어서 공감함 유지보수 측면으로는 병신이지만 어차피 si는 만들고 튀면 그만이니까 생산성을 최우선으로 고려해야하지
인정. 툴이 좋으면 가능. 근데 내 경험상 가끔 툴도 엉뚱한거 고치거나 빼먹고 안고치는 경우가 있어서. 나는 그냥 코드 안고치고 주석만 바꾸는게 더 낫다고 생각함
테스트가 언제나 가능하다고 믿는다면 지금까지 행복하게 살아온거라고 생각함 하지만 좋다고 생각하는 사람에게 하지말라고 할만큼 양심 없지는 않음. 좋으면 계속 하면 됌
아재요 테스트에 통과된 코드만 실제 로직에 넣는건데 뭔 테스트가 안 통하는 환경 타령이쇼ㅋㅋ 어차피 코드를 못 믿고 눈으로 작동되는걸 봐야 안심하는 사람들이 많으니까 나도 굳이 먹어보라 강요하진 않음 아무리 설명해도 못 믿더라고..
잘동작하면 계속 쓰면 된다니까 테스트 작성해봐서 잘 알겠지만 테스트라는건 같은 시나리오에서 동작하는거잖아 시나리오가 달라지고 로직이 변경되면 그 테스트 못써먹어 이번주까지 뭐해주세요. 내일까지 뭐 해주세요. 오늘 퇴근전까지 뭐 해주세요 하는 환경에서는 더하고.
ㅋㅋ 아재요 그러니까 그런 환경에서 더 빛을 발한다고요 갑자기 요구사항 변경되고 고객한테서 건물 3cm 옮겨달라는 요청 들어올 때마다 로직 재설계 하고 모든 기능 다시 테스트 하고 그러다가 오픈 전에 통합버그 튀어나와서 골 썩이는거에요 근데 어차피 아무리 설명해도 안 써본 사람은 못 믿더라ㅋㅋ 잠깐 써보다가 생산성 떨어진다고 때려치니 익숙해질 리가 없징
니가 말하는거랑 내가 말하는 것에 근본적인 차이가 있어 넌 시나리오가 변하지 않으니 작성한 테스트를 2번이상 계속 돌릴 수 있다고 믿는거야 난 그걸 부정하지 않는다니까
비즈니스 로직이 바뀌면 당연히 테스트 시나리오도 변하지 하나도 모르면서 참 고지식하시네ㅋㅋ 긴급한 수정사안 들어와서 부랴부랴 쳐내고 테스트 돌리잖아요? 그럼 수정한 페이지는 잘 되는데 꼭 내가 의도하지 않았던 부분에서 테스트 fail 뜨는 곳이 있어요 톰캣 껐다켰다 하며 눈으로만 작동 테스트 하는 사람들은 검증을 못하는 부분이죠 이런게 누적돼서 오픈 직전에 통합버그 터지고 야근하는겁니다 시나리오 바뀔 때마다 테스트 코드도 바꾸는거 짧게보면 코드 2번 치는거 같고 미련해보이지만 길게보면 크런치 타임에 야간 철야할거 다 없애줍니다
오키 도키. 아마 내가 본글에 tdd 완전히 쓸모없다고 너무 부정적으로 적어서 그런것 같은데 내가 너무 과장했고 잘못했음. 수정하지 않은 부분에서 문제 튀어나올때 테스트 만들어놓으면 쉽게 잡을 수 있다는거 인정.
솔직히 그동안 안 쓰고도 개발 잘 해왔으니 굳이 필요성을 못느끼는건 ㅇㅈ합니다 근데 정말 찍먹이라도 해보면 쾌적해요 난 첨엔 업무도 안 익숙한데 바보같이 테스트 작성에 시간 다 뺏겨서 업무 시간엔 기능 쳐내고 남들 퇴근할 때 남아서 테스트 작성하며 배웠음.. 오히려 짬 좀 차서 속도 빠른 개발자면 테스트가 더 빛을 발할겁니다
일단 나는 프론트 주로함 화면 레이아웃 변경되는건 예사고 화면 동작이나 기능이 다른 곳으로 옮겨가거나 그 자체가 바뀌는 것 엄청 흔함 애니메이션 타이밍 수정되면 같은 기능이라도 테스트 시점이 달라져서 그 코드 못씀 어쨌든 만들어놓은 테스트가 유용하다는걸 부정하지는 않음
아.. 프론트 테스트는 작성해본적 없어서 모르겠네 ㅋㅅㅋ;
님 테스트코드는 어떻게배움? 백엔드기획자인데 requst가 바뀌는경우도 허다한데 시간마저 없어서 넘 힘든데 구조적으로 tdd하려면 어떤서적,/강의부터 시작해야하나요? 경섬공유좀요 - dc App
핑계좋다 ㅂㅅ ㄱㅋ 인텔리제이한테 가르침을 받고 와라 If로만 10점 받것노
프로젝트 규모나 인력이 정말 많아지면, tdd나 클린코드가 유의미하다고봄. 근데 그 레벨 엄청 높다고 생각함 MSA 개인적으로 비슷한 맥락이라고 봄 - dc App
모듈 분리만 잘해도 빌드 속도 극적으로 줄어들고, 모듈 분리 잘하면 테스트코드 넣기도 편하긴함. 그과정이 심하게 골때리긴 한데 - dc App