บทความ IT เจ๋งๆ

ดูเหมือน Programmer ส่วนหนึ่งจะลืมวัตถุประสงค์ที่แท้จริงของ Software ที่พวกเขาสร้างขึ้น ซึ่งก็คือ การแก้ปัญหาในโลกของความเป็นจริง เรามาดูกันว่าเหตุใด ปัญหาที่คุณแก้ไข ถึงสำคัญกว่า Code ที่คุณเขียน มาหาคำตอบจากบทความของคุณ Fagner Brack กัน

เมื่อ 50 ปีที่แล้วในปี 2511 ได้มีการประชุมคณะทำงานด้าน Software Engineer ซึ่งได้รับการสนับสนุนจาก NATO Science Committee โดยในเวลานั้นผู้คนเริ่มสังเกตว่า Software ได้กลายเป็นส่วนสำคัญของสังคม แต่ก็ยังยากที่จะเข้าใจอยู่ หลังจากการประชุมครั้งนั้น Programming เริ่มกลายเป็นอุตสาหกรรม มันเริ่มหลุดจากการควบคุมของนักธุรกิจ

ทั้งๆ ที่ เส้นทางของ Programming จะดำเนินการตั้งแต่นั้นเป็นต้นมา แต่ก็ยังคงมีปัญหาเกี่ยวกับการแยกธุรกิจ กับ การพัฒนาSoftware หรือ Engineer ตามที่ ที่ประชุมเรียกกันเป็นครั้งแรก หาก Developer มุ่งเน้นที่การพัฒนที่น้อยเกินไป พวกเขาก็อาจพลาดจุดประสงค์ที่ซ่อนอยู่เบื้องหลัง Software ที่พวกเขาเขียน พวกเขาอาจไม่เห็น Solution ที่ซ่อนอยู่ซึ่งไม่ต้องใช้ Code ใดๆ

ลองมาดูตัวอย่างนี้กัน:

มี Startup ที่สร้าง Device ซึ่งช่วยให้ผู้ใช้งานสามารถปลดล็อกประตูบ้านของตนเองได้ โดยใช้ Bluetooth ซึ่ง Visual Interface ที่ใช้ในการสื่อสารกับ Device ก็คือ Widget ซึ่งสามารถมองเห็นได้แม้ในขณะที่โทรศัพท์ถูกล็อคอยู่ และมีปุ่มเพียงปุ่มเดียวที่ชื่อ "Open the door" เมื่อผู้ใช้งานเข้ามาใกล้บริเวณบ้าน พวกเขาเพียงคว้าโทรศัพท์ขึ้นมาเพื่อหา Widget แล้วคลิกปุ่ม เพื่อทำการเปิดประตู

มีบางคนที่มองเห็น Workflow ดังกล่าว แล้วตั้งคำถามขึ้นมา:

ถ้าเรากำลังใช้ Bluetooth และ Business Model ของเราก็ยอมรับให้ใครก็ตามที่มีโทรศัพท์สามารถเข้าบ้านได้ แล้วทำไมเราต้องให้คนเหล่านั้นหยิบโทรศัพท์ขึ้นมาแล้วกดปุ่ม? ทำไมไม่อนุญาตให้ปลดล็อกประตู เมื่อมีการตรวจพบ Device ภายในระยะ 1 เมตร ซึ่งวิธีนี้ ทำให้เราไม่จำเป็นต้องเสียค่าใช้จ่ายในการออกแบบและเขียน Code สำหรับ Visual Interface

เรื่องของ Bluetooth เป็นตัวอย่างที่ดีในการ Focus ให้แคบลง: เป้าหมาย ก็คือ การปลดล็อกประตูบ้านด้วยการใช้ความพยายามเพียงเล็กน้อย มันไม่มีเหตุผลเลยที่จะออกแบบ Visual Interface  ในขณะที่ Sensor เป็นแบบ Wireless

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

นี่เป็นตัวอย่างที่ดีเยี่ยมสำหรับวิธีการในการแก้ปัญหา Programming โดยไม่ต้องเขียน Code เพิ่มเติมนอกเหนือจาก Code สำหรับ Function สำหรับปลดล็อกประตู อย่างไรก็ตามเช่นเดียวกับ Technical Debt ไม่มีอะไรที่ควรใช้เป็นข้ออ้างในการเขียน Code ที่ไร้ประโยชน์ในส่วนที่เหลือ ดังนั้น ไม่ใช่ทุกเรื่องที่คุ้มค่ามากพอจะเขียน Code

ในบางครั้ง การแก้ Bug ก็อาจไม่ใช่เรื่องที่สำคัญที่สุด หากคุณเป็น Crypto Exchange และระบบของคุณก็อนุญาตให้เกิดการฝากเงินที่ซ้ำกันขึ้นได้ การแทรกแซงของมนุษย์อาจเป็นทางออกที่เหมาะที่สุด ถ้าต้นทุนในการแก้ไขปัญหานั้น มีราคาแพงเกินไป

