function ทางคอมพิวเตอร์คือโปรแกรมที่รับ input แปลงออกไปเป็น output ซึ่งมันก็ควรจะตรงไปตรงมาตามนั้น
แต่ตอนเขียนจริง ๆ มันมี function แบบที่ไปแก้ input ก็มี, function แบบที่ว่า input ก็เหมือนเดิมแต่เรียกสองทีสามทีแล้วผลออกมาไม่เหมือนกัน; ถ้ามีอาการแบบที่ว่าก็น่าจะ test ยากทั้ง manual ทั้ง auto; แก้ยาก; แบ่งงานไปรันหลาย ๆ core ยาก
ใน Grokking Simplicity เขาแยก Calculation กับ Action, Calculation เช่น sum ส่วน Action เช่น sendEmail อันนี้จะเห็นได้ว่าถ้าเรียก 10 ครั้งซ้ำ ๆ โดนด่าแน่นอน
code ส่วน calculation กับ action ควรจะถูกจับแยกกัน อันนี้เป็นประเด็นที่สองที่ผมจับได้จาก grokking simplicity ในบทที่ 4
ถ้าไม่แยกส่วนที่ไป update หน้าเว็บผ่าน dom กับส่วนคำนวณ cart total ก็กลายเป็นว่าจะ test ว่าคำนวณถูกหรือเปล่า อย่างน้อยก็ต้องเปิด web browser ก่อน แล้วไปแกะผลมาจากหน้าเว็บ แต่พอแยก calculation ออกมาก็ test แยกเป็น function เดี่ยว ๆ เว็บไม่เกี่ยวได้เลย
บทที่ 5 ข้อแรกคือบอกว่า action ก็ควรใส่ argument ให้ชัดเจนอยู่ดี เช่น
update_shipping_icons()
ก็เใส่ไปเลยว่า
update_shipping_icons(cart)
อันนี้ให้นึกภาพว่าทำเว็บ Lazada นะครับ แล้วต้องเอา cart ไปคำนวณว่าส่งฟรีหรือเปล่า ถ้าฟรีก็ต้องเปลี่ยน icon
ถ้าไม่ใส่ให้ชัดเจน ก็เหมือนเดิมจะ test ยาก เอา calculation ที่ทำไว้บนที่ 4 มาต่อก็ยากอีก
ข้อสองคือให้แบ่งออกเป็น function บ่อย ถ้าแบ่งให้ function นึงมีหน้าที่เดียวได้ก็จะดี
บทที่ 6 programming language ส่วนมากจะใช้การแก้ค่า ใน array ใน collection หรือใน object ก็ตาม
แต่ functional programming เป็นแนวที่ไม่อยากแก้ค่าเดิม เพราะผมพูดเองเลยว่าการแก้ค่านี่ล่ะที่ทำให้โปรแกรมบึ้ม
แต่ถึงใช้ภาษาที่เน้นแก้ค่า เปลี่ยนแปลง object array collection ต่าง ๆ ก็มีท่าแก้อยู่ดีคือ copy-on-write ซึ่งเขายกตัวอย่างว่า setQuantityByName แทนที่จะไปแก้ object ตรง ๆ ก็ไป copy object มาก่อนแล้ว ก็แก้ object ตัวที่ copy มาใหม่ แล้ว return object นั้น
บทที่ 7 ถ้ามี function เก่า หรือ function ที่คนอื่นเขียน แล้ว function อาจจะแก้ค่าอะไรหรือเปล่าก็ไม่รู้ เท่าที่อ่านคร่าว ๆ คือเขาก็แก้ด้วยการ copy นี่ล่ะ
บทที่ 8 ละเอียดละออมากแต่สรุป ๆ คือทำโปรแกรมให้เป็น layer
function ในแต่ละชั้นให้ดีก็ไม่ควรไปเรียกข้ามชั้นเยอะ เช่น ในชั้น basic cart operations ก็ไม่ควรข้ามไปใช้ for loop ไปทำ indexOfItem() มาขั้นในชั้น copy-on-write ดีกว่า
บทที่ 9 พูดถึง pattern ที่ function ไม่ควรเรียกกันทะลุ layer คือ function layer บน 3 ก็ควรมาเรียกแค่ layer 2 ไม่ใช่ล้วงเรียก layer 1 เอง
อีก pattern คือถ้าไม่จำเป็นก็อย่างเอา function ไปใส่ layer ล่าง ๆ เยอะ
patten สุดท้ายคือใส่ layer เข้ามาแล้ว ทุกคนควรจะรู้สึกว่าทำงานสะดวกสบายขึ้น
ทั้งหมดนี้ในภาคปฏิบัติสำหรับ front-end ทำให้ผมนึกถึง re-frame; ผมมองว่า re-frame ของวาง layer พวกนี้มาให้แล้ว ถ้าเป็นสายปฏิบัติก่อนอ่านทีหลัง ก็อาจจะลองเขียนอะไรด้วย re-frame ดูสักชิ้นก็ได้
บาที่ 10-14 พูดถึง tool ใน functional programming ต่าง ๆ ตั้งแต่ higher function; เรื่อง map, filter; เรื่องการเอาพวกนี้มาต่อ ๆ กันเป็น chain และแก้ไขข้อมูลที่มันซ้อน ๆ กันด้วย update
บาที่ 15-17 เป็นเรื่อง concurency ทั้งวิธีวิเคราะห์ แยกจากกันว่า function ไหนต้องทำเป็นลำดับหรือไม วิธี share resource กันระหว่าง timeline ใน functional programming lanauge มีเครื่องมือช่วย เช่น atom ใน Clojure; ของ Erlang/Elixir ก็ใช้อีกอย่าง; สุดท้ายคือการทำให้แต่ละ timeline มันประสานงานกันบางทีอาจจะต้องมีหยุดรออีก timeline
บาที่ 18 เป็นเรื่อง onion architecture ที่นอกจากจะแบ่งระบบแบบเดิม ก็แบ่งตาม layer ที่เรียนมาบทแรก ๆ ด้วย
บนที่ 19 บทสุดท้ายเป็นเรื่อง functional programming language ต่าง ๆ ที่พอจะเอามาใช้ได้
ซึ่งไปซื้อได้ที่ https://www.manning.com/books/grokking-simplicity