คำถามติดแท็ก legacy

คำถามเกี่ยวกับภาษารหัสหรือแอปพลิเคชันดั้งเดิม

6
แนวปฏิบัติที่เหมาะสมที่สุดสำหรับการเลิกใช้คอลัมน์ฐานข้อมูลล้าสมัยคืออะไร [ปิด]
ปิด คำถามนี้จะต้องมีมากขึ้นมุ่งเน้น ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้มุ่งเน้นที่ปัญหาเดียวโดยแก้ไขโพสต์นี้ ปิดให้บริการใน2 ปีที่ผ่านมา ฉันออกแบบแอปพลิเคชันซึ่งจะรวบรวมข้อมูล A, B และ C จากลูกค้าในระยะแรก แต่หลังจากนั้นจะรวบรวมข้อมูล A, B และ D แทน A, B, C และ D ที่เกี่ยวข้องมากและในขณะนี้มีอยู่เป็นคอลัมน์ของฐานข้อมูลเดียว PostgreSQL ตารางT เมื่อไม่ต้องการใช้ C อีกต่อไปฉันต้องการลบการอ้างอิงออกจากแอปพลิเคชันของฉัน (ฉันใช้Django ORM ) แต่ฉันต้องการเก็บข้อมูลที่ป้อนไว้แล้ว วิธีที่ดีที่สุดที่จะทำคืออะไร? ฉันคิดว่าจะสร้างตารางใหม่สำหรับ ABD แต่นั่นหมายความว่าอาจทำให้เกิดปัญหากับตารางอ้างอิงแถวใดก็ได้ที ฉันสามารถปล่อยให้คอลัมน์ C ไปพร้อมกันและลบการอ้างอิงถึงมันในโค้ดทำให้ข้อมูลที่มีอยู่รอด มีตัวเลือกที่ดีกว่าที่ฉันไม่เห็นหรือไม่ รายละเอียดพิเศษบางอย่าง: จำนวนแถวจะไม่ใหญ่มากที่สุดน่าจะเป็น 1-2 ต่อผู้ใช้ นี่เป็นแอปพลิเคชั่นสำหรับตลาดมวลชน แต่เมื่อฉันเปลี่ยนจาก C เป็น …

3
สนับสนุนการพัฒนาระบบปฏิบัติการรุ่นเก่า
ฉันกำลังบำรุงรักษารหัสมรดกส่วนใหญ่เขียนด้วยภาษาซีรหัสนี้ถูกเขียนขึ้นครั้งแรกเพื่อเป็น comiled กับ Windows 3 สำหรับ Workgroups และรุ่นที่ใหม่กว่าสำหรับ NT ถูกสร้างขึ้น แอปพลิเคชั่นรุ่นเก่านี้ยังคงใช้งานได้ในปัจจุบันทำงานอย่างสนุกสนานบนเวิร์กสเตชัน 3.11 และ NT จากต้นยุค 90 มันใช้งานได้และทำในสิ่งที่ควรทำและเหตุผลที่พวกเขายังคงใช้งานอยู่คือไดรเวอร์สำหรับฮาร์ดแวร์ที่กำหนดเองซึ่งเป็นของโซลูชันไม่เข้ากันได้กับ Windows ในภายหลัง นอกจากนี้ยังมีแอปพลิเคชั่นอื่นที่ฉันยืนยันว่าด้วยเหตุผลเดียวกันนี้ใช้งานได้กับ Win2k เท่านั้น อย่างไรก็ตามในขณะที่สิ่งต่าง ๆ ดำเนินต่อไปมันก็ยากที่จะเรียกใช้สภาพแวดล้อมแบบดั้งเดิมเหล่านี้ ตอนนี้ฉันเก็บเครื่องทางกายภาพไว้กับซอฟต์แวร์การพัฒนาที่ติดตั้งดังนั้นฉันจึงสามารถทำงานกับฮาร์ดแวร์ดั้งเดิมได้ แต่สิ่งเหล่านี้อาจตายได้ตลอดเวลา (พวกเขามีอายุ 25 ปี) ดังนั้นคำถามของฉันคือเมื่อเห็นว่าเป็นปี 2559 อะไรคือตัวเลือกของฉันสำหรับการรักษาสภาพแวดล้อมโบราณนี้ในวิธีที่มีเสถียรภาพมากขึ้น? คุณสามารถย้าย 3.11 ไปยังโฮสติ้งคลาวด์ได้หรือไม่ ฉันลองใช้การจำลองเสมือน แต่เนื่องจากลักษณะเฉพาะของการตั้งค่าฉันไม่สามารถใช้งานได้กับไดรเวอร์อุปกรณ์ดังนั้นฉันคิดว่าอาจต้องทำให้ภาพเต็มของระบบปฏิบัติการตามที่เป็นอยู่แล้วจึงเรียกใช้งานใน VM เพื่อพัฒนาซอฟต์แวร์หรือไม่ สิ่งนี้เป็นไปได้หรือไม่สำหรับแขกระบบปฏิบัติการรุ่นเก่าที่เป็น Win3 และ NT มีประสบการณ์ในการรักษาแพลตฟอร์มเก่า ๆ เช่นนี้เพื่อการพัฒนาหรือไม่ แต่ในแบบที่ทันสมัยกว่าและปลอดภัยกว่าที่ฉันสามารถดึงดูดได้ เป้าหมายของฉันคือการกำจัดเครื่องเก่าออกและย้ายไปยังระบบเสมือนจริง
14 c  windows  legacy 

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

