การสร้างซอฟต์แวร์ใหม่เป็นส่วนสำคัญของงานเขียนโปรแกรมส่วนใหญ่หรือไม่? [ปิด]


63

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

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

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

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


11
@JamieTaylor แปลเป็นคำเปรียบเทียบของคุณแล้วคำถามคือ: เป็นเรื่องปกติไหมที่จะแก้ไขรูปแบบ Lego ของคนอื่นและมักจะสร้างรูปแบบใหม่หรือไม่
แม็กเคเล็บ

22
@ โจฮะ! ดังนั้นคุณคือคนที่สร้างสิ่งเหล่านั้นทั้งหมด! * # @ * &!% ระบบเดิมที่เราต้องรักษาไว้ตลอดไป! ;-P
PéterTörök

14
@ โจใช่ฉันทำขอบคุณมาก บางทีถ้าคุณสามารถเขียนการทดสอบหน่วยเพิ่มเติม tad ฉันจะเป็นเนื้อหาที่สมบูรณ์ :-)
PéterTörök

8
@ โจทำให้นึกถึงสุภาษิตโบราณซึ่งฉันไม่ได้พบโดยเฉพาะอย่างยิ่งฉลาด - ถึงตอนนี้: "รหัสเสมอราวกับว่าคนต่อไปรับรหัสของคุณเป็นโรคจิตอันตรายที่รู้ว่าคุณอยู่ที่ไหน"; -)
PéterTörök

11
@JonMcdonald ไม่ควรรู้สึกหดหู่ใจ - ไม่มีงานใดที่เป็นดอกกุหลาบทั้งหมดและการบำรุงรักษา codebase ที่มีอยู่อาจเป็นวิธีที่เร็วที่สุดในการรับประสบการณ์และพัฒนาทักษะของคุณในฐานะวิศวกร การใช้เวลาในการบำรุงรักษาจะช่วยให้คุณเข้าใจและหลีกเลี่ยงข้อผิดพลาดทั่วไปทั้งหมดซึ่งนำไปสู่การใช้รหัสที่ไม่สามารถรักษาได้ในตอนแรกและจะช่วยให้คุณชื่นชมสิ่งที่คุณอาจไม่สนใจเช่นการวิเคราะห์รหัสแบบคงที่
Ben Cottrell

คำตอบ:


66

การทำงานของซอฟต์แวร์จำนวนมากคือการบำรุงรักษา แน่นอนว่าไม่มีผู้จัดการการจ้างงานที่จะบอกคุณในเรื่องนี้ แต่เป็นกรณีที่แน่นอน


13
นี้น่าจะจริง แต่การบำรุงรักษายังคงเป็นสิ่งที่สำคัญจริงๆและสามารถนำความรู้ที่ท้าทายเช่นกันบางครั้ง :)
joshin4colours

3
ไม่มีอะไรผิดปกติกับการบำรุงรักษา แต่ผู้คนพบว่ามันมีเสน่ห์น้อยกว่าดังนั้นรายละเอียดของงานจึงมีแนวโน้มที่จะทำให้ต่ำลง
Scott C Wilson

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

3
@omouse - บางครั้งก็ใช่ แต่บางครั้งก็เป็นเพียงการแก้ไขข้อบกพร่องที่เห็นได้ชัดในการดำเนินการเพื่อตอบสนองข้อกำหนดเดิม แต่คุณพูดถูก - กิจกรรมที่หลากหลายครอบคลุมภายใต้รูบริกของ "การบำรุงรักษา"
Scott C Wilson

@ บ้านออกแบบและ refactoring มีความหมายเกินไปและไม่ครอบคลุมสิ่งที่เรามักเรียกว่า "mantainance" หากซอฟต์แวร์บางตัวใช้ฟังก์ชั่นที่เลิกใช้แล้วในขณะนี้หรือการเปลี่ยนแปลง API ภายนอกสิ่งที่คุณจะทำคือไม่ใช่การออกแบบใหม่หรือการปรับโครงสร้างใหม่
cbrandolino

59

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

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

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


15
+1 สำหรับ "ไม่มีใครที่ทำงานอย่างต่อเนื่องในโครงการกรีนฟิลด์ขนาดเล็กจริงๆสามารถอ้างว่ามีความสามารถ"
mattnz

1
"โครงการกรีนฟิลด์ขนาดเล็ก" คืออะไร?
คุกกี้แป้งข้าว

@RiceFlourCookies: Greenfieldเป็นคำสำหรับความพยายามในการทำงานที่ใหม่ทั้งหมด ในกรณีนี้โครงการเริ่มต้นจากศูนย์
Steven Evers

