มาใช้ SonarLint ตรวจสอบ Code ของเรากันเถอะ

ปัญหาเรื่องการเขียน Code

ในการเขียน Code นั้นทุกคนคาดหวัง Code ที่ดี ซึ่ง Code ที่ดีนั้นประกอบไปด้วยหลายอย่าง ไม่ว่าจะเป็นการอ่านง่าย แก้ไขง่าย ไม่เปิดช่องโหว่เรื่องความปลอดภัย ไม่มี Bug ซึ่งการที่จะเขียน Code ที่ดีได้นั้นคนที่เขียนจะต้องมีประสบการณ์ ต้องรู้ว่าทำไมเขียนแบบนี้ดี เขียนแบบนี้ไม่ดี ซึ่งประสบการณ์ส่วนใหญ่เนี่ยมักจะได้มาจากการเกิดปัญหา หรือถ้าคุณโชคดีหน่อยคุณอาจจะมีคนมาทำ Code Review ให้ แล้วบอกคุณว่า Code นี้ดี Code นี้ไม่ดี ซึ่งคนมา Review นั้นก็คือเหล่าผู้มีประสบการณ์ซึ่งนั่นก็คือเหล่า Senior Developer

แต่คำถามคือ Senior Developer จะรู้เหรอว่า Code ที่ดีและไม่ดีทั้งหมดมีอะไรบ้าง ถ้าตอบตามความจริงเลยคือไม่มีใครรู้หรอกครับ ทุกคนรู้กันอย่างละนิดละหน่อยจากงานที่ตัวเองเจอ อีกทั้งในชีวิตจริงไม่มีใครมานั่งทำ Code Review ทุกส่วนหรอกครับ (วงการ Open Source อาจมี แต่ระดับบริษัทเล็กๆที่งานยุ่งกันจะตายไม่มีใครมานั่ง Code Review กันทุกส่วนหรอกครับ ) แล้วถ้ามองให้แรงกว่านี้หน่อย การ Review อะไรซ้ำๆ เห็นอะไรที่ผิดซ้ำๆ แล้วต้องมานั่งบอกซ้ำๆ หลายๆรอบ คุณไม่คิดว่ามันเสียเวลาแบบเปล่าประโยชน์เหรอกับการทำอะไรซ้ำๆ อีกทั้งมันยังต้องเสียเวลารอกันไปมาระหว่างคนเขียนกับคน Review อีก

แล้วเราจะแก้ปัญหานี้ยังไง

ปัญหาของเราคือ

1. เราไม่สามารถให้คนมาทำ Code Review ตรวจสอบ Code ของเราได้ตลอดเวลา ซึ่งต่อให้ทำได้ก็เสียเวลา

2. คนทำ Code Review ไม่รู้ทั้งหมดหรอกว่า Code ที่ดีไม่ดีทั้งหมดมีอะไรบ้าง

จากปัญหาที่ว่าถ้าเราสร้าง Software ตัวหนึ่งขึ้นมา ซึ่ง Software ตัวนี้สามารถกำหนดรูปแบบของ Code ที่ไม่ดีว่ามีหน้าตาอย่างไร และ Software ตัวนี้สามารถอ่าน Code ของคุณแล้วหาว่า Code ของคุณมีตรงไหนบ้างที่ตรงกับรูปแบบของ Code ที่ไม่ดี

เพียงเท่านี้คุณก็สามารถสั่งให้ Software ตัวนี้ทำงานได้ตลอดโดยคุณไม่ต้องเสียเวลารอพวก Senior Developer มา Review คุณจะทำตอนไหนก็ได้ ทำกี่ครั้งก็ได้ อีกทั้งรูปแบบของ Code ที่ไม่ดีสามารถเพิ่มได้เรื่อยๆ ดังนั้นถ้าเรามี Community ที่ใหญ่พอมาช่วยกันใส่รูปแบบของ Code ที่ไม่ดีเรื่อยๆตามการเจอนั่นก็เท่ากับว่าเราก็แทบจะรู้รูปแบบของ Code ที่ไม่ดีทั้งหมด

Software ที่ว่านี้มีอยู่บนโลกแล้วคุณไม่ต้องสร้างเองก็ได้

