You are viewing a single comment's thread from:
RE: SonarQube를 이용한 정적분석 및 소스코드 품질검증 방법 (#2-Use Guide)
품질이 중요한건 알지만 항상 뒷전이 되네요...
제작년인가...몇가지 유료 소스분석 솔루션을 검토했었는데 실무자 입장에서 저게 있어도 결국 소스를 다 봐야하기에 쓸모 없다고 판단했거든요. 비지니스가 워낙 분기가 많아서 툴로 보니 마치 미로 같더군요.
그래도 궁금하긴 합니다 ^^ tip!
tip 매우 감사합니다. 처음받아 보네요~ 기분이 좋습니다. 역시 팁을 받으면 기분좋은것은 모든 사람들의 공통점인가 봅니다.
정적분석은 중요합니다. 그렇다고 비싼 외산 솔루션까지 구입해서 진행하는 것은 금전적인 낭비라고 생각이 듭니다만 이런 툴을 이용하게 되면 소스가 한결 간결하게 되고 그리고 사용되는 리소스를 줄일수도 있습니다. 변수만 선언해놓고 사용하지 않는다면 해당 변수에 할다된 메모리가 가베지로 남게되는 상황이 발생합니다. 정적분석툴은 그런것들을 잡아주고 또한 오류가 발생할 법한 로직에 대해서 교정을 요청하게 됩니다.
사람이 눈으로 하나하나 코드리뷰를 하는것이 물론 제일 완벽하긴 하지만 그러기가 쉽지 않다라는것은 아마 모두들 공감하실것입니다.
이렇게 올려놓은 자료 좋게 봐주셔서 감사드립니다. 즐거운 하루 되세요~
예 좋은 말씀 감사합니다. 사실 메모리같은 경우 스펙으로 밀기도하고 프레임웤 사용으로 인해 많이 등한시 되고 있네요. ^^ 저희 사이트만 그런건지 다른 사이트도 그런건지 잘 모르겠지만 항상 디비가 문제입니다요. ㅎㅎ oltp 처리를 하다보니... 이런건 사이트 특성에 좌지우지 되겠지요?
그렇지요 oltp에서 제일 비중을 많이 차지하는 성능이슈는 디비에서부터 나오기 때문에 디비가 중요합니다. 물론 사이트 특성에 좌지우지 되겠지만 기본적으로 프레임웍의 가이드라인을 잘 지켜진 상태에서 sql까지 튜닝이 잘 되어있다라면 좋은 성능을 뽑을수 있겠지요 물론 디비설계가 한몫합니다만 정규화가 꼭 정답은 아니고 성능을 위해서 일부테이블에 대해서 비정규화를 통한 성능향상을 올릴 수 있습니다.
결국 이러니 저러니 해도 중도가 중요한듯 싶네요 ㅎㅎ
분기문이 많은 것은 어려운 일입니다.
몇년전에 2000라인 정도를 리팩토링 한적이 있습니다.
60프로는 분기문, 30프로는 대입문으로 추상화 레벨 0에 가까운 코드였습니다.
이런 코드는 다시 짜는 것이 현명한 일인데,
(스펙을 따로 정리한 문서가 없을 경우)
비지니스 요구사항(스펙)이 그 분기문에 들어가 있다면
다시 짜는 것도 쉬운 일이 아닙니다.
정석대로 스펙을 차근차근 문서화 하는 방법을 권해드립니다.
역시나 좋은 말씀 감사합니다. 항상 kdj님이 올려주시는글 잘 보고 있습니다. 잘 이해는 못하지만...^^ 제가 댓글로 단 프로그램의 경우 너무 복잡해서 추상화를 포기했답니다... 극악의 로직을 자랑하고 있어서 새로 만드는것도 거의 불가능... 그리고 그만큼의 리스크를 감당할수 있는 사람이 없 다는게 큰 요인으로 작용했습니다.
오늘도 좋은 말씀 해주셔서 택시 안에서 추상화와 직관성의 사이에서 고민해봅니다. 어떻게 하는게 best practice일까?^^
@kdj님, @nhj12311님 두분의 댓글에 많은 고민을 하고 또한 공부를 하게 되네요~
극악의 로직을 자랑하는 프로그램을 수정하는데 있어서 그 리스크를 감당할 수 없다라면 더군다나 운영환경이라면 저같으면 그대로 둘듯 합니다.
리팩토링 하는 것보다 해당 로직이 수정되어서 발생될 수 있는 오류가 더 치명적이라면 어찌할 수 없을것 같은데요
다만 전체 개선이 아닌 일부일부 개선 및 파악을 위해서라도 kdj님께서 말씀해 주신것처럼 문서화는 최선의 선택이 아닌 필수로 꼭 진행되어야 할 듯 합니다.
오늘도 좋은하루 되세요~