การทำงานร่วมกันที่ดีขึ้นโดยนำนักออกแบบเข้าสู่กระบวนการตรวจสอบโค้ด

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

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

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

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

อาฮะ! ช่วงเวลา

ในเดือนกรกฎาคม 2017 ฉันก่อตั้ง Confrere ร่วมกับนักพัฒนาสองคน และเราก็ได้ว่าจ้างวิศวกรคนแรกของเราอย่างรวดเร็ว (ฉันไม่ใช่นักพัฒนาเอง ฉันเป็น UX หรือนักออกแบบเนื้อหามากกว่า) การทำงานร่วมกันของเราดำเนินไปอย่างราบรื่นอย่างน่าประหลาดใจ มากเสียจนเมื่อมองย้อนกลับไป หัวข้อที่เกิดซ้ำคือเราทุกคนรู้สึกว่าเรากำลัง “ทำถูกต้อง”

ฉันนั่งลงกับเพื่อนร่วมงานเพื่อพยายามระบุว่าสิ่งที่เรา "ทำถูกต้อง" นั้นคืออะไร เพื่อที่เราจะสามารถพยายามรักษาความรู้สึกนั้นไว้ได้แม้ในขณะที่บริษัทของเราเติบโตขึ้นและทีมของเราจะขยายตัว เราตระหนักว่าเราทุกคนชื่นชมที่ทั้งทีมมีส่วนร่วมตั้งแต่เนิ่นๆ และเราจริงใจและชัดเจนในการให้ความคิดเห็นซึ่งกันและกัน Dag-Inge CTO ของเรากล่าวเสริมว่า: “มันได้ผลเพราะเรากำลังทำมันในฐานะเพื่อนร่วมงาน คุณไม่ได้ถูกวิพากษ์วิจารณ์และเพิ่งได้รับรายการข้อผิดพลาด”

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

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

หากคุณคุ้นเคยกับการตรวจทานโค้ดอยู่แล้ว ก็ข้ามไปส่วนถัดไปได้เลย

การตรวจสอบรหัสคืออะไร?

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

คำขอดึงมีบทบาทที่กำหนดไว้อย่างชัดเจน: มีผู้เขียนและผู้ตรวจสอบ

ตัวอย่างเช่น สมมติว่าวิศวกรอาวุโสของเรา Ingvild ได้ทำการเปลี่ยนแปลงขั้นตอนการสมัครของ Confrere ก่อนที่จะรวมเข้ากับฐานรหัสหลักและจัดส่ง เธอ (ผู้เขียน) ได้สร้างคำขอดึงเพื่อขอให้มีการตรวจสอบจาก CTO Dag-Inge ของเรา (ผู้ตรวจสอบ) เขาจะไม่ทำการเปลี่ยนแปลงใดๆ ในโค้ดของเธอ เพียงเพิ่มความคิดเห็นของเขาเท่านั้น

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

เมื่อผู้ตรวจสอบอนุมัติคำขอดึง Ingvild สามารถรวมการเปลี่ยนแปลงของเธอเข้ากับฐานรหัสหลักได้

ทำไมต้องทำการตรวจสอบโค้ด?

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

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

— บรูซ จอห์นสัน ผู้ร่วมก่อตั้ง Full Story

การตรวจสอบรหัสช่วยลดความเสี่ยง การมีคนมาพิสูจน์งานของคุณ และการ รู้ว่า ใครบางคนจะพิสูจน์งานของคุณ ช่วยขจัดข้อผิดพลาดและเพิ่มคุณภาพ นอกจากนี้ยังช่วยให้เกิดความสม่ำเสมอและช่วยให้สมาชิกในทีมทุกคนคุ้นเคยกับฐานรหัสมากขึ้น

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

การมีคนอย่างน้อยสองคนคอยดูโค้ดอยู่เสมอจะลดแนวคิดของโค้ด "ของฉัน" และโค้ด "ของคุณ" มันคือรหัส ของเรา

เมื่อพิจารณาถึงข้อดีเหล่านี้แล้ว บทวิจารณ์ไม่ควรมีเพียงแค่โค้ดเท่านั้น

ทบทวนหลักการสำหรับทุกวินัย ไม่ใช่แค่โค้ด

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

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

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

แม้ว่าเราจะไม่ได้ตรวจทานโค้ด แต่ก็ยังมีอีกมากให้เรียนรู้จากแนวทางปฏิบัติที่ดีที่สุดที่มีอยู่สำหรับการตรวจทานโค้ด

ภายในทีมของเรา เราพยายามปฏิบัติตามหลักการต่อไปนี้เมื่อทำการตรวจสอบ:

1. วิจารณ์งานไม่ใช่ผู้เขียน
2. เป็นคนวิพากษ์วิจารณ์ แต่ยังคงอ่อนโยนและอยากรู้อยากเห็น
3. แยกความแตกต่างระหว่าง ก) ข้อเสนอแนะ ข) ข้อกำหนด ค) ประเด็นที่ต้องการการอภิปรายหรือการชี้แจง
4. ย้ายการสนทนาจากข้อความไปยังตัวต่อตัว (จำนวนวิดีโอ)
5. อย่าลืมชื่นชมส่วนดี! อะไรจะฉลาด สร้างสรรค์ มั่นคง ดั้งเดิม ตลก ดี และอื่นๆ?

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

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

ตัวอย่าง

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

ขั้นตอนที่ 1: การรวบรวมความต้องการ

ผู้เขียน : ไอด้า (UX)

ผู้ตรวจสอบ: Svein (กลยุทธ์), Dag-Inge (วิศวกรรม), Ingvild (วิศวกรรม)

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

ขั้นตอนที่ 2: จำลองด้วย microcopy

ผู้เขียน : ไอด้า (UX)

ผู้วิจารณ์: Ingvild (วิศวกรรม), Eivind (การออกแบบ), Svein (กลยุทธ์)

ในฐานะผู้เขียน ฉันได้สร้างแบบจำลองขั้นตอนการสมัครใช้งานด้วยไมโครสำเนา ขั้นตอนการลงชื่อสมัครใช้สมเหตุสมผลไหมจากทั้งผู้ใช้และมุมมองด้านวิศวกรรม และเราจะปรับปรุงโฟลว์จากมุมมองการออกแบบและส่วนหน้าได้อย่างไร ในขั้นตอนนี้ จำเป็นอย่างยิ่งที่จะต้องทำงานในรูปแบบที่ง่ายต่อการให้คำติชมในทุกสาขาวิชา (เราเลือกใช้ Google เอกสาร แต่ก็สามารถทำได้ด้วยเครื่องมืออย่าง InvisionApp)

ขั้นตอนที่ 3: การดำเนินการตามขั้นตอนการลงทะเบียน

ผู้เขียน : Ingvild (วิศวกรรมศาสตร์)

ผู้ตรวจสอบ: Ida (UX) และ Dag-Inge (วิศวกรรม)

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

ขั้นตอนที่ 4: การทดสอบผู้ใช้

ผู้เขียน : ไอด้า (UX)

ผู้ตรวจทาน: ผู้ใช้

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

ขั้นตอนที่ 5: ออกแบบ

ผู้แต่ง: Eind (ออกแบบ)

ผู้ตรวจสอบ: Ingvild (วิศวกรรม) และ Ida (UX)

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

ขั้นตอนที่ 6: การนำไปใช้

ผู้เขียน : Ingvild (วิศวกรรมศาสตร์)

ผู้วิจารณ์: Eivind (การออกแบบ), Ida (UX) และ Dag-Inge (วิศวกรรม)

แล้วเราก็กลับมาดำเนินการ

ทำไมรีวิวถึงได้ผล

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

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

เกมส์ทบทวนเป็นประจำ

เราใช้แรงบันดาลใจจากคำแนะนำแบบโค้ด เรายังดำเนินการทบทวนคำแนะนำแบบปกติที่มีจุดโฟกัสต่างๆ กัน โดยมีแนวทางตามหลักการต่อไปนี้:

• บทแนะนำจะทำ ร่วมกัน
• คนหนึ่ง มีหน้าที่ตรวจสอบและจัดทำเอกสาร
• แนวคิดคือการ ระบุปัญหา ไม่จำเป็นต้องแก้ไข
• เลือก รูปแบบ ที่ให้บริบทมากที่สุดเท่าที่จะเป็นไปได้ เพื่อให้ง่ายต่อการดำเนินการตามสิ่งที่ค้นพบในภายหลัง (เช่น InvisionApp สำหรับการตรวจสอบด้วยภาพ, Google เอกสารสำหรับข้อความ และอื่นๆ)

เราได้ตรวจสอบคำแนะนำการใช้งานสำหรับสิ่งต่างๆ เช่น การตรวจสอบการช่วยสำหรับการเข้าถึง การตรวจสอบคำขอคุณลักษณะ การตรวจสอบการใช้งานการออกแบบ และการประเมินความสามารถในการใช้งานแบบศึกษาสำนึก

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

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

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

การทดสอบผู้ใช้คือรูปแบบการทบทวน

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

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

การข้ามการทดสอบของผู้ใช้นั้นมีความเสี่ยงสูงพอๆ กับการข้ามการตรวจสอบโค้ด

การทบทวนหมายถึงความตายต่อความคิดสร้างสรรค์หรือไม่?

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

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

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

มาสร้างสรรค์สิ่งดีๆ ไปด้วยกัน