เรื่องของตัว S (Single Responsibility) ในหลักการ SOLID

Screen Shot 2560-08-23 at 12.04.58 AM.png

หลังจากที่ผมได้เกริ่นเกี่ยวกับหลักการ SOLID ไปแล้วนั้น วันนี้เราจะมาลองดูกันกับตัวแรกของเรา ซึ่งก็คือตัว S ซึ่งย่อมากจาก Single Responsibility หรือแปลว่า หลักการทำหน้าที่เดียวพอ ซึ่งผมจะขอใช้ตัวอย่างด้วย TypeScript ครับ

Single Responsibility Principle (SRP) นั้นกล่าวถึงการออกแบบ Class ในภาษา Object Oriented เพื่อที่จะทำให้ Class นั้นดูแลและจัดการได้สะดวกมากขึ้น

เริ่มต้น ผมมี Class ตัวอย่างที่ชื่อว่า SmartPhone

class SmartPhone {
   // properties
   private apps : Array<string>;
   private contacts : Array<string>;
   private phoneNumber : string;
   private phoneModel : string;
   private screenWidth : number;
   private screenHeigth : number;

   // methods
   public call( telNum : number){
   }
   public ring(){
   }
   public installApp(appName : string){
      this.apps.push(appName);
   }
   public launchApp(appName : string){
      let app = this.apps.filter(element => element === appName);
   }
   public addContact(contact : string){
      this.contacts.push(contact);
   }
   public getScreenPixel() : number {
      return this.screenWidth * this.screenHeigth;
   }
   public getModel() : string {
      return this.phoneModel;
   }
}

ซึ่งจาก Code ตัวอย่างนี้จะเห็นได้ว่า Class SmartPhone นี้ก็ออกแบบมาตามหลัก OO ระดับหนึ่ง ซึ่งถ้าเรามาดูรายละเอียดดีๆนั้นจะเห็นว่ามันมี 3 ส่วนด้วยกัน

  1. การจัดการ Apps
  2. การจัดการ Contact
  3. ข้อมูลของตัว SmartPhone เอง

แต่จะเห็นว่า Code นี้ยังไม่ได้ใช้หลักการของ SRP เลย ดังนั้นสิ่งที่เราต้องทำคือ เราจะมาลองเปลี่ยน Code ให้สอดคล้องกับหลักการนี้ ขั้นตอนนี้เราเรียกว่า การ Refactor 

สิ่งที่ต้องทำก็คือจะใช้เทคนิคการ  Refactor ที่ชื่อว่า Extract Class ก็คือเป็นการแยก Code ในส่วนของ Properties และ Methods ที่น่าจะรวมกันเป็น Class ใหม่ได้ออกมา

ดังนั้นเราเราจะได้ Class ใหม่มาเพิ่มอีก 3 Class คือ Apps และ Contacts

  1. Class Apps จะเอาการเก็บข้อมูล Array และ Methods การ install กับ launch มาไว้ใน Class นี้
class Apps {
   private apps : Array<string>;
   public install(appName : string){
      this.apps.push(appName);
   }
   public launch(appName : string){
      let app = this.apps.filter(element => element === appName);
   }
}

2. Class Contacts จะเอาไว้จัดการเกี่ยวกับ Contact List

class Contacts {
   private contacts : Array<string>;
   public add(contact : string){
      this.contacts.push(contact);
   }
}

3. Class PhoneInfo เราจะเอามาเก็บข้อมูลทั่วไปเช่น เบอร์โทร ชื่อรุ่น ขนาดหน้าจอ

class PhoneInfo {
   private phoneNumber : string;
   private phoneModel : string;
   private screenWidth : number;
   private screenHeigth : number;
   constructor(model : string){
      this.phoneModel = model;
      this.screenWidth =5;
      this.screenHeigth =10;
   }

   public getModel() : string {
      return this.phoneModel;
   }

   public getScreenPixel() : number {
      return this.screenWidth *this.screenHeigth;
   }
}

ซึ่งเมื่อมาถึงตรงนี้แล้วเราก็ต้องทำการแก้ Class หลักของเราก็คือ Class SmartPhone ให้มาเรียกใช้งานทั้ง 3 Classes นี้