คุณอ่านไม่ผิดครับ Software นั้นมีอยู่แล้วมันคือ static code analyser ซึ่งมีมากมายหลายยี่ห้อตามภาพเลย ซึ่งคุณสามารถไปเลือกใช้ได้เลยตามใจ แต่วันนี้ที่จะมาแนะนำให้ใช้กันคือ SonarLint ครับ

ทำไมถึงเลือกใช้ SonarLint

1. ฟรี

   SonarLint มันฟรีครับ ใช้ได้โดยไม่เสียเงินสักบาท

2. รองรับหลายภาษา

   ตัว SonarLint ลงทีเดียวใช้ได้กับหลายภาษาเลย ดังนั้นไม่ต้องปวดหัวเวลาต้องเขียนหลายภาษาแล้วต้องไปไล่ลง software หลายๆตัว

3. สามารถใช้ได้กับ IDE ยอดนิยมได้หลายตัว

   ตัว SonarLint สามารถใช้งานร่วมกับตัว IDE ที่เป็นที่นิยมได้หลายตัว ซึ่งจะมาในรูปแบบ Plugin ดังน้ันการใช้งานจึงง่ายเหมือนสั่งให้ Plugin ของ IDE ทำงาน

4. สามารถทำงานได้โดยไม่ต้องต่อ Server

   เนื่องจาก Static code analyser บางตัวนั้นเราต้องส่ง Code ไปทำการตรวจสอบบน Server ซึ่งแปลว่าเราต้องทำการลง Software ที่เป็น Server ซึ่งนั่นตามด้วยต้องหาเครื่อง Server ลงโปรแกรม จัดการ Network และอีกมากมายก่อนถึงจะสามารถทำการตรวจสอบ Code ได้ แต่ SonarLint สามารถ Install ที่เครื่องตัวเองแล้วใช้งานได้เลย

วิธีการ Install

ตอนนี้ผมจะแนะนำ SonarLint บน IDE สองตัวคือ Intellij และ Visual Studio Code

Intellij

ทำตามลำดับดังภาพจากนั้นทำการกดปิด Intellij แล้วเปิดใหม่ เพียงเท่านี้คุณก็สามารถใช้งาน SonarLint บน Intelij ได้แล้ว

Visual Studio Code

ทำตามลำดับดังภาพจากนั้นทำการกดปิด Visual Studio Code แล้วเปิดใหม่ เพียงเท่านี้คุณก็สามารถใช้งาน SonarLint บน Visual Studio Code ได้แล้ว

ใช้ Sonarlint ตรวจสอบ Code

ในส่วนนี้จะเป็นการแสดงวิธีการใช้งาน SonarLint ทำการตรวจสอบ Code โดยจะแสดงให้ดูใน Intellij และ Visual Studio Code

ใช้ Sonarlint ตรวจสอบ Code บน Intellij

สมมติผมเขียน Code Java ประมาณนี้

public class TestSonarlint {

    public byte[] readFileToByteArray(String path) {

        try {
            FileInputStream fileInputStream = new FileInputStream(path);
            return fileInputStream.readAllBytes();
        } catch (IOException e) {
            return null;
        }
    }

}

หากคุณเคยเขียน Java มาระดับหนึ่งคุณจะรู้เลยว่า Code ส่วนนี้มีส่วนไม่ดีตรงไหน แต่หากคุณไม่เคยเขียน Java คุณจะบอกว่าก็ไม่มีอะไรผิดนี่ คราวนี้เรามาลองใช้ SonarLint ตรวจสอบ Code ตามภาพ

1. คลิกขวาเลือกไฟล์หรือ folder ที่ต้องการตรวจสอบ
2. ทำการเลือก SonarLint และ Analyze With SonarLint

ซึ่งเมื่อ Scan เสร็จจะได้ผลลัพธ์ดังภาพ ซึ่งจากภาพจะเห็นว่าตัว SonarLint ได้แสดงผลลัพธ์การตรวจสอบ Code ให้กับเรา โดยเขาบอกว่า Resource ของเราไม่ได้ปิด พร้อมมีตัวอย่าง Code ที่มีลักษณะตรงตาม Pattern (จากภาพคือเหมือนกันคือเปิดใช้งาน Resource แล้วไม่ปิด)

