ข้อผิดพลาดในการพัฒนา WordPress ที่แย่ที่สุดห้าข้อของฉัน

หรือสำหรับเซิร์ฟเวอร์ทั้งหมดที่ฉันเคยทำมาก่อน: มองย้อนกลับไปอย่างน่ากลัวที่ห้าข้อผิดพลาด WordPress ที่เลวร้ายที่สุดที่ฉันทำ

ในฐานะนักพัฒนา เราทำผิดพลาดหลายประเภทในจุดต่างๆ ในอาชีพการงานของเรา ในการพัฒนา WordPress โดยเฉพาะอย่างยิ่ง เราทำผิดพลาดประเภทต่างๆ เนื่องจากความคุ้นเคยกับ Codebase ของ WordPress เติบโตขึ้น

เมื่อหลายปีก่อนฉันได้ยิน Matt Mullenweg ประกาศบางสิ่งเกี่ยวกับผลกระทบที่ว่าคนส่วนใหญ่ทำผิดซ้ำซาก คนที่ฉลาดกว่าจะเรียนรู้จากความผิดพลาดของพวกเขา และคนที่ฉลาดที่สุดในหมู่พวกเราเรียนรู้จากความผิดพลาดของผู้อื่น ฉันชอบสิ่งนี้ และฉันขอเสริมว่า: ทุกคนทำผิดพลาด คนถ่อมตัวแบ่งปันข้อผิดพลาดเหล่านั้นเป็นการส่วนตัว และคนที่กล้าหาญที่สุดในหมู่พวกเราเขียนและเผยแพร่ในบล็อก!

แต่มีเวลาสำหรับการรำพึงในภายหลัง คุณกำลังอ่านบทความนี้เพราะต้องการทราบเรื่องรถไฟชนกัน และฉันเป็นวิศวกร หากไม่มีคำนำเพิ่มเติม โปรดกลับมาทบทวนความผิดพลาดที่น่าอับอายที่สุดห้าประการที่ฉันได้ทำไว้ในฐานะนักพัฒนา WordPress

เวลาที่ฉันอัปเดตเวอร์ชันที่ถูกแฮ็กของ WordPress Core

ฉันเพิ่งจบการศึกษาจากการทำกิ๊กการเข้ารหัส CraigsList ที่คลุมเครือมาก ไปสู่การทำงานจริงในหน่วยงานจริง ฉันมาแล้ว! ฉันรู้สึกประหม่าที่จะทำงานจากที่อื่นที่ไม่ใช่โซฟาในที่อื่นที่ไม่ใช่ชุดนอนของฉัน แต่ถึงอย่างนั้น โดยทั่วไปฉันรู้จัก WordPress ถูกต้องจาก WordPress Doing It Wrong และฉันพบว่าการอวดตัวเองเกี่ยวกับแนวทางปฏิบัติที่ดีที่สุดของ WordPress เป็นเรื่องที่น่ายินดี อย่างที่ไม่เคย "เจาะระบบ"

งานพัฒนา WordPress งานแรกของฉันที่เอเจนซี่นี้คือการเริ่มโครงการที่หยุดชะงัก—ซึ่งค่อนข้างซับซ้อนสำหรับทักษะของฉันในขณะนั้น มันเกี่ยวข้องกับการปรับแต่งมากมายสำหรับการลงทะเบียน WordPress และขั้นตอนการเข้าสู่ระบบ ผู้พัฒนาคนก่อนนี้ขึ้นชื่อว่ามีความก้าวหน้าอย่างมากโดยเพียงแค่แก้ไขไฟล์หลัก wp-login

ฉันรู้ว่าสิ่งนี้ไม่ยั่งยืน ดังนั้นธุรกิจอันดับแรกของฉันคือการติดตั้งปลั๊กอินสำรอง/กู้คืนและแทนที่ WordPress core ด้วยเวอร์ชันที่ดาวน์โหลดใหม่ ฉันมั่นใจว่ายังไม่มีการดำเนินการใดๆ ที่น่าประทับใจอย่างยิ่งในโปรเจ็กต์ และฉันสามารถเลียนแบบชุดคุณลักษณะที่มีอยู่ผ่านตัวกรองได้

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

