ทำไมเราถึงเลือกใช้ Scala

“แชมป์ คุณลองดูสิ ในแต่ละ Domain ของธุรกิจ มีภาษาเฉพาะ

หมอก็จะมีศัพท์ของหมอ เวลาใช้คุยกันในวงหมอ

นักบัญชีก็จะมีศัพท์ของนักบัญชี เวลาใช้คุยกันในวงนักบัญชี

ซึ่งศัพท์พวกนี้ มันย่อความ และเข้าใจกันเฉพาะในวงนั้นๆ

มันทำให้การสื่อสารสั่นลง และง่ายขึ้น…”

ประโยคนี้ของเจ้านายเก่าอยู่ในหัวผมตลอด 10 ปีที่ผ่านมา…

.

“แชมป์ คุณลองดูสิ ระบบแต่ละระบบย่อมมีวิธีแลกเปลี่ยนข้อมูลระหว่างกัน

ด้วยภาษาที่มีเฉพาะระบบนั้นๆ คุณลองคิดดูว่า

ภาษาของการโอนเงินก็เป็นการโอนเงิน

ภาษาของการกู้เงิน ก็เป็นการกู้เงิน

ซึ่งเวลาระบบจะสื่อสารกัน ก็ใช้ภาษาพวกนี้

แล้วใครที่ฟังแล้วเข้าใจ ก็เอาไปทำตามแค่นั้นแหละ…”

นี่ก็อีกประโยคที่ผ่านมา 10ปี ก่อนที่เราจะมี microservices

และก่อนที่เราจะมี json ซะอีก

.

จำได้ว่า 2 ประโยคนี้ เจ้านายเก่าพูดตอนที่พวกเราอยู่ที่แบงค์

ตอนนั้นผมก็ยังเป็นเด็กจบใหม่ไฟแรงสูงอยู่

และตอนนั้น แบงค์เรากำลังเริ่ม explore SOA ว่าเหมาะไม่เหมาะในการ implement

.

“ผมว่า ESB มันตลกจะตาย มันเอาทุกอย่างมารวมศูนย์ไว้ แล้วมันจะ Scale ยังไง”

“แทนที่ ESB มันจะทำงานเร็ว มันดันมี features อะไรก็ไม่รู้เยอะแยะ จนมันทำงานช้า

Message ระหว่างระบบต้องทำงานเร็วสิ”

ก็เป็นอีกสองประโยคที่เราได้ระหว่าง explore เรื่อง SOA ให้แบงค์ เมื่อ 10 ปีก่อน

.

จนถึงวันนี้ ผมก็กลับไปคุยกับเจ้านายเก่าอีกครั้ง

ตามภาษาหลานชายและคุณอา ที่บ้าเรื่องเทคโนโลยีเหมือนกัน

ผมเอาแผนภาพ microservices ที่ design ที่ Billme ให้แกดู

แล้วก็บอกแกไปว่า desgin นี้ inspired มาจากคำพูดของแกเมื่อ 10 ปีก่อน

แกก็ตอบกลับมาสั้นๆว่า

“โปรแกรมเมอร์คุณต้องเก่งมาก และต้องมีวินัยมาก

ถึงจะทำ Architecture ที่อิสระต่อกันแบบนี้ได้”

“ประโยคพวกนั้น ที่ผมเล่าให้คุณฟัง

ผมเอามาจากตอนผมทำ expert system สมัยก่อนโน้น”

และก็นี่แหละครับ inspired หลักในการออกแบบ Architecture ของผม

.

นอกจากนั้น ก็คงมีภาพเรือ Titanic ของ Jonas Boner

ที่เป็นอีก inspiration ในการออกแบบ Architecture

.

พร่ำมาตั้งนาน เข้าเรื่องซักที

จริงๆ Blog นี้ก็จะมาเล่า ว่าทำไม Billme ถึงเลือกใช้ภาษา Scala

ถ้าใครเข้าใจ aim ของภาษา และพอเดาประโยคด้านบนที่เปิด Blog ได้

คงแทบไม่ต้องอ่าน Blog ที่เหลือตรงนี้ หรืออ่านแค่เอาบันเทิงก็พอ

.

แน่นอนครับ aim ของ Scala คือการสร้าง

“A LANGUAGE THAT GROWS ON YOU”