และ SonarLint เขาไม่ได้แค่บอกว่า Code เรามีปัญหาอะไร เขาบอกแนวทางการแก้ไขปัญหาด้วย (ซึ่ง Code มีปัญหาเพราะไม่ได้ทำการปิด Resource ซึ่งอาจทำให้เกิดปัญหาคนมาใช้งาน Resource ต่อไม่ได้ หรือ อาการบางอาการที่เกี่ยวข้องกับการใช้งาน Resource พร้อมกัน)

ซึ่งผมสามารถแก้ไข code ของผมได้ประมาณนี้

public class TestSonarlint {

    public byte[] readFileToByteArray(String path) {

        try (FileInputStream fileInputStream = new FileInputStream(path)) {
            return fileInputStream.readAllBytes();
        } catch (IOException e) {
            return null;
        }
    }

}

ซึ่งจะเห็นว่าส่วนที่แจ้งเตือนว่า Code เกี่ยวกับการปิด Resource ได้หายไปแล้ว (จริงๆยังเหลืออีกข้อที่ผมน่าจะตามไปแก้ ซึ่งเขาก็บอกแล้วว่าให้ return empty byte array แทนการ Return null)

ใช้ Sonarlint ตรวจสอบ Code บน Visual Studio Code

สมมติผมเขียน Code javascript ประมาณนี้

function findEpisode(data ) {
  var splitText = data.split(":");
  return parseInt(splitText[1]); 
}

console.log(findEpisode("doctorwho:01"))
console.log(findEpisode("doctorwho:02"))
}

ซึ่งบอกเลยว่าผมมั่นใจมากว่า Code ตรงนี้ไม่น่ามีปัญหาตรงไหน (ผมเคยเขียน javascript ตั้งแต่ปี 2012 แต่หยุดไปช่วงปี 2016) แต่ในเมื่อผมเอามาเป็นตัวอย่างแน่นอนว่ามันมีปัญหาครับ โดยเราสามารถดูว่า Code มีปัญหาอะไรได้โดยทำตามดังภาพ

1. ทำการเอาเมาส์ไปชี้ตรงจุดที่ code มีปัญหาโดยดูได้จากการมีเส้นสีเหลืองอยู่ข้างใต้
2. จากนั้นจะมี pop up ขึ้นมาให้เลือกที่ Quick fix
3. ในส่วนนี้คุณสามารถกดเลือก Quick fix ได้เลยเพื่อให้ Visual Studio Code ทำการแก้ code ให้ แต่ในที่นี้เราจะเลือก Opendesctiption เพื่อดูว่าทำไมมันถึงเป็น Code ที่มีปัญหา (Code ผมมีปัญหาเพราะประกาศด้วย var ซึ่งมันสามารถ access ได้ในระดับ function scope นั่นแปลว่า แม้อยู่ในคนละ scope ก็สามารถ access ค่าที่ประกาศด้วย var ได้ขอแค่อยู่ใน function เดียวกัน )

ในส่วนนี้จะเห็นว่าหน้าตาคล้ายๆกับในตัว Intellij ซึ่งไม่ต้องแปลกใจครับ เปิดใน IDE ไหนก็จะคล้ายๆกันหมดเพราะ sonarlint เขามี Rule ( Pattern ของ Code ที่มีปัญหา ) เกี่ยวกับปัญหาไว้ IDE ก็แค่ไปเอา Rule นั้นไปตรวจสอบและแสดงสาเหตุและวิธีการแก้ คุณสามารถไปดู Rule ทั้งหมดได้ที่ https://rules.sonarsource.com/

ซึ่งจากการอ่านผมเลือกที่จะแก้ code เป็น

function findEpisode(data ) {
  let splitText = data.split(":");
  return parseInt(splitText[1]); 
}

console.log(findEpisode("doctorwho:01"))
console.log(findEpisode("doctorwho:02"))
}

เพียงเท่านี้เรา Code ของผมก็ไม่มีปัญหาแล้ว

เราได้อะไรจากการใช้ SonarLint ตรวจสอบ Code