@RiceFlourCookies และในขณะที่ขนาดเล็กเป็นญาติโครงการที่สามารถทำได้โดยคนคนหนึ่งอาจถือว่ามีขนาดเล็กพอสมควร
Scott C Wilson

23

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

อาจน้อยกว่า 5% ของซอฟต์แวร์ที่เขียนจะยังคงทำงานต่อไปอีกสิบปี

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


8
... หรือพวกเขารอดชีวิตเพราะมีใครบางคนที่มีอิทธิพลต่อการตัดสินใจและมีความสนใจที่ซ่อนเร้นในการรักษาทรัพย์สมบัติของช้างแมมมอ ธ ไปอีก 10 ปีหรือมากกว่าเช่นการรักษางานบำนาญหรือเพียงไร้ความสามารถเกินไปและทักษะของเขาล้าสมัยเกินไป เพื่อหางานใหม่
Marek

@ marek มันสามารถเป็นได้ทั้งแน่นอน
ลัส

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

@Caleb - ในฐานะที่เป็นระบบกฎทั่วไปที่นักพัฒนาได้ฟังผู้ใช้และล็อคความต้องการอยู่รอด ไม่ว่าจะเขียนไม่ดี! ระบบที่นักพัฒนาพยายามที่จะจับคู่กับรูปแบบการออกแบบล่าสุดการใช้ fads ล่าสุดและการหมกมุ่นกับการเยื้องของพวกเขาไม่ได้ทำให้มันเป็นรุ่นแรก รหัสการทำงานจะเต้นสวยรหัสที่ตรงตาม buzzword
James Anderson

14

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

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

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


7
"ความพยายามล้มเหลวของคนอื่น" - ระบบเดิมเป็นเรื่องราวความสำเร็จของดาร์วินโครงการที่ล้มเหลวไม่ได้รับการดูแล!
James Anderson

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

6

ขึ้นอยู่กับว่าคุณหางานอะไร

ฉันเคยทำงานให้กับ บริษัท ผลิตภัณฑ์ซอฟต์แวร์เพียงครั้งเดียวซึ่งฉันทำงานในแอพพลิเคชั่นเคลือบทองในทีมเริ่มต้นเล็ก ๆ

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

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

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


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

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

7
@maple_shaft สิ่งที่สนุกยิ่งกว่านี้คือเมื่อพวกเขาพูดว่า "เราสามารถซื้อ X ได้ในราคา $ 10K และวิธีการแก้ปัญหาทั่วไปนี้จะเข้ากับปัญหาที่เรากำหนดเองได้อย่างสมบูรณ์แบบโดยไม่ต้องตั้งค่า! BTW คุณจะต้องรับผิดชอบ ข้อผิดพลาดของซอฟต์แวร์ที่เราซื้อเป็นความผิดของคุณ "
Spencer Rathbun

3
@SpencerRathbun คุณชนะนั่นเป็นสถานการณ์ที่เลวร้ายที่สุดที่จะเข้ามา
maple_shaft

5

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

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

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

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

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


4

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

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

กว่าในสถานที่ทำงาน Beta มีคำถามเกี่ยวกับวิธีการ 20% โครงการส่วนการทำงานของระบบของ

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

ด้วยการมีโครงการ 20% ฉันคาดการณ์ว่านักพัฒนาซอฟต์แวร์ของ Google จะไม่สนใจที่จะปรับปรุงโครงการของ Google เพราะเขาหรือเธอยังคงมีความสนุกสนานที่ได้อยู่ที่จุดเริ่มต้นของสิ่งใหม่


2

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

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


2

ฉันจะบอกว่ามันขึ้นอยู่กับ บริษัท ที่คุณทำงานด้วย

