정작 그들이 쓰는 스프링, 자바, 코틀린 전부 코드 까보면
이 코드는 어떻게 쓰이는건지 정말 상세하게 설명해주고 있는데
이사람들보다 개발 실력도 뛰어나지 않은 새끼들이,
책임 분리도 제대로 하지도 못하는 새끼들이
내 코드는 클린 코드야 자기 딸딸이 치면서 주석 한줄 안적는 모습이 굉장히 병신같음.
정말 간단한 코드에 주석을 쓰라는 말이 아니라,
복잡한 서비스를 구현할 때는 최소 이런 코드는 이렇게 해서 동작한다 라는 주석만 달아줘도
다른 개발자가 그 코드를 읽었을 때 이해하는 시간을 크게 줄일 수 있음.
정작 자기가 짜놓은 코드도 일주일 뒤에 돌아보면 가물가물해서 다시 보는 경우가 많은데
그 때의 니가 써놓은 주석 보고 아 맞다 여긴 이렇게 수정하면 되겠지랑
아 .. 요구사항 새로 추가됐는데 어디 수정해야되더라. 하면서 다시 처음부터 코드 분석하는 병신이랑
누가 생산성이 더 높겠냐
코드 분석을 최대한 범위를 좁혀가면서 할 수 있도록 도와주는게 주석의 장점인데
주석 때문에 코드 라인 3~4줄 늘어난다고, 이정도 깔끔하게 짰으면 남들이 이해해주겠지~
이러면서 주석 쓰는건 클린 코드가 아니야~ 이러는 애들은 솔직히 싸커킥 마렵긴함.
주석은 꼭 필요한 곳에만 같은 소리하는 개발자 보면 줘패고싶긴함 self explanatory한 코드가 베스트지만 현실은 95%가 자바 개발자인 나라에서 러스트가 이상적인 언어라고 하는 것과 다른게 없지 오픈소스 까본 적 있냐고 물어보고싶음
코드 개같이 짜고 주석으로 커버치려는 부류임?
오픈소스 자주 까보지만 주석은 꼭 필요한 곳에만 있어야 한다고 생각함 - dc App
그냥 주석 쓰는건 비추 JavaDoc/KDoc/JSDoc 같은 걸 써야 함
ㅇㅇ 그거 말하는거임
코드는 개판인데 주석 남발하고 커버칠 생각 하지 말고 주석 최소화해도 괜찮은 코드를 짤 생각을 해야지. 그 코드와 주석사이의 퀄리티가 사람마다 다른거고. 걔네는 주석 코드 둘 다 퀄이 그냥 낮은거지. 너가 말하는 스프링, 자바, 코틀린 주석은 모듈 레벨이고 라인 단위에서는 그리 많지 않음. 게다가 애초에 모듈레벨에서는 컨벤션으로 논의되야할 부분임.
라인 단위에서는 최대한 self explain하게 짜는게 맞고 해당 코드가 그렇게 작용하지 못한다면 주석을 쓰기 보다는 모듈을 더 나눠야하는거임. 그런 부분에서 주석은 죄악시되는거고
오픈소스에서 함수 바디에 있는 주석 찾아봐라 그렇게 찬양받는 글로벌 대기업이더라도 주석 한줄 없는 경우도 많다.
주석 한줄 없는 오픈소스 하나만 알려줘봐. 리눅스 커널을 봐도 주석 간간히 보이는데 주석이 전혀 없는 오픈소스가 뭔지 한번 보고싶네
머기업 다니는데 이 회사 코드도 90%가 주석이 없다. 없는 이유는 self explanatory한 코드여서가 아니고, 게을러서, 양심이 없어서다
정형화된 패턴이 있는 코드의 경우에는 주석 안 달아도 이해가는 경우가 있는데, 좀 마이너한 분야의 코딩하다보면 내가 봤을 때 패턴이 안 보이니까 3개월 뒤에 내가 짠 코드 수정하려고 들여다보면 시간 오지게 걸림. 그럴 때는 주석 남발해도 된다고 봄 - dc App
주석 팍팍 무치는게 그래도 협업하는데 더 좋음, 팍팍 치셈
ㄹㅇ 주석 있는게 낫다
해당 댓글은 삭제되었습니다.
주석도 안고치는 게으른놈이 문서는 작성은 꼼꼼하게 할거란 이유는? - dc App
주석이랑 코드가 따로 놀 때 작성자가 달라졌다는 사실을 알려주는 git lens 쓰세요
잘 짜인 코드는 주석이 필요없다 > 땔감들이 이걸 듣게된게 만악의 근원
주석 거의 없는 오픈소스 보쉴?
https://github.com/clojure/clojure/blob/master/src/clj/clojure/core.clj
https://github.com/clojure/clojure/blob/master/src/clj/clojure/main.clj
예전에 이 닉네임 개좆이라고 본것같은데
나 혼자 문제풀때는 귀찮아서 안쓸이유라도있지 딴애들 볼 코드는 시간 걸리더라도 달아야 알아먹을텐데 (이유 주석안달린 코드 해석 힘들어하는 ㅂㅅ이라 역지사지 함) - dc App