บันทึกการเรียน Humanistic Software Architecture

ถ้าถามผม ตอนแรกที่มาเรียน ผมคิดเป็นภาพ Requirement เลย 5555 ปัญหกส่วนใหญ่มาจากคน และเข้าใจว่ามีอะไรสักอย่างที่มาสะท้อน Software Architecture เพราะหลายครั้งที่ทำงาน เรามีอิหยังวะ แต่ไม่รู้ว่ามัน เพราะอะไร มันแค่ไม่ใช่แหละ เลยลองสมัครดูรอบแรกแค่เต็มไปซะก่อน เลยเป็น Waiting List ของรอบ#02 ครับ หัวข้อก็มี ดังนี้ครับ

การเดินทาง

  • สำหรับงานนี้จัดที่ Geeky Base สมัยนี้เดินทางสะดวกสบายมาก ต่างกับตอนไป TDD เมื่อหลายปีก่อนเลย ต่อรถเมล์หลายต่ออยู่
  • เรียกว่ารอบนี้มาสะดวกมากครับ ออกจากบ้าน 6.35 ถึงที่ Geeky Base ตอน 8 โมงพอดีครับ นั่ง 515 มาลงอนุสาวรีย์ 20 บาท แล้ว BTS จากอนุสาวรีย์ > กรมป่าไม้ 35 บาท ทางออก 3
    //ดีที่ถามน้องที่ไป Workshop DDD สัปดาห์นี้มาก่อนไม่งั้นได้ไปลงอีกสถานี 555
  • เดินมานิดนึงครับ ซอยแรกของตึกเหลืองจะเจอเลยครับ

Day1

ก่อนเรียนให้มอง useful > correct นะครับ

เริ่มต้นด้วยอะไรที่มองว่าเป็น problem จะช่วยให้เราแยก หรือ Sense ได้นะ ว่า อะไรเป็น

  • Statement - ประโยคบอกเล่าทั่วไป ทั้งที่เป็น + หรือ - (disappointment) เช่น System cannot scale เป็น
  • ส่วน Problem ซึ่งต้องมี 3 ส่วนนะ
    - Current State (จุด A) - สภาวะปัจจุบัน
    - Desire State (จุด B) - สิ่งที่อยากจะเป็น / ต้องการ
    - gap - วิธีการจะไปเป้าหมาย มองว่าเป็น Solution ก็ได้
[1. Current State (A)] ---《 2.gap 》 --- [3.Desire State (B)]

ภาพในหัวผมไปตอนทำ Requirement ซึ่งเรียกในส่วนของ Desire State (to be) เป็นอะไรที่ต้องวัดได้

[1. As of] ---《 2.gap 》 --- [3. To Be]
As of: System cannot scale 
Gap: ไปหาหนทาง ซึ่งมีได้หลายทาง เช่น Rate Limit / ทำให้ App Scale ง่าย / แก้ไขจาก HW
To Be: System can handle 1m request/sec

จาก Statement เรามีลางสังหรณ์(Sense) มาเป็น Problem ได้นะ ที่นี้การตีความมันได้หลายแบบทั้งสิ่งที่ Improve หรือ Pain แทนนะ ต้องระวังด้วย ทำผิดทางไปเหนื่อย 555

หลังจากเรารู้นิยามของ Problem แล้ว มันเกี่ยวกับจิตวิทยายังไง ในศาสตร์ด้านนี้ 3 ส่วน

  1. Behaviorism (ปรับพฤติกรรมการเปิดใจคุยกัน)
  2. Psychoanalysis (สาย Data)
  3. Humanistic (Heal)

สำหรับใน Course นี้จะเป็น Humanistic โดยใช้ตัว Therapy Model - Satir (ตอนแรกผมเข้าใจว่าพี่เค้าคิดคำขึ้นมาเอง) เอาภาพของ Problem ตั้งใหม่

[1. Current State (A)] ---《 2.Coping 》 --- [3.Desire State (B)]


NOTE: Coping มันมีโอกาสปรับจาก disappointment มาเป็น problem จนกว่าเราจะถึงจุดที่ยอมรับ(Acceptance) กับมันได้ (Exit Case ได้รับ Yearning ที่ต้องการ)

[1. Current State A] ---《 2.Coping B 》 --- [3.Desire State C]
           [1. Current State B] ---《 2.Coping D 》 --- [3.Desire State E]
                     [1. Current State D] ---《 2.Coping F 》 --- [3.Desire State G] --ถ้า Acceptance 