3
วิธีจัดการกับสถานการณ์“ ซอฟต์แวร์สิ้นสุดอายุการใช้งาน”?
เมื่อผู้ขายประกาศว่าพวกเขาไม่ต้องการให้การสนับสนุนหรือบริการใด ๆ กับซอฟต์แวร์อีกต่อไป (และระบุความตั้งใจที่จะออกจากธุรกิจโดยไม่เสนอเส้นทางการอัปเกรด) ลูกค้าประเภทใดที่สามารถขอความช่วยเหลือได้ โปรดพิจารณาสิ่งนี้จากมุมมองของลูกค้า พนักงานไอทีของลูกค้ามีแนวโน้มที่จะพิจารณาทางเลือกด้านเทคนิคเท่านั้น แต่มีตัวเลือกที่ไม่ใช่ด้านเทคนิคที่ลูกค้าสามารถติดตามได้เช่นกัน นอกจากนี้ลูกค้ายังสามารถดำเนินการขั้นตอนที่เหมาะสมได้ล่วงหน้าเพื่อลดการหยุดชะงักเช่นในแง่ของสัญญา สิ่งที่ฉันคิดได้: จำเป็นต้องซื้อฮาร์ดแวร์สำรองและตั้งค่าสภาพแวดล้อมสำรองที่ซอฟต์แวร์สามารถทำงานได้ต่อไป วิธีการส่งออกข้อมูลที่หลากหลายซึ่งไม่ต้องการการมีส่วนร่วมของผู้ขาย (ซึ่งอาจรวมถึงเทคนิคที่ไม่สำคัญเช่นการตรวจสอบข้อมูลที่เก็บไว้ในแบ็กเอนด์ฐานข้อมูลสินค้าสำหรับเทคนิคที่เกี่ยวข้องเช่นการขูดหน้าจอการพิมพ์ไปยังภาพตามด้วยการสแกนซ้ำเป็นต้น) ระบบคู่ขนานที่พนักงานจะทำซ้ำข้อมูลเก่าลงในระบบใหม่ด้วยตนเองหรือกึ่งอัตโนมัติ วิธีการทางกฎหมายในกรณีที่ผู้ขายมีปัญหาทางการเงิน (เช่นในกรณีของสัญญารหัสต้นทาง ) ความคิดอื่น ๆ ? สมมติว่าไม่มี "การหลบเลี่ยง" ที่เกี่ยวข้อง (ไม่มี DRM หรือ DMCA) ไม่มีการกู้คืนข้อมูลหรือวิศวกรรมย้อนกลับทางกฎหมาย / ยอมรับได้หรือไม่? หมายเหตุการแก้ไข: มันเป็นการผสมผสานของเรื่องราวเล็ก ๆ น้อย ๆ แต่เป็นเรื่องจริง ฉันไม่ได้เกี่ยวข้องโดยตรงกับสิ่งเหล่านี้ มันเป็นเพียงความปรารถนาของฉันที่จะเรียนรู้เกี่ยวกับวิธีการจัดการสถานการณ์ "จุดสิ้นสุดของชีวิต" โดยทั่วไป มันไม่ใช่ความตั้งใจของฉันที่จะทำให้เนื้อเรื่องดั้งเดิมฟังเหมือน "ยาก" ที่ต้องแก้ไข

