Node.js – Profiling เพื่อดูว่า Code เรากิน CPU รึเปล่า

สิ่งที่จะทำให้เรายกระดับการเป็น Developer ขึ้นไปอีก ก็คือเราต้องรู้ว่า Code ที่ตัวเองเขียนไปนั้น Perform ยังไงตรงตามที่คาดคิดไว้รึเปล่า รวมถึงมีไอเดียที่จะปรับปรุงให้มันทำงานได้ดียิ่งขึ้น

ซึ่งขั้นตอนที่ขาดไม่ได้สำหรับการวัดประสิทธิภาพของ Code ก็คือ สิ่งที่เรียกว่า Profiling

ซึ่งทาง Node.js Tools for Visual Studio ก็มีเครื่องมือนี้มาให้ด้วย ซึ่งปกติเครื่องมือช่วยการทำ Profiling เราก็เรียกง่ายๆว่า Profiler  (Features อื่นๆ อ่านเพิ่มเติมจาก link นะครับ)

ถ้าผมมี Code ตัวอย่าง JavaScript ประมาณนี้

console.log('Hello world');

for (let i = 0; i < 50; ++i){
    let rand = getRandomNum(10000000);
    print(rand, calSum(rand), findDivideBy5(rand));
}

function getRandomNum(max) {
    return Math.floor((Math.random() * max) + 1);
}

function calSum(num) {
    let sum = 0;
    for (let i = 0; i <= num; ++i) {
        sum += i;
    }
    return sum;
}

function findDivideBy5(num) {
    let n = 0;
    for (let i = 0; i <= num; ++i) {
        if (i % 5 == 0) {
            n++;
        }
    }
    return n;
}

function print(rand, sum, count5) {
    console.log("number : " + rand);
    console.log("Sum of 0 to " + rand + " is " + sum);
    console.log("Can divide by 5 count of 0 to " + rand + " is " + count5);
    console.log("----------------------");
}

 

Code นี้ทำอะไรบ้าง?

เป็นการสุ่มค่ามาค่านึง (N) แล้วก็
1. หาผลรวมของ 0 ถึง N – function calSum()
2. หาจำนวนของตัวเลขระหว่าง 0 ถึง N ที่หารด้วย 5 ลงตัว – function findDivideby5()
3. แสดงผล – function print()

คำถามคือ Code ตรงไหนช้าที่สุด…เรามาดูกัน

เราสามารถเริ่มการทำ Profiling จากเมนูนี้

menu

เมื่อ app ทำงานจบหรือเราหยุดการทำงานก่อน Visual Studio ก็จะทำการสร้าง Report มาให้เราอย่างละเอียด

fullreport

เรามาดู Hi-light ที่สำคัญกันครับ

  1. Code นี้ใช้พลัง CPU ไป ~20% ซึงเครื่องผมมี 4 Cores แล้วว่าทำงานไปเต็มๆ 1 Corecpu_usage
  2. มาดูระดับ Function กันครับ ปรากฎว่า app.calSum เป็นผู้ชนะไป (หมายความว่าแย่สุด เพราะใช้ CPU ไปเยอะที่สุด)function_usage
  3. นอกจากนี้ยังสามารถดู Call Tree เพื่อที่จะได้รู้ว่าแต่ละ Function ถูกเรียกมาได้ยังไง รวมถึงใช้ CPU ไปมากน้อยเท่าไหร่
    เช่น จากตัวอย่าง Top level (หรือ Global) นั้นได้ทำการเรียก function calSum() กับ app.fineDivideby5()call_tress

จากตัวอย่างนี้จะเป็นว่าการทำ Profiling นั้น ช่วยให้เราสามารถวิเคาะห์ปัญหาเกี่ยวกับการใช้งาน CPU ได้สะดวกยิ่งขึ้น แต่ทั้งนี้ทั้งนั้น นอกจากการใช้งาน CPU แล้ว สิ่งที่ควรจะทำการ Profile ก็ควรจะมีทั้ง Memory รวมถึง HTTP Resource หรือ Disk I/O ด้วย (แต่เหมือน Visual Studio ยังไม่ Support สำหรับ Node.js มั้งครับ ผมหาไม่เจอ 55)