ตัว Satir มันจะเอามาตอบว่าคนเรา แสดงการกระทำออกมา (Behavior) หรือ ปรับ Skill ด้านให้ดีขึ้น หรือลดมัน จาก Event ต่างๆที่เข้ามา Trigger ขึ้นมา เรียกมันขยายจะเดิมมี Cause > Effect ทำให้เราเห็นสิ่งที่มา Support อย่างเช่น พวก Yearning / feeling ที่เหลือจะอยู่ใน Satir Iceberg นะ

Satir Iceberg

ส่วนตัวผมชอบตัวอย่างนี้นะ

 <Cause>        <Effect> 
เราโดนต่อย จากนั้น เราต่อยตืน
มาเป็น
 <Cause>   <Satir Iceberg:feeling>  <Satir Iceberg:Yearning >     <Effect> 
เราโดนต่อย      เราเจ็บแค้นเคือง             win อยากเอาคืนเอาชนะ      จากนั้น เราต่อยตืน

จากนั้นลองไป Focus ที่ตัว Yearning (แปลไทย = ความปรารถนา/แรงปรารถนา โดยเจ้าตัว Yearning มันเป็น universal language) โดยถ้าเราเอาตัว Satir มาลองวิเคราะห์จากเรื่องทั่วๆไป เช่น การตัดสินใจในด้าน IT ในหลายเรื่อง ถ้าลองวิเคราะห์ก็จะพบว่ามี Yearning ซ่อนไว้จาก disappointment ที่แสดงออกมา จนเรานำไปสู่การจัดเป็น Problem นั้นเอง จากเรื่อง System cannot scale ถ้าเราตีความ Yearning ซ่อนไว้จาก disappointment ไม่ออกมันจะได้ หลาย 2 solution ดังนี้

  • มองว่าอยาก Control มัน
[1. Current State (A)] ---《 2.Solution》 --- [3.Desire State (B)]
System cannot scale -------Rate Limit-------> System can handle 1m request/sec
  • มองว่าอยากให้ Efficient เพิ่ม
[1. Current State (A)] ---《 2.Solution》 --- [3.Desire State (B)]
System cannot scale -------Re-architect-------> System can handle 1m request/sec

มันจะอารมณ์แบบตอนเรารับเคสจากลูกค้า แล้วบางทีเราแก้ไม่ตรงจุดลูกค้ากินหัว แต่ถ้าแก้ได้ตรงจุดจะลดจัดการ disappointment ของลูกค้าได้ แก้ได้ตรง Yearning ลูกค้า

ต่อมาจะเป็นในส่วนของการรู้จักตัวเราเอง ผ่านตัว Three Centers of Intelligence มี 3 ส่วน

  • The Head Center (Thinking) - จากความกลัว กังวล (แม้ยังไม่เกิด) หาเหตุ และผล
  • The Heart Center (Feeling) - จากพลังใจ ไม่อยากอับอาย ทำให้เกิดเป้าหมาย
  • The Body Center (Moving) - ซ้อม / จดจำ สาย Dev อาจจะเริ่มจาก Tutorial ไปลองมันเลย

ซึ่งทุกคนมีทั้ง 3 มุมเลย ปกติเราจะได้อยู่แต่มุมเดียว จึงควรนำมาใช้บ่อยๆ และลับให้คม สุดท้ายจากทั้ง 3 มุม และใน Course มีให้ลองทำ Meditation ให้รู้จักกับตัวเอง (จริงๆตั้งแต่จบมัธยมมาไม่ได้เคยได้มาทำเลย)

วนกลับด้าน IT เรื่องเดียวกัน ถ้าให้คน Head /Heart /Body เข้ามา Address มันจะเป็นยังไงนะ ?

สำหรับวันนี้เรียกว่ามาเรียน มาฟัง เพื่อเข้าใจตัวเราเอง หรือมองลึกขึ้นว่า Behavior ที่ออกมา มันมีมาจากอะไรบ้าง

เราต้องเข้าใจ Yearning ตัวเอง เพื่อที่จะเข้าใจ Yearning ของคนอื่น

และคำได้ยินบ่อย Yearning / Congruence (ตอนแรกผมคิดว่าเป็นอีกคำ Confluent มาฟังวันที่ 2 แล้วอ๋ออ)

Day2

เริ่มด้วย Recap จากเรื่องในวันแรกก่อน และปิดท้าย Three Centers of Intelligence ให้เราคุยกับตัวเองมุมมอง 3 ด้าน Head / Heart / Body มาเริ่มกิจกรรมลองเอา Three Centers of Intelligence ดูว่านำเสนอ Design ยังไง เพื่อให้ตอบคนกลุ่ม Head / Heart / Body มา Buy Idea ของเรา