// Smart Phone V2
class SmartPhone {
   private apps : Apps; // เรียกใช้ Class Apps
   private info : PhoneInfo; // เรียกใช้ Class PhoneInfo
   private contacts : Contacts; // เรียกใช้ Class Contacts

   constructor(){
      this.apps =new Apps();
      this.info =new PhoneInfo('S10');
      this.contacts =new Contacts();
   }

   public call( telNum : number){
   }

   public ring(){
   }

   public installApp(appName : string){
       this.apps.install(appName); // เรียกใช้ Method ของ Class Apps
   }

   public launchApp(appName : string){
      this.apps.launch(appName);// เรียกใช้ Method ของ Class Apps
   }

   public addContact(contact : string){
      this.contacts.add(contact);// เรียกใช้ Method ของ Class Contacts
   }

   public getScreenPixel() : number {
      return this.info.getScreenPixel();// เรียกใช้ Method ของ Class PhoneInfo
   }

   public getModel() : string {
       return this.info.getModel();// เรียกใช้ Method ของ Class PhoneInfo
   }
}

หลังจากทำการ Refactor เสร็จก็จะเห็นได้ว่า Class SmartPhone Verion 2 นั้นจะเป็นระเบียบมากขึ้น ไม่ต้องมาเก็บตัวแปรที่เป็น String หรือ Array ที่ไม่เกี่ยวข้องอะไรกับตัว Class นี้เองเลย แต่จะย้ายไปเก็บใน Class ย่อยๆแทนเพื่อที่จะให้ Code นั้นเหมาะสมกับ Class แต่ละ Class จริงๆ

เท่านี้เพื่อนๆก็จบหลักสูตร Single Responsibility Principle กันแล้วครับ หวังว่าจะเป็นประโยชน์กับทุกคน แล้วเจอกันตอนหน้าด้วยหลักการตัว O 🙂

Advertisements

หลักการ SOLID สำหรับคนที่เขียน OOP

SOLID เป็นหลักการ 5 ข้อที่จะช่วยให้ Developer ที่เขียนภาษา Object Oriented เช่นพวก C#, Java, C++) นั้นสามารถเขียน Code ได้ดูเป็นระบบระเบียบมากขึ้น รวมถึงสามารถที่จะดูแลและแก้ไขได้ง่ายและสุดท้ายทำให้พวกเราดูเป็น Profressional กันด้วย 🙂

ถึงแม้ว่าหลักการของ SOLID นั้นมีมาก็หลาย 10 ปีแล้วแต่ผมคิดว่าสำหรับนักพัฒนาที่เขียนภาษา OO ก็เป็นสิ่งที่ยังควรรู้ รวมถึงคนที่เขียนภาษาอื่นๆเช่นพวก Script หรือ Dynamic languages ก็อาจจะเอาไปประยุกต์ใช้ได้เหมือนกัน

เอาล่ะเรามาดูกันว่าหลักการ 5 ข้อนั้นย่ามาจากอะไรบ้าง

S – Single Responsibility Principle

กล่าวถึง Class หนึ่งๆนั้นควรจะมีแค่หน้าที่ ความรับผิดชอบเดียวเท่านั้น

O – Open Closed Principle

กล่าวถึง ระบบของ Software นั้นควรง่ายและเป็นระบบเปิดต่อการต่อยอดโดยที่แก้ไขระบบหลักให้น้อยที่สุด

L – Liskov substitution Principle

กล่าวถึง Object ของ Class ที่ระบบได้เรียกใช้นั้นควรจะสามารถเรียกใช้ Class ลูกๆได้โดยที่ไม่ต้องแก้ไขระบบเลย (ข้อนี้อาจจะเข้าใจยากนิดนึงนะครับ อาจจะต้องลองดูตัวอย่าง)

I – Interface segregation Principle

กล่าวถึงการแบ่งย่อย Interface ให้เป็นสัดสวนตามหน้าที่ของมัน ดีกว่ามี Interface เดียวที่มีหลายๆ Methods

D – Dependency Inversion Principle

กล่างถึงการที่ Class ต่างๆติดต่อกับอีก Class อื่นๆนั้น ควรจะติดต่อกันผ่าน Interface มากกว่า Object ของ Class นั้นๆตรงๆ

 

 

มาถึงตรงนี้เพื่อนๆที่ยังไม่รู้จัก SOLID ก็อาจจะยังไม่เข้าใจอยู่ดี ซึ่งผมคิดว่าบทความครั้งต่อๆไปนั้นจะลองมาเน้นขยายความกันในแต่ละเรื่องให้นะครับ