3
Poor Man's Dependency Injection เป็นวิธีที่ดีในการแนะนำความสามารถในการทดสอบกับแอปพลิเคชันรุ่นเก่าหรือไม่?
ในปีที่ผ่านมาฉันสร้างระบบใหม่โดยใช้ Dependency Injection และ IOC container เรื่องนี้สอนฉันมากมายเกี่ยวกับ DI! อย่างไรก็ตามหลังจากเรียนรู้แนวคิดและรูปแบบที่เหมาะสมแล้วฉันคิดว่ามันเป็นความท้าทายในการแยกรหัสและแนะนำคอนเทนเนอร์ IOC ในแอปพลิเคชันรุ่นเก่า แอปพลิเคชันมีขนาดใหญ่พอที่จะนำไปใช้จริง แม้ว่าค่าจะเข้าใจและเวลาที่ได้รับ ใครให้เวลากับอะไรแบบนี้ ?? เป้าหมายของหลักสูตรคือการนำการทดสอบหน่วยมาใช้ในตรรกะทางธุรกิจ! ตรรกะทางธุรกิจที่เกี่ยวพันกับการเรียกการป้องกันฐานข้อมูลการทดสอบ ผมเคยอ่านบทความและผมเข้าใจอันตรายของคนจนพึ่งพาการฉีดตามที่อธิบายไว้ในบทความ Los Techies นี้ ผมเข้าใจว่ามันไม่ได้อย่างแท้จริง decouple อะไร ฉันเข้าใจว่าสามารถมีส่วนร่วมในการปรับโครงสร้างระบบได้มากเนื่องจากการติดตั้งใช้งานต้องอาศัยการพึ่งพาใหม่ ฉันจะไม่พิจารณาใช้กับโปรเจ็กต์ใหม่ที่มีขนาดเท่าใดก็ได้ คำถาม:การใช้ DI ของ Poor Man เพื่อแนะนำการทดสอบกับแอปพลิเคชั่นรุ่นเก่าและเริ่มต้นการหมุนลูกบอลได้หรือไม่? นอกจากนี้การใช้ Poor Man's DI เป็นวิธีรากหญ้าในการฉีด Dependency ที่แท้จริงเป็นวิธีที่มีคุณค่าในการให้ความรู้เกี่ยวกับความต้องการและประโยชน์ของหลักการหรือไม่ คุณสามารถ refactor วิธีการที่มีการอ้างอิงการโทรฐานข้อมูลและนามธรรมที่โทรไปด้านหลังส่วนติดต่อ? เพียงแค่มีสิ่งที่เป็นนามธรรมจะทำให้วิธีการนั้นสามารถทดสอบได้เนื่องจากการใช้งานจำลองอาจถูกส่งผ่านทางตัวสร้างเกินพิกัด เมื่อถึงความพยายามที่ได้รับการสนับสนุนโครงการสามารถปรับปรุงเพื่อใช้คอนเทนเนอร์ IOC และผู้สร้างจะออกไปที่นั่นในนามธรรม

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