1. ได้ Code ที่ดีตามมาตรฐานของ SonarLint

   เมื่อเราใช้ SonarLint ตรวจสอบ Code และแก้ไขตามที่ SonarLint บอก เราย่อมได้ Code ที่ดีตามมาตรฐาน Sonarlint ( อย่าลืมว่ามันอาจจะไม่ใช่ Code ที่ดีที่สุด เพราะกฏทั้งหมดมาจาก Community ของ SonarLint ไม่ได้รวมจากที่อื่น อีกทั้ง บางอย่างที่ Community ของ SonarLint บอกว่าไม่ดี แต่ที่อื่นอาจจะบอกว่าดีก็ได้ หรือที่ SonarLint บอกว่าดี ที่อื่นอาจจะบอกว่าไม่ดีก็ได้ )

2. ได้ความรู้เกี่ยวกับการเขียน Code ว่า Code ที่ไม่ดีเป็นยังไง

   จากการที่เราใช้ SonarLint ทำการตรวจสอบ Code เราจะเห็นว่าตัว SonarLint บอก Rule พร้อมบอกเหตุผลว่าทำไม Code ถึงมีปัญหา เช่น จากตัวอย่างของ Java เราจะรู้ว่าการไม่ปิด Resource นั้นจะทำให้เกิดปัญหา หรือ การประกาศ var ของ javascript นั้นอาจก่อให้เกิดปัญหาอะไร ซึ่งตรงนี้ถือเป็นจุดสำคัญจุดหนึ่งเพราะเราได้เรียนรู้ว่าปัญหาต่างๆเกิดจากอะไร เวลาเราเขียนอะไรที่ทำคล้ายๆกันเราจะรู้ว่ามันอาจก่อให้เกิดปัญหา เช่น เรารู้ว่าการประกาศ var นั้นทำให้เกิดปัญหาการ access ตัวแปรข้าม Scope ดังนั้น ถ้าเราเขียน Code ที่ใช้ตัวแปร Global นั่นก็แปลว่ามันอาจจะเกิดปัญหาได้เช่นกัน ซึ่งนั่นจะทำให้เราเกิดคำถามว่า เราจำเป็นต้องใช้ตัวแปร Global จริงๆหรือ อีกตัวอย่างหนึ่งคือเรารู้ว่าการใช้งาน Resource แล้วต้องจัดการให้เรียบร้อยไม่ว่าจะเกิดอะไรขึ้น ดังนั้นเมื่อเราเขียนโปรแกรมจองตั๋วเครื่องบิน (ซึ่งเป็นการใช้งาน Resource) เราจะเริ่มระวังว่า ถ้าจองตั๋วไม่สำเร็จเราจะจัดการ Resoruce ยังไง ถ้าโปรแกรมเกิดตายระหว่างกำลังจองตั๋วอยู่ สภาพของตั๋วจะเป็นยังไง
   ซึ่งสิ่งที่พูดมาทั้งหมดนั้น SonarLint บอกเราไม่ได้เลยเพราะมันไม่ได้อยู่ใน Rule ของ SonarLint แต่เรารู้ได้เพราะเรารู้ว่าปัญหาเกิดจากอะไร

Code Review ยังจำเป็นอยู่ไหม

บางคนอาจจะคิดว่าเราใช้ SonarLint แล้ว เราไม่จำเป็นต้องมี Code Review แต่จริงๆแล้ว Code Review ยังจำเป็นต้องทำอยู่ครับเพราะ

1. มันมี Code ที่ไม่ดีที่ไม่อยู่ใน Rule ของ SonarLint

2. Code ผ่าน SonarLint แต่ไม่ผ่านมาตรฐานของ Code base นั้น

   ข้อนี้เราต้องมาทำความเข้าก่อนว่าตอนที่เราเขียน Code นั้นเราอาจจะไม่ได้เขียนคนเดียว ถ้า Project ใหญ่มากอาจจะเขียนกันหลายคน ทีนี้ถ้าเราไม่ตั้งมาตรฐานการเขียน Code กันไว้ว่าจะมีหลักการการเขียนยังไง เช่น เราแบ่ง Layer Code ยังไง ถ้าจะเข้ารหัสลับข้อมูลต้องเรียกใช้ Method ไหน การตั้งชื่อตัวแปรจะเป็นแบบไหน ซึ่งการทำแบบนี้มีจุดประสงค์เพื่อให้สามารถกลับมาอ่าน Code ได้ง่าย เพราะถ้ามีมาตรฐานเราจะรู้ว่า Code ส่วน Logic ควรไปดูตรงไหน จะแก้เกี่ยวกับการเข้ารหัสลับต้องแก้ที่ไหน ตัวแปรชื่อแบบนี้หมายความว่าอะไร ซึ่งเรื่องพวกนี้ SonarLint ทำให้ไม่ได้