Debug – แอบส่องค่าตัวแปรต่างๆด้วย Watch (และ Autos, Locals)

ถ้าต้องยกว่าอะไรคือหัวใจหลักของการ Debug ผมก็คงต้องยกให้ความสามารถที่เรา ดูค่าของตัวแปรหรือ Object ได้ในขณะที่โปรแกรมนั้นกำลังทำงานอยู่ เพราะมันช่วยให้เราสามารถเข้าใจปัญหาได้เร็วขึ้นมาก ว่าทำไมโปรแกรมถึงทำงานได้ไม่ตรงที่เราคาดหวังไว้

ความสามารถนี้ Debugger ยอดนิยมต่างๆมีให้เราครับ ผ่านหน้าต่าง Watch รวมทั้ง Autos และ Locals

มาลุยกันเลยครับ ผมมี Code แบบนี้ ซึ่งหลักๆก็คือ รับค่าจาก Keyboard จากนั้นก็จะแสดงผลบนหน้าจอว่า User พิมพ์อะไรเข้ามา มีความยาวกี่ตัวอักษร และเวลาเมื่อไหร่

using System;

namespace ConsoleApplication1
{
   class Program
   {
      static void Main(string[] args)
      {
         Console.WriteLine("Type some keys please");
         var ireader = new InputReader();
         ireader.Capture();
         Console.WriteLine("User Input : {0} | Length : {1} | at {2}", ireader.Data, ireader.Length, ireader.Time.ToShortTimeString());
      }
   }

   class InputReader
   {
      public string Data { get; set; }
      public int Length { get; set; }
      public DateTime Time { get; set; }
      public void Capture()
      {
         Data = Console.ReadLine();
         Length = Data.Length;
         Time = DateTime.Now;
      }
   }
}

ลองรันกันก่อนรอบนึงครับ ผลจะออกมาเป็นแบบนี้

run

ที่นี้เรามาตั้ง Break Point  ไว้ที่บรรทัดที่ 12 กันครับ ซึ่งจะหยุดหลังจากที่ User พิมพ์อะไรเข้ามาแล้ว Enter

run_1

หยุดแล้วครับหลังจากพิมพ์ว่า “Debuggerrrrrrrr!!!!@”

run_2

ที่นี้ถ้าเราอยากดูว่าตอนที่โปรแกรมมันทำงานจริงๆแล้วมันเก็บค่าอะไรอยู่

มาที่เมนูนี้เลยครับ Debug > Windows > Watch, Autos, Locals ทำการเปิดทั้ง 3 หน้าต่างนี้

watch_menu

โดยปกติแล้วหน้าต่างพวกนี้จะอยู่บริเวณนี้ครับ (ปรับได้ที่หลังตามสะดวก)

watch_windows.png

Watch

หน้าต่างนี้ถือเป็นไฮไลท์ของเรา เพราะเราสามารถพิมพ์ชื่อตัวแปรใส่ไปในช่อง Name ได้เลยครับแล้วมันจะทำการแสดงค่าออกมา
1. ลองใส่ ireader ดูเราก็จะเห็นค่าของ Object นี้ทั้งหมด รวมทั้ง Properties ด้วย

watch_win1

2. เท่านั้นยังไม่พอครับ เราสามารถใส่ expression ได้ครับ เช่น ireader.Length > 0 ซึ่งจากตัวอย่างมันก็ return ค่าเป็น true ให้เราครับ

watch_win2

Autos

สำหรับคนที่ขี้เกียจเพิ่มตัวแปรเอง ก็ใช้หน้าต่าง Autos ซึ่งจำทำการแสดงตัวแปรทั้งหมดใน Memory ของ Scope นั้นๆ จนกระทั่งมาถึง Code บรรทัดที่ทำการ Break ในเคสนี้ก็จะเห็นตัวแปรประมาณนี้