คุณเดาได้ไหมว่าจะไปที่ไหน

ปลั๊กอินนั้นตามที่โชคชะตาจะมีไว้ สำรองเฉพาะโฟลเดอร์ wp-content เท่านั้น แฮ็ก WordPress ใดก็ตามที่อยู่ในไฟล์หลักเหล่านั้นก็หายไปตลอดกาล ฉันยังจำอีเมลของฉันที่ส่งกลับไปหาเธอได้ (เธอไล่ฉันกลับบ้านมานานแล้วตั้งแต่ตอนนี้):

พวกฉันไม่สามารถสำรองข้อมูลได้

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

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

ฉันได้เรียนรู้ที่จะให้ความสำคัญกับสภาพแวดล้อมที่มีการจัดการ เช่น WP-Engine ด้วยระบบสำรอง/กู้คืนที่มีประสิทธิภาพ โฮสต์บูติกหลายแห่งมีเครื่องมือบรรทัดคำสั่งที่หลากหลายและคุณสมบัติอื่นๆ ที่เน้นนักพัฒนาซอฟต์แวร์สำหรับการสำรองข้อมูล แต่ WP-Engine เป็นรายการโปรดของฉัน มันค่อนข้างเร็วเว้นแต่คุณจะมีเครือข่ายที่ใหญ่มาก UI นั้นเรียบง่าย มัน มี UI ช่วงเวลา: ใครก็ตามที่รู้วิธีใช้ WordPress สามารถทำงานกับสิ่งนี้ได้ กล่าวคือ ตรงกันข้ามกับแนวทาง CLI บางอย่างที่อาจเร็วกว่า หรือบางสิ่งที่ไม่ชัดเจนซึ่งฝังอยู่ใน Plesk ลูกค้าของฉันสามารถใช้สิ่งนี้ ทำความเข้าใจ ตรวจสอบ และตรวจสอบว่าฉันกำลังใช้อยู่ ฉันเป็นแฟนตัวยง

เวลาที่ฉันลากทั้งแพลตฟอร์มของเราไปยังไดเรกทอรีพี่น้อง

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

ย้อนกลับไปในสมัยนี้ โฟลว์การพัฒนา WordPress ของเรายังคงรวมถึงการปรับใช้กับการผลิตผ่าน FTP ไม่ใช่เรื่องแปลกสำหรับฉันที่จะใช้เวลาทั้งวันทำงานเขียนโค้ด แชท ตอบอีเมล โดยทั่วไปแล้ววนไปมาผ่านเมาส์วิเศษตัวใหม่ของฉัน โดยที่ Cyberduck เปิดให้ใช้งานจริงบนเดสก์ท็อปของฉัน เอ้ย ฟังดูแย่! แต่นั่นเป็นวิธีที่มันเป็น

วันหนึ่งแพลตฟอร์มทั้งหมดของเราก็หายไป ผู้ดูแลระบบของเราคิดอย่างรวดเร็วว่าเป็น DDoS บางประเภทหรือบางอย่างในระดับของเขา สำหรับนักพัฒนาซอฟต์แวร์อย่างเรา เราเชื่อมั่นในสัญชาตญาณของเขาและคิดว่าเขาจะเข้าใจมันในไม่ช้า

ชั่วโมงผ่านไป วันนั้นมาและไป ยังลง.

เช้าวันรุ่งขึ้น สิ่งต่างๆ ได้รับการฟื้นฟู และ CTO ของเราขอให้ฉันเข้าร่วมกับเธอในห้องประชุมอย่างนุ่มนวล ผู้ดูแลระบบของเราได้ระบุปัญหาแล้ว เขาดึงบันทึก FTP และสังเกตว่าผู้ใช้ของฉันย้ายแพลตฟอร์มทั้งหมดของเราไปที่ไดเร็กทอรีพี่น้อง นั่นคือ wp-content ซ้อนกันภายใต้ wp-includes

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

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

