ผมเคยเล่าให้ฟังบ้างว่าเคยมีส่วนร่วมในการสัมภาษณ์งาน ซึ่งเป็นโอกาสที่ดีมาก เพราะผมได้ทำตั้งแต่ทำงานปีแรกเลย (นี่ผมสัมภาษณ์คนมา 10 ปีแล้วนะเนี่ย 😉 ) ได้เจอคนมาหลากหลายแบบเหมือนกันครับ ในฐานะที่เป็นสายเทคนิคัล ผมก็จะได้สัมภาษณ์แนว ๆ เทคนิคัลซะทั้งหมดนั่นแหละ ซึ่งตามปรกติของสายนี้เราจะต้องให้ทำเทสต์ก่อนว่าคนที่สัมภาษณ์เนี่ยเขามีความสามารถจริงหรือเปล่า เพราะว่าถ้าเป็นคนที่ไม่มีทักษะเลยเราก็คงให้เขาเข้ามาร่วมงานไม่ได้ เพราะเขาก็คงจะทำงานไม่ได้

แต่ทีนี้ถ้าพูดเรื่องการทดสอบว่าเราดูอะไรกัน ส่วนตัวผมเน้นเรื่องความรู้พื้นฐาน คือคนที่มีความรู้พื้นฐานเนี่ยจะทำงานระดับพื้นๆ ได้ ถึงแม้ว่าการทำงานที่ยากขึ้นไปอาจจะต้องใช้ความคิดสร้างสรรค์มากขึ้น แต่ว่าเขาก็ต้องมีความรู้พื้นฐานด้วยเช่นกัน ดังนั้นคนที่มีแต่ความคิดสร้างสรรค์อย่างเดียวคงทำงานอะไรไม่ได้

อันที่จริงคนที่คิดอย่างเดียวโดยปราศจากพื้นฐานเนี่ย เราเรียกง่าย ๆ ว่าเป็นพวกเพ้อฝันครับ

จากประสพการณ์ส่วนตัวในระยะหลังผมพบว่าผมเจอคนที่ขาดความรู้พื้นฐานอยู่บ่อย ๆ อย่างเช่นที่เจอเอาหมาด ๆ เลยคือถามว่า integer ขนาด 32 บิตนั้นสามารถเก็บตัวเลขได้กี่หลัก (คำตอบคือ 10 ครับ ถ้าเป็น sign int จะเก็บได้ตั้งแต่ลบสองพันล้านกว่า ๆ ถึงสองพันล้านกว่า ๆ ทั้งนี้ถ้าจะเอาให้ปลอดภัยควรเก็บไม่เกิน 9 หลักนะครับ ไม่งั้นอาจจะเกิด overflow ได้เมื่อเกินสองพันล้าน ทั้งนี้เวลาฟังคำตอบก็ต้องดูเหตุผลประกอบครับ คำถามนี้ตอบว่า 9 ก็ได้เช่นกันด้วยเหตุผลเดียวกัน)

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

ผมยกตัวอย่างนึง ถ้าพูดถึง access level เราก็มักจะพูดว่า ฟังก์ชั่นควรเป็น public ในขณะที่ฟิลด์ควรเป็น private ดังนั้นจะมีบางคนเขียนคลาสตามนี้โดยไม่คิดอะไรเลยว่า public คืออะไร และ private คืออะไร ทั้ง ๆ ที่จริง ๆ ถ้าคิดกันตามตรรกกะแล้วฟังก์ชันที่เป็น private ก็มีประโยชน์ของมัน ส่วนฟิลด์ที่เป็น public ก็ไม่ใช่ปีศาจ (ผมใช้ constant public field ประจำ ใช้ในแนว enumerator น่ะครับ)

ยิ่งเทคนิคที่มีความยากสูง ๆ ความรู้พื้นฐานก็ยิ่งสำคัญมากขึ้น เช่นเรื่องของการทำ multi-thread คุณต้องรู้เรื่องของการทำ synchronization ต้องรู้เรื่องของ atomic operation ไม่ใช่สักแค่เอา lock ไปแปะหัวท้าย (เพราะนั่นคือการบังคับให้ทุกงานถูกประมวลผลตามลำดับ (serial) กลายเป็นว่าเขียนของยากมาโดยไม่ได้ประโยชน์อะไรเลย) ซึ่งมันเป็นการแก้ปัญหาที่ปลายเหตุละ

