รีวิวรหัสพวกเขาทำงานจริงในเปรียวจริงหรือไม่


13

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

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

อย่างไรก็ตามข้อโต้แย้งของฉันคือการวิจารณ์รหัสเป็นการเสียเวลาในการทำซ้ำหรือการพัฒนาแบบ Agile ที่ UX / UI นั้นรุนแรง / รุนแรง (คิดว่าสมบูรณ์แบบของ Apple / Steve Jobs) บางทีคนที่นี่อาจช่วยให้เข้าใจก่อนที่พวกเขาจะยิงฉัน

นี่คือกระบวนการพัฒนาของฉันและขั้นตอนเริ่มต้นสุดท้ายคือ Agile

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

เมื่อเราเข้าใกล้จุดสิ้นสุดของรอบการทำซ้ำ 8 สัปดาห์ QA เริ่มทำการทดสอบจากนั้นจะไปที่ผู้ใช้อัลฟ่าและในที่สุดผู้ใช้เบต้า แต่ในช่วงที่นักพัฒนาอัลฟ่าและเบต้ากำลังก้าวข้ามฟีเจอร์ใหม่และฟีเจอร์ที่เก่ากว่าทำให้การเปลี่ยน UI เป็นรายวันหรือชั่วโมงซ้ำเพื่อปรับปรุง UX ดังนั้นคุณลักษณะที่ได้รับการพัฒนาในรุ่นนี้อาจสิ้นสุดลงเมื่อมีการเปลี่ยนแปลง 3 ครั้งในช่วงสี่สัปดาห์ที่ผ่านมาเพื่อปรับปรุงและปรับปรุงให้สมบูรณ์หรือเพิ่มคุณสมบัติเล็ก ๆ น้อย ๆ (เช่นทำให้ส่วนประกอบมีความสั่นไหวหรือฉลาดขึ้นเล็กน้อย) บางครั้งการเปลี่ยนแปลงอาจเป็นเพียงผิวเผินซึ่งหมายความว่าไม่มีการดำเนินการ CRUD ที่มีการเปลี่ยนแปลงหรือแก้ไข แต่ UI ทั้งหมดเท่านั้นที่เปลี่ยนแปลง

ดังนั้นด้วยกระบวนการพัฒนาประเภทนี้ Agile สุดขีด, การรีวิวโค้ดไม่ต้องเสียเวลาหรือเปล่า? หมายความว่าถ้าฉันมีนักพัฒนาอีกคนหรือสองคนตรวจสอบรหัสของฉัน แต่แล้วรหัสนั้นเปลี่ยนไปอีก 3 ครั้งก่อนที่มันจะออกนอกบ้านเนื่องจากการปรับปรุง UI / UX ทั้งหมดเราไม่ได้เสียเวลาไปกับ 3 ครั้งแรกที่พวกเขาตรวจสอบ รหัสตามที่โค้ด / ส่วนประกอบ / UI ถูกทิ้งใช่ไหม

เราไม่เคยมีปัญหาด้านคุณภาพมากมายในกระบวนการนี้และใช่ถ้านักพัฒนาทิ้งความรู้ทั้งหมดที่เดินออกจากประตู แต่เราพบนักพัฒนาที่ชาญฉลาดมารับและครอบครอง

และใช่เรามีผู้ทดสอบจำนวนมากเพราะพวกเขาอาจต้องสอบใหม่ 3 หรือ 4 ครั้ง นอกจากนี้โปรดอย่าลังเลที่จะถามว่าเหตุใด UI / UX ทั้งหมดจึงเปลี่ยน ... นั่นเป็นสิ่งที่ทำไปแล้ว ... นั่นเป็นสาเหตุที่ทำให้แอปชนะรางวัลมากมายสำหรับ UI / UX และผู้ใช้จะฆ่าเพื่อ แอป กระบวนการคิดคือถ้าฉันสามารถปรับปรุงบางอย่างได้ถึง 2% เพราะฉันมีเวลาเพิ่มอีกหนึ่งชั่วโมงจากนั้นทำ ผู้ใช้จะมีความสุขมากขึ้นซึ่งหมายถึง $ หรือผู้ใช้มากขึ้น และใช่ผู้ใช้ของเราตกลงกับแอปที่เปลี่ยนแปลงอย่างต่อเนื่องเพราะนั่นเป็นวิธีที่ทำมาตั้งแต่วันแรกดังนั้นพวกเขาจึงไม่เห็นว่าเลวหรือลบ

