วิธีการเข้าถึงการปรับเปลี่ยนโปรแกรมประยุกต์บนเว็บที่มีอยู่ได้อย่างไร

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

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

ในแบบเดียวกันกับที่คุณใช้รหัสมรดก คุณพบชิ้นส่วนที่ทดสอบได้คุณเขียนแบบทดสอบและทดสอบซ้ำ

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

รหัสที่ไม่แสดงสิ่งต่าง ๆ ในเบราว์เซอร์ - รหัส "โครงสร้างพื้นฐาน" รุ่นสิ่งที่สัมผัสกับฐานข้อมูลอาจเป็นจุดเริ่มต้นที่ดี

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

มีหนังสือที่ยอดเยี่ยมเกี่ยวกับเรื่องนี้ที่เรียกว่า "การทำงานอย่างมีประสิทธิภาพด้วยรหัสมรดก" โดย Michael Feathers เอาหน้าเราทุกคนมีรหัสดั้งเดิม

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

• ใช่ - เว็บแอปพลิเคชันแตกต่างจากเว็บไซต์

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

• เริ่มใช้การควบคุมเวอร์ชัน

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

• ลดอนันต์

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

คุณต้องถามตัวเองว่า "ให้ url อะไรคือรูปแบบที่ทำให้เป็นมาตรฐาน?" เมื่อคุณได้กดลงนี้ จากนั้น URL ที่ลดลง 50,0000+ ไซต์บนไซต์ของคุณจะบอกว่า 2,000 ซึ่งง่ายกว่ามากในการทำความเข้าใจและจัดการในใจของคุณ

ดู: http://www.sugarrae.com/be-a-normalizer-a-c14n-exterminator/

• เริ่มต้นด้วยการสร้างแบบจำลอง 'อะไร' ไม่ใช่ไม่ใช่สิ่งที่คุณต้องการ

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

ดู: http://www.joelonsoftware.com/articles/fog0000000069.html

ดู: http://www.laputan.org/mud/

• วางไว้ภายใต้การทดสอบเป็นความคิดที่ดี

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

โปรดดู: http://www.simpletest.org/en/web_tester_documentation.html

• มีความกล้าหาญในความเชื่อมั่นของคุณ

วรรณกรรมส่วนใหญ่เกี่ยวกับแนวทางปฏิบัติที่ดีที่สุดในการพัฒนาซอฟต์แวร์คือ Centric App Center ในขณะที่ไซต์ของคุณยุ่งเหยิงคุณอ่านหนังสือเหล่านี้และคุณอาจกลัวความรู้ที่แสดงออกมาจากพวกเขา แต่อย่าลืมว่าการปฏิบัติที่ดีที่สุดนี้เกิดขึ้นในช่วงเวลาก่อนที่เว็บ / SEO จะกลายเป็นสิ่งสำคัญ คุณรู้มากมายเกี่ยวกับเว็บสมัยใหม่มากกว่าที่กล่าวถึงในหนังสือคลาสสิกเช่น POEA, Gof และอื่น ๆ อีกมากมายมีให้เลือกมากมาย แต่ไม่ควรละทิ้งประสบการณ์และความรู้ของคุณ

ฉันสามารถไปต่อ แต่สิ่งเหล่านี้คือสิ่งที่ฉันเลือกเมื่อทำการเปลี่ยนสภาพไซต์เก่าให้เป็นไซต์ใหม่ที่เป็นประกาย

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

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

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

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

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

ในที่สุดมันเป็นกระบวนการหลายขั้นตอน อย่าพยายามทำมันทั้งหมดในครั้งเดียว

ถ้ามันน่าเกลียดพอที่จะฉี่ฉันออกไปมันก็น่าเกลียดพอที่ฉันจะลบทุกสิ่งและเขียนการแทนที่

คุณจะพบว่าบ่อยครั้งกว่าจะใช้เวลาในการทำเช่นนี้เช่นเดียวกับการนั่งที่นั่นและปลายนิ้วเท้ารอบ ๆ ระเบียบที่ไม่มีการรวบรวมกันและไม่มีเอกสารและจับมันเบา ๆ