พอพูดถึงการที่ต้องเลือกระหว่าง ระดับความร้ายแรงและลำดับความสำคัญ ก็ทำให้ Fagner นึกถึง Model หนึ่งที่เพื่อนร่วมงานแสดงให้ดู มันถูกเรียกว่า Priority Matrix ซึ่งเป็นแบบจำลอง 2 มิติ ที่สามารถใช้จัดลำดับความสำคัญของ Bug โดยพิจารณาจากจำนวน User ที่ได้รับผลกระทบ กับ ความร้ายแรง

ปัญหาการฝากเงินที่ซ้ำกันครั้งเดียว ที่อธิบายไว้ก่อนหน้านี้ อยู่ในหมวดความไม่สะดวก (inconvenience) ที่มีผลต่อผู้ใช้ 1 ราย ดังนั้น ลำดับความสำคัญ (priority) จึงอยู่ที่ 3 ดังนั้น ไม่ใช่ Bug ทุกตัว ที่คุ้มค่ามากพอที่จะแก้ไข

เป็นเรื่องปกติที่ Developer พยายามเขียน Scripts ไว้สำหรับทุกอย่าง อย่างไรก็ตาม งานที่ทำซ้ำได้บางอย่างอาจไม่คุ้มค่าและไม่เหมาะที่จะทำงานแบบอัตโนมัติ คุณไม่จำเป็นต้องใช้เวลาในการเขียน Code สำหรับ Script หากคุณต้องการปกปิดความรู้ที่จำเป็นของวิธีการทำงานของคำสั่งที่สำคัญ

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

มันจะมีประโยชน์มาก ในการใช้ low-level commands บางประเภทใน CLI แทนที่จะใช้ high-level command ซึ่งเป็น abstracts knowledge อย่างเช่น Git aliases ดังนั้น ไม่ใช่ทุกคำสั่ง ที่คุ้มค่ามากพอจะเขียน Script

หลายปีมาแล้ว Fagner ได้ทำงานใน Project ที่ใช้ Incremental Delivery มันเป็นระบบการยืนยันตัวตน (Identity Verification System) ที่จะขอให้ User ส่งข้อมูลส่วนตัวบางอย่าง ที่จะได้รับการยืนยันโดย Third-Party Provider

มันมี Feature ที่ใช้ในการ Validate Field ที่ทีมงานต้องการจะสร้าง อย่างไรก็ตาม ในเรื่องการ Validation มักจะถูกลดลำดับความสำคัญลงในช่วงการวางแผน Sprint (Sprint Planning) อยู่บ่อยๆ โดยเฉพาะอย่างยิ่งเมื่อช่วง Deadline ของงานกำลังใกล้เข้ามา และในท้ายที่สุด ทีมงานก็มักจะคิดว่า ไม่มีเหตุผลใดที่จะจัดให้การ Validation มีความสำคัญอยู่ลดำดับแรกๆ ซึ่งสิ่งนี้นำไปสู่เหตุผลที่ว่า: การ Verify ข้อมูล ถือเป็นสิ่งจำเป็น

มันเป็นเรื่องคสามสนใจของ User ที่จะกรอกข้อมูลที่ตรงตามจริง หากพวกเขาไม่กรอกข้อมูลตามจริง พวกเขาก็จะไม่ไดรับการยืนยันและไม่สามารถเข้าใช้งานระบบได้  แถม Browser ส่วนใหญ่ก็ยัง Support การตรวจสอบ HTML ที่มีมาตรฐานดีเพียงพออีกด้วย

ในกรณีที่แย่สุด คือสำหรับ User ที่ไม่ได้ Verify ข้อมูลตนเอง จะมีฝ่าย Support ที่โทร.ไปสอบถามข้อมูลโดยตรงเพื่อเป็นการ Verify ข้อมูลที่ถูกต้อง ดังนั้น ไม่ใช่ทุก Feature ที่คุ้มค่ามากพอจะเขียน Code

ในฐานะของ Developer ถ้าคุณเข้าใจปัญหาที่คุณต้องการแก้ไขอย่างแท้จริง คุณจะสามารถเขียน Code ที่มีประสิทธิภาพกว่า หรือบางครั้งก็ไม่ต้องเขียน Code เลยด้วยซ้ำ คุณไม่ใช่แค่คนที่สักแต่พิมพ์ตัวอักษรบนหน้าจอไปวันๆ แต่คุณเป็นมืออาชีพที่บริษัทจ้างมาเพื่อให้ช่วยแก้ไขปัญหาต่างหาก

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

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

ที่มา:  https://levelup.gitconnected.com/

รับตำแหน่งงานไอทีใหม่ๆ ด้วยบริการ IT Job Alert

อัพเดทบทความจากคนวงในสายไอทีทาง LINE ก่อนใคร
อย่าลืมแอดไลน์ @techstarth เป็นเพื่อนนะคะ

บทความที่เกี่ยวข้อง

• 8 เหตุผลหลัก ว่าทำไมควรเรียนรู้ภาษา C#
• Recursion ไม่ใช่เรื่องยาก พร้อมตัวอย่างการใช้งานหลายรูปแบบ
• 4 เคล็ดลับ ช่วยทำให้ Security Incident Response ของคุณดีขึ้น