งานแรกของฉันคือ บริษัท ซอฟต์แวร์บัญชีที่มีผลิตภัณฑ์หลักคือระบบ ERP แข่งขันกันในระดับเดียวกับ Great Plains หรือ Peachtree (เหมือนกับที่คุณย้ายมาจาก QuickBooks หรือด้านข้างเมื่อคุณเบื่อกับ GP ที่ยุ่งเหยิงของ GP หรืออะไรก็ตาม คุณคิดว่าผิดกับ PT จากนั้นคุณย้ายจากระดับทั้งหมดมาเป็นแพ็คเกจเช่น SAP) งานนั้นคือการบำรุงรักษา 99.99% หมายถึงการแก้ไขข้อบกพร่องและเพิ่ม "สิ่งเล็ก ๆ " โดยไม่ต้องเปลี่ยนวิธีการทำงานของซอฟต์แวร์หรือสิ่งที่มันสามารถทำได้ ฉันออกจาก บริษัท ไปเมื่อ CEO ต้องการทำการเขียนหน้าใหม่ของระบบซึ่งจะเจ๋งมากยกเว้นเขายืนยันในคุณสมบัติการออกแบบหลายอย่างที่มีรูปแบบการต่อต้านที่ชัดเจนเช่นในแพลตฟอร์ม (อนุญาตให้ปรับแต่งได้ในระดับสูง ของโปรแกรมโดยทั่วไปให้ลูกค้า VS Designer ที่ไม่เข้าใจ

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

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


1

ฉันจะบอกว่ามันขึ้นอยู่กับบทบาทของคุณเป็นอย่างมาก

ฉันเป็นส่วนหนึ่งของทีมเล็ก ๆ และต้องรักษาและสนับสนุนทุกสิ่งที่ฉันสร้าง

5 ปีที่แล้วสิ่งที่ฉันทำส่วนใหญ่คือ "ใหม่" - ตอนนี้ฉันบอกว่าการบำรุงรักษาโค้ดที่มีอยู่ใช้เวลาอย่างน้อยครึ่งหนึ่งของเวลาโดยอีก 25% เป็นระบบรุ่นใหม่ "

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


1
  1. มันขึ้นอยู่กับว่าตำแหน่งงานของคุณมีอันตรายแค่ไหน: ;-)

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

    หากคุณทำงานให้กับ บริษัท เก่าที่มีตำแหน่งมั่นคงในตลาดมีแนวโน้มว่าคุณจะใช้รหัสในโหมดบำรุงรักษา ;-)

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

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

ไม่มีใครทำถูกต้องดังนั้นเราต้องรักษารหัสของพวกเขาและขัดให้อยู่ในสภาพที่เหมาะสม ;-)

ข่าวดีก็คือถ้าคุณอยู่ใน บริษัท นานพอคุณสามารถมีอิทธิพลต่อวิธีการเขียนรหัสใหม่ :-)


1

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

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


1

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

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

ฉันขอคำแนะนำที่คุณผลักดันและของานพัฒนาใหม่ได้ไหม? และถ้านายจ้างของคุณทำการบำรุงรักษาเพียงอย่างเดียวคุณอาจต้องไปต่อ


0

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

สี่ปีที่ฉันทำงานที่ บริษัท ของฉันฉันจะบอกว่า 70-80% ของเวลาที่ฉันใช้ไปกับการสร้างสิ่งใหม่ ๆ น่าจะเป็น 50-60% ของที่ใช้ในโครงการขนาดใหญ่ที่เป็นรหัสใหม่ทั้งหมดในขณะที่ส่วนที่เหลือของเวลานั้นจะใช้ในการปรับปรุงการทำงานปัจจุบัน

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


0

ฉันทำงานเกือบสามปีในฐานะนักพัฒนาเพียงคนเดียวใน บริษัท ที่ใช้QuickBooksและ Excel และไม่มีอะไรอื่นเมื่อฉันเริ่มต้น ตอนนี้เรามีแอพพลิเคชั่นWindows Forms , การติดตั้งSharePoint , SQL Server + Reports, Add-in ของ Excel และ Add-in ของ Outlook

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

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


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

ฉันดีใจที่ฉันไม่มีความรู้สึกเพราะพวกเขาอาจได้รับบาดเจ็บโดยมีเพียงคำตอบเดียวในกระทู้นี้ที่จะมีประเด็นด้านลบ :(
Aaron Anodide

คุณไม่ตอบคำถามที่ถาม

0

บางองค์กรขนาดใหญ่เช่น บริษัท ที่ฉันทำงานเพื่อมีนโยบายในการรื้อถอนซอฟต์แวร์หลังจากหลายปีที่ผ่านมาอาจเป็นเพราะภาษาการพัฒนาที่ถูกเขียนขึ้นไม่ได้ใช้งานแล้ว (Delphi ใคร?) หรือแพลตฟอร์มถูกแทนที่ (Windows XP) หรือข้อกำหนดด้านกฎระเบียบเรียกร้อง ตัวอย่างเช่นโปรแกรมระดับสองที่พูดคุยโดยตรงกับฐานข้อมูลกำลังถูกยกเลิกการใช้งานเนื่องจากมีสามระดับที่ใช้การเชื่อมต่อแบบ Kerberized เพื่อความปลอดภัยที่มากขึ้น

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

คาดว่ารอบการทดแทน 5-7 ปีสำหรับสิ่งประเภทนี้ เช่นในปี 2020 ฉันคาดหวังว่าซอฟต์แวร์ WPF (ไคลเอนต์) / Java (เซิร์ฟเวอร์) ที่ฉันกำลังเขียนตอนนี้จะเป็นเทคโนโลยีเก่าและถูกแทนที่ด้วยสิ่งใหม่กว่า

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