หวังว่าโพสต์นี้จะไม่ออกมาอย่างโอ้อวด แต่ฉันแค่ไม่เห็นว่ารีวิวโค้ดไม่สิ้นเปลือง อาจเป็น 2% ของรหัสทั้งหมดของเราในรหัสที่ตรวจสอบแล้วมีข้อบกพร่อง แต่ละรุ่นเราอาจพบ 3 ข้อบกพร่องผ่านการตรวจสอบรหัส ดังนั้นมันจึงเป็น 40 ชั่วโมงของการตรวจสอบรหัสต่อผู้พัฒนาต่อการเปิดตัว (4 x 40 = 160 ชั่วโมง) เพื่อหาข้อบกพร่อง 3 ถึง 5? โอกาส 50% ที่ 3 ถึง 5 ข้อผิดพลาดจะได้รับการหยิบขึ้นโดย QA ต่อไป จะดีกว่าไหมถ้าใช้เวลา 40 ชั่วโมงต่อนักพัฒนาเพิ่มคุณสมบัติใหม่หรือปรับปรุงที่มีอยู่เดิม?


@DeadMG: ประสบการณ์ผู้ใช้
Steven A. Lowe

4
@ user25702: กระบวนการที่คุณอธิบายไม่เหมือน Agile แต่ดูเหมือน RUP / Spiral โดยเฉพาะ "หลายครั้งในช่วงสัปดาห์ของการพัฒนาของเราเราถือ sesssions กับผู้มีส่วนได้ส่วนเสียอีกครั้งเพื่อดูว่าพวกเขายังคงเห็นด้วยคุณสมบัติ / ฟังก์ชั่น / UX / UI ยังคงเหมาะสมและเป้าหมาย" ต่อต้าน - เปรียว; คุณสมบัติจะถูกแช่แข็งในระหว่างการทำซ้ำเพื่อหลีกเลี่ยงปัญหาการเคลื่อนย้ายเป้าหมายที่เกี่ยวข้องกับวิธีการ RUP / เกลียว สำหรับคำถามเล็กน้อยของคุณฉันไม่เห็นคุณค่ามากนักในการรีวิวโค้ดที่นี่ถ้าหากคุณมั่นใจว่า QA จะพบข้อบกพร่อง
Steven A. Lowe

1
การทำซ้ำ 8 สัปดาห์ไม่คล่องแคล่วและไม่แน่นอน "สุดขีดเปรียว"
Martin Wickman

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

หากคุณต้องการที่จะโต้แย้งรหัสรีวิวจากนั้นฉันแนะนำให้จดสถิติบางอย่าง จัดทำเอกสารเวลาที่ใช้ในการตรวจสอบโค้ด (จำนวนชั่วโมงทำงานทั้งหมด) จำนวนข้อบกพร่อง / ปัญหาที่ค้นพบรวมถึงความรุนแรงของปัญหา สำหรับทีมของฉันปรากฎว่าเราใช้เวลาอย่างน้อย 16 ชั่วโมงต่อการตรวจสอบพบโดยเฉลี่ย 2-3 ข้อบกพร่องซึ่งทั้งหมดเป็นเครื่องสำอางในธรรมชาติ มันง่ายที่จะโต้แย้งวิธีการทดสอบครั้งแรกเพื่อแทนที่ความเห็นจากเพื่อนในหน้าของตัวเลขเหล่านั้น
Berin Loritsch

