ซอฟต์แวร์นำมาใช้ซ้ำขัดขวางกระบวนการทำซ้ำได้หรือไม่

การใช้รหัสซ้ำเป็นปัญหา

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

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

การเปรียบเทียบบางสาขากับสาขาอื่น

การก่อสร้าง

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

ผู้สร้างต้นแบบเป็นผู้เชี่ยวชาญที่ได้รับการยอมรับว่ามีการออกแบบและ / หรือสร้างสิ่งของหลายสิบหลายร้อยหรือหลายพันรายการ ยกตัวอย่างเช่นFrank Lloyd Wrightdesigned more than 1,000 structures and completed 532 worksโลกสถาปนิกที่มีชื่อเสียงและนักออกแบบ เปรียบเทียบกับAnders Hejlsbergผู้ออกแบบ“ just” ห้าภาษา (Turbo Pascal; Delphi; J ++; C #; Typescript) เป็นการเปรียบเทียบที่ไม่ยุติธรรมเนื่องจากหลายโดเมนแตกต่างกัน แต่ในระดับกว้างการผลิตเชิงปริมาณจากคนฉลาดมากสองคนนั้นแตกต่างกันอย่างมากมาย

ศิลปะการต่อสู้

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

งานไม้

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

ดังนั้นการใช้ซอฟต์แวร์ซ้ำจะช่วยป้องกันไม่ให้นักพัฒนาซอฟต์แวร์มีความเชี่ยวชาญมากขึ้นหรือไม่

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

คำถามของฉัน:ความสามารถของซอฟต์แวร์ที่จะนำกลับมาใช้ซ้ำป้องกันการปรับปรุงกระบวนการและประสิทธิภาพที่จำเป็นซึ่งมาจากการทำซ้ำโครงการ

ความสามารถในการนำซอฟต์แวร์มาใช้ซ้ำไม่ได้ป้องกันการปรับปรุงกระบวนการ

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

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

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

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

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

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

ซอฟแวร์เป็นที่แตกต่างจากสาขาอื่น ๆ มากที่สุดเพื่อให้เศรษฐกิจของที่เราใช้เวลาที่ดีที่สุดของเรามักจะแตกต่างกัน

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

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

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

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

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

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

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

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

แต่สำหรับคำถามโดยย่อและกระชับของคุณ: จากประสบการณ์ของฉันฉันจะบอกว่าใช่และไม่ใช่

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

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

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

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

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

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

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

อ่าแดงติดตามอีกครั้ง ... ข้อแก้ตัวของฉันคือฉันไม่ได้นอนเป็นเวลา 32 ชั่วโมงดังนั้นความสามารถในการโฟกัสของฉันจึงค่อนข้าง ... ฉันกำลังพูดอะไรอยู่

หากใครยังอ่านอยู่ข้อสรุปของฉันคือ:

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

และไม่ใช่การใช้ซอฟต์แวร์ซ้ำด้วยความระมัดระวังอาจให้เวลาแก่คุณมากในการพิจารณาและวางแผนการปรับปรุงกระบวนการ

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

การอ่านที่แนะนำสำหรับสิ่งนี้คือการเปรียบเทียบการสร้างซอฟต์แวร์เสีย

ซอฟต์แวร์มักจะเปรียบกับการก่อสร้าง น่าเสียดายที่การเปรียบเทียบนี้มีข้อบกพร่องและมีการเรียนรู้บทเรียนจากอุตสาหกรรมการก่อสร้าง ...

สิ่งที่ฉันสังเกตคือโครงการซอฟต์แวร์ที่ดี "เปลี่ยน" การทำซ้ำจำนวนมากเป็นการประกันคุณภาพ

เมื่อฉันเป็นผู้ทดสอบในโครงการระยะยาว 1,5 ปีเราเรียกใช้รอบการทดสอบในการเปิดตัว "ด่าน" รายสัปดาห์รวมทั้งหมดประมาณ 70 ครั้งผ่านโครงการ นั่นคือ ... ทำซ้ำได้ค่อนข้างพูดเบา ๆ (ไม่ค่อยมีอะไรเปลี่ยนแปลงในหนึ่งสัปดาห์) การทดสอบการสร้างทุกคืนนั้นเป็นไปตามธรรมชาติและสามารถทำซ้ำได้มากขึ้น - ประมาณ 500 ครั้งผ่านโครงการ

ทีนี้หลังจากที่ "ผู้ต้องสงสัย" อุปมาอุปมัยบอก บริษัท ก่อสร้างที่สร้างสะพาน 500 แห่ง - ทั้งหมดมีทีมงานเดียวกัน

• ติดตามต่อไปบอก บริษัท ที่ใช้อิฐและเหล็กเดียวกันเป็นส่วนใหญ่ในแต่ละสะพานใหม่ของพวกเขา (ที่นี่ฉันหมายถึงความจริงที่ว่าการเผยแพร่ที่เราทดสอบมีส่วนใหญ่เป็นรหัสวันต่อวันโดย สัปดาห์ - "ไม่มีอะไรเปลี่ยนแปลงมากนัก")
  

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

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

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

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

• เป็นอีกตัวอย่างหนึ่งของโครงการที่ผ่านมาของฉัน (อีกครั้งไม่มีอะไรที่น่าประทับใจมากกว่าโครงการปกติ) คราวนี้ในบทบาท dev ได้ดำเนินมานานกว่า 5 ปี (มีการเผยแพร่ครั้งใหญ่ 8 ครั้งและอีกหลายสิบครั้ง) มีจุดตรวจรายสัปดาห์ที่คล้ายกัน ( 5x52~=250ของพวกเขา), เผยแพร่ในยามค่ำคืนที่คล้ายกัน ( 5x365~=1800ของพวกเขา) และในทำนองเดียวกันทีม dev / QA เดียวกันทำงานเกี่ยวกับสิ่งเหล่านี้ แบบวันต่อสัปดาห์รายสัปดาห์รายเดือนส่วนใหญ่เป็นเรื่องซ้ำ ๆ (ไม่เปลี่ยนแปลงมากนักระหว่างสองงานสร้างยามค่ำคืน) ตามที่สัญญาไว้ในช่วงหลายพันครั้ง (1800)

โครงการที่มีชีวิตอีกต่อไปเช่น Windows หรือ Java หรือ AutoCAD สามารถมีอายุ 10, 20, 30 ปีซึ่งง่ายต่อการทำซ้ำสำหรับ "พัน" สร้างขึ้นทุกคืนและทดสอบทุกคืนตามที่ได้รับ

แนวคิดของการทำซ้ำการเปลี่ยนเป็น QA ยิ่งโดดเด่นยิ่งขึ้นด้วยการรวมอย่างต่อเนื่อง ...

การปฏิบัติ ... ของการรวมสำเนาการทำงานของนักพัฒนาทั้งหมดด้วยการฉีดที่ใช้ร่วมกันหลายครั้งต่อวัน ... CI สามารถมองเห็นได้ว่าเป็นการเพิ่มความเข้มข้นของการปฏิบัติงานของการรวมเป็นระยะ ..

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

การทำซ้ำ? มันอยู่ที่นั่นมากเท่าที่จะคิด

ด้วย QA ที่ใช้บ่อย / ต่อเนื่องสิ่งต่าง ๆ ที่ผิดพลาดจะกลับไปหานักพัฒนาที่ถูกบังคับให้พยายามทำซ้ำอย่างถูกต้องจนกระทั่งการทดสอบล้มเหลวสำเร็จ ในความเป็นวงจรที่ซ้ำจนกว่าจะผ่านไปคล้ายCATA รหัส ,

แบบฝึกหัดในการเขียนโปรแกรมซึ่งช่วยให้โปรแกรมเมอร์ฝึกฝนทักษะของพวกเขาผ่านการฝึกฝนและการทำซ้ำ ...

สิ่งที่คุณพูดเป็นความจริง: เช่นห้องสมุดแก้ปัญหาฟังก์ชั่นที่ไม่ได้แก้ไขด้วยภาษาระดับสูงซึ่งแก้ปัญหาที่ไม่ได้แก้ไขโดยการชุมนุมซึ่งแก้ปัญหาที่ไม่ได้แก้ไขด้วยรหัสเครื่อง เมื่อคุณเรียกใช้ System.out.println () ใน java คุณจะสูญเสียการเห็นว่า CPU ทำงานอย่างไรกับอุปกรณ์

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

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

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

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

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

สิ่งที่ดีที่สุดที่เราทำได้คือดูที่การออกแบบโดยรวมของโครงการใหม่และดูว่ามันจะสามารถปรับปรุงได้อย่างไรจากประสบการณ์ที่ผ่านมาของทีม แต่มันต้องใช้ประสบการณ์สถาปนิกซอฟต์แวร์จริง ๆ มีวิสัยทัศน์เกี่ยวกับสิ่งที่พิจารณาจริง ๆ แล้วปรับปรุงการออกแบบเพื่อพัฒนาทักษะ vs เพียงแค่ใส่ buzzword ล่าสุดในการพัฒนาเช่น Agile, OOP ฯลฯ