ref : https://en.wikipedia.org/wiki/SOLID_(object-oriented_design)

npm แล้วช้ามาลองใช้ yarn จาก facebook กัน

yarn-kitten-full

ทุกๆท่านที่เขียน Node.js ก็ต้องคุ้นเคยกับ npm กันอยู่แล้วนะครับ ซึ่งบางทีเรามักจะเจอว่า มัน install นาน รวมถึงเวลาเน็ตมีปัญหาแล้วมัน install ไม่ได้ มาวันนี้ Facebook ได้ประกาศ Open Source ตัว package manager ตัวใหม่ที่ทำงานบนพื้นฐานของ npm ซึ่งชื่อของมันก็คือ Yarn

ทาง Facebook ได้พูดถึงจุดเด่นหลักๆได้ประมาณนี้ครับ

  1. เร็ว – เพราะมีระบบการ Cache ถ้า pkg ไหนโหลดมาแล้วก็ไม่ต้องโหลด
  2. เชื่อถือได้ – ใช้ในการติดตั้ง package ได้เหมือนเจ้าอื่น
  3. ปลอดภัย – ทำการ check sum ซึ่งเป็นการตรวจเช็คว่าการ install นั้นถูกต้อง

ความสามารถหลักๆของมันคือเช่น

  • Offline Mode ถ้าเคย insatll package มาแล้วครั้งนึง ก็ไม่ต้องใช้ internet ในการ install แล้ว
  • ใช้ประโยชน์จาก Network อย่างเต็มที่ทำให้การ install นั้นเร็วขึ้น
  • ใช้ได้ทั้งกับ npm และ Bower
  • ทำการ retry ถ้าหากว่ามีปัญหาตอน install

อ่านรายละเอียดได้ที่ https://github.com/yarnpkg/yarn และ https://code.facebook.com/posts/1840075619545360 สำหรับ Architure และที่มาที่ไปของ Project นี้ครับ

เกริ่นมาพอแล้ว เรามาลองเล่นกันดีกว่าครับ

ก่อนอื่นก็

npm install -g yarnpkg

แล้วก็ลองเช็คดูครับว่าลงได้

yarnv.png

ที่นี้เดี๋ยวผมลอง install module เล่นๆ เอาเป็น socket.io ละกันครับ ดังนั้นผมสร้าง package.json ง่ายๆมาก่อน

{
“dependencies”: {
“socket.io”: “^1.5.0”
}
}

package.json

ที่นี้ลองรัน “yarn” ซึ่งเทียบเท่ากับ “npm install”

จะเห็นว่าเราจะได้ node_modules มารวมถึงเวลาที่ใช้ไป 3.61s

yarn_install.png

ทีนี้ผมลองลบ folder ‘node_modules’ ทิ้งเพื่อจะดูว่ามัน Offline install ได้จริงเปล่าแล้วก็ทำการ yarn อีกที ผลที่ได้คือ !!! 0.77s

yarn_reinstall

จะเห็นได้ว่า yarn นั้นทำการ cached ตัว package ที่เคยโหลดมาแล้วไว้ที่ Local Machine ซึ่งผมลองไปคุ้ยๆ Folder ดูก็เจอว่ามันไปเก็บไว้ที่  %localappdata%/yarn นี่เองสำหรับบน Windows

local_yarn.png

สรุป ผมว่า Tool ตัวนี้น่าสนใจครับ เดี๋ยวว่าจะเอาไปลองใช้ใน Production บ้าง โดยเฉพาะช่วงเน็ตช้าและต้องงานหลายๆ repo ที่อาจจะมีการใช้ npm package ซ้ำๆกันบ่อยๆ…

Fear Driven Development

จะเกิดอะไรขึ้นถ้า Developer ต้องทำงานอยู่ภายใต้สิ่งแวดล้อมที่มีความกลัวครอบงำ…