ที่สำคัญที่สุด มันไม่ผิดที่ไม่รู้ แต่ที่ผิดจริง ๆ คือรู้ทั้งรู้ว่าตัวเองไม่รู้ก็ปล่อยให้ตัวไม่รู้ต่อไปทั้งอย่างนั้นครับ ดังนั้นอะไรก็ตามที่คุณคิดว่าตัวเองขาดไปคุณต้องศึกษาเพิ่ม ส่วนตัวผมพบว่าวิธีการตรวจสอบว่าตัวเองไม่รู้พื้นฐานเรื่องไหนก็คือการเปิดหนังสือที่เป็น reference แล้วอ่านทีละเรื่องไปตามลำดับ อย่างตระกูล In The Nutshell ของ Oreilly เนี่ยเป็นตัวอย่างที่ดี ลองค่อย ๆ อ่านไปตั้งแต่ต้นยันจบแล้วดูว่าตัวไม่เข้าใจมากน้อยแค่ไหน ถ้าเกิดว่ามึนตั้งแต่หน้า 10 นี่ก็ควรทบทวนควรรู้ด่วนล่ะครับ

สร้างตึกเริ่มที่ฐานราก สร้างคนต้องเริ่มที่ความคิดพื้นฐานครับ ลองดูนะ

1

e here มึงทำอะไรของมึงวะ sad i ngo เห็นมั้ยว่ามันพังหมดเลย yed mang เอ๊ย มึงมาเลย มึงมาแก้เดี๋ยวนี้เลยนะ

ข้างบนเป็นเรื่องสมมติของบ่ายวันหนึ่ง ผมได้ยินคำพูดนี้ขณะที่ผมกำลังนั่งทำงาน (ขอแปลงบางคำให้เป็นภาษาอังกฤษ เผื่อจะดูเบาลงนะครับ ... คือถ้าเซ็นเซอร์เอามันจะอ่านไม่รู้เรื่องเลย)

นี่คือบทสนทนาระหว่างเพื่อนร่วมงาน คนพูดเป็นผู้ชาย คุยกับน้องอีกคนที่เป็นผู้หญิง น้ำเสียงอาจจะฟังแรง แต่เท่าที่คุยกับหลาย ๆ คนเขาก็ว่านี่คือการเล่นกัน เป็นแค่การคุยงานกัน ไม่ได้ทะเลาะกันหรือด่ากันแต่อย่างใด ... เห็นว่าคุยกันแบบนี้จนเป็นปรกติแล้ว (ได้ยินประจำ)

ย้ำอีกทีนะ ไม่ได้ด่ากันแต่อย่างใด

ส่วนตัวผมไม่ค่อยชอบนะ คือ คิดว่า ถ้าทำงานด้วยกัน ก็ควรจะเคารพซึ่งกันและกัน บางครั้งการเรียกใช้คำสรรพนามอย่าง "e here" (อ่านออกเสียงนะครับจะได้รู้ว่าคืออะไร) มันเป็นการดูถูกกันว่าคนที่คุณคุยด้วยนั้นเป็นคนที่อยู่ลำดับชั้นกว่าตัวเอง

สรรพนามที่ผมไม่ชอบเอามาก ๆ แต่เป็นคำที่ได้ยินอยู่บ่อย ๆ ก็คือคำว่า "ไอ้โง่" (มันไม่ค่อยหยาบเนอะ เขียนไทยละกัน) ก็เป็นการเหยียดว่า คนที่กำลังคุยด้วยมีสติปัญญาด้อยกว่า คือ คิดเล่น ๆ นะ ผมทำงานที่นี่ มีเพื่อนร่วมงานเป็นคนที่คุณกำลังด่าว่า "โง่" การที่ผมต้องทำงานกับคนโง่ นั่นหมายถึงผมต้องโง่พอที่จะมาทำงานด้วยกันได้ นั่นหมายถึงการที่มีเพื่อนร่วมงานที่ถูกหาว่า "โง่" ก็เป็นการดูถูกผมว่าผมก็โง่พอกันด้วย ว่าไหม ?

ผมไม่ได้โดนคำเหล่านี้เอง คือ ผมไม่ได้สนิทกับคนที่ทำงานมากพอที่เขาจะมาเล่นหัวกันแบบนี้ได้ (และถ้ามีใครหาญกล้ามาเล่นแบบนี้ล่ะก็จบไม่สวยแน่ ๆ ผมถือว่าการทำกับผมแบบนี้เป็นการล่วงละเมิดนะครับ (harassment) ไม่ว่าจะสนิทแค่ไหนก็ตาม)

