จดหมายรักถึงการเขียนโปรแกรม

น่าแปลกที่การบรรลุถึงความเรียบง่ายนั้นไม่ใช่เรื่องง่ายในตัวเอง เราโชคดีที่มีคนใส่ใจเรื่องนี้มาก

ฉันอยู่ที่การประชุม dotgo ในปารีสเมื่อปี 2558 และ Russ Cox เป็นวิทยากรคนสำคัญ เขาเชิญผู้ชมมาร่วมสำรวจความเรียบง่ายและความสะดวกของเขา ในที่สุดก็สรุป (อย่างที่หลายคนคาดหวัง) ว่าต้องใช้ความรักและความเอาใจใส่อย่างมากในการสร้างสิ่งที่ใช้งานง่าย และนั่นคือสิ่งที่ผลักดันเขาและเพื่อนร่วมงานส่วนใหญ่ ' แรงจูงใจในการทำให้เป็นอย่างที่มันเป็น เป็นการพูดคุยที่ยอดเยี่ยมและเน้นย้ำถึงความเป็นมนุษย์ของการเขียนโปรแกรมเหนือความบริสุทธิ์ที่แผ่ซ่านไปทั่วงานฝีมือ

ฉันคิดว่านี่เป็นความพยายามที่สวยงามจริงๆ สำหรับวิศวกรซอฟต์แวร์ที่จะอุทิศตัวเองให้ เพราะมันง่ายมากที่จะทรยศต่อความเรียบง่ายโดยหันไปสร้างสิ่งที่ใช้ได้ผล นี่เป็นเหตุผลเดียวกับที่ฉันจุดประกายความรักให้กับการพัฒนา Ruby on Rails อีกครั้ง เป็นเวลาสองปีเต็มนับตั้งแต่ที่ฉันออกจากเอเจนซี่เก่าในลอนดอนชื่อ New Bamboo (ปัจจุบันคือ Thoughtbot) และเดินทางไปที่ Typeform ในบาร์เซโลนา ฉันได้รับสิทธิพิเศษและความหรูหราในการเริ่มต้นโปรเจ็กต์ใหม่กับทีมของฉันโดยใช้ Rails เพื่อสนับสนุน Node, PHP และ Go และฉันยินดีที่จะแบ่งปันประสบการณ์เหล่านั้นในช่วงเวลาที่ New Bamboo ในลักษณะที่ตรงไปตรงมามาก

หากคุณไม่เคยใช้ Rails มาก่อนคุณคงเคยได้ยินเรื่องนี้มาบ้างแล้ว เป็นเฟรมเวิร์กที่มีชื่อเสียงในการเลือก "ความเรียบง่ายและรอยยิ้ม" เหนือความบริสุทธิ์ทางเทคนิค ซึ่งนักพัฒนาบางคนไม่ชอบ แต่คนอย่างฉันชอบ DHH และกลุ่มประชากรตามรุ่นของเขาที่ Basecamp (née 37 Signals) ตัดสินใจอย่างกล้าหาญในการจัดการกับความซับซ้อนของเว็บสแต็คด้วยตนเอง เพื่อให้ผู้ใช้เฟรมเวิร์กไม่จำเป็นต้องทำ และผลลัพธ์ที่ได้ก็ใช้งานง่ายอย่างน่าอัศจรรย์

เช่นเดียวกับนักพัฒนา Russ Cox และ the Go สิ่งนี้จำเป็นต้องมีการจัดทำแบบแผนจำนวนมากโดยเสียค่าใช้จ่ายในการกำหนดค่า และทั้ง Go และ Rails อาจไม่รู้สึกง่ายนักจนกว่าคุณจะใช้เวลาซึมซับวัฒนธรรมของเครื่องมือมากพอ เมื่อคุณทำเช่นนั้น คุณจะเริ่มเข้าใจว่ามันมีอยู่จริง ดังนั้นโค้ดจึงสามารถตั้งสมมติฐานได้มากมายสำหรับคุณ จากนั้นโปรเจ็กต์ถัดไปของคุณที่ใช้ภาษาหรือเฟรมเวิร์กก็สามารถเริ่มต้นระบบได้รวดเร็วยิ่งขึ้นโดยคำนึงถึงสิ่งนั้น

