แนวคิดการเขียนโปรแกรมแบบคลาสสิก: บทเรียนที่เรายังได้เรียนรู้จาก Kernighan & Pike

“ปัญหาที่แท้จริงคือ โปรแกรมเมอร์ใช้เวลามากเกินไปกับการกังวลเรื่องประสิทธิภาพในจุดที่ไม่สำคัญ”
— Brian Kernighan

โลกของการเขียนโปรแกรมสมัยใหม่พูดถึงเฟรมเวิร์ก สถาปัตยกรรม และเครื่องมืออยู่ตลอดเวลา
แต่การเขียนโปรแกรมแบบคลาสสิกพูดถึง ความชัดเจน ความเรียบง่าย และการคิดอย่างเป็นระบบ

Brian Kernighan และ Rob Pike—ผู้เขียน The Practice of Programming—เป็นตัวแทนของแนวคิดที่มองว่า การเขียนโปรแกรมไม่ใช่การพิมพ์โค้ดให้เร็วที่สุด แต่คือการ แก้ปัญหาให้ชัดเจนและเข้าใจได้

บทความนี้จะอธิบายว่า “การคิดแบบคลาสสิกในการเขียนโปรแกรม” คืออะไร ทำไมยังสำคัญในปัจจุบัน และเราจะนำไปใช้กับระบบซอฟต์แวร์ยุคใหม่—including ระบบองค์กรและ system integration—ได้อย่างไร

1. การเขียนโปรแกรมคือการคิด ไม่ใช่การพิมพ์

Kernighan & Pike ย้ำแนวคิดสำคัญเพียงข้อเดียวซ้ำแล้วซ้ำเล่า:

บั๊กส่วนใหญ่มาจากการออกแบบ ไม่ใช่จาก syntax

โปรแกรมเมอร์สายคลาสสิก:

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

แนวคิดแบบคลาสสิก

เข้าใจปัญหา → ออกแบบอย่างเรียบง่าย → เขียนโค้ดให้ชัด → ทดสอบอย่างมีเหตุผล

กับดักแบบสมัยใหม่

เลือกเฟรมเวิร์ก → สร้าง boilerplate → แก้บั๊กทีหลัง

แนวคิดนี้สำคัญมากในงาน system integration เช่น ระบบโรงงาน ระบบบัญชี ระบบ IoT หรือระบบที่ต้องเชื่อมต่อหลายฝ่าย เพราะความผิดพลาดเล็ก ๆ ในการออกแบบ จะลุกลามทั้งระบบได้ง่าย

2. ความเรียบง่ายชนะความฉลาด (เสมอ)

หนึ่งในบทเรียนที่ชัดที่สุดจาก The Practice of Programming คือ:

ถ้าโค้ดอ่านยาก แสดงว่าโค้ดนั้นผิด—even ถ้ามันจะทำงานเร็วแค่ไหนก็ตาม

โปรแกรมเมอร์สายคลาสสิกหลีกเลี่ยง:

one-liner ที่ฉลาดเกินไป
abstraction ซ้อนหลายชั้น
โค้ดที่มีแต่คนเขียนคนเดียวที่เข้าใจ

แต่จะเลือก:

logic ที่ตรงไปตรงมา
data flow ที่มองเห็นได้ชัด
ชื่อตัวแปรที่อธิบายตัวเอง

(ตัวอย่างโค้ด Python ด้านล่างยังคงเหมือนต้นฉบับ เพื่อให้ผู้อ่านนำไปทดลองได้ทันที)

3. โครงสร้างข้อมูลมาก่อน อัลกอริทึมตามมา

Kernighan–Pike เชื่อว่า:

เมื่อเลือกโครงสร้างข้อมูลถูก อัลกอริทึมจะชัดเจนตามมาเอง

คำถามแบบคลาสสิกคือ:

ข้อมูลควรมี “รูปทรง” แบบไหน
ข้อมูลไหลผ่านระบบอย่างไร
จุดไหนที่ข้อมูลเปลี่ยนสถานะ