ทั้งนี้ในกรณีที่เลวร้ายที่สุด คำพูดเหล่านี้ถูกใช้ในการอ้างถึงลูกค้า-ผู้ใช้งานระบบด้วย สำหรับผู้ประกอบธุรกิจคงไม่อยากให้ลูกค้าของตัวเองถูกนินทาลับหลังว่า "โง่" หรือ "บ้า" หรอกครับ แต่ถ้าลองเงี่ยหูฟังดี ๆ เราจะพบว่าไอ้บรรดาคนทำงานทั้งหลายทั้งแหละเนี่ยเขาก็พูดถึงลูกค้าแบบนี้แหละ (ก็อารมณ์เดียวกับคนขับแท็กซี่แหละครับ) คือ บริษัทมีรายได้เพราะลูกค้า แต่กลับไปด่าลูกค้าว่า "โง่" หรือ "บ้า" เนี่ย ก็ไม่ควรมาทำงานบริการแบบนี้นะครับ ความเห็นส่วนตัวนะครับ

ผมเชื่อว่าถ้าเราเคารพซี่งกันและกัน มันก็อยู่ร่วมกันได้ ทำงานร่วมกัน มีความสุขร่วมกันได้

ทั้งนี้ก่อนจากขออ้างอิงหนังสือ How Starbucks Saved My Life -- Michael Gates Gill นิดนึงละกัน

คริสตัลทำเสียงเหมือนครูกำลังโกรธจัด ก็ได้ ผมจะอ่านให้เธอฟัง เพราะตอนนี้ผมอ่านออกแล้วนี่ ผมจึงอ่านข้อแรก "กฎที่ไม่อาจประนีประนอมผ่อนปรนได้" ดัง ๆ ด้วยน้ำเสียงที่ทรงพลัง มีอำนาจและชัดเจนด้วยความมั่นใจ "เพื่อสร้างเสริมสภาพแวดล้อมการทำงานที่ดีเยี่ยมและปฎิบัติต่อกันด้วยความเคารพและให้เกียรติ"

คริสตัลยืนขึ้น แม้ผมจะอ่านกฎข้อแรกของสตาร์บัคส์ที่ไม่อาจประนีประนอมผ่อนปรนได้ด้วยความแข็งขัน แต่ก็ดูเหมือนว่าเธอกำลังหงุดหงิดอะไรสักอย่างอยู่ดี

"เคารพ" เธอเน้น ชี้นิ้วผ่านหน้าผมไปที่คำคำนั้น "ฉันไม่คิดว่ามันเป็นการแสดงความเคารพเมื่อใช้คำพูดข้างถนนอย่างนั้นในร้านแห่งนี้"

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

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

ปล. ผมโอเคนะ ถ้าพ่อผมจะพูดว่า "yed mang" ใส่ผม คือ ... เขามีสิทธิที่จะทำแบบนั้นอ่ะ (จริง ๆ นะ ไม่เชื่อลองหาความหมายของคำนี้ดูสิ) แต่ผมว่าอายุเขาเยอะแล้วคงไม่ทำหรอก อ้อ เขาพูดประจำ ๆ แหละ ไม่ว่ากับใครก็ตาม

จั่วหัวภาษาไทยให้งงเล่นอีกแล้ว วันนี้จะพูดถึงเรื่องของ Business Logic นะครับ

ความหมายของคำว่า Business Logic ก็คือ บรรดาลอจิกทั้งหลายที่เกี่ยวข้องกับการทำธุรกรรมต่าง ๆ ในระบบของเรา โดยคำนี้เรามักจะใช้กับโปรแกรมที่สร้างขึ้นมาสำหรับงานด้านธุรกิจต่าง ๆ เช่น พวกระบบจัดเก็บข้อมูลของธนาคาร ที่ใช้กันตามแบงค์นั่นล่ะครับ Business Logic นั้นก็จะรวมตั้งแต่ การตรวจสอบข้อมูล (Validation) การประมวลข้อมูลเพื่อประกอบการตัดสินใจ การสร้างค่าปริยาย (Default) และอื่น ๆ ที่เกี่ยวข้อง ทั้งนี้จะไม่เกี่ยวกับการแสดงผลข้อมูล และการจัดเก็บข้อมูลครับ

ถ้าเป็นใน Model-View-Controller (MVC) ส่วนของ Business Logic จะเป็นส่วนของ Controller ครับ

ในส่วนของ Business Logic เท่าที่ผมพอจะรู้นะ ในปัจจุบันจะมีส่วนประกอบหลัก ๆ ก็คือ Business Object กับ Business Process โดย Business Object ก็คือวัตถุที่เกี่ยวข้องกับการทำธุรกรรมต่าง ๆ เช่นวัตถุที่แทนข้อมูลบัญชีลูกค้า วัตถุที่เก็บข้อมูลการซื้อขาย เป็นต้น ส่วน Business Process นั้นหมายถึงการทำธุรกรรมต่าง ๆ เช่นการซื้อขาย การเรียกดูข้อมูลย้อนหลัง การเรียกดูและเปลี่ยนแปลงข้อมูลที่อยู่ลูกค้า เป็นต้น