ฉันพูดถึงประสบการณ์ Typeform โดยเฉพาะเพราะเราต้องเผชิญกับการตัดสินใจนั้น มันเป็นความรับผิดชอบของทีมของฉันในการจัดการกับความซับซ้อนหรือไม่ หรือจะปล่อยให้ผู้ใช้ปลายทาง (นักพัฒนารายอื่น) และปกปิดมันด้วยเอกสารประกอบได้หรือไม่? มันง่ายและกลับกลายเป็นว่าง่ายอีกครั้ง และเราตัดสินใจว่าจะดีกว่าสำหรับเราที่จะทำทุกวิถีทางเพื่อให้การสนับสนุนเป็นไปตามสัญชาตญาณมากที่สุดเท่าที่จะเป็นไปได้ แอป Rails ของเราไม่สามารถเชื่อมต่อกับฐานข้อมูลได้อย่างสมบูรณ์เนื่องจากเราใช้สถาปัตยกรรมไมโครเซอร์วิส ดังนั้นความท้าทายหลักคือการดูว่าเราจะปฏิบัติต่อ API ในฐานะแบ็กเอนด์ที่คงอยู่ได้อย่างไร เพื่อให้นักพัฒนารายอื่นสามารถพึ่งพาเอกสารประกอบและบทช่วยสอนที่มีอยู่เกี่ยวกับโมเดลได้ เราเขียนโค้ดซึ่งต่อมากลายเป็นอัญมณีที่เรียกว่า Pupper (ไม่ใช่ว่าฉันแนะนำให้คุณใช้มันเพราะมันค่อนข้างหยาบบริเวณขอบ) นั่นเป็นผลผลิตของแบบแผนพิเศษชุดหนึ่งที่เรากำหนดไว้ในนามของความเรียบง่าย:

1. โมเดลที่มี API สำหรับแบ็กเอนด์ต้องมีไคลเอ็นต์ที่เกี่ยวข้องซึ่งจัดการคำขอ
2. โมเดลและไคลเอนต์ต้องอยู่ในโมดูลที่ตั้งชื่อตาม API เช่น หากเราต้องรวมเข้ากับบริการที่เรียกว่า Rainbow คลาสเหล่านี้จะต้องอยู่ภายในโมดูลชื่อ Rainbow
3. หากโมเดลชื่อ Rainbow::Colour ดังนั้นไคลเอ็นต์ API จะต้องเรียกว่า Rainbow::ColoursClient

สิ่งนี้ทำให้เราสามารถตั้งสมมติฐานเกี่ยวกับโค้ดเพื่อให้นักพัฒนาสามารถแบ่งปันความรู้สึกยินดีของเราเองเมื่อนำเสนอฟีเจอร์ใหม่ที่ยอดเยี่ยมในเวลาเพียง 30 นาที หากคุณกล้าที่จะดูการใช้งานใน Pupper คุณจะสังเกตเห็นว่ามีตัวช่วยสร้างการเขียนโปรแกรมเมตาที่จำเป็นเพื่อให้สมมติฐานเหล่านั้น (และอื่น ๆ อีกมากมาย) ดำรงอยู่ได้ และแม้จะไม่ได้ใช้งานง่ายอย่างที่โค้ด นั้น สามารถเป็นได้ ฉันภูมิใจในความสปาเก็ตตี้ของมันเพราะมันมีอยู่จริง ฉันสนุกกับการรวมมันเข้าด้วยกันเพราะความเรียบง่ายคือความท้าทาย และมันจุดประกายความหลงใหลในการเขียนโปรแกรมสิ่งต่าง ๆ ของฉันอีกครั้ง

ความเรียบง่ายมีไว้สำหรับผู้ใช้ปลายทาง ไม่ใช่ผู้สร้าง

ฉันไม่ต้องการที่จะไม่ยุติธรรมกับชุมชน PHP, Java หรือ JS เมื่อฉันพูดสิ่งนี้ แต่ฉันคิดว่ามีแนวโน้มระยะยาวเกี่ยวกับวิศวกรรมที่มากเกินไปบางประเภทที่ทำให้เข้าใจผิดโดยพื้นฐานถึงวัตถุประสงค์และเป้าหมายของความเรียบง่าย - ซึ่ง คือความเรียบง่ายนั้นมีไว้สำหรับผู้ใช้ปลายทาง ไม่ใช่ผู้สร้าง