3. Code ไม่เป็นไปตาม Requirement ไม่ถูก Business Logic

   ข้อนี้ก็อยู่เหนือสิ่งที่ SonarLint ทำได้เพราะ SonarLint ไม่ได้รู้ Requirement ที่เราทำ คนที่รู้ก็คือคนแบบเราๆเนี่ยแหละที่รู้ว่า Requirement เป็นยังไง ตัวอย่างเช่น ตกลงกันว่าให้ดึงข้อมูลทีละเดือนมาทำการ Process แต่คนเขียน Code เขียนเอาง่ายดึงทั้งหมดมาทำทีเดียวเลย

นี่เป็นเหตุผลเบื้องต้นที่ยังต้องทำ Code Review จริงๆยังมีเหตุผลอีกมากมายที่ยังต้องทำ Code Review เช่น ต้องการให้คนคุยกันเพื่อสร้างความสัมพันธ์ระหว่างคนในทีม ต้องการให้คนแลกเปลี่ยนความรู้ระหว่างผู้พัฒนา เป็นต้น

แล้วเราจะใช้ SonarLint ไปทำไมในเมื่อก็ต้องทำ Code Review

ที่เราใช้ SonarLint เราทำเพื่อช่วยให้คนเขียน Code จัดการกับ Code ที่ไม่ดี ที่มี Rule อยู่บน SonarLint ซึ่งเมื่อจัดการหมดเนี่ย เราก็แทบจะเชื่อได้แล้วว่า Code เหล่านี้ไม่มีปัญหาที่พบได้ทั่วไป พอเวลาทำ Code Review เราจะได้ดูเฉพาะส่วนอื่นเช่น Requirement และ Business Logic ถูกต้องไหม Code ที่เขียนเป็นไปตามมาตรฐาน Code Base ไหม

ซึ่งตรงการทำ Code Review นี้ก็อยู่ที่แต่ละบริษัทจะเลือกเลยว่าจะทำไหม บางบริษัท Project นึงใช้คนเดียวเขียน ดังนั้นมันก็ไม่มีความจำเป็นที่จะต้องมาตรวจสอบ Requirement & Business Logic เพราะคนเขียนกับคนรับ Requirement มาเขียน Code เป็นคนเดียวกัน มันมีความจำเป็นอะไรต้องมาตรวจสอบ หรือ Requirement & Business Logic สามารถถูกตรวจสอบได้ตอน Test อยู่แล้ว ( แล้วจะทำไปทำไม เพื่ออะไร ) หรือ บาง Project นั้นใช้ Developer ที่เก่งอยู่แล้วรู้แล้วว่าอะไรดีอะไรไม่ดี มาตรฐาน Code Base เป็นยังไง ดังนั้นก็ไม่มีความจำเป็นอะไรที่จะต้องมานั่ง Review กันเอง (คำพูดเดิมครับ ทำไปทำไม ทำไปเพื่ออะไร)

สรุป

สำหรับบทความนี้เราได้เรียนรู้ปัญหาเรื่องการเขียน Code เราพยายามหาวิธีแก้ปัญหากันว่าจะแก้ยังไง และเราได้รู้ว่ามีคนเขียน Software ที่แก้ปัญหาเหล่านี้ไว้แล้วมากมาย ซึ่งในบทความนี้เราเลือกใช้ SonarLint มาเป็นตัวตรวจสอบ Code เราได้เรียนรู้วิธีใช้ SonarLint บน Intellij และ Visual Studio Code ว่าใช้งานยังไง และสุดท้ายเรา ได้เรียนรู้ข้อจำกัดของ SonarLint ว่ามันทำอะไรไม่ได้บ้าง สำหรับบทความนี้ก็ขอจบเพียงเท่านี้ครับ สวัสดีครับ