3
ผู้จัดการที่ไม่ใช่ฝ่ายไอทีควรรักษาความปลอดภัยในการบำรุงรักษาและการพัฒนาซอฟต์แวร์ระยะยาวที่สำคัญได้อย่างไร
เราเป็น บริษัท เล็ก ๆ ที่มีความเชี่ยวชาญเป็นพิเศษและมีประโยชน์มากโดยมีซอฟต์แวร์ที่มีประโยชน์และมีประสิทธิภาพซึ่งบางส่วนเขียนในภาษาโคบอล แต่ส่วนใหญ่เป็นภาษาเบสิก ที่ปรึกษาเต็มเวลาสองคนได้รับการบำรุงรักษาและปรับปรุงระบบนี้มานานกว่า 30 ปี ไม่จำเป็นต้องพูดว่าพวกเขาจะออกจากตำแหน่งในไม่ช้า (หนึ่งในนั้นหมดหวังที่จะเกษียณเป็นเวลาหลายปี แต่ภักดีต่อความผิดและค้างอยู่แม้จะมีการยืนยันจากสามีของเธอว่ากอล์ฟควรให้ความสำคัญเป็นอันดับแรก) เราเริ่มต้นเส้นทางของการแปลงเป็นระบบที่พัฒนาโดยหนึ่งในสาม บริษัท ในประเทศที่เสนอซอฟต์แวร์ประเภทที่เราใช้ ตอนนี้เรารู้สึกว่าถึงแม้ บริษัท นี้จะมีความสามารถในการแปลงกระบวนการให้เสร็จตามหลักทฤษฏี แต่พวกเขาก็ไม่มีทรัพยากรที่จะทำได้ทันเวลาและเราเชื่อว่าพวกเขาจะไม่สามารถให้บริการที่เราต้องการได้ ธุรกิจของเรา. (ไม่มีอะไรที่เหมือนกับการสามารถกำหนดลำดับความสำคัญของตนเองและมีอำนาจในการจัดสรรทรัพยากรของตนเองตามที่เห็นสมควร) ฮาร์ดแวร์ไม่ใช่ปัญหา - เราสามารถจำลองได้อย่างมีประสิทธิภาพบนเซิร์ฟเวอร์ที่ทันสมัย หากภาษาโคบอลและภาษาเบสิกเป็นภาษาสมัยใหม่เรายินดีที่จะรับความเสี่ยงที่เราสามารถหาผู้แทนที่ปรึกษาปัจจุบันของเราได้ในอนาคต ดูเหมือนว่าควรจะมีรูปแบบธุรกิจสำหรับ บริษัท ที่ให้การสนับสนุนด้านไอทีซึ่งมุ่งเน้นไปที่แพลตฟอร์มดั้งเดิมเช่นนี้และให้ความสามารถด้านการเขียนโปรแกรมและการพัฒนาซอฟต์แวร์เพื่อสนับสนุนระบบเช่นของเราโดยขจัดความเสี่ยงในการค้นหาผู้เชี่ยวชาญด้านการเขียนโปรแกรมที่เหมาะสมและ งานของนักเขียนโปรแกรมอายุน้อยที่น่าเชื่อว่าพวกเขาสามารถมีอาชีพที่มีประสิทธิผลและได้ผลตอบแทนส่วนหนึ่งในภาษาที่เก่าและไม่เซ็กซี่เช่น BASIC กล่าวโดยย่อในฐานะผู้จัดการที่ไม่ใช่ฝ่ายไอทีเราจะจัดการการเปลี่ยนแปลงนี้ได้อย่างไร
13 legacy 

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

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

6
ข้อดีของเมนเฟรมคืออะไร [ปิด]
ตามที่เป็นอยู่ในปัจจุบันคำถามนี้ไม่เหมาะสำหรับรูปแบบคำถาม & คำตอบของเรา เราคาดหวังว่าคำตอบจะได้รับการสนับสนุนจากข้อเท็จจริงการอ้างอิงหรือความเชี่ยวชาญ แต่คำถามนี้อาจเรียกร้องให้มีการอภิปรายโต้แย้งโต้แย้งหรือการอภิปรายเพิ่มเติม หากคุณรู้สึกว่าคำถามนี้สามารถปรับปรุงและเปิดใหม่ได้โปรดไปที่ศูนย์ช่วยเหลือเพื่อขอคำแนะนำ ปิดให้บริการใน8 ปีที่ผ่านมา ข้อเสียของเมนเฟรมคือพื้นดี ราคาแพงมรดกชุมชนลดน้อยลง ฯลฯ ฉันไม่สนใจข้อเสียโดยเฉพาะอย่างยิ่ง แต่ฉันอยากรู้ว่ามีประโยชน์ใด ๆ กับฮาร์ดแวร์ / ซอฟต์แวร์เมนเฟรมในสภาพแวดล้อมของ Intel / AMD & Linux / Windows ปัจจุบัน ฉันได้รับแจ้งว่า MFs นั้นดีมาก (และดีกว่าเซิร์ฟเวอร์ปัจจุบัน) ที่โหลด I / O จำนวนมาก สิ่งนี้ยังคงเป็นจริงหรือไม่?
11 legacy  mainframe 

