แนะนำให้มีการเปลี่ยนแปลงครั้งใหญ่ / เขียนใหม่เป็นนักศึกษาฝึกงาน [ปิด]

บริบท:

• มันเป็นโครงการภายใน (ที่ฉันไม่คิดว่ามีผู้ใช้งานมากมาย)
• มันเก่า
• เรากำลังอัพเดท

ประเด็น:

1. มันละเมิดเฟรมเวิร์ก mvc (ไม่ใช้รุ่น, ตรรกะทางธุรกิจในมุมมอง, ฯลฯ )
2. สิ่งที่เรากำลังขอให้ทำมีขนาดเล็ก แต่เนื่องจากการติดต่อกันต่ำเรามีสองตัวเลือก:
   1. ทำสิ่งต่อไปให้เรียบร้อย
   2. ย้ายชิ้นโค้ดขนาดใหญ่ไปรอบ ๆ หรือเขียนสิ่งใหม่

การแก้ปัญหา (ฉันเห็น):

1. ทำงานกับมันต่อไปอย่าเพิกเฉยแนวปฏิบัติที่ดีที่สุดเพื่อไม่ให้ถูกทำเร็ว ๆ นี้และไม่แนะนำข้อบกพร่องใหม่ด้วยการเปลี่ยน / เขียนใหม่
2. refactor / เขียน

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

ตกลงไปเลย

คุณคิดว่าแอปพลิเคชันมีโครงสร้างที่ไม่ดีและเขียนได้ไม่ดี

ลูกค้าคิดว่าทำงานได้ดี

คุณต้องการเขียนซ้ำโดยไม่มีเหตุผลอื่นนอกจากเพื่อปรับปรุง "ความงามภายใน"

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

การคัดค้านหลักในการเขียนโค้ดที่มีโครงสร้างไม่ดีคือมันยากที่จะเข้าใจ

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

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

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

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

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

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

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

หากคุณคิดว่าไม่เป็นความจริงคุณจะต้องทำเรื่องให้มากกว่าที่คุณทำที่นี่

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

คุณเป็นเด็กฝึกงาน สมมุติว่าคุณเป็นแบรนด์ใหม่ พวกเขาอาจสงสัยว่าคุณเป็นคนงี่เง่า

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

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

ในที่สุดเมื่อคุณแสดงความสามารถและความรู้ของคุณคุณอาจจะสามารถดึงข้อเสนอแนะหรือสอง

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

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

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

แต่มันไม่เจ็บที่จะถามคนรอบข้างและถ้าคุณทำคุณจะได้เรียนรู้อะไรบางอย่าง และนั่นคือ 7983879342 นั่นคือการฝึกงาน

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

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

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

อย่างไรก็ตามนั่นไม่ได้หมายความว่าคุณควรลืมกฎลูกเสือ :

ออกจากที่ตั้งแคมป์สะอาดกว่าที่คุณพบ

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

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

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

การเปลี่ยนแปลงส่วนใหญ่เกิดขึ้นแบบค่อยเป็นค่อยไปตามกฎทั่วไป

สิ่งเล็ก ๆ น้อย ๆ ที่ควรทราบ;

• ประวัติของแอปพลิเคชั่นคืออะไร?
• ทำไมวันนี้น่าเกลียด
• ประโยชน์ของการเปลี่ยนแปลงทางสถาปัตยกรรมคืออะไร?

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

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

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