ในระบบจริงขององค์กรไทย—เช่น ERP, MES, ระบบคลังสินค้า—ปัญหาส่วนใหญ่ไม่ได้มาจากโค้ดช้า แต่มาจาก data model ที่ออกแบบผิดตั้งแต่ต้น

4. การทดสอบคือการตั้งคำถาม ไม่ใช่แค่ตัวเลข

การทดสอบแบบคลาสสิกไม่ถามว่า “coverage กี่เปอร์เซ็นต์” แต่ถามว่า:

ข้อมูลว่างจะเกิดอะไรขึ้น
ข้อมูลมากผิดปกติจะพังตรงไหน
สมมติฐานอะไรที่เรากำลังเชื่ออยู่โดยไม่รู้ตัว

แนวคิดนี้เหมาะมากกับระบบที่ พังไม่ได้ เช่น ระบบการเงิน ระบบการผลิต และระบบที่เชื่อมต่อฮาร์ดแวร์

5. โปรแกรมเล็ก ๆ ขยายได้ดีกว่าโปรแกรมใหญ่

Kernighan & Pike สนับสนุน:

ฟังก์ชันเล็ก
โมดูลที่ทำหน้าที่เดียว
การเชื่อมต่อที่หลวม (loose coupling)

เพราะมนุษย์ เข้าใจสิ่งเล็ก ๆ ได้ดีกว่าสิ่งใหญ่

ในโลกจริง:

microservice ล้มเหลวเพราะซับซ้อนเกินไป
monolith ล้มเหลวเพราะไม่มีใครกล้าแก้

6. ทำไมแนวคิดนี้ยังสำคัญในปี 2025

แม้วันนี้เราจะมี:

AI ช่วยเขียนโค้ด
เฟรมเวิร์กขนาดใหญ่
ระบบ cloud-native

แต่ความล้มเหลวส่วนใหญ่ยังมาจาก:

ความเข้าใจ requirement ไม่ตรงกัน
การออกแบบที่ซับซ้อนเกินจำเป็น
การสื่อสารระหว่างทีมและระบบ

แนวคิดแบบคลาสสิกช่วยให้ระบบ:

อยู่ได้นาน
ดูแลต่อได้
อธิบายให้ผู้บริหารและผู้ใช้งานเข้าใจได้

7. วิธีฝึกคิดแบบคลาสสิกในปัจจุบัน

คุณไม่จำเป็นต้องเลิกใช้เครื่องมือสมัยใหม่ แต่ต้องใช้มันด้วย วินัยแบบคลาสสิก

ลองทำสิ่งเหล่านี้:

เขียนวิธีแก้ปัญหาเป็นภาษาคนก่อน
วาด data flow ลงกระดาษ
เขียนโค้ดเวอร์ชันที่ง่ายที่สุดที่ใช้งานได้จริง
ลบโค้ดแทนการเพิ่ม abstraction
ทำให้โค้ดอธิบายตัวเองได้

8. ตัวอย่างโปรแกรมเล็ก ๆ ในสไตล์ Kernighan–Pike

"""
Word Frequency Counter

A small program written in the Kernighan–Pike spirit:
- clear purpose
- simple data structures
- readable control flow
"""

import sys
from collections import defaultdict

def read_words(filename):
    """Read words from a file and normalize them."""
    words = []

    try:
        with open(filename, "r", encoding="utf-8") as f:
            for line in f:
                for raw in line.split():
                    word = raw.strip(".,!?\"'()[]{}")
                    if word:
                        words.append(word.lower())
    except OSError as err:
        print(f"Error reading file: {err}")

    return words

def count_words(words):
    """Count occurrences of each word."""
    counts = defaultdict(int)

    for word in words:
        counts[word] += 1

    return counts

def print_report(counts, limit=10):
    """Print a simple frequency report."""
    print("Word frequency report")
    print("---------------------")

    items = sorted(
        counts.items(),
        key=lambda item: item[1],
        reverse=True,
    )

    for word, count in items[:limit]:
        print(f"{word:15s} {count}")

def main(filename):
    words = read_words(filename)
    counts = count_words(words)
    print_report(counts)

if __name__ == "__main__":
    if len(sys.argv) != 2:
        print("Usage: python wordcount.py <filename>")
    else:
        main(sys.argv[1])