auto_win

Locals

คล้ายๆกับ Autos แต่จะแสดงเฉพาะตัวแปรที่มีกาประกาศหรือสร้างใน Scope เท่านั้น

เช่น args นั้นจะถูกประกาศตอนที่ Main() method ถูกเรียก
และ ireader นั้นถูกประกาศและสร้างจาก new InputReader();

locals_win

มาถึงตรงนี้ก็จะเห็นว่าเมื่อรวม Break Point, Steps (Into, Over, Out) และ Watch ก็ทำให้เราไล่ Code พร้อมทั้งดูตัวแปรต่างๆในขณะที่โปรแกรมทำงานได้ หวังว่าจะมีประโยชน์นะครับ

แต่…ความสามารถของ Debugger ยังไม่หมดเท่านั้นครับ

Edit and Continue

เรายังสามารถแก้ไขค่าในตัวแปรแล้วให้มันทำงานต่อได้ด้วยโดยการ double click ที่ Value ในช่องของหน้าต่าง Watch, Autos, Locals

watch_editing.png

แก้เป็น “hey dude anurocha!”

watch_editing2
ตัวแปรที่ถูกแก้ไขค่าจะเป็นสีแดง

ที่นี้ก็ลอง F5 เพื่อ Continue ดูครับจะเห็นว่ามัน Write ค่า ireader.Data เป็นค่าที่เราแก้ไข

watch_edit_run.png

ณ จุดๆนี้เป็นอันจบพื้นฐานการ Debug ที่จะช่วยให้ทุกท่านทำงานได้อย่างง่ายขึ้นนะครับ

*รูป Featured Image จาก The Lord of the Rings

Debug – 3 Steps(Into, Over, Out) วิถีแห่งนักไล่ Code

steps_title

ในการ Debug โปรแกรมนั้น การที่เราจะไล่ Workflow ว่ามันทำงานถูกต้องหรือไม่นั้น มีเครื่องมือที่ช่วยเหลือเราให้เราไล่ Code ได้ง่ายขึ้น สิ่งนี้คือ 3 Steps มหัศจรรย์

  • Step Over – จะสั่งให้ Code ทำงานในบรรทัดที่หยุดอยู่ และจะไปหยุดที่บรรทัดถัดไป
  • Step Into – จะเป็นการเข้าไปดูข้างใน Function/Method ของบรรทัดนั้นๆ ถ้า Code ของบรรทัดนั้นไม่ใช่ Function/Method ก็จะทำงานเหมือน Step Over
  • Step Out – เป็นการสั่งให้ Code ทำงานให้จบใน Function/Method นั้นๆ แล้วจะไปหยุดที่ Code ที่เรียก Function/Method นี้

ซึ่งเมนูหรือ Hot Key ก็ตามนี้เลยครับ

step_menu.png

มาดูตัวอย่างกันครับ

ผมมี Code ประมาณนี้ และผมทำการตั้ง Break Point ไว้ที่บรรทัดที่ 9

steps1.png

เมื่อเริ่ม Debug โปรแกรมก็จะหยุดที่ Break Point ที่ตั้งไว้ซึ่งแน่นอนว่า สีเหลืองหมายถึงว่าตอนนี้ Code กำลังทำงานอยู่ที่บรรทัดนี้แหละ

steps2.png

ถ้าเราอยากให้ Code มันทำงานบรรทัดที่ 9 ให้จบก็ลองกด Step Over ดูครับ ก็จะเห็นว่า ลูกศรสีเหลืองนั้นขยับมาที่บรรทัดที่ 10

steps3.png

ที่นี้ถ้าเราอยากรู้ว่าใน Method ที่ชื่อว่า StartLog() มันจะทำงานแบบไหนเราก็สามารถ Step Into เข้าไปได้เลยครับ จะเห็นว่า ลูกศรสีเหลืองขยับมาอยู่ใน Method นี้แล้วในบรรทัดที่ 17

steps4.png

