Skip to main content

ลองเล่น SonarQube คลื่นโซนาร์ช่วยตรวจสอบคุณภาพของ code

SonarQube คือเครื่องมือช่วยตรวจสอบคุณภาพของ source code ช่วยหาข้อบกพร่องใน source code ไม่ว่าจะเป็น Bug ที่น่าจะเกิดขึ้น ช่องโหว่ทางด้านความปลอดภัยหรือกลิ่นไม่ดีใน source code ของเรา (Code Smell) และ ช่วยตรวจสอบเราเขียน code ทดสอบครอบคลุมหรือดีแล้วยังยัง (code coverage)


Code Smell ไม่ได้ใช้วัดว่า source code นี้สามารถทำงานได้ถูกต้อง มี bug หรือช่องโหว่หรือไม่ แต่ Code Smell ใช้วัดถึงคุณภาพของการออกแบบ เพื่อตรวจสอบว่า source code ที่เป็นอยู่ในปัจจุบันจะสามารถต่อเติม แก้ไขหรือทดสอบได้ง่ายหรือไม่

โดยหลักเกณฑ์ที่นำมาใช้วัดในส่วนของ Code Smell คือ ความซ้ำซ้อนของ code มี code แบบเดียวกันไปซ้ำกันในไฟล์ไหนบ้าง ตรวจสอบเงื่อนไขใน if ให้ ว่าเงื่อนไขตรงนี้มันมีโอกาสเป็นไปได้ไหม เพราะบางทีเงื่อนไขที่เราเขียนขึ้นมาเพื่อดักไว้ในบางครั้งมันแทบจะไม่มีโอกาสที่เวลามันทำงานแล้วเข้าเงื่อนไขในส่วนนั้น เป็นต้น สามารถไปอ่านรายละเอียดเพิ่มเติมได้ที่นี่ http://www.somkiat.cc/code-smell-internal-class/

นอกจาก SonarQube จะสามารถบอกถึงคุณภาพของ source code เราได้แล้ว ยังสามารถใช้ในการแจกแจงงานให้กับเพื่อนร่วมทีมช่วยกันแก้ได้อีกด้วย (มอบหมายให้ใครแก้ไข) แต่ที่่น่าจะฮาที่สุดถ้า source code ของเราผูกกับ version control ตัว SonarQube สามารถเข้าไปอ่านได้ด้วยว่าใครเป็นคน commit ในส่วนของ code ที่ไม่มีคุณภาพ และจะแสดงชื่อประจานออกมาด้วย
และนั่นคือภาพรวมโดยคร่าวๆ ของ SonarQube ว่ามันคืออะไร มันทำอะไรได้บ้าง ถึงเวลาแล้วที่เราจะลองมาเล่น SonarQube กัน โดยในบทความนี้ เราจะเน้นไปยังการตั้งค่า Java Project ที่ใช้ Maven เป็นแกนหลัก สำหรับในภาษาอื่นหรือ build tool ตัวอื่นๆ สามารถอ่านรายละเอียดเพิ่มเติมได้ที่เว็บ SonarQube
ติดตั้ง SonarQube
  • ดาวโหลด SonarQube ได้ที่ https://www.sonarqube.org/downloads/
  • แตกไฟล์ zip ไปวางไว้ที่ c:\sonarqube สำหรับระบบ Windows หรือ /etc/sonarqube สำหรับระบบ Unix
  • Start ระบบ SonarQube ผ่าน command line
    # สำหรับบนระบบ Windows
    C:\sonarqube\bin\windows-x86-xx\StartSonar.bat
     
    # สำหรับบนระบบอื่นๆ
    /etc/sonarqube/bin/[OS]/sonar.sh console
    
  • รอ start เสร็จก็ใช้ได้แล้ว เราสามารถเข้าไปลองใช้บน web browser ผ่าน url http://localhost:9000 โดยบัญชีของผู้ดูแลระบบจะถูกตั้งค่าเริ่มต้นเป็น admin/admin ซึ่งเราสามารถไปเปลี่ยนได้ภายหลัง

ตั้งค่าฐานข้อมูล