คงมีคนสงสัย อ้าวไหนบอกว่ามันเป็นส่วนของ Controller ไง ไหง BO ถึงเป็นวัตถุเรียกเก็บข้อมูลขึ้นมาล่ะ คืองี้ครับ เจ้า Business Object เนี่ยมันจะมีส่วนของการตรวจสอบข้อมูล การประมวลผลข้อมูลประกอบการตัดสินใจ การสร้างค่าปริยาย อะไรทำนองนี้เอาไว้ด้วย เช่น สมมติว่าผมมี BO ชื่อว่า Entity

class Entity extends BusinessObject {
  final String accountNumber;
  String name;
  String lastname;
  int age;
  Date dateOfBirth;
  //..some other related fields
}

เวลาที่ผมเปลี่ยนค่าใน dateOfBirth จะต้องมีการเปลี่ยนค่าของ age ด้วย ถูกไหมครับ ?

void setDateOfBirth(Date date) {
  dateOfBirth = date;
  age = calculateAge(dateOfBirth);
}

ถ้าเรายกกระบวนการตรงนี้ไปไว้ใน Business Process เนี่ยจะเกิดการซ้ำซ้อน (redundant) เกิดขึ้นได้

ทั้งนี้เราอาจจะใช้การคำนวนอายุใหม่ทุกครั้งที่มีการเข้าถึงแทน อันนี้ก็แล้วแต่ความเหมาะสมครับ

จะว่าไปผมควรจะเขียนตัวอย่างของ Business Process ให้ดูสักหน่อยเนอะ ? สมมติว่าผมมี BP สำหรับการเรียกดูและปรับเปลี่ยนที่อยู่ของผู้ใช้นะครับ

class AddressMaintenanceProcess extends BusinessProcess {
  private final Entity entity;
  private ArrayList<Address> addressList;
  private int index = 0;
  AddressMaintenanceProcess(String entityId) throws DataNotFoundException {
    entity = Entity.searchForId(entityId);
    addressList = copyList(entity.getAddressList());
  }

  public String name { return entity.getName();}
  public String lastName { return entity.getLastName();}
  public String[] getAddressText { return addressList[currentIndex].getAddressText();}
  public String[] getValidPostalCodes { return addressList[currentIndex].getValidPostalCodes(); }

  public void setIndex(int index) { this.index = index;}
  public void getIndex() { return index }

  public void commitChanges() { 
    entity.setAddressList(addressList);
    entity.commitChanges(); 
  }
}

อะไรทำนองนี้

ในความเป็นจริง โค๊ดส่วนของ Business Logic นั้นจะถูกเขียนเพื่อให้ไม่เกิดการยึดติด (Code Cohesion) กับโค๊ดส่วนอื่น ๆ (เช่นส่วนของ UI) มากนัก เพราะเราอาจจะมีการยกเอา BL ไปใช้กับแอพลิเคชั่นหลาย ๆ ตัวที่ใช้ส่วนประกอบอื่น ๆ ที่แตกต่างกัน ซึ่งตรงนี้สามารถที่จะทำเป็นลักษณะของ Web Service ไปก็ได้ (ใช้โปรโตคอล HTTP ในการคุยกันระหว่างส่วนประกอบต่างๆ) หรือจะยังทำเป็นโค๊ดโปรแกรมธรรมดา แต่มีการออกแบบคลาสให้มีชุดฟังก์ชั่นมาตรฐานในแต่ละคลาสเพื่อให้สามารถแยกส่วนไปใช้กับโปรแกรมอื่นได้ง่ายก็ได้ครับ (อันนี้เป็นเรื่องของการออกแบบซึ่งก็ต้องศึกษาข้อดีข้อเสียกันเองนะ)

ตัวที่ผมทำงานด้วยประจำจะเป็นแบบการสร้างฟังก์ชั่นมาตรฐานที่ใช้การรับส่งค่าผ่าน key-value น่ะครับครับ (ผมเรียก key ว่า fieldId นะ) คือก็ประมาณว่าแต่ละ process และ business object จะมีมีฟังก์ชั่น getField กับ setField เพื่อที่จะใช้ในการรับส่งค่าระหว่างกัน อะไรทำนองนี้ครับ

ก็ขอจบเรื่องของ Business Logic เอาไว้แค่นี้ละกัน มีอะไรสงสัยก็ถามได้ครับผม