ทีมที่ทำงานด้วย Fear Driven Development (FDD) นั้นจะทำให้ Developer นั้นรู้สึกว่า

  • กลัวที่จะทำผิด
  • ไม่กล้าแก้ Code
  • ไม่กล้า Refactor
  • ไม่กล้า Commit หรือ Push Code
  • ไม่กล้าเปลี่ยน Design
  • ไม่กล้าท้าทาย UI/UX หรือ Product เพราะกลัวได้งานเพิ่ม
  • ไม่กล้ารับปาก เพราะกลัวทำไม่ได้
  • ไม่กล้าออกความเห็น เพราะกลัวต้องรับผิดชอบกับ Idea ตัวเอง
  • ไม่กล้าเปลี่ยน Tools หรือ Framework
  • กลัวว่า Software นั้นจะมี BUG ซึ่งเห็นเหตุผลให้เกิด Process ต่างๆมากมาย
  • และสุดท้ายทำให้ Developer ใช้เวลาไปกับงาน Admin/Process มากกว่าการเขียน Code….

ความกลัวและไม่กล้าต่างๆเหล่านี้ทำให้ Project ไปได้ช้าลงแน่นอน รวมถึงทำให้เกิด Over-Engineer (การ Design Software เกิด Use case ที่จะเกิดขึ้นจริง) และกลัวการ Estimate ซึ่งเป็นการบอกเวลาว่า Project นี้จะเสร็จตอนไหนกับเหล่าท่านๆผู้บริหารระดับสูงทั้งหลาย จึงทำให้การ Estimate (ประเมิณ) กลายมาเป็นการลงรายละเอียดซึ่งใช้เวลาเยอะมากจนกว่าจะได้ตัวเลขออกมาก

วัฒนธรรมกลัวตกงาน

เป็นลักษณะหนึ่งของ FDD ซึ่งเกิดจากทีมใช้งาน Developer อย่างหนักและมีการกดดันกันว่าถ้ามีปัญหากับโปรเจคอาจจะโดนไล่ออกได้ ซึ่งการทำแบบนี้ไม่อาจจะทำให้ทีมนั้นมี Productivity ที่ดีได้ รวมทั้งยังขาด Innovation ด้วยรวมถึงทำให้เกิดความกดดันต่างๆและทำให้อัตรา Turn-Over สูงขึ้น ซึ่งในทีมที่มีวัฒนธรรมแบบนี้ส่วนใหญ่ก็จะมีการยกย่องคนที่เรียกว่า Hero(Hero Driven Development) ซึ่งเป็นคนที่ทำให้แต่ละ Release นั้นผ่านไปได้จะได้รับการยกย่องและสุดท้ายก็จะกลายเป็นว่าทีมนั้นต้องการ Hero ตลอดเวลานี่แหละคือปัญหา!

รวมถึงวัฒนธรรมการ Blame เช่นเมื่อเวลามีปัญหาเกิดขึ้นก็หาคนทำผิดแทนที่จะช่วยกันแก้ปัญหาให้ User…

วัฒนธรรมกลัวการแก้ Code

อีกสิ่งที่น่ากลัวของการพัฒนา Software ซึ่งก็คือ Developer ไม่กล้าแก้ไข Code ซึ่งอาจจะเป็นเพราะว่า Code นั้นเก่ามากๆซึ่งปกติน่าจะเกิดจากการที่ไม่เข้าใจ Code ชุดนั้นมากกว่า ลักษณะของ Code ประเภทนี้คือมันก็ work ดีเกือบทุก case แต่ถ้าจะต้องแก้ Developer ก็จะกลัวจะเกิดผลที่คาดไม่ถึง รวมทั้งเกิด Bug ต่างๆ และที่เลวร้ายไปกว่านั้นคือไม่กล้าแก้ Code ของตัวเอง!

สุดท้าย

ส่วนตัวผม คิดว่าสิ่งที่อาจจะน่ากลัวกว่าก็คือการกลัวการเปลี่ยนแปลงโดยเฉพาะ Developer เพราะอย่างที่รู้กันอยู่แล้วว่า Software Development นั้นเทคโนโลยีหรือ Tools ต่างๆมาเร็วไปไว ซึ่งการที่เราไม่ยอมรับการเปลี่ยนแปลงตรงนี้ก็จะคงอยู่แต่โลกเดิมๆ โดยไม่ได้มองหาสิ่งที่จะมาเพิ่ม Productivity ความรู้ใหม่ๆ เพื่อช่วยให้เราเก่งขึ้นและทำงานได้ดีขึ้น 🙂

ถ้า Developer ไม่กล้าแก้ Code แล้วใครจะกล้าแก้ล่ะ???