ถ้าเราดูที่หน้าต่าง Call Stack จะเห็นว่าตอนนี้ Code นั้นกำลังทำงานอยู่บน Stack นี้แล้ว

steps5.png

ลอง Step Into อีกครั้งก็จะเข้าไปใน Method doLog() อีกหนึ่งชั้นในบรรทัดที่ 22
steps6

ที่นี้ลอง Step Out ออกมาเพื่อออกจาก Method doLog() ครับ จะเห็นว่า ลูกศรสีเหลืองกลับมาที่บรรทัดที่ 18 ซึ่งเป็น Code ที่เรียก doLog() และถ้าดูใน Console จะพอว่ามันมีการเขียน “hey log…” ไปแล้ว ซึ่งแสดงว่าโปรแกรมได้ทำงานในส่วนของบรรทัดที่ 23 ซึ่งเป็น Console.Write() ไปแล้ว

steps7.png

เพียงเท่านี้เราก็สามารถนั่งไล่ Code แบบลงรายละเอียดได้ทุกบรรทัดและทุก Function/Method แล้วครับ 🙂

และสุดท้ายมี Quote ดีๆอยากจะบอกทุกคนว่า

“Code never lies, comments sometimes do.”~R.Jeffries

Code ไม่เคยโกหก, แต่ Comments บางทีอาจจะ….

เราต้องเชื่อในสิ่งที่ Code เขียนไว้…

 

Debugging Series:

Debug – รู้ว่า code เรามาถึงจุดนี้ได้ยังไงกับ Call Stack

สำหรับ Computer Science แล้วคำว่า Stack นั้นหมายถึงโครงสร้างของข้อมูลชนิดหนึ่งที่มีลักษณะคือ

  • เก็บข้อมูลได้เป็นชั้นๆ (เหมือนกับการวางมันฝรั่งแผ่นซ้อนๆกันไปเรื่อยๆ)
  • การที่ข้อมูลเข้า Stack เรียกว่า Push และการเอาข้อมูลออกเรีนกว่า Pop
  • ข้อมูลที่เก็บไว้นั้นเป็นแบบที่หลังได้ออกก่อน (เช่น เวลาเราจะต่อชั้นของมันฝรั่งเราจะทับแผ่นบนสุดของก่อนหน้านั้น จากนั้นมันฝรั่งแผ่นบนสุดจะถูกเอาไปกินก่อนเสมอ)

ส่วน Call Stack นั้นคือ ลำดับการเรียกของ Function/Method ของ Code โดยที่เก็บข้อมูลในแบบ Stack

Call Stack นี้สำคัญมากในการวิเคราะห์หรือการไล่ workflow เพื่อทางการแก้ไขข้อผิดพลาดของโปรแกรม เพราะจะช่วยให้เราเห็นว่า Function หรือว่า Code จุดที่เราสนใจนั้นมีลำดับการเรียกมาได้ยังไงกัน

มาดูกันเลยดีกว่า

ผมมี Code ตัวอย่างหน้าตาแบบนี้ครับ

debug_callstack1.png

Code นี้ไม่มีอะไรมาก คือมี Class Logger เพื่อทำหน้าที่เขียนข้อความลงบน Console

คำถามคือเวลาโปรแกรมนี้ทำงานมีนั้น มันมีลำดับการทำงานยังไงบ้างจนกระทั่งมาถึงการเขียนหน้าจอลง Console ในบรรทัดที่ 24

ซึ่งนี่แหละครับ Call Stack จะช่วยเราได้
1. ผมทำการตั้ง Break Point ไว้หลังจากที่มันเขียนข้อความเสร็จนะครับ
2. ลอง Debug กันเลยครับ F5 จัดไป

จะทำให้ Code เราหยุดที่บรรทัดที่ 24 ตามที่คิดไว้ แต่ตอนนี้เราจะไม่รู้เลยว่า Code มาถึงจุดนี้ได้ยังไง

debug_callstack2.png

ไปที่ Debug เมนูข้างบน Windows > Call Stack

debug_callstack3.png

