ฉันเพิ่งเริ่มงานกับการแย่งชิงกันและดูเหมือนจะมีบางอย่างขาดหายไป ฉันใหม่เพื่อการต่อสู้

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

ส่วนใดใน Scrum ที่นักพัฒนาสามารถมีอำนาจที่จะพูดได้ว่าเพียงพอแล้วและเรียกร้องให้พวกเขาได้รับเวลาเพื่อเริ่มการเขียนครั้งใหญ่? เราดูเหมือนจะวนรอบไม่สิ้นสุดเพียงแค่ติดตั้งโค้ดเก่ากับ 'Stories'

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

ดังนั้นใครจะเป็นผู้รับผิดชอบในการเปลี่ยนแปลงครั้งใหญ่นี้เกิดขึ้น? นักพัฒนา ปริญญาโทการต่อสู้?

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

ฉันไม่แน่ใจว่าทำไมสิ่งนี้จึงเป็นเรื่องยากสำหรับผู้คน กรณีธุรกิจของเขาอยู่ที่นี่:

We seem in an endless loop of just patching old code with 'Stories'.

เวลาของนักพัฒนาคือเงิน เงินจำนวนมาก ฉันออกจาก บริษัท ที่วางแผนจะปรับปรุง UI ของพวกเขาในช่วงหนึ่งปีที่ผ่านมาและหวังว่าการใช้การต่อสู้จะช่วยให้พวกเขาหยุดหมุนวงล้อ เกิดอะไรขึ้น? Same ol 'Same Ol' พวกเขายังคงเพิ่มฟีเจอร์ใหม่ ๆ และ "หนี้ทางเทคนิค" ไม่มีกรณีธุรกิจแม้ว่าครึ่งหนึ่งของรหัสที่เราเขียนนั้นไม่มีความหมายกับการวนซ้ำทุกครั้งเนื่องจากโค้ดเบสพื้นฐานเป็นระเบียบที่ล้าสมัยอย่างสมบูรณ์ ไม่มีสิ่งใดเปลี่ยนแปลงที่ปลายด้านหน้าของพวกเขาตั้งแต่ฉันจากไปและฉันถูกนำตัวไปเพื่อจุดประสงค์ในการปรับปรุงใหม่อย่างสมบูรณ์ ในสองเดือนที่ฉันอยู่ที่นั่นฉันไม่ได้สัมผัส CSS หรือ JavaScript อย่างแท้จริง ฉันแค่ล้อเล่นกับ HTML และระบบเทมเพลต Java เก่าแก่บางส่วนจากปลายปี 1990

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

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

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

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

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

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

http://blog.objectmentor.com/articles/2009/01/09/the-big-redesign-in-the-sky
http://www.joelonsoftware.com/articles/fog0000000069.html

หากต้องการขยายใน "การเขียนซ้ำไม่ใช่ความคิดที่ดี":

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

ฉันจะทื่อจริง ๆ ...

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

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

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

ใช้ระบบปฏิบัติการของ Window เป็นตัวอย่าง เมื่อมีการสร้างเวอร์ชั่นใหม่ขึ้นมาแต่ละรุ่นจะมีการยกโค้ดขนาดใหญ่ขึ้นจากเวอร์ชั่นก่อนหน้า บางครั้งทั้งไลบรารีและ API จะถูกลากไปข้างหน้าข้ามระบบปฏิบัติการหลายชั่วอายุคน ทำไม? เนื่องจากนักพัฒนาทราบว่าองค์ประกอบเหล่านี้ทำงานได้รับการทดสอบได้รับการติดตั้งและแก้ไขเพื่อป้องกันปัญหาด้านความปลอดภัยและหน่วยความจำและเพราะพวกเขาต้องเสียเงินจำนวนมากในการเข้าสู่สภาวะนั้น ไม่มีใครต้องการทิ้งรหัสการทำงานเมื่อมันสร้างรายได้แม้ว่าค่าบำรุงรักษาจะค่อนข้างสูงค่าใช้จ่ายในการเริ่มต้นจากศูนย์มักจะสูงกว่าเสมอและใน บริษัท เช่นกรณีของ Microsoft พวกเขามีพันล้านในธนาคาร อนุญาตให้พวกเขาเริ่มต้นจากจุดเริ่มต้นหากพวกเขาต้องการ แต่พวกเขา don ' เพราะพวกเขาต้องการเพิ่มผลตอบแทนจากการลงทุนให้สูงสุด นายจ้างของคุณไม่แตกต่างจาก Microsoft ยกเว้นเรื่องเล็กน้อยเกี่ยวกับการมีเงินสดเป็นพันล้านในการโปรเจ็กต์

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

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

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

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

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

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

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

• พวกเขาจัดระเบียบตัวเอง ไม่มีใคร (ไม่ใช่แม้แต่ Scrum Master) บอกทีมพัฒนาว่าจะเปลี่ยนผลิตภัณฑ์ที่ค้างไว้ให้เป็นการเพิ่มฟังก์ชั่นการกู้คืนที่อาจเกิดขึ้นได้อย่างไร