12
ในฐานะนักพัฒนาซอฟต์แวร์รุ่นใหม่ฉันควรกังวลเกี่ยวกับการใช้เทคโนโลยีที่ล้าสมัยหรือไม่? [ปิด]
ปิด. คำถามนี้เป็นคำถามปิดหัวข้อ ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้เป็นหัวข้อสำหรับ Software Engineering Stack Exchange ปิดให้บริการใน5 ปีที่ผ่านมา ฉันเป็นบัณฑิตวิทยาลัยเมื่อเร็ว ๆ นี้ (เมื่อเดือนพฤษภาคม!) ในขณะที่ฉันยังอยู่ในโรงเรียนฉันต้องการให้แน่ใจว่าฉันมีงานก่อนที่ฉันจะจบการศึกษาและเร็วมาก (อาจเร็วเกินไป) ในการหางานของฉันฉันตั้งรกรากอยู่ในภูมิภาคที่ฉันหวังว่าจะได้ย้าย . อย่างไรก็ตามฉันคาดเดาการตัดสินใจครั้งนี้มาหลายเดือนแล้วด้วยเหตุผลหลายประการ หนึ่งคือฉันไม่ได้ท้าทายการทำงานมากและฉันรู้สึกว่าฉันไม่ได้พัฒนาโปรแกรมมากนักตั้งแต่เริ่มต้นที่นี่ ฉันสามารถหาเวลาทำงานกับโอเพ่นซอร์ส (และมีในอดีต) นอกงานของฉันได้ตลอดเวลาดังนั้นฉันจึงมีสถานที่เพื่อแก้ไขความผิดหวังนี้ ที่สำคัญกว่านั้นฉันเป็นกังวลกับความจริงที่ว่างานของฉันคือการทำงานบนเว็บแอปพลิเคชัน Perl เก่า ๆ ที่ไม่น่าเชื่อ (ใช้ Mason และ ORM ในบ้านที่แปลก) ฉันกำลังยิงตัวเองที่นี่ด้วยการทำงานกับเทคโนโลยีที่ไม่เป็นที่นิยมอีกต่อไปและจะไม่ช่วยฉันในการหางานในอนาคตหรือไม่? ฉันไม่ค่อยเห็นงาน Perl และเมื่อฉันทำมันมักจะทำสิ่งที่ฉันไม่สนใจ (การพัฒนาเว็บส่วนหน้า) การเขียนโปรแกรมระบบ, การสร้างภาพ, การเขียนโปรแกรมเครือข่ายหรืออย่างน้อยแบ็กเอนด์การพัฒนาเว็บเป็นประเภทของหัวข้อที่ฉันสนุกกับการทำงานจริง ๆ - ดูเหมือนว่าประสบการณ์การทำงานในปัจจุบันของฉันจะช่วยให้ฉันทำสิ่งเหล่านี้ .
11 legacy  perl 