ครั้งหนึ่งฉันเคยพยายามเริ่มโปรเจ็กต์กับ Symfony และฉันรู้สึกงุนงงกับเอกสารประกอบมาก Rails อาจรู้สึกน่าเบื่อในบางครั้งเพราะมันเหมือนกับการวางบล็อก Lego ไว้ด้วยกันเพื่อวัตถุประสงค์ส่วนใหญ่ แต่ Symfony ก็ 'น่าสนใจ' ในแบบที่ Terry Pratchet จะทำให้คุณรู้จักมัน ฉันไม่สามารถเขียนคอนโทรลเลอร์หรืออินพุตฟอร์มแยกวิเคราะห์โดยไม่ต้องรวมคลาสครึ่งโหลจากเนมสเปซต่างๆ และฉันต้องตัดสินใจว่าจะกำหนดค่าเส้นทาง โมเดล เอนทิตี และบริการโดยใช้คำอธิบายประกอบในความคิดเห็น YAML หรือ XML หรือไม่ ฉันคิดว่าการจัดวางแบบนี้ค่อนข้างง่ายที่จะสร้างเมื่อเทียบกับความเจ็บปวดของ 37 Signals และทีมงาน Go ได้ทำเพื่อให้บรรลุสิ่งที่ต้องการ เพราะมันให้ความรู้สึกเหมือนสร้างเฟอร์นิเจอร์ของ IKEA โดยไม่มีคำแนะนำแบบกราฟิก ตรงข้ามกับการซื้อของที่เสียบเข้าด้วยกันอย่างสังหรณ์ใจ ฉันไม่เข้าใจว่าทำไมฉันต้องสนใจว่าคอนโทรลเลอร์กำหนดให้ฉันต้องนำเข้าคำขอ การตอบกลับ โปรแกรมสร้างอนุกรม JSON และพระเจ้าก็รู้อะไรอีก ในขณะเดียวกัน Laravel พยายามเลียนแบบ Rails เพื่อให้ผู้คนเริ่มต้นได้ง่ายขึ้น

แน่นอนว่า สำหรับหลายๆ คน สิ่งนี้เป็นเรื่องปกติ และนั่นคือสาเหตุที่เฟรมเวิร์กดังกล่าวยังคงมีอยู่ และแน่นอนว่า มันไม่ได้ทำให้คุณเป็นนักพัฒนาที่ดีขึ้นหรือแย่ลงสำหรับความชอบนั้น สำหรับฉัน มันให้ความรู้สึกเหมือนเป็นผลสืบเนื่องตามธรรมชาติของการพัฒนาผู้คนด้วย IDE เพราะครึ่งหนึ่งของสิ่งนี้เป็นเพียงตัวอย่างที่โปรแกรมแก้ไขของคุณสามารถนำเข้าได้โดยอัตโนมัติ แล้วใครจะสนใจล่ะ ฉันไม่คิดว่าการมี IDE เป็นการพึ่งพาโครงการของคุณโดยปริยายทำให้มันง่าย เพราะโค้ดของคุณกลายเป็นฝันร้ายในการนำทางสำหรับนักพัฒนาที่ชอบโปรแกรมแก้ไขข้อความ เช่น VS Code, Atom, Sublime Text, vim หรือ emacs

ฉันคิดว่าสิ่งเดียวกันนี้สามารถพูดได้สำหรับเทรนด์ล่าสุดในชุมชน JS เครื่องมือนี้ยอดเยี่ยมมาก อย่าเข้าใจฉันผิด: ไลบรารีอย่าง Babel และ Webpack นั้นยอดเยี่ยมมากและเป็นประโยชน์สำหรับนักพัฒนาที่ไม่พอใจกับระบบนิเวศของ Javascript มานานแล้ว ประสบการณ์ในการตั้งค่าแพ็คเกจเหล่านี้ทำให้เป็นที่ต้องการอย่างมาก และฉันรู้สึกราวกับว่าชุมชนให้ความสำคัญกับความเรียบง่ายสำหรับผู้ดูแลมากกว่าสำหรับผู้ใช้ไลบรารีเหล่านั้น Babel ได้ทำการเปลี่ยนผ่านไปสู่สถาปัตยกรรมไมโครโมดูลซึ่งเป็นที่ถกเถียงกัน ซึ่งหมายความว่า npm install babel ไม่มีการติดตั้ง Babel ที่ใช้งานได้หรือมีประโยชน์อีกต่อไป แต่ฉันอาจจำเป็นต้องเรียกใช้ npm install babel-core babel-cli babel-preset-es6 babel-preset-react (หรืออะไรที่คล้ายกัน) เพื่อให้ได้ผลลัพธ์เดียวกัน เหตุใดในฐานะผู้ใช้ไลบรารีนี้ ฉันจึงถูกบังคับให้รู้เกี่ยวกับ babel-core และ babel-cli ที่เป็นแพ็คเกจอิสระ ด้วยเหตุนี้ นักพัฒนาจำนวนมากจึงเลือกที่จะเผยแพร่ Repository ที่ Forkable โดยที่การกำหนดค่าทั้งหมดนี้ทำเพื่อคุณ