อย่างที่สองคือ ฉันสนใจอย่างมากในการปรับใช้ผ่าน Git ในที่สุด ฉันก็เลิกเขียนปลั๊กอิน WordPress เพื่อสานเวอร์ชัน Bitbucket ของเราลงในโฟลว์การอัปเดต wp-admin ตามปกติ ตั้งแต่นั้นมา เราแทบไม่มีเหตุผลเลยที่ จะ เข้าถึง FTP เพื่อใช้งานจริง ปลั๊กอินนี้เป็นหนึ่งในความสำเร็จระดับมืออาชีพที่ฉันโปรดปราน แน่นอน ความใกล้ชิดกับ Git เป็นข้อกำหนดเบื้องต้นสำหรับนักพัฒนาในปัจจุบัน

เวลาที่ฉันลบเนื้อหาส่วนหน้าทั้งหมดผ่าน add_filter()

ฉันคิดว่าตอนนี้ฉันค่อนข้างฉลาดแล้วกับแนวทางปฏิบัติ WordPress ของฉัน คำขอคือการผนวก "ป้าย" กับโพสต์ของบางหมวดหมู่ ด้วยเหตุผลบางอย่าง ฉันจึงนึกขึ้นได้ว่ามีเพียง noobs เท่านั้นที่จะเพิ่มเงื่อนไขอื่นให้กับไฟล์เทมเพลตสำหรับสิ่งนี้ ดังนั้นด้วยความภาคภูมิใจอย่างยิ่ง ฉันจึงใช้ตัวกรองต่อไปนี้:

 add_filter( 'the_content', 'myprefix_add_a_badge' ); function myprefix_add_a_badge( $content ) { global $post; if( ! has_category( 'sponsored', $post ) ) { return false; } $out = $content . myprefix_get_badge(); return $out; }

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

โดยเฉพาะอย่างยิ่ง ผลลัพธ์ก็คือการโพสต์ที่ไม่มีตราสัญลักษณ์แสดงที่ส่วนหน้าโดยไม่มีเนื้อหาเลย! คุณเห็นไหมว่าทำไม? ปัญหาคือแทนที่จะส่งคืน $content ในสภาพการป้องกันของฉัน ฉันกลับ false แต่จริงๆแล้วมีข้อผิดพลาดหลายชั้นที่นี่

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

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

เวลาที่ฉันหารด้วย Zero Inside ของ Infinite Loop

คำขอของลูกค้าคือการจัดรูปแบบใหม่ทางสายย่อยของบล็อกโพสต์ WordPress โดยให้วันที่จะเป็น "XYZ ago" แทนที่จะเป็น "10 พฤศจิกายน 2554" ฉันไม่แน่ใจว่าจะบรรลุเป้าหมายนี้ได้อย่างไร แต่ฉันรู้ดีว่ารูปแบบวันที่นี้ดูเหมือนจะได้รับความนิยมเพิ่มขึ้น และแน่นอนว่า Dr. Google ได้ให้ข้อมูลโค้ดแก่ฉันอย่างรวดเร็ว มันใช้งานได้ในพื้นที่ของฉัน! มันมีคณิตศาสตร์มากมาย โดยเฉพาะอย่างยิ่ง การ แบ่ง จำนวนมาก ฉันไม่แน่ใจนักว่าทำไมมันถึงได้ผล—มีลูปซ้อน เศษ การปัดเศษ และอื่นๆ ที่ซ้อนกันอยู่มากมาย แต่มันอยู่บน Google และดูเหมือนว่าจะใช้งานได้ และฉันมีความสุขพอที่จะปรับใช้กับเวอร์ชันที่ใช้งานจริง