เรียบเรียงจาก:

http://www.hanselman.com/blog/FearDrivenDevelopmentFDD.aspx

 

สร้าง Node.js module แบบ Native ด้วย C++

node_cpp

เป็นที่รู้กันว่าสำหรับทุกคนว่า Node.js นั้น Powerful ก็เพราะว่ามี Modules ให้เราใช้ไปแทบทุกอย่าง รวมถึงหลายๆคนอาจจะเคยเขียน Module ด้วย JavaScript ทั้งใช้เองและให้คนอื่นใช้

แต่วันนี้ผมจะมาแนะนำวิธีการเขียน Node.js module ด้วย C++ กัน

ก่อนอื่นในเมื่อเราเขียน Module ด้วย JavaScript ได้ทำไมต้องใช้ C++ มาดูข้อดีกันก่อนเลย

  1. System Access – ด้วย Native enviroment ทำให้ Module ที่เขียนด้วย C++ สามารถเข้าถึง API ของ System/OS ได้
  2. Performance – JavaScript นั้นทำงานด้วย Single Thread แต่ว่า Native นั้นสามารทำงานแบบ Multi Thread ได้
  3. Compiled Binary – JavaSciprt ถึงแม้จะมี Minify/Uglify แต่ก็พอจะ reverse engineer ได้แต่สำหรับ Native นั้นถึงแม้จะทำได้เหมือนกันแต่ก็ต้องมานั่ง Deassembly

เริ่มกันเลยครับ จริงๆแล้วผมก็ทำตาม https://nodejs.org/api/addons.html  แต่!…ผมทำตามแล้วมันมีขั้นตอนเยอะและต้องใช้ Python ในการ Build อีก ผมเลยขอสรุปเองจากการลองแงะ Python scipt เพื่อลดความงงลง(หรือว่ายากขึ้น?)

  1. สร้าง Project C++ ใหม่จาก Visual Studio 2015
    newproj
  2. เป็น DLL นะ
    dllproj
  3. ไปโหลด Node.js ไฟล์ headers และ node.lib มาครับที่
    https://nodejs.org/download/release เลือกตาม version ของ Node ที่เราจะใช้ได้เลย เช่น v6.3.0
    download
  4. Extract .gz แล้วก้ copy ไฟล์มาที่ Folder C++ Project ของเรา
    ผมตั้งชื่อ folder เป็น
    – include สำหรับ headers ไฟล์ที่เรา Extracted มา
    – lib สำหรับเก็บ node.lib
    copy_dep
  5. ที่นี้ก็ copy Source code นี้ไปที่ .cpp หลักครับ
    // anurocha_node.cpp : Defines the exported functions for the DLL application.
    //
    
    #include "stdafx.h"
    #include "include/node/node.h"
    
    namespace demo {
    
     using v8::FunctionCallbackInfo;
     using v8::Isolate;
     using v8::Local;
     using v8::Object;
     using v8::String;
     using v8::Value;
    
     void SayHi(const FunctionCallbackInfo<Value>& args) {
     Isolate* isolate = args.GetIsolate();
     args.GetReturnValue().Set(String::NewFromUtf8(isolate, "Hi - How are you doing?"));
     }
    
     void init(Local<Object> exports) {
     NODE_SET_METHOD(exports, "hello", SayHi);
     }
    
     NODE_MODULE(addon, init)
    
    } // namespace demo
  6. ลอง Build Project ดูครับ…เจ๊ง!
    link_err
    อ๊ะ!.. เราลืม Link ครับ
  7. ไปเพิ่ม lib/node.lib ใน Linker ซะ
    linker
  8.  Build อีกรอบ….เจ๊งเหมือนเดิม!!@#ไม่ต้องตกใจครับ….เป็นมุข..เรามี Lib ของ node.dll เป็น x64 ตามที่โหลดมา แต่เรากำลัง Compile แบบ x86 อยู่(ซึ่งเป็น Default Configuration ตอนสร้าง Project) ดังนั้นไปแก้ Project – Linker อีกรอบนึงครับ มั่นใจว่าแก้สำหรับ Platform x64 ด้วยนะครับ
    linker64
  9.  Build อีกทีจริงๆ ด้วย Target x64 นะครับbuildx64
  10. ถ้า Build ผ่านจะได้ไฟล์ .dll มาครับ
    out
    ให้เปลี่ยนชื่อเป็น anurocha.node แทน
  11. สร้างไฟล์ app.js ง่ายๆมา มี Code แค่ 2 บรรทัด ที่ Folder เดียวกับ anurocha.node
    const addon = require('./anurocha');
    console.log(addon.hello());
  12. รัน “node app.js” ดูครับ…..แล้วความตื่นเต้นก็เกิดขึ้น!!!
    node_out