เราก็จะเป็นหน้าต่าง Call Stack พร้อมกับลำดับชื่อ Functions ที่มีการเรียกจากล่างขึ้นบน

debug_callstack4.png

จากตัวอย่างนี้ตำแหน่งปัจจุบันคือสีเหลืองซึ่งก็คือ Logger.doLog()
และเราจะรู้ลำดับการเรียกของ Code จาก Call Stack (ดูจากล่างขึ้นบน) คือ Program.Main() ซึ่งเป็น Entry Point หลัก -> Logger.StartLog() -> Logger.doLog()

นี่แหละครับขุมพลังของ Call Stack

แต่ช้าก่อนเรายังสามารถเลือกดู Code ใน function ต่างๆใน Stack ได้จากการ Double Click นะครับ
ซึ่งจะทำให้มีลูกศรเขียวๆขึ้นมา

debug_callstack5

และทำให้เราเห็น Code ของ จุดที่เรียก Function นั้นๆ ด้วยครับ

debug_callstack6

สุดท้ายเราก็รู้ว่า Code เรามาถึงจุด Break Point นี้ได้ยังไง กันแล้วนะครับ 🙂

Debugging Series:

Debug – สกัดจุดหยุด Code ด้วย Break Point

ถ้าถามว่าจะเริ่ม Debug โปรแกรมต้องทำอะไรบ้าง ทุกๆคนจะตอบเป็นเสียงเดียวกันว่าไปใส่ Break Point ไว้ใน Code ตรงบรรทัดที่เราต้องการให้ Code หยุดการทำงาน

การใส่ Break Point ก็ทำได้ตามนี้ครับ คือ

  1. คลิ๊กที่พื้นที่หน้า Code บริเวณที่ล้อมกรอบสีแดง ถ้าสำเร็จแล้วจะมี จุดสีแดงขึ้น (คลิ๊กอีกทีเพื่อเอา Break Point ออก)

breakpoint1.png

2. หรือจะใช้ Hot Key ก็ได้ (ปกติของ Visual Studio คือ F9)

breakpoint2.png

เริ่มได้
จากนั้นลอง Run โปรแกรมแบบ Debug เช่นกด F5 ครับ เราจะเห็นว่าเมื่อ Code ทำงานมาถึงบรรดัดที่เราตั้ง Break Point ไว้มันก็จะหยุดเป็นลูกศรสีเหลืองๆ ซึ่งหมายถึงตอนนี้ Code กำลังทำงานอยู่ที่บรรทัดที่ 9

breakpoint3

ถ้าเรามีหลาย Break Point ทำการกด F5 นั้นจะเป็นการสั่งให้ Code ทำงานต่อจนไปถึง Break Point จุดถัดไปนะครับ

แล้วจะ Break ไปทำไมกัน มันมีประโยชน์แน่นอนครับ ถ้า Code ของเรามีตัวแปรเราสามารถเอา Mouse ไปจิ้มดูได้ครับแล้ว Debugger ก็จะโชว์ค่าของตัวแปร

ตัวอย่างเช่น

breakpoint4

Console.ReadLine() ทำการรับข้อมูลจาก User ซึ่งผมพิมพ์ “hey anurocha” ไป แล้วเก็บค่าใส่ตัวแปรชื่อ input ผมสามารถเอา Mouse ไปจิ้มตรง input แล้วจะเห็นว่าตัวแปรนี้เป็นค่า “hey anurocha” อยู่

ที่นี้ถ้าโปรเจคเราใหญ่มากแล้วเราทำการตั้ง Break Point ไว้หลายที่ หลายไฟล์เราจะจำได้มั้ย ซึ่งก็จะมี Break Point Window อยู่ครับ

breakpoint5.png

ซึ่งจะเห็นหน้าต่างสำหรับจัดการ Break Point ทั้งหมดของโปรเจคนี้ครับ เช่น
– เปิด/ปิด
– เซฟ หรือ Export/Import

breakpoint6.png