UX นั้นเหมาะสมไม่น้อยเมื่ออินเทอร์เฟซไม่ใช่แบบกราฟิก แต่เป็นโค้ด

อีกด้านหนึ่ง เส้นด้ายทำให้ถูกต้อง มันรู้ว่าคุณอาจต้องการบันทึกการขึ้นต่อกันให้กับโปรเจ็กต์ของคุณ ดังนั้น yarn add จึงทำเพื่อคุณ ซึ่งหมายความว่าโค้ดของคุณจะไม่เสียหายเมื่อมีคนในทีมของคุณพยายามเรียกใช้เนื่องจากคุณทำ npm install แทนที่จะเป็น npm install --save React นั้นยอดเยี่ยมมากและน่ายินดีที่ได้เริ่มต้นใช้งาน เพราะสิ่งที่คุณต้องมีในการสร้าง Component ก็คือฟังก์ชันและไวยากรณ์บางอย่างที่กระตุ้นให้เกิดความคุ้นเคยอย่างมากกับ HTML ทุกสิ่งที่ฉันได้เห็นเกี่ยวกับ TypeScript จนถึงตอนนี้ก็เหมือนกัน พวกเขาใช้ความพยายามอย่างมากเพื่อทำให้ประสบการณ์นั้นดีสำหรับนักพัฒนา และเอล์มสมควรได้รับการกล่าวถึงเป็นพิเศษ เนื่องจากภาษาต้องใช้ในการอธิบายข้อผิดพลาดสำหรับคุณ สิ่งที่ Ruby ได้เริ่มนำมาใช้กับฟีเจอร์ 'คุณหมายถึงอะไร'

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

ประสบการณ์ผู้ใช้เป็นสาขาที่ใหญ่และน่าตื่นเต้นซึ่งส่วนใหญ่มุ่งเน้นไปที่การออกแบบอินเทอร์เฟซแบบกราฟิก แต่ก็ไม่เหมาะสมไม่น้อยเมื่ออินเทอร์เฟซนั้นเป็นโค้ด ฉันมีความเคารพอย่างสูงต่อนักพัฒนาโอเพ่นซอร์สเหล่านั้นที่มอบความรักและความเอาใจใส่อย่างมาก เพราะหากไม่มีมันก็คงไม่มีเฟรมเวิร์กแบบ Rails ที่จะทำให้การพัฒนาแอปอย่างรวดเร็วเป็นไปอย่างสนุกสนาน จะไม่มีภาษาเช่น Ruby, Go และ Elixir ที่ทำให้การเขียนโค้ดเป็นเรื่องง่ายและสนุกในรูปแบบที่แตกต่างกันอย่างไม่น่าเชื่อ จะไม่มี React หรือ React Native ที่จะแปลงการพัฒนาแอปหน้าเดียวบนเว็บ สิ่งนี้ไม่ได้ทำให้เครื่องมือที่ซับซ้อนมากขึ้นมีค่าน้อยลง แต่ก็ไม่ได้ทำให้ฉันมีความสุขเหมือนกัน

นี่คือบทกวีของฉันต่อหลักการแห่งรอยยิ้มที่ใหญ่กว่าของ DHH (ตามที่อธิบายไว้ใน "Rails Doctrine") ซึ่งเป็นหลักการที่สำคัญที่สุดของการพัฒนา ซึ่งอธิบายทั้งหมดนี้ได้อย่างสวยงามเกินกว่าที่ฉันเคยทำได้ เพื่อเป็นการตอบแทน ฉันจะทิ้งคำพูดที่ยอดเยี่ยมเกี่ยวกับผู้สร้าง Ruby ซึ่งแสดงให้เห็นว่าหลักการนี้น่ายินดีเพียงใด:

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

นั่นไม่น่าทึ่งเหรอ?