สำเร็จแล้วกับ 12 ขั้นตอนที่ยาวนาน !!!!!

ลองมาดูรายละเอียดกันครับเกี่ยวกับขั้นตอนการทำงานของ JavsScript <–> C++
ซึ่งหัวใจสำคัญที่ทำให้ทั้ง 2 ภาษาคุยกันได้คือ V8 ที่เป็น JavaScript Engine เขียนด้วย C++ จาก Google นั่นเอง

  1. เวลาที่ dll ถูกโหลดด้วย JavaScript จาก require(); ตัว dll จะถูกเรียกครั้งแรกเพื่อทำการ Init ค่าต่างๆ
    ในที่นี้เราทำการ export Fuction ที่ชื่อว่า hello ออกไป ซึ่ง function hello นั้นทำการ Map กับ Method ที่ชื่อว่า SayHi

    void init(Local<Object> exports) {
     NODE_SET_METHOD(exports, "hello", SayHi);
     }
    
     NODE_MODULE(addon, init)
  2. เวลาที่ JavaScript เรียก addon.hello();
    Code ฝั่ง C++ จะถูกเรียก Method ที่ชื่อว่า SayHi(); ทำให้มีการ return String object ที่มีค่า “Hi – How are you doing?” ออกมาให้ฝั่ง JavaScript

    void SayHi(const FunctionCallbackInfo<Value>& args) {
     Isolate* isolate = args.GetIsolate();
     args.GetReturnValue().Set(String::NewFromUtf8(isolate, "Hi - How are you doing?"));
     }

จากตัวอย่างนี้จะเห็นได้ว่าการเขียน Node.js Module ด้วย C++ นั้นอาจจะดูยุ่งยากซักนิดนึง แต่มันทำให้เราเขียน Logic ต่างๆด้วย C++ ได้ นั่นหมายความว่าถ้าเรารัน Node บน Windows เราก็สามารถเรียกใช้งาน Win32 API ต่างๆได้เช่น การเรียก Registry Key, ต่อ Socket, อ่านไฟล์บน HDD รวมถึงการทำงานร่วมกับสารพัด Library ของ C++ อย่างที่ทำได้เหมือนการเขียนโปรแกรมบน OS นั้นๆ….

LONG LIVE C++

ปล. Code ทั้ง Solution ดูได้จาก https://github.com/anurocha/node_cpp_addon ครับ

IDE หนึ่งในสิ่งพื้นฐานควรรู้ของ Developer

Developer คนไหนไม่รู้จัก IDE บ้าง? ถ้าคนๆนั้นเป็นคุณก็…..อ่านต่อเถอะครับ 🙂
ส่วนถ้ารู้แล้วก็ลองอ่านเล่นๆดูได้ครับ

IDE ย่อมากจาก Integrated Development Enviroment ซึ่งก็คือเครื่องมือที่ Developer ใช้ในการพัฒนา Software แบบครบวงจร เช่น Visual Studio, XCode, Netbean, Eclips, Xamarin และอื่นๆ

โดยความสามารถหลักๆ ของ IDE ผมขอแบ่งเป็น 4 อย่างใหญ่ๆละกัน

  1. Editor – เอาไว้เขียน Source Code รวมถึงพวก Syntax Hilight, Auto-Complete
  2. Compiler – เอาไว้ Build โปรแกรมจาก Code ไปเป็น Binary
  3. Debugger – เอาไว้ใช้ในการแก้หาวิธีในการแก้ Bug
  4. Tools – เครื่องมือช่วยต่างๆ เช่น Refactoring, จัดหน้าจอหรือ Visual Design, การทำ UML, ดู Database รวมถึงพวกทำ Static Code Analysis และการสร้าง Document จาก Code