ซึ่งเราสามารถที่จะปิด Break Point ได้โดยที่เรายัง Mark ตำแหน่งไว้จาก Check Box ทำให้เวลา Code ที่ทำงานจะไม่หยุดตรงจุดนั้นๆ

breakpoint7.png

จบ…(เรื่องพื้นฐาน)

มาต่อกันที่ระดับ Advanced ขึ้นนิดนึงครับ 
ปกติแล้ว Break Point ที่เราตั้งเนี่ยจะทำให้ Code หยุดทุกครั้งที่บรรทัดนั้นเรียก แล้วถ้าเราอยากให้มันหยุดเฉพาะบางกรณีล่ะ

ทำได้ครับ มีทางเลือกง่ายๆ คือทำการ Right Click ที่ Break Point นั้นๆ จะมี Conditions..เมนูให้เลือก

breakpoint8.png

ปกติผมใช้ Condition Expression กับ Hit Count ครับ

breakpoint9.png

  1. Condition Expression – เราสามารถกำหนดได้ว่าจะให้ Code มันหยุดตอนไหนบ้างโดนใส่ expression เหมือนใน if() เช่น ถ้าเรามี loop ที่ทำงาน 100 รอบ แล้วเราต้องการให้หยุดตอน i==10 ก็ใส่ไปแบบนี้
    breakpoint10.png
  2. Hit Count – กรณีเช่นเรามีปัญหาว่า Code จุดนี้รัน 30 ครั้งแล้วมันถึงมีปัญหา ถ้าเรา Break แบบปกติมันจะหยุดทุกครั้งซึ่งจะทำให้เราทำงานช้า เราก็สามารถกำหนดไปเลยว่า ขอหยุดเมื่อมันมารันครั้งที่ 30breakpoint11.png

เมื่อ Break Point มีการตั้งเงื่อนไขขึ้นสัญลักษณ์ก็จะเปลี่ยนไปเป็น

breakpoint12.png

ใช้กับ Google Chrome ก็ได้นะ

breakpointchrome.png

แล้ว Break Point เก็บไว้ที่ไหน????
หลายๆท่านอาจจะงงว่า เราตั้ง Break Point ไว้แล้วปิด Visual Studio ไปแล้วพอเปิดใหม่ Break Point ที่เคยตั้งไว้ก็กลับมาด้วย แต่พอไปเปิดเครื่องอื่นกลับไม่มา

สำหรับ Visual Studio นั้น โดยทั่วไป Break Point นั้นไม่ได้เป็นส่วนหนึ่งของไฟล์ในโปรเจค ทำให้เวลาที่เราแก้ไขมันแล้วเราเอาไฟล์ขึ้น Repository ต่างๆเช่น Git/SVN) คนอื่นจะไม่เห็น

ซึ่งไฟล์ของมันเก็บไว้ที่นี่ “.vs”
breakpoint13.png

ลองเข้าไปดู เจอไฟล์ .suo แต่เปิดไม่ได้…

breakpoint14.png

ลองใช้ 7z เปิดดูก็พอเดาได้ว่าข้อมูลการตั้ง Break Point อยู่ในนี้แหละครับ

breakpoint15.png

เป็นอันจบหลักสูตรพื้นฐานวิชาสกัดจุดครับ HAPPY DEBUGGING

Debugging Series:

Debug – การ Run กับ Debug สิ่งนี้คืออะไร

โดยปกติแล้วพวกเราเหล่า Developer ที่ใช้  Visual Studio หลังจากเขียน Code เสร็จแล้วอยากจะดูผลของการทำงาน เราก็จะใช้ปุ่มสุดฮิต นั่นก็คือ กด F5…สิ่งนี้แหละคือการ Debug!..จบ

อ้าวยังครับ! มาดูกันต่อ
ตัวอย่างเช่นการเลือกเมนูข้างล่างหรือ F5 เนี่ยคือการ Start การ Debug แล้วจริงๆ

2016-07-21 00_28_01-ConsoleApplication1 - Microsoft Visual Studio

หรือแม้กระทั่งการปกปุ่มเขียวๆตรงนี้ก็คืการเริ่มต้นการ Debug