ประมาณ 30 นาทีต่อมา ฉันได้รับ Skype ที่ไม่เป็นมิตรจากผู้ดูแลระบบของเรา การผลิตลดลง ตายในน้ำ. เขาถามฉันว่าฉันหารด้วยศูนย์เมื่อเร็ว ๆ นี้และฉันไม่รู้ว่าเขาหมายถึงอะไร นี่คือสิ่งที่เกิดขึ้น

เชื่อหรือไม่ว่าตัวอย่างข้อมูล "ทำงานในพื้นที่ของฉัน" ที่อ่านไม่ได้ซึ่งฉันพบเมื่อพิจารณาจากขนาดตัวอย่างที่มากพอ มีความสามารถในพฤติกรรมผิดปกติบางอย่าง ลูปของ Rube Goldberg มักจะพยายามหารตัวเลขด้วยศูนย์พร้อมกับจำนวนวัน ชั่วโมง และนาทีที่นำโชคร้ายมาผสมกัน จำได้จากคณิตศาสตร์โรงเรียนมัธยม:

ในเลขคณิตธรรมดา นิพจน์ไม่มีความหมาย เนื่องจากไม่มีตัวเลขที่เมื่อคูณด้วย 0 ให้ a (สมมติว่า a ≠ 0) และการหารด้วยศูนย์นั้นไม่ได้กำหนดไว้ - วิกิพีเดีย

สิ่งนี้หมายความว่าสำหรับคอมพิวเตอร์? โดยปกติเป็นเพียงข้อความแสดงข้อผิดพลาดในบันทึก แต่ในกรณีของฉัน มันแย่กว่านั้น: ข้อผิดพลาดทางคณิตศาสตร์กำลังรบกวนลอจิกลูปของฉัน ทำให้การวนซ้ำที่ซ้อนกันของฉันทำงานโดยที่ไม่เคยทำเสร็จเลย—การวนซ้ำที่ไม่สิ้นสุดที่นำไปสู่หน้าจอสีขาวแห่งความตาย และมันก็แย่ลงไปอีก! เนื่องจากการวนซ้ำแต่ละครั้งของลูปกำลังเขียนข้อผิดพลาดสำหรับการหารด้วยศูนย์ บันทึกข้อผิดพลาดจึงขยายเป็นสัดส่วนที่ยอดเยี่ยม และเริ่มขัดขวางระบบไฟล์ของเรา สิ่งนี้มีผลกระทบจากการโจมตี DDoS แม้ว่าจะเป็นการทำร้ายตัวเองอย่างไร้เหตุผล

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

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

โอ้และสิ่งที่ตลกจริงๆเกี่ยวกับความผิดพลาดนี้? คอร์ WordPress มีโซลูชันแบบซับเดียวสำหรับมัน

เวลาที่ฉันปล่อยให้โครงการหมุนวนจนควบคุมไม่อยู่จนใครๆ ก็เบื่อ

ฉันได้ลงจอดโครงการที่น่าสนใจจริงๆ ฉันต้องเป็นผู้นำด้านเทคนิคและวิศวกรพัฒนา WordPress และฉันจะมีนักพัฒนา Amazon AWS Lambda และผู้เชี่ยวชาญอย่างลึกซึ้งในการรายงาน JavaScript ให้ฉัน นี่เป็นครั้งแรกที่มีคนรายงานฉันหลายคน และเป็นโครงการที่ซับซ้อนที่สุดเท่าที่ฉันเคยทำมา แม้แต่การเรียกมันว่าโปรเจ็กต์ WordPress ก็ยังทำให้เข้าใจผิดอย่างมากในเรื่องนี้ แต่ WordPress เป็นกาวที่ยึดทุกสิ่งไว้ด้วยกัน ดังนั้นจึงสมเหตุสมผลสำหรับฉันที่จะทำหน้าที่เป็นผู้นำด้านเทคโนโลยี