มาถึงตรงนี้แล้วมีใครใช้ IDE ครบ 4 อย่างมั้ยครับ….จากประสบการณ์ของผมแล้วน้องๆ Developer  ส่วนใหญ่จะรู้จักมันในฐานะข้อ 1 และ 2 เท่านั้น

ซึ่งผมอยากแนะนำสำหรับคนที่ยังไม่ได้ลองใช้ความสามารถของ IDE ในการเป็น Debugger ควรจะหาเวลาไปเรียนรู้ไว้ครับ เพราะมันจะช่วยทำให้คุณแก้ Bug รวมถึงพัฒนา Feature ที่ซับซ้อนได้เร็วขึ้นจริงๆ

แต่ช้าก่อน…..ถ้าท่านที่สามารถทำงานกับโปรเจคขนาดใหญ่โดยไม่ต้องใช้ Debugger ได้ผมนับถือมากครับ แสดงว่า  Source Code น่าจะมี Unit Test ครบ 100% ซึ่งทำให้เจอBug ได้จาก Unit Test และไม่ต้องพึ่งการ Debug

นี่คือ Utopia of Software – Software ในอุดมคติเลย!

Canary Testing นกขมิ้นน้อยในเหมืองใหญ่

4_1278772155

เหล่าท่านๆ Engineer ทั้ง Developer และ QA อาจจะรู้ว่าการปล่อย Software ขึ้น Production ให้คุณลูกค้านั้นมีความตื่นเต้นเพียงใด ถึงแม้ว่าเราจะมีการหลายๆ Enviroment ในการพัฒนาระบบเช่น Development, Pre-Production, Production เพื่อลดความเสี่ยงลงแล้ว แต่ถึงอย่างนั้นตอนเอาขึ้น Production ก็ยังต้องลุ้นทุกที

เป็นปกติที่ระบบ Production ของ Software จะมีการ Config ที่แตกต่างกันกว่า Development อยู่เสมอ (แล้วทำไมมันไม่เหมือนกันล่ะ??) แต่ถ้าเราต้องอยู่ด้วยสถานะระบบแบบนี้เรายังมีทางออกนะครับ

สิ่งนี้เรียกว่า Canary Testing ซึ่งมาจาก Canary in Coal Mine มาจาก

การที่นักขุดเหมืองสมัยก่อนนั้นจะใช้นกขมิ้นในการทดสอบว่าเหมืองนั้นปลอดภัยไม่มีก๊าซพิษก่อนที่คนละทำการลงไปขุดในระดับที่ลึกขึ้น

การนำแนวคิดนี้มาใช้กับ Sofware ก็คือ เราจะให้กลุ่ม Users บางกลุ่มนั้นได้ลองใช้ Software Version ใหม่ก่อนคนอื่นๆ เพื่อป้องกันการความเสี่ยงจากการ Release ที่เดียว Impact ทุกคน หรือเรียกว่า BIG BANG Release
จากนั้นก็ค่อยๆรับ Feedback จาก Users กลุ่มๆนี้ ถ้ามี Critical Bug ก็ทำการแก้ไขก่อนที่จะเริ่ม Release ให้กับ Users ในกลุ่มที่ใหญ่ขึ้น และทำแบบนี้ไปเรื่อยๆจน Release ให้กับทุก Users

ถ้าระบบของ Software เราเป็น Web เราอาจจะทำ Canary Tetsing/Release ได้ง่ายขึ้นจากการ

  1. โดยอาจจะเริ่มจาก กลุ่มผู้โชคดี > ประเทศ > ทวีป > ทั้งโลก เป็น 4 ขึ้นตอน
    ซึ่งอาจจะทำได้โดย detect  ว่า Users มาจาก IP ช่วงไหนแล้วก็ Redirect ไปยัง URL ของ Version ใหม่
  2. ถ้ามีระบบ User อาจจะมี Option ว่าเป็น Early Accessได้ แล้วระบบเราเช็ค Flag นี้ในการตัดสินใจ Version
  3. สร้าง URL ใหม่เลยแล้ว Promote ที่ Banner ว่า Try Latest Version!

ซึ่งแน่นอนว่าการที่ระบบจะทำ Canary Testing ได้ก็ต้องลงทุนและต้องมีสถาปัตยกรรมที่รองรับ และยิ่งถ้าระบบใหญ่ๆและการ Release ทีนึงมี Impact กับ Users เยอะๆนี่ ผมว่าคุ้มนะ 🙂