5
การเริ่มต้นสถาปัตยกรรมที่สอดคล้องกันในแอปพลิเคชันดั้งเดิม
ฉันมีความรับผิดชอบต่อเว็บไซต์ Asp.Net ขนาดใหญ่ ปัจจุบันเป็นเว็บไซต์ (ไม่ใช่เว็บแอปพลิเคชัน) บริการ windows บางอย่างและห้องสมุดคลาสจำนวนหนึ่ง ชั้นข้อมูลใช้การผสมผสานของLLBLGEN และ Linq To LLBGen เช่นเดียวกับอินสแตนซ์ของอินไลน์ SQL ดั้งเดิมที่ยังไม่ได้รับการปรับสภาพใหม่ มีการใช้งานประเภทผู้จัดการบางส่วน แต่ในหลาย ๆ กรณีแอปพลิเคชันแสดงรูปแบบการต่อต้าน Smart UI (เช่นตรรกะทางธุรกิจมากเกินไปในรหัสหลังคลาส) ไซต์นั้นมีการรับส่งข้อมูลที่สูงพอสมควรและประสิทธิภาพการทำงานก็ดี แต่เรากำลังเพิ่มขีดความสามารถในการพัฒนาของเราให้กับทีมงานประมาณ 10 คนและยิ่งชัดเจนมากขึ้นเราจำเป็นต้องมีการออกแบบเลเยอร์ที่ครอบคลุมบนมิดเดิลแวร์ที่มีอยู่ คำถามของฉันจะเริ่มตรงไหน? เรามีรหัส 10 ปี (บางส่วนยังคงเป็นเพียงแค่การย้ายข้อมูล ASP Classic) วิธีการที่แตกต่างและสไตล์ การสร้างฐานรหัสใหม่ทั้งหมดนั้นไม่จริงและอาจไม่เป็นที่ต้องการ ฉันรู้ว่านี่ไม่ใช่สถานการณ์ใหม่มีความคิดหรือแนวคิดที่มีประโยชน์เกี่ยวกับวิธีการแก้ไขปัญหานี้หรือไม่?

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

3
อะไรจะช่วยได้เมื่อทำการเปลี่ยนวิธีการขนาดใหญ่เพื่อให้แน่ใจว่าฉันจะไม่ทำลายอะไรเลย?
ขณะนี้ฉันกำลัง refactoring ส่วนหนึ่งของ codebase ขนาดใหญ่ที่ไม่มีหน่วยทดสอบใด ๆ ฉันพยายาม refactor code ในแบบที่โง่เง่านั่นคือการพยายามเดาว่าโค้ดกำลังทำอะไรและการเปลี่ยนแปลงใดที่จะไม่เปลี่ยนความหมาย แต่ไม่ประสบความสำเร็จ: มันสุ่มแยกคุณสมบัติรอบ ๆ codebase โปรดทราบว่าการเปลี่ยนโครงสร้างรวมถึงการย้ายรหัส C # ดั้งเดิมไปสู่รูปแบบการทำงานที่มากขึ้น (รหัสดั้งเดิมไม่ได้ใช้คุณสมบัติใด ๆ ของ. NET Framework 3 และใหม่กว่ารวมถึง LINQ) การเพิ่มข้อมูลทั่วไปที่รหัสอาจได้รับประโยชน์จากพวกเขาเป็นต้น ฉันไม่สามารถใช้วิธีการที่เป็นทางการได้เพราะจะมีค่าใช้จ่ายเท่าใด ในทางกลับกันฉันคิดว่าอย่างน้อย"กฎใด ๆ ที่ได้รับการปรับเปลี่ยนใหม่จะต้องมาพร้อมกับการทดสอบหน่วย"ควรปฏิบัติตามกฎอย่างเคร่งครัดไม่ว่าจะต้องเสียค่าใช้จ่ายเท่าใด ปัญหาคือเมื่อฉันสร้างส่วนเล็ก ๆ ของวิธีส่วนตัว 500 LOC การเพิ่มการทดสอบหน่วยดูเหมือนจะเป็นงานที่ยาก สิ่งใดที่สามารถช่วยฉันในการรู้ว่าการทดสอบหน่วยใดที่เกี่ยวข้องกับโค้ดบางส่วน ฉันเดาว่าการวิเคราะห์โค้ดแบบคงที่จะมีประโยชน์ แต่เครื่องมือและเทคนิคที่ฉันสามารถใช้เพื่อ: รู้ว่าฉันควรสร้างการทดสอบหน่วยใด และ / หรือทราบว่าการเปลี่ยนแปลงที่ฉันทำมีผลกับรหัสต้นฉบับในแบบที่มันทำงานแตกต่างจากนี้หรือไม่?

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

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