ให้ความสำคัญกับปัญหาที่กำลังแก้มากกว่าโค้ดที่ต้องเขียน
เรื่องนี้มาจาก Blog ใน medium อ่านดูแล้วน่าสนใจดีแล้วก็เปิดค้างอยู่ใน Safari มานานมาก เลยถือโอกาสมาสรุปอะไรเขียนใน medium ตัวเอง
อะไรคือเหตุผลของการมีอยู่ของซอฟท์แวร์
มี startup หนึ่งพัฒนาอุปกรณ์ที่ทำให้คนเปิดล็อกประตูบ้านโดยใช้ Bluetooth โดยมี Widget ที่จะเห็นตลอดเวลาแม้ว่าโทรศัพท์จะถูกล็อกอยู่ โดยจะมีปุ่มที่เขียนว่า “เปิดประตู” อยู่
โดยเมื่อผู้ใช้เดินเข้ามาที่บ้าน เขาจะเอาโทรศัพท์ออกมา เข้าไปที่ widget แล้วกดปิดเปิดประตู
ที่อ่านดูมันก็ดูเท่ดีนะ แล้วซอฟท์แวร์นี้มีขึ้นเพื่อแก้ปัญหาอะไรนะ? เพื่อเปิดประตูบ้านผ่าน bluetooth หรือเปล่า ?
อย่างไรก็ตามก็คนก็ให้ความเห็นเพิ่มเติมว่า
ถ้าเราจะใช้ Bluetooth แล้วจะให้ใครก็ได้เข้ามาที่บ้าน ทำไมต้องให้คนยกโทรศัพท์ขึ้นมากดปุ่มหล่ะ ก็ให้มันเช็คว่ามีคนเข้ามาในระยะ 1 เมตร จะได้ไม่ต้องเสียทั้งเวลาและเงินในการออกแบบและโค้ดตัว Widget นั้น
ในปัจจุบันปัญหาหนึ่งที่หลายฝ่ายเริ่มสังเกตเกี่ยวกับการพัฒนาซอฟท์แวร์คือ การแยกส่วนระหว่างส่วนของธุรกิจ กับส่วนของการพัฒนาซอฟท์แวร์ให้ออกจากกัน ซึ่งถ้าทำให้ทีมพัฒนาโฟกัสแค่เพียงการทำซอฟท์แวร์เท่านั้น แล้วอาจจะลืมในเหตุผลของการมีอยู่ของซอฟท์แวร์ไป ทั้งๆ ที่บางเรื่อง อาจจะสามารถแก้ไขปัญหาได้โดยไม่ต้องเขียนโค้ด
ซึ่งในกรณีนี้ เป็นตัวอย่างหนึ่งของการที่ทีมพัฒนาโฟกัสในเรื่องของการเขียนโค้ดมากกว่า การมีอยู่ของซอฟท์แวร์นี้คือ “เราต้องการให้ปลดล็อคประตูโดย ใช้ความพยายามน้อยๆ”
สิ่งที่ผู้เขียนแนะนำ คือ ต้องรู้ว่าธุรกิจกำลังจะแก้ปัญหาอะไร และมันมีคุณค่าต่อผู้ใช้ยังไง จากนั้นนำเอาข้อมูลเชิงลึกต่างๆ มาดูว่าจะใช้เทคโนโลยีอะไรในการแก้ปัญหา ซึ่งในบางครั้งอาจจะได้คำตอบว่าไม่ต้องเขียนเยอะก็ได้
Bugs
สัจธรรมเรื่องนึงที่ใครก็ตามที่เข้ามาในงานพัฒนาซอฟท์แวร์ จะเข้าใจคือ ภายใต้สถานการณ์จริง เราไม่สามารถแก้ไขบั๊กที่เกิดขึ้นในซอฟท์แวร์ได้หมด
แล้วบางสถานการณ์ ปัญหาบั๊กที่เกิดขึ้น สามารถแก้ไขจากกระบวนการทางธุรกิจทั่วไป ได้รวดเร็วและง่ายกว่าการไปแก้โค้ดซึ่งอาจจะใช้เวลานานกว่า
และบางครั้ง ระดับความรุนแรงของปัญหา(Severity) ก็ไม่จำเป็นต้องสอดคล้องกัล ลำดับความสำคัญของปัญหา(Priority) ก็ได้
ซึ่งทางผู้เขียนแนะนำให้วางของลงใน Priority Matrix แต่ใช้กลุ่มผู้ใช้ที่ได้รับผลกระทบ แทนที่แกนความถี่เหมือนทั่วไป
ซึ่งอันนี้ส่วนตัวคิดว่า เป็นอะไรที่น่าสนใจ แอบรู้สึกเหมือนจะใช้อยู่ แต่ก็คิดว่าก็ควรจะผสมกับความถี่ในการเกิดด้วย เพราะถ้ายิ่งเกิดบ่อย Cost ของการแก้ไขโดย operation จะเพิ่มขึ้น และอาจจะมากกว่า การแก้ไขโดยการแก้โค้ดก็ได้ ซึ่งตรงนั้นอาจจะส่งผลต่อความพึงพอใจได้
เรื่องสำคัญของส่วนนี้คือ การแก้ปัญหามีทั้งการแก้เชิง operation และการแก้โค้ด เลือกให้เหมาะสมกับสถานการณ์ อย่าไปโฟกัสด้านใดด้านหนึ่งเพียงอย่างเดียว
Automation Scripts
อันนี้เป็นปัญหาที่น่าสนใจ คือนักพัฒนาจะพยายามเขียน script เพื่อจัดการทุกอย่าง ซึ่งจริงๆ มันดูน่าจะเป็นอะไรที่ดี
แต่ทางผู้เขียนมองอีกมุมนึงคือ ถ้า Automate มากเกินไปจนซ่อนข้อมูลที่จำเป็นหมด ก็อาจจะเกิดปัญหาได้
There’s a difference between encapsulation of complex logic and abstract of useful knowledge
ยกตัวอย่างเช่น ถ้าเราต้องทำ script ในการ build ระบบทั้งหมด แล้วเกิดไว้ใน คำสั่งชื่อ a ทุกคนอาจจะสามารถทำงานได้ ในช่วงเวลาหนึ่ง แต่ถ้ามีการเปลี่ยนแปลงอาจจะเป็นโปรแกรมที่รัน หรือ OS อาจจะต้องเสียเวลาเข้าไปปรับปรุง ซึ่งสถานการณ์มักจะเลวร้ายมากถ้าคนเขียนสคริปท์ a ไม่อยู่แล้ว
เพราะสิ่งที่สำคัญที่สุดคือ เราได้ซ่อนสิ่งที่ทีมจำเป็นต้องรู้จริงๆ ไปอยู่ใน script
Features
ผู้เขียนเล่าว่าครั้งหนึ่ง ได้พัฒนาเกี่ยวกับเรื่องของ ระบบการตรวจสอบตัวตน โดยจะให้ผู้ใช้ส่งข้อมูลเข้ามาแล้วเขาจะทำการตรวจสอบผ่านระบบผู้ให้บริการหลายๆเจ้าอีกทีนึง
โดยในช่วยแรก ตั้งใจว่าจะมีฟีเจอร์การแสดงผลการตรวจสอบแต่ละข้อมูลแบบแฟนซี อย่างไรก็ตามเนื่องจากเวลาเริ่มกระชั้น ฟีเจอร์นี้ก็ถูกลดระดับความสำคัญลงเรื่อยๆ จนสุดท้ายทีมก็สรุปว่า จริงๆ ฟีเจอร์นี้มันไม่ควรจะมีตั้งแต่แรก…
ทั้งที่การตรวจสอบข้อมูลมีความสำคัญ แต่ทำไมมันถึงไม่จำเป็นต้องมี
เขาให้เหตุผลว่า
- เพื่อประโยชน์ของผู้ใช้เอง เขาจำเป็นต้องให้ข้อมูลที่ถูกต้อง
- ถ้าผู้ใช้ให้ข้อมูลผิด ก็เข้าระบบไม่ได้อยู่แล้ว
- Browser ต่างๆ ก็มีการ html input validation ซึ่งดีพออยู่แล้ว
- ในสถานการณ์ที่เลวร้ายที่สุด เขาจะโทรมาหาทีมงาน เพื่อตรวจสอบแบบ Manual
สรุปของบทความ
ถ้าทีมพัฒนาเข้าใจปัญหาที่จะแก้ จะสามารถได้ซอฟท์แวร์ที่โค้ดลดลง หรือในบางครั้งไม่ต้องโค้ดก็ได้
เราไม่ได้สร้างคุณค่าจากการเขียนโค้ด แต่สร้างคุณค่าจากการแก้ปัญหา
คุณและโค้ดของคุณเกิดมาเพื่อสร้างคุณค่าและทำให้โลกดีขึ้น ไม่ใช่เขียนเพื่อตอบสนองความต้องการของตัวเอง
มันเคยมีประโยคที่ว่า “ถ้าคุณมีแต่ค้อน คุณจะเห็นทุกอย่างเป็นตะปู” แต่สิ่งที่ควรจะเป็นคือ คุณควรจะเห็นตะปูก่อน คุณถึงจะสามารถเลือกค้อนมาใช้งานได้
อย่าให้การเขียนโค้ดเป็นเหมือน Silver Bullet ในการแก้ปัญหาทุกอย่าง
ส่งท้าย
เป็นบทความที่น่าสนใจบทความหนึ่ง จุดสำคัญคือส่วนตัวชอบคือ
เราต้องรู้ก่อนว่าปัญหาที่เราจะแก้ในภาพรวมคืออะไร แล้วใช้แนวทางแก้ปัญหาต่างๆ และมีการพัฒนาซอฟท์แวร์เป็นเครื่องมือตัวหนึ่ง ถ้าอันไหนไม่โค้ดแล้วดีกว่า สะดวกกว่า ก็ไม่โค้ด อันไหนโค้ดแล้วช่วยได้เยอะ ก็โค้ด สิ่งที่สำคัญคือต้องชั่งน้ำหนักให้เหมาะสมตามสถานการณ์นั้นๆ
ขอบคุณคุณ Fagner Brack สำหรับบทความดีๆ
ส่งท้ายด้วยบทสรุปง่ายๆ ของเขาครับ
Not every code is worth writing
Not every bug is worth fixing
Not every command is worth scripting
Not every feature is worth coding