การเริ่มต้นสถาปัตยกรรมที่สอดคล้องกันในแอปพลิเคชันดั้งเดิม

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

ชั้นข้อมูลใช้การผสมผสานของLLBLGEN และ Linq To LLBGen เช่นเดียวกับอินสแตนซ์ของอินไลน์ SQL ดั้งเดิมที่ยังไม่ได้รับการปรับสภาพใหม่

มีการใช้งานประเภทผู้จัดการบางส่วน แต่ในหลาย ๆ กรณีแอปพลิเคชันแสดงรูปแบบการต่อต้าน Smart UI (เช่นตรรกะทางธุรกิจมากเกินไปในรหัสหลังคลาส)

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

คำถามของฉันจะเริ่มตรงไหน? เรามีรหัส 10 ปี (บางส่วนยังคงเป็นเพียงแค่การย้ายข้อมูล ASP Classic) วิธีการที่แตกต่างและสไตล์

การสร้างฐานรหัสใหม่ทั้งหมดนั้นไม่จริงและอาจไม่เป็นที่ต้องการ

ฉันรู้ว่านี่ไม่ใช่สถานการณ์ใหม่มีความคิดหรือแนวคิดที่มีประโยชน์เกี่ยวกับวิธีการแก้ไขปัญหานี้หรือไม่?

ฉันยังทำงานในสถานการณ์ที่คล้ายกันและฉันสามารถให้คำแนะนำต่อไปนี้

1. คุณจะต้องลดหนี้ทางเทคนิค ตอนนี้ ทำไม? เพราะหนี้ทางเทคนิคเป็นเหมือนหนี้ทางการเงิน คุณจะจ่ายดอกเบี้ยมัน
2. เนื่องจากการปรับเปลี่ยนรหัสฐานทั้งหมดไม่สามารถทำได้ให้ถามตัวคุณเองว่าอะไรที่ป้องกันไม่ให้เกิดขึ้น? มันทำงานมากเกินไปหรือเปล่า ทำไม?
3. สร้างแผนเพื่อลดหนี้ทางเทคนิคในเวลา ตัวอย่างเช่นโดยการตั้งค่ากฎเป็น " โค้ดทุกบิตที่ทีมสัมผัสต้องได้รับการแก้ไข / สร้างใหม่ให้เป็นมาตรฐานใหม่ " โดยทั่วไป: การทดสอบหน่วยจะต้องเขียนรหัสจะต้องย้ายในชั้นที่ถูกต้อง ฯลฯ นี้ช่วยให้คุณสามารถแก้ไขรหัสจำนวนมากโดยไม่ต้องหันไปโครงการ "เปลี่ยน" ที่มีราคาแพงและน่าขัน
4. ห่ออึ Decoupling เป็นกุญแจสำคัญในการปรับโครงสร้างและสถาปัตยกรรมที่ดี หากคุณสามารถแบ่งรหัสฐานได้คุณสามารถ refactor บิตที่เล็กลงได้
5. อย่าเพิ่มหนี้เทคโนโลยีอีกต่อไป อย่าเพิ่มหนี้เทคโนโลยีอีกต่อไป อย่าเพิ่มหนี้เทคโนโลยีอีกต่อไป อย่า...

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

คำแนะนำเพิ่มเติมจากสิ่งที่ Sklivvz พูดว่า:

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

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

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

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

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

มีหนังสือ / pdf ฟรีที่ดีมากสำหรับการปรับรื้อซอฟต์แวร์แบบดั้งเดิม: http://scg.unibe.ch/download/oorp/

มันบอกว่า OO ในชื่อ แต่ความคิดส่วนใหญ่ใช้กับซอฟต์แวร์ใด ๆ มันอธิบายถึงที่จะเริ่มต้นวิธีการจัดการกับส่วนต่าง ๆ ของระบบในระหว่างการปรับโครงสร้างและหัวข้อเหล่านั้นอีกมากมาย

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

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

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

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