เนื่องจากโดยทั่วไปแล้ว บทบาทหลักของฉันคือการเป็นช่างเทคนิคอย่างเคร่งครัด และเนื่องจากฉันมีความสนใจในความเรียบง่าย ฉันไม่เคยคิดที่จะใช้บางอย่าง เช่น Jira หรือ Basecamp หรือแพลตฟอร์มจริงใดๆ สำหรับการจัดการงาน สิ่งต่าง ๆ ดำเนินไปค่อนข้างดีสำหรับการทำซ้ำครั้งแรกของโครงการ เราสามารถทำงานบนส่วนประกอบแต่ละส่วนของเรา อ้างถึงเอกสารข้อกำหนดของลูกค้าเป็นแผนงานผลิตภัณฑ์ของเรา และเพียงส่งคำสั่ง ping หากันผ่าน Slack เมื่อเราต้องการรวมสิ่งต่าง ๆ เข้าด้วยกัน

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

สิ่งต่าง ๆ เริ่มไม่สบายใจ ฉันคิดว่าลูกค้ารู้สึกเหมือนสูญเสียการควบคุมทิศทางของโครงการ และที่สำคัญพอๆ กัน เขารู้สึกเหมือนสูญเสียการมองเห็นสถานะของโครงการ นักพัฒนา Amazon ของฉันพูดถึงวันหนึ่งว่า "ฉันสงสัยว่าเราควรจะใช้ Trello หรือไม่"

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

ฉันรวบรวมอีเมลทั้งหมด เอกสารข้อมูลจำเพาะทั้งหมด เธรดความคิดเห็นที่แตกต่างกันทั้งหมดของเรา และแมปพวกเขาทั้งหมดบนกระดาน Trello โปรเจ็กต์ฟื้นคืนชีพในทันทีจากหลุมฝังศพดิจิทัลเพราะเราสามารถสื่อสารกับค่าใช้จ่ายทางจิตน้อยกว่ามาก แทนที่จะค้นหาข้อความในกล่องจดหมายอีเมลของฉันหรือเอกสารข้อมูลจำเพาะที่ส่วนใหญ่ล้าสมัย เรามีกระดาน รายการ และการ์ดที่น่ารัก ง่ายต่อการดูสถานะของคุณลักษณะใดๆ เพื่อรวมคำติชม และทำงานใหม่ รู้สึกเหมือนเราค่อยๆ มืดบอดไปช้าๆ จนเราไม่ทันสังเกต แล้วทันใดนั้นก็ มองเห็น ได้อีกครั้ง

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

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

ออกไปเรียนรู้จากความผิดพลาดของผู้อื่น

นี่คือสิ่งที่ฉลาดที่สุดเรื่องหนึ่งที่ฉันได้ยินมาในระหว่างที่ฉันเป็นทหาร: “เป็นเรื่องปกติที่นายร้อยจะทำผิดพลโท และกัปตันก็ทำผิดกับกัปตันได้ ไม่เป็นไรสำหรับกัปตันที่จะทำผิดพลาดของร้อยโทหรือสำหรับร้อยโททำผิดพลาดส่วนตัว”

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

ฉันหวังว่าเราในฐานะนักพัฒนาจะเรียนรู้ที่จะเห็นอกเห็นใจผู้อื่นเมื่อพวกเขาทำผิดพลาด อย่างที่หวังว่าคนอื่นๆ จะอยู่กับเรา ฉันหวังว่าจะยังคงอยากรู้อยากเห็นและรับผิดชอบเมื่อฉันทำผิดพลาดเพื่อที่ฉันจะได้สร้างสรรค์สิ่งใหม่ ๆ ต่อไป ฉันหวังว่าจะถูกรายล้อมไปด้วยชุมชนที่สร้างแรงบันดาลใจของผู้เชี่ยวชาญ WordPress อยู่เสมอ—ผู้คนที่มีข้อผิดพลาดที่ฉันสามารถเรียนรู้และหลีกเลี่ยงการทำเองได้ และไม่น้อยไปกว่านั้น ฉันหวังว่าคนอื่นๆ จะได้เรียนรู้จากประสบการณ์ของฉัน เช่น ข้อผิดพลาดของ WordPress ที่ฉันแบ่งปันที่นี่