(คำนี้อยู่ใน บทที่ 1 ของ Programming in Scala

ที่เขียนโดย Martin Odersky)

ซึ่งมันก็อธิบายว่า Scala เป็นภาษาที่โตได้ด้วยคุณ

ก็แปลว่ายิ่งคุณสร้างรูปแบบการเขียนใหม่ๆเข้าไปเท่าไหร่

ภาษาก็จะโตและขยายออกไปตามสิ่งที่คุณสร้าง

แน่นอนว่า Scala เตรียมเครื่องมือ

สำหรับสร้างรูปแบบการเขียนไว้ให้คุณอยู่แล้ว และรูปแบบการเขียนนั้นๆ

ก็จะดูเหมือนมัน Support จาก Native ของ Scala

ซึ่งทำให้เรา define ภาษาใหม่ที่โตมาจากภาษาเดิมได้

ด้วยรูปแบบการเขียนใหม่ๆ

.

แล้วถ้าเราสร้างภาษาได้ มันจะดียังไง???

.

ถ้าใครเคยอ่าน Blog ของ Billme มาบ้างแล้ว

จะคุ้นกับภาพนี้อยู่บ้าง

แต่ถ้ายังไม่คุ้น ผมจะใบ้ให้ด้วยภาพนี้เพิ่ม…

พอใส่ description สีน้ำเงินเข้าไป

ทุกคนเริ่มเข้าใจธุรกิจที่ Billme ทำมากขึ้นจากภาพแรกถูกมั้ยครับ

ดังนั้นภาพด้านบนนี่ เราเรียก Business Architecture ครับ

.

ซึ่งนิยามของ Business Architecture ง่ายๆก็คือ

ดูแล้วเข้าใจว่า เราทำธุรกิจอะไร มีองค์ประกอบอะไรในธุรกิจบ้าง

.

และพอเราเข้าใจองค์ประกอบในธุรกิจ

เราก็สามารถอธิบายศัพท์ที่ใช้ในส่วนย่อยๆของกระบวนการนั้นๆได้

ผมจะยกตัวอย่างให้ดูนะครับ

จะเห็นได้ว่า Code Structure ที่เป็นโครงสร้างของ Projects

ใน Core Services และ Business Services จะดูต่างกัน

เพราะวิธีการทำงานของ Core กับ Business นั้นต่างกัน

Business มุ่งเน้นแค่ CRUD เพื่อให้เกิด What You Do is What You Get

ส่วน Core นั้น มุ่งเน้นการสร้างอะไรซักอย่างเช่น PDF ให้ได้ในเวลาต้องการ

.

เมื่อเราสามารถ แยก Code Structure ที่ต่างกัน

ตามประเภทของ Projects ซึ่งอิงตาม Business Architecture ได้แล้ว

เราก็สามารถใช้ Scala เริ่มสร้าง Structure ใหม่ๆ

เพื่อ wrap Low-Level Code เดิมๆ ที่ต้องเขียนซ้ำกัน

ให้ย่นย่อ Code Structure เดิมของเรา และเขียนได้ง่ายและเร็วขึ้น

โดยที่ยังทำงานเท่าเขียน Low-Level Code เดิมๆ

.

เพราะแน่นอนว่าในแต่ละ Layer ของ Business Architecture ไม่ได้มี Services เดียว

ซึ่งการจะเพิ่ม Services ที่ 2, 3, … และปรับแก้ Services เดิมๆ

ก็จะปรับเปลี่ยนได้เร็ว บน Structure ใหม่ๆ ที่ wrap Low-Level Code เดิมๆไปแล้ว

และทำให้การเปลี่ยนแปลงให้ทันกับจังหว่ะของธุรกิจนั้น เร็วขึ้นด้วย

.

แต่ก็แน่นอนครับ Scala ไม่ใช่ Silver Bullet และไม่ได้เหมาะกับทุกงาน

แต่ถ้ามองว่า ชื่อตัวแปร คือก้อนอิฐแต่ละก้อนใน Software Architecture

แล้วภาษา Scala ก็เพิ่มพลังให้เรา “นิยามก้อนอิฐของเราเองได้”

แต่ก็ใช่ว่าอิฐทุกก้อน จำเป็นต้องถูกนิามขึ้นมาใหม่

.

สวัสดีครับ

.