2016-07-21 00_28_01-debug-button

อ้าวแล้วการ Run ล่ะคืออะไร
คำตอบง่ายๆก็คือการ double click ไฟล์ Executable (หรือไฟล์ .exe) ตรงๆไงล่ะครับ
หรือถ้าจาก Visual Studio ก็ใช้ เมนู Start Without Debugging ซึ่งก็คือ Ctrl+F5

2016-07-21 00_28_01-debug-run_btn.png

แล้ว 2 อย่างนี้มันต่างกันยังไง????

(Run with) Debug – จะเป็นการ Run โปรแกรมโดยที่ทาง Debugger จะโหลดไฟล์หรือโมดูลเพื่อเตรียมพร้อมให้เราใช้สำหรับการ Debug โปรแกรมของเราได้ ซึ่งบางครั้งอาจจะทำให้รู้สึกว่าโปรแกรมมันทำงานช้าลงไปบ้าง..
แต่สิ่งที่เราจะได้มาคือ
– หยุดการทำงานของโปรแกรมตาม Code ในบรรทัดที่เราต้องการ
– ดูค่าตัวแปรต่างๆเวลาที่โปรแกรมทำงาน
– แก้ไขค่าได้แม้กระทั่งโปรแกรมทำงานอยู่
– และอีกมากมาย

ถ้าเราใช้ Process Explorer ดูจะเห็นว่าโปรแกรมที่เราทำการ Debug อยู่เนี่ยมันเป็น Process ลูกของ devenv.exe(ชื่อ Process ของ Visual Studio) ตรงๆเลยครับ (สำหรับ .NET ตัว Process จะมีเป็นชื่อ .vshost.exe แทน)

2016-07-21 00_28_01-debug-debug_tree

Run – จะเหมือนกับการใช้งานทั่วไปของ Users ซึ่งจะมี Performance ของโปรแกรมเราตามปกติ
ซึ่งจะเห็นได้ว่า deven.exe นั้นจะสร้าง cmd.exe( Commandline Application ) แล้วจึงทำการรัน ConsoleApplication1.exe ซึ่งเป็นโปรแกรมของเราอีกหนึ่งต่อ

2016-07-21 00_28_01-debug-run_tree

และตามปกตินั้นเวลาที่เรา Debug นั้นหน้าตาของ IDE จะเปลี่ยนไป เช่น

2016-07-21 00_28_01-debug-codeview.png
หน้าจอเขียน Code

ไปเป็น

2016-07-21 00_28_01-debug-debugview.png
หน้าจอตอน Run โปรแกรมแบบ Debug

ซึ่งไม่ต้องตกใจนะครับว่าอุตส่าห์จัดหน้าจอสวยๆแล้ว เพราะหน้าจอแบบนี้แหละจะช่วยให้เราทำการ Debug ได้ง่ายขึ้นแล้วมันก็จะเปลี่ยนกลับถ้าออกจากโหมด Debug ไปเป็นโหมด Editor 🙂

จบตรงนี้หวังว่าทุกท่านจะเข้าใจการรันโปรแกรมแบบ Debug ได้ดีขึ้นนะครับ…

Debugging Series:
Debug – Debugger สิ่งนี้คืออะไร

Debug – Debugger สิ่งนี้คืออะไร

จากที่ผมเขียนเกี่ยวกับ IDE (Integrated Development Enviroment) ไปแล้วนั้น ผมได้เน้นว่าอยากให้ศึกษาเรื่อง  Debugger เพิ่มขึ้น มาคราวนี้เลยขอลงรายละเอียดเลยนะครับ

debug.png

เคยมีโค๊ชที่ผมรู้จักท่านนึงกล่าวไว้ว่าการ Debug นั้นคือศาสตร์มืด เพราะมันเป็นการโกงและไม่ทำให้ Code มีการพัฒนาไปในทางที่เหมาะสม เพราะพอโกงชนะก็มักจะขี้เกียจแก้ Code ให้มันเขียน Unit Test ดีๆได้