• ทีมพัฒนามีการทำงานข้ามสายงานโดยมีทักษะทั้งหมดเป็นทีมที่จำเป็นในการสร้างผลิตภัณฑ์ที่เพิ่มขึ้น

• Scrum ไม่รู้จักชื่อสำหรับสมาชิกในทีมพัฒนานอกเหนือจากผู้พัฒนาโดยไม่คำนึงถึงงานที่ทำโดยบุคคลนั้น ไม่มีข้อยกเว้นสำหรับกฎนี้

• สมาชิกทีมพัฒนาส่วนบุคคลอาจมีทักษะเฉพาะด้านและมีจุดสนใจ แต่ความรับผิดชอบนั้นเป็นของทีมพัฒนาโดยรวม และ,

• ทีมพัฒนาไม่ได้มีทีมย่อยสำหรับโดเมนเฉพาะเช่นการทดสอบหรือการวิเคราะห์ธุรกิจ

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

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

หากคุณต้องเขียนใหม่ทั้งหมดคุณต้องแก้ไขปัญหาที่ Scrum Restrospective เจ้าของผลิตภัณฑ์อาจยกเลิกโครงการและเริ่มโครงการใหม่ในที่สุด เจ้าของผลิตภัณฑ์เป็นเพียงคนเดียวที่สามารถยกเลิกการวิ่งได้

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

นี่เป็นปกติ

สิ่งที่คุณอธิบายคือเอนโทรปีปกติของฐานรหัส ในกรณีของคุณทีมอาจเริ่มห่างจากอุดมคติ แต่ในที่สุดทุกฐานรหัสก็กลายเป็นBig Ball of Mudลูกบิ๊กของโคลน

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

ฉันเห็นด้วยกับคนอื่น ๆ รหัสฐานยุ่งเหยิงเป็นเพราะนักพัฒนา ฉันมั่นใจว่าจะมีการใช้ SCRUM มาก่อนหลายปี

นี่ไม่ใช่การตัดสินใจทางเทคนิคหรือนักพัฒนาในการเขียนใหม่ แต่เป็นการตัดสินใจทางธุรกิจ

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

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

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

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

หากคุณสามารถแสดงหลักฐานได้จริง ๆไม่ใช่แค่ทฤษฎี แต่เป็นหลักฐานที่พิสูจน์ได้ว่าการใช้จ่ายXเงินดอลลาร์ในการเขียนใหม่ของกรีนฟิลด์จะรับประกันว่าจะทำให้ X * Nดอลลาร์สำหรับธุรกิจในYกรอบเวลา (ที่NสูงและYสั้น) คุณอาจได้รับแรงฉุด . นี่เป็นกรณีที่ไม่น่าเป็นไปได้สูงที่คุณจะสามารถนำเสนอและพิสูจน์ได้

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

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

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

ฉันอยู่ที่ไหนและทำงานอย่างไรนี่คือสิ่งที่เราจะทำ: เขียนเรื่องใหม่และมอบมันให้กับเจ้าของผลิตภัณฑ์แล้วใครจะเป็นผู้ตัดสินใจว่าจะจัดลำดับความสำคัญอย่างไร ตัวอย่างเช่น: "ในฐานะนักพัฒนาผลิตภัณฑ์ X ฉันต้องการเขียนโค้ดใหม่ในพื้นที่นี้เพื่อให้การพัฒนาในอนาคตมีประสิทธิภาพมากขึ้น" จากนั้นเกณฑ์การยอมรับจะต้องเป็นไปตาม: การเขียน / refactoring x เพื่อให้ดีขึ้นในวิธีนี้

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

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

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

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

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

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

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

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

คุณถาม:

ส่วนใดใน Scrum ที่นักพัฒนาสามารถมีอำนาจที่จะพูดได้ว่าเพียงพอแล้วและเรียกร้องให้พวกเขาได้รับเวลาเพื่อเริ่มการเขียนครั้งใหญ่? เราดูเหมือนจะวนรอบไม่สิ้นสุดเพียงแค่ติดตั้งโค้ดเก่ากับ 'Stories' ดังนั้นสิ่งที่กำลังดำเนินการโดยบุคคลที่ไม่ใช่ด้านเทคนิคซึ่งดูเหมือนจะไม่มีความปรารถนาที่จะผลักดันให้มีการเขียนซ้ำเพราะพวกเขาไม่เข้าใจว่าฐานรหัสเลวร้ายเพียงใด ..

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

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

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

รออะไร?

คุณกำลังปะ ? คุณควรจะrefactoring ติดกับค่าเปรียว ใช้ TDD และแนวทางปฏิบัติที่เหมาะสมและในที่สุดสถานการณ์ก็จะดีขึ้น