SonarQube를 이용한 정적분석 및 소스코드 품질검증 방법 (#2-Use Guide)
안녕하세요 @flyyou입니다.
이전 포스트에서 SonarQube에 대한 설치 및 설정을 알아보았습니다.
SonarQube를 이용한 정적분석 및 소스코드 품질검증 방법 (#1-SonarQube Install & Setting) : https://steemit.com/kr-dev/@flyyou/sonarqube-1-sonarqube-install-and-setting
설치 및 설정을 했으면 사용을 해야겠죠?
사용을 하기위한 설명입니다.
복잡도 같은 경우에는 업체마다 정책이 있습니다. 한 Method당 if문이나 switch 문등의 개수를 말하는데
이런 분기처리가 많으면 복잡도가 올라가게 되어있습니다.
이런 경우에는 Method를 보다 더 세세하게 분할하여서 개발을 하는것이 좋습니다.
개발 완료하고 나서 SonarQube를 수행하면 수정해야 할 것들이 너무 많이 나옵니다.
중간중간에 기간을 두고 정적분석을 수행하여서 개발 중간에 교정이될 수 있도록 하여야만
학습효과가 생겨서 추후 정적분석을 수월하게 진행 할 수 있겠습니다.
Fail 발생 주요 사유
Fail 발생 주요 사유는 위와 같습니다.
설정이 잘못되면 Fail발생이 되오니 이점 참고 부탁드립니다.
개발도 중요하지만 품질을 높이는것은 보다 더더더더 중요하다는 사실을 잊으시면 안됩니다.
Hi @flyyou! @nhj12311 is sending you 0.1 SBD tip and @tipU upvote
:)
send tips with @tipU | earn interest in @tipU profit
thank you
자바도되고 닷넷도 되나 보군요~ 좋습니다. 저희는 PMD와 Findbug를 병행해서 체크하고 있는데 한번 검토한번 해봐야겠습니다. 감사합니다.
품질 중요하죠... 좋은정보 감사합니다.
네 즐거운 하루 되세요~
품질이 중요한건 알지만 항상 뒷전이 되네요...
제작년인가...몇가지 유료 소스분석 솔루션을 검토했었는데 실무자 입장에서 저게 있어도 결국 소스를 다 봐야하기에 쓸모 없다고 판단했거든요. 비지니스가 워낙 분기가 많아서 툴로 보니 마치 미로 같더군요.
그래도 궁금하긴 합니다 ^^ tip!
tip 매우 감사합니다. 처음받아 보네요~ 기분이 좋습니다. 역시 팁을 받으면 기분좋은것은 모든 사람들의 공통점인가 봅니다.
정적분석은 중요합니다. 그렇다고 비싼 외산 솔루션까지 구입해서 진행하는 것은 금전적인 낭비라고 생각이 듭니다만 이런 툴을 이용하게 되면 소스가 한결 간결하게 되고 그리고 사용되는 리소스를 줄일수도 있습니다. 변수만 선언해놓고 사용하지 않는다면 해당 변수에 할다된 메모리가 가베지로 남게되는 상황이 발생합니다. 정적분석툴은 그런것들을 잡아주고 또한 오류가 발생할 법한 로직에 대해서 교정을 요청하게 됩니다.
사람이 눈으로 하나하나 코드리뷰를 하는것이 물론 제일 완벽하긴 하지만 그러기가 쉽지 않다라는것은 아마 모두들 공감하실것입니다.
이렇게 올려놓은 자료 좋게 봐주셔서 감사드립니다. 즐거운 하루 되세요~
예 좋은 말씀 감사합니다. 사실 메모리같은 경우 스펙으로 밀기도하고 프레임웤 사용으로 인해 많이 등한시 되고 있네요. ^^ 저희 사이트만 그런건지 다른 사이트도 그런건지 잘 모르겠지만 항상 디비가 문제입니다요. ㅎㅎ oltp 처리를 하다보니... 이런건 사이트 특성에 좌지우지 되겠지요?
그렇지요 oltp에서 제일 비중을 많이 차지하는 성능이슈는 디비에서부터 나오기 때문에 디비가 중요합니다. 물론 사이트 특성에 좌지우지 되겠지만 기본적으로 프레임웍의 가이드라인을 잘 지켜진 상태에서 sql까지 튜닝이 잘 되어있다라면 좋은 성능을 뽑을수 있겠지요 물론 디비설계가 한몫합니다만 정규화가 꼭 정답은 아니고 성능을 위해서 일부테이블에 대해서 비정규화를 통한 성능향상을 올릴 수 있습니다.
결국 이러니 저러니 해도 중도가 중요한듯 싶네요 ㅎㅎ
분기문이 많은 것은 어려운 일입니다.
몇년전에 2000라인 정도를 리팩토링 한적이 있습니다.
60프로는 분기문, 30프로는 대입문으로 추상화 레벨 0에 가까운 코드였습니다.
이런 코드는 다시 짜는 것이 현명한 일인데,
(스펙을 따로 정리한 문서가 없을 경우)
비지니스 요구사항(스펙)이 그 분기문에 들어가 있다면
다시 짜는 것도 쉬운 일이 아닙니다.
정석대로 스펙을 차근차근 문서화 하는 방법을 권해드립니다.
역시나 좋은 말씀 감사합니다. 항상 kdj님이 올려주시는글 잘 보고 있습니다. 잘 이해는 못하지만...^^ 제가 댓글로 단 프로그램의 경우 너무 복잡해서 추상화를 포기했답니다... 극악의 로직을 자랑하고 있어서 새로 만드는것도 거의 불가능... 그리고 그만큼의 리스크를 감당할수 있는 사람이 없 다는게 큰 요인으로 작용했습니다.
오늘도 좋은 말씀 해주셔서 택시 안에서 추상화와 직관성의 사이에서 고민해봅니다. 어떻게 하는게 best practice일까?^^
@kdj님, @nhj12311님 두분의 댓글에 많은 고민을 하고 또한 공부를 하게 되네요~
극악의 로직을 자랑하는 프로그램을 수정하는데 있어서 그 리스크를 감당할 수 없다라면 더군다나 운영환경이라면 저같으면 그대로 둘듯 합니다.
리팩토링 하는 것보다 해당 로직이 수정되어서 발생될 수 있는 오류가 더 치명적이라면 어찌할 수 없을것 같은데요
다만 전체 개선이 아닌 일부일부 개선 및 파악을 위해서라도 kdj님께서 말씀해 주신것처럼 문서화는 최선의 선택이 아닌 필수로 꼭 진행되어야 할 듯 합니다.
오늘도 좋은하루 되세요~
Good post.i resteem it.hope it will be a hot post today.best of luck.
thank you~
your post is very good I really like it
you are lucky in this steemit, and I hope you also support me in this steemit thanks.
I'm new to this steemit community so I still have a lot to learn with all of you who already know a lot and have experience in steemit, I hope you can see my introduction post in steemit hope you like it.
thank you~
죄송합니다. 본 포스트에 사용한 일부 자료는 제가 직접 작성한 내용이 아닙니다.
좋은 자료를 빨리 공유하고 싶은 마음에 원작자의 동의없이 자료를 사용했습니다.
해당 포스트에 사용된 자료는 Steemit에 삭제요청을 한 상태입니다.
컨텐츠의 원작자와 제글을 관심있게 읽어주신 분들께 머리숙여 깊이 사과 드립니다.