ช่วงบ่ายพอมีเครื่องมือครบและ มาลองทำให้ Design มัน Congruence อ๋อพวก Design มันไม่ได้คำตอบเป๊ะๆ 100% แต่จะเป็น optimization โดยเริ่มจาก

  1. Map Statement(disappointment) อยู่ในรูปของ Problem (A=>B)
  2. Empathized (คำนี้จะได้ยินทั้งวันเลย) กับตัว Coping Stance
  3. เอาตัว Three Centers of Intelligence มาหา Why (คุยกับตัวเองทั้ง 3 มุม)
  4. ดูมัน Design มัน Congruence ไหม Three Centers / Yearning ไปในแนวทางที่สอดคล้องกัน
    - Congruence ทั้ง Head / Heart / Body (เอาเสียงส่วนใหญ่ ปกติมันจะไม่ 100%) ไปในทางเดียวกัน Yearning
    - Incongruence ตรงข้ามกันครับ

จากนั้นลงลึกใน case study อย่างตัว Microservice ซึ่งเป็นเรียกว่าหักมุมไหม มันมาในแนวทางเดียวกันตลอดเลยนะ แต่จุดลง Design ดันทำให้เอ๊ะ ผมชอบในมุมของการถกเถียงให้ Class นะ มันทำให้เห็นการมอง Design เดียวกันในคนละมุม Yearning ต่างกัน และมาจูนให้เข้าด้วยกัน //ถ้ามันเอ๊ะได้จากกระดาษที่คุยกันมันจะดีมาก

สุดท้ายตบในเรื่องของ Abstraction เริ่มจาก Yearning ว่าเราอยากให้ Abstraction ขึ้นไป เพื่ออะไรนะ แต่ละมุมมองแต่ละอันมันส่งผลยังไงนะ และแนะนำมุม Successful (อิงจาก Yearning) ทำให้ได้ลองคิด Code เมื่อหลายปีก่อนทำไม ถึงทำแบบนี้นะ มันอาจจะมีเหตุผลในตอนนั้นที่รองรับ แต่ปัจจุบันมันขัดใจเราอยู่ แต่ลองคิดในมุม Successful ปรับไปแล้วจะเป็นยังไงนะ Code ตรงนี้มีคนมายุ่งเยอะไหม / มีเวลาปรับไหม / ปรับแล้วเพิ่ม Load ทีม หรือป่าว ? / หรือ ปรับแล้วมันช่วยแก้ Incident ที่มักมาโผลตรงนี้บ่อยๆ
จากนั้นลองดู Detail 2 ส่วนได้แก่

  • Conceptual Abstraction - Common บางอย่างที่เราพยายามทำให้มัน Abstraction Case ที่ผมชอบ เรื่อง Mail Template อยากให้ Code มัน DRY แต่ทำไม มันเริ่มยากขึ้น และซับซ้อนแทน แล้วมันเคสที่ตัวเองเคยเจอจริงๆ ทำไป ทำไม แล้วต้องมาแก้ Test เดิมบ่อย แล้วที่แก้ไปมันเริ่มจะ Complex ขึ้น ทั้งที่จริงๆ เราสามารถนำ
    - Real World Concept มาใช้
    - ถ้ามันใหม่จริง เตรียม Environment ให้มันพร้อมพวก doc ต่างๆ
    - และอย่าลืมดูว่ามันแก้งาน อ่านง่าย ไม่ใช่สำหรับเรานะ แต่ต้องคนอื่นๆ ที่เข้ามาดูต่อด้วย
  • Structural abstraction - จัดว่าอะไรควรอยู่ที่ไหน ปกติมันมีที่เค้าคิดว่าระดับนึงแล้ว อย่าง MVC / Clean Architecture เป็นต้น ผมอาจจะเข้าใจผิดนะพยายามหา Boundary แล้ววนขมวดไปตาม Domain เช่น Code ชุดนี้ควรจะอยู่ในจุดไหน จนถึงจุดที่เรายอมรับได้

Warp-Up ได้ฟังมุมมองใหม่ๆทั้งจากพี่คริส ผู้สอน และเพื่อนๆในห้อง มันจะเป็นบรรยากาศที่ต้อง On-Site ถ้าออนไลน์ มันจะดูแปลกๆ วันที่สองใช้คิดสมองเยอะมาก จะสสับสับสน Useful กับ Correct หลังๆเริ่มมาจูนได้และ ส่วนวันแรกเหมือนทำความรู้จักกับตัวเองมากขึ้น นอกจากเรื่อง Architecture Design มันปรับไปใช้กับชีวิตเราได้ อย่างที่ผมบ่นๆใน FB ช่วงนี้ ต้องลองมาติดลองกลับมาฉุกคิดอีกทีเหมือนกันครับ

Blog ของท่านอื่นๆ

Reference


Discover more from naiwaen@DebuggingSoft

Subscribe to get the latest posts sent to your email.