แต่ผมคิดว่ามันคือเครื่องมือที่ช่วยเรามากกว่าครับ 🙂

การ Debug ก็คือการวิเคราะห์หาข้อผิดพลาดของ Code ของเราที่มันทำงานไม่ถูกต้องอย่างที่เราคิด ยกตัวอย่างเช่น เราคาดหวังว่า Function จะคำนวณผลมาแบบนึง แต่เราได้ค่าที่ไม่ตรง..หรือว่าเรากดปุ่มนึง แต่ข้อมูลดันออกอีกแบบนึง รวมถึงเวลาต้องการทำความเข้าใจ Workflow ของ Code ที่เราไม่คุ้นเคย ซึ่งปัญหาเหล่านี้ถ้ารู้จักวิธีการ Debug ก็จะทำให้ชีวิตเราง่ายขึ้น

แล้ว Debug กันยังไง? วิธีการ Debug นั้นมีหลายวิธีครับ ขอพูดถึงเฉพาะวิธีที่น่าจะใช้กันบ่อยๆกัน

  1. ไล่ Code ดิบๆ – วีธีสุด Classic คือนั่งเปิด Code ดูแล้วก็รีวิวแบบคิดทุกอย่างในหัว ถ้า Code จุดนั้นไม่ซับซ้อนก็ใช้ได้เหมือนกันครับ
  2. Log – อีกหนึ่งวิธีสุด Classic ที่ใช้การเขียนตัวแปรลงไฟล์ หรือ Console ใช้ได้ดีมากครับ โดยเฉพาะถ้าเราต้องทำที่ระบบปิด เช่น เครื่องของ users หรือบน Production
  3. เช็ค Unit Test – วิธีที่ดีที่สุดและท้าทายที่สุด ซึ่งก็คือถ้าเจอ Bug ก็เพิ่ม Test Case ให้สามารถฟ้องว่าเจอ Bug ได้แล้วก็ทำการแก้ Code ให้ Test ผ่าน จากนั้นเราก็จะได้ Test ที่มันครอบคลุมมากขึ้น
  4. ใช้ Debugger – ซึ่งเป็นสิ่งที่จะพูดถึงต่อไปครับ

Debugger คืออะไร? มันก็คือเครื่องมือช่วยเหลือในการแก้ Bug หรือไล่ Workflow ต่างๆ ซึ่งโดยปกติแล้ว IDE นั้นจะมี Debugger ติดมาให้ด้วยอยู่แล้วสังเกตดูจากเมนูของ IDE ต่างๆครับ จะมีเมนูชื่อ Debug อยู่

เช่น…

Screen Shot 2559-07-19 at 11.58.29 AM.png
Debug ใน XCode
vsdebug
Debug ใน Visual Studio
chromedebug.png
Debug ใน Google Chrome (Developer Tools)

แต่สำหรับ Windows ถ้าไม่อยากลงโปรแกรมแบบหนักๆแบบ Visual Studio เช่นต้องไป Debug  ที่เครื่องของ User ก็มี WinDbg ที่เป็น Debugger แบบ Stand Alone แต่มันค่อนข้าง Advanced มากและเป็น Command Line ผมขอยังไม่พูดถึงนะครับ

ขอทิ้งท้ายไว้กับสิ่งที่ต้องรู้สำหรับการเป็นนัก Debug ละกัน ใครยังไม่รู้จักตัวไหนเจอกันครั้งหน้าครับ

  1. Debug กับ Run
  2. Break Point สกัดจุดหยุดทุกสิ่ง
  3. Call Stack
  4. 3 Steps – Step Over, Step Into, Step Out
  5. หน้าต่าง Watch, Autos, Locals

“If debugging is the process of removing bugs, then programming must be the process of putting them in.” – Edsger W. Dijkstra

ถ้าการ Debug เป็นการจัดการ Bug ให้หมดไป ถ้างั้นการเขียนโปรแกรมก็เป็นการเพิ่ม Bug เข้าไป!