ตัว SonarQube จำเป็นต้องใช้ฐานข้อมูลเพื่อใช้บันทึกบัญชีผู้ใช้ หรือข้อมูลต่างๆ ของ project บนระบบ SonarQube โดยปกติถ้าเราไม่มีการตั้งค่าฐานข้อมูล ตัว SonarQube จะใช้ฐานข้อมูลบนหน่วยความจำ (in-memory database: IMDB) ซึ่งไม่เหมาะกับการนำไปใช้งานจริง เพราะการจัดการฐานข้อมูลเป็นไปได้ยากเมื่อต้องการย้ายหรืออัปเดตเวอร์ชัน ดังนั้นถ้าเราจะใช้งาน SonarQube อย่างจริงจังควรตั้งค่าฐานข้อมูลไว้ แต่ถ้าลองเล่นเพื่อจะเรียนรู้ว่า SonarQube สามารถทำอะไรได้บ้างก็สามารถข้ามขั้นตอนนี้ไปได้

แต่ใช่ว่า SonarQube จะรองรับฐานข้อมูลได้ทุกตัว รองรับแค่ 4 ตัวเท่านั้น (https://docs.sonarqube.org/display/SONAR/Installing+the+Server)
  • Microsoft SQL Server
  • MySQL
  • Oracle
  • PostgreSQL
การที่จะให้ SonarQube เชื่อมต่อฐานข้อมูล เราต้องไปตั้งค่า properties ในไฟล์ sonar.properties ซึ่งไฟล์นี้จะตั้งอยู่ที่ %sonarqube_home%\conf\sonar.properties
sonar.jdbc.url=%jdbc_url%
sonar.jdbc.username=%database_username%
sonar.jdbc.password=%database_password%
ค่า properties
  • sonar.jdbc.url: เป็นการตั้งค่า jdbc url ตามแต่ละฐานข้อมูลที่เราจะเลือกใช้ ซึ่งเป็นรูปเหมือน jdbc url ทั่วไป 
  • sonar.jdbc.username: ชื่อบัญชีสำหรับเชื่อมต่อฐานข้อมูล 
  • sonar.jdbc.password: รหัสผ่านสำหรับเชื่อมต่อฐานข้อมูล
ตั้งค่าใน Build Tool  (Maven)

หลังจากเราตั้งค่า server และฐานข้อมูลใน SonarQube แล้ว เรายังเหลืออีกสิ่งหนึ่งที่ต้องทำ ทำยังไงให้ project ที่เราต้องการไปอยู่บนระบบของ SonarQube เพื่อตรวจเช็คคุณภาพของ source code

ซึ่งขั้นตอนนี้เราจะกระทำผ่าน Build Tool เช่น Maven, Gradle, Ant สำหรับในภาษาที่รองรับ Java Virtual Machine หรือ MSBuild สำหรับ .NET และ sonaqube-scanner สำหรับในการรองรับภาษาอื่นๆ นอกเหนือจากนี้

ในบทความนี้เราจะกล่าวถึงแค่ในส่วนของ Maven เท่านั้น ส่วนการตั้งค่าอื่นสามารถไปหาอ่านได้ที่นี่ https://docs.sonarqube.org/display/SCAN/Analyzing+Source+Code

ข้อกำหนดขั้นต่ำในการใช้ SonarQube ผ่าน Maven
  • ต้องเป็น Maven 3.x ขึ้นไป
  • รองรับ Java ขั้นต่ำสุดตามที่ SonarQube รองรับ ซึ่งSonarQube ใช้ Java 8 ตัวล่าสุดเป็นค่าปกติ ดังนั้น Java ที่นำไปใช้กับ Maven ต้องเป็น Java 8 เป็นขั้นต่ำ
  • ติดตั้ง plugin สำหรับภาษาที่เราต้องการตรวจสอบ
การตั้งค่าใน Maven

เราต้องเพิ่ม goal profile สำหรับการตรวจสอบ code จาก SonarQube นอกเหนือจาก goal profile ทั่วไปที่ใช้กันใน Maven อย่าง clean, verify, install, test... สำหรับการเพิ่ม goal profile เราต้องแก้ไขในการตั้งค่าส่วนกลาง (golbal config) ของ Maven

เราต้องเข้าไปแก้ไขในไฟล์ setting.xml ซึ่ง file นี้จะตั้งอยู่ที่ $MAVEN_HOME/conf/setting.xml หรือ ~/.m2
<settings>
...
  <plugingroups>
    <plugingroup>org.sonarsource.scanner.maven</plugingroup>
  </plugingroups>
...
</settings>
add pluginGroups ของ SonarQube (org.sonarsource.scanner.maven) ลงไป
จากนั้นก็เพิ่ม goal profile sonar สำหรับการตรวจสอบ code และตั้งค่า host url ของ SonarQube เข้าไป (sonar.host.url)

วิธีการตรวจสอบ Maven Project

วิธีการตรวจสอบ code ทำได้ผ่าน Maven โดยใช้ goal sonar:sonar ในโฟลเดอร์ที่มีไฟล์ pom.xml
mvn clean verify sonar:sonar
แต่ในบางครั้งเราอาจจะรันแยกขั้นตอนออกจากกันก็ได้ อย่างเช่นการ build project ก่อนที่จะตรวจสอบ code
mvn clean install
mvn sonar:sonar
ตัวอย่างการ build SonarQube ผ่าน Maven ด้านบน สามารถใช้กับ SonarQube ที่ไม่มีการตั้งค่าบังคับให้ยืนยันตัวตน Force user authentication ซึ่งการตั้งค่านี้จะอยู่ในหน้า Administation -> Configuration -> Security -> Force user authentication (http://localhost:9000/settings?category=security)

ถ้าหากเป็นเช่นนี้ เวลา build SonarQube ต้องส่ง user token (-Dsonar.login) ที่มีสิทธิการตรวจสอบ source code เข้าไปด้วย
mvn sonar:sonar -Dsonar.login=a3ee698ec0b70ed4dc23494f3ff8db88s57de82ca0d43
ส่วน user token สามารถสร้างได้ที่หน้าการตั้งค่าของ Users (http://localhost:9000/users)
ถ้าหากการ build SonarQube ของเราไม่มีปัญหา Project ที่เรา build ผ่านจะไปปรากฎอยู่ในหน้าเว็บของ SonarQube สามารถเข้าไปดูได้ผ่าน http://localhost:9000/projects


ในหน้านี้จะบอกรายละเอียดคร่าวๆ ของ Project หลักจากที่ถูกตรวจสอบจาก SonarQube อย่าง Project ตัวอย่างชื่อ JavaABC นั้นมีผลประเมินดังนี้
  • Reliability: ความน่าเชื่อถือของ code สูงสุดคือ A ต่ำสุดคือ E ซึ่ง project นี้ได้ต่ำสุดคือ E T-T
  • Security: ความปลอดภัยของ code ปลอดภัยสูงสุดคือ A ปลอดภัยต่ำสุดคือ E 
  • Maintainability: ความสามารถในการแก้ไขหรือต่อเติมในอนาคต A คือต่อเติมแก้ไขง่ายสุด ส่วน E แก้ไขต่อเติมได้ยากสุด
  • Coverage: ความครอบคลุมในการทดสอบของ project โดยคิดจาก unit test ว่าเขียนทดสอบครอบคลุมแค่ไหน โดย SonarQube จะแสดงเป็น % ว่าครอบคลุมแค่ไหน สูงสุด 100% ต่ำสุด 0%
  • Duplicate: จำนวน code ที่มีซ้ำกันใน project แสดงเป็น % จาก source code ทั้งหมดว่าซ้ำกันกี่เปอร์เซ็นต์
  • Project Size: ขนาดของ project วัดจากจำนวน lines of code (จำนวนบรรทัดใน project) 

ในส่วนของ Code Coverage นั้นไม่ได้มีในทุกภาษา อย่างในส่วนของ .NET ทาง SonarQube ยังไม่รองรับ นอกจากนี้ต้องมีการตั้งค่า Code Coverage ในตัว Maven ด้วย ไม่งั้น SonarQube จะไม่สามารถอ่านข้อมูลเกี่ยวกับ Code Coverage ได้

เมื่อกดเข้าไปใน project จะมีรายละเอียดจากการตรวจสอบมากขึ้น อย่างเช่นใน project ของเราที่ได้รับการประเมิน Reliability ไว้ที่ระดับ E เป็นเพราะอะไร ที่เป็นเช่นนี้เพราะใน project นี้มี Bug อยู่ 2 ตัว

เมื่อกดเข้าไปตรง bug จะเห็นรายละเอียดของ Bug ว่าอยู่ตรงส่วนไหนของ class

อย่าง bug ที่ SonarQube มองเห็น เป็น bug ที่เราไม่ได้มีการเขียน try catch ดักเวลาเรียกใช้ I/O ใน source code ทำให้มี source code ในส่วนนี้มีโอกาสเกิด Exception ได้ มันจึงมองเป็น bug

สรุป

SonarQube เป็นเครื่องมือที่ช่วยให้เราค้นหาข้อบกพร่องใน code ของเราว่ามีส่วนไหนที่ไม่ได้ตามมาตรฐาน และถือเป็นเครื่องมือที่นำมาวัดความสมบรูณ์ของ source code ได้ในระดับนึง สามารถเอามาใช้ประกอบรายงานสำหรับการประเมินผลได้ แถมยังสามารถทำงานร่วมกับ Automated Test อย่าง Jenkins ได้อีกด้วย

แต่ในบางครั้งเราไม่มีความจำเป็นต้องทำตามทั้งหมด ยกตัวอย่างเช่น เรื่อง Code Coverage เพราะในบางครั้งในส่วนของ Getter หรือ Setter บางทีเราก็ละทิ้งไว้ไม่จำเป็นต้องทดสอบ แต่ถ้าหากเราละไว้ก็จะทำให้เปอร์เซ็นต์ของ Code Coverage มันไม่ถึง 100% ของทั้ง project ทำให้ตัวเลขในรายงานออกมาไม่สวย

Comments

Popular posts from this blog

ลองเล่นและเรียนรู้พื้นฐานขั้นต้นของ Spring Framework

** สำหรับใครที่ไม่เคยเรียนรู้ในด้านของ Java EE หรือ J2EE อาจจะมึนงงกับศัพท์หน่อยครับ ทำไมต้อง Spring Spring เป็น framework ที่นิยมมากในการนำไปสร้างระบบในระดับ enterprise ในเริ่มแรกที่ Spring เกิดมา มีจุดมุ่งหมายเพื่อที่จะมาแทนที่มาตรฐานของ Java อย่าง J2EE (Java 2 Enterprise Edition) ที่มันทั้งหน่วงทั้งอืดและยุ่งยาก โดยเฉพาะในส่วนของ EJB (Enterprise Java Bean) ที่ถือว่าเป็นฝันร้ายของนักพัฒนา ทำให้กูรูสาย Java ในช่วงนั้นถึงกับแนะนำว่า ถ้าจำเป็นที่ต้องพัฒนาระบบด้วย J2EE จงอย่าใช้ EJB ถึงขั้นถึงกับมีหนังสือแนะแนวทางการพัฒนาระบบ J2EE โดยไม่ใช้ EJB อย่างไรก็ตามทาง Sun ผู้เป็นเจ้าของ Java ในสมัยนั้น ถึงกับต้องมาล้างระบบ J2EE ใหม่ในปี 2006 จัดการใน EJB ให้ใช้ง่ายขึ้น มีประสิทธิภาพมากขึ้น และมีการเปลี่ยนชื่อจาก J2EE เป็น Java EE (Java Enterprise Edition) เพื่อลบภาพอันเลวร้ายของเดิมให้หมด และได้มีการนำฟีเจอร์เด็ดๆ ของ open source framework หลายๆ ตัว อย่างเช่นแกนหลักของ Spring อย่าง IoC (Inversion of Control) หรือ OR Mapping (Object Relational Mapping) ที่เป็นที่นิยมอย่าง Hibernate แต่ก็ไ...

Inversion of Control และ Dependency Injection

Inversion of Control (IoC) คืออะไร IoC เป็นทฤษฏีที่ว่าด้วย การลดความผูกมัด (dependency) กันในระหว่าง module เพื่อให้ application ของเราแก้ไข (maintain) ต่อเติม (extensible) หรือทดสอบ (test) ได้ง่ายขึ้น ซึ่งเอาจริงๆ IoC เป็นอะไรที่ทำให้เราสับสนและงุนงงมากๆ ว่ามันคืออะไร หลายๆ คนจึงยกให้ว่า IoC คือ Dependency Injection (DI) ซึ่งจริงๆ มันก็ไม่ถูกซะทีเดียว  Dependency คืออะไร Dependency คือการผูกมัดที่เกิดขึ้นในระบบ เมื่อ module นึงมีการเรียกใช้อีก module นึงด้วยการอ้างอิง (reference) ตรงๆ แล้วอะไรที่เรียกว่าการ อ้างอิง (Reference) แบบตรงๆ   อย่างภาพ diagram ด้านบน class LogEngine มีการเรียกใช้ ConsoleLog โดยตรง ซึ่งมองผ่าน diagram อาจจะไม่เห็นภาพลองดู code กัน public class ConsoleLog { public void openLog(){ //do something to open log } public void log(String message){ //do something to log } public void closeLog(){ //do something to close log } } public class LogEngine { private ConsoleLog log; public LogEng...