คำตอบ:


13

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

  • ความเป็นเจ้าของร่วม
  • ค้นหาข้อบกพร่อง (QC)
  • บังคับใช้รูปแบบที่สอดคล้องกัน (QA)
  • การให้คำปรึกษา

กระบวนการเปรียวหลายอย่างจะจัดการกับวิธีต่าง ๆ :

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

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


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

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

"ความเป็นเจ้าของร่วม": จากประสบการณ์ของฉันนี่มักจะเป็นภาพลวงตา: ผู้ตรวจสอบมักจะพูดถึงในรายละเอียดเล็กน้อยและไม่เห็นภาพรวมในโค้ดที่เขียนโดยคนอื่น จากนั้นเมื่อพูดถึงการแก้ไขโค้ดพวกเขาไม่เข้าใจจริง ๆ และพวกเขา (1) ไม่กล้าเปลี่ยนหรือ (2) พวกเขาเขียนใหม่อย่างกว้างขวางเพื่อให้สามารถเข้าใจได้ วิธีการ (2) มักมีผลข้างเคียงสองอย่าง: (A) พวกเขาแนะนำข้อบกพร่องและ (B) นักพัฒนาดั้งเดิมไม่เข้าใจรหัสอีกต่อไป
Giorgio

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

11

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

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


4

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


7
ฉันจะเถียงอย่างยิ่งกับเรื่องนี้ แน่นอนว่ามันกำลังถูกตรวจสอบโดยคนสองคน แต่โดยทั่วไปคนเหล่านั้นจะอยู่ในหน้าเดียวกันกับที่เขียนโค้ด การตรวจสอบโค้ดคือคนที่มีสภาพจิตใจแตกต่างไปจากเดิมอย่างสิ้นเชิงเมื่อมองดูโค้ดของคุณและการค้นหาปัญหา "doh! ลืมเกี่ยวกับการจัดการกับปัญหา" - XP ไม่ได้ช่วยอะไรอย่างนั้น
Billy ONeal

4

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

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

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

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


2

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

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

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


1

ฉันมักจะเห็นด้วยว่าการเป็นเจ้าของรหัสโดยรวมและการจับคู่พร้อมกับ TDD และ CI เป็นยาแก้พิษ Agile ในการทบทวนรหัสอย่างเป็นทางการ

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

ฉันรู้สึกว่าเพราะมี: - บางรีวิวร่วมกันของการออกแบบ (มักแสดงใน UML อย่างน้อยบนไวท์บอร์ด) หมายถึงปัญหาการออกแบบขนาดใหญ่หรือการใช้ API ที่ไม่ดี ฯลฯ ถูกจับได้ก่อนที่จะมีการเขียนโค้ดจำนวนมาก - FxCop, CheckStyle, FindBugs (หรือคล้ายกัน) ที่ทำงานพร้อมกับการรวมระบบอัตโนมัติอย่างต่อเนื่องเพื่อตรวจจับการตั้งชื่อ, โวหาร, การมองเห็น, การทำสำเนารหัส ฯลฯ

เราสามารถล้มเหลวก่อนหน้านี้และรับข้อเสนอแนะได้เร็วกว่าพฤติกรรมการตรวจสอบรหัสดาวน์สตรีมที่จะเกิดขึ้น

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


0

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

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

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

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

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

UI / UX นั้นต้องใช้เวลาในการทดสอบ แต่การมีผู้เชี่ยวชาญด้านการออกแบบ / การพัฒนาที่ส่วนหน้าควรจะลดลง นอกจากนี้ยังต้องใช้หน้าจอด้านหน้า อย่างไรก็ตามในแอปพลิเคชันทั้งหมดที่ฉันทำงานด้วยมันเป็นรหัสที่ค่อนข้างเล็ก

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

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.