ข้อผิดพลาดนับพัน!

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

และปัญหาคือมันเต็มไปด้วยข้อผิดพลาด บางส่วนของมันย้อนหลังไปถึงศตวรรษที่ผ่านมาเมื่อไม่มีมาตรฐานเว็บและฉันไม่สนใจเกี่ยวกับโหมด Quirks widthและheightคุณลักษณะแทน CSS, ตารางที่ใช้สำหรับการจัดวางเฟรมเซต ฯลฯ แต่โอ้ข้อผิดพลาดเหล่านั้นทั้งหมด! width="20px"ทั่วทุกสถานที่onchange="javascript:..."และในสถานที่ที่พวกเขาใช้ CSS style="width:20"และstyle="width=20px"เป็นเรื่องธรรมดา ไม่ต้องพูดถึงสายมากมายที่มีความขัดแย้งwidthและstyleคุณลักษณะ เป็นต้น ฯลฯ
เป็นผลให้แอปพลิเคชันเว็บทำงานภายใต้ IE เท่านั้นและในโหมดความเข้ากันได้เท่านั้น เป็นที่ชัดเจนว่านักพัฒนาไม่เคยดูความถูกต้องของรหัสเฉพาะเมื่อสิ่งที่ออกมาดูเหมือนสิ่งที่พวกเขามีอยู่ในใจมันควรมีลักษณะเช่นนั้น

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

ดูเหมือนว่าคุณกำลังสับสนหลายสิ่งในคำว่า "ข้อผิดพลาด"

• แอตทริบิวต์ html ดั้งเดิม
• สไตล์การเข้ารหัส
• ข้อผิดพลาดในการเขียนโค้ดซึ่งไม่ก่อให้เกิดข้อบกพร่อง
• ข้อบกพร่องที่ไม่ได้รายงาน
• ข้อผิดพลาดซึ่งตอนนี้มีคุณสมบัติ
• รายงานข้อบกพร่อง
• รายงานข้อบกพร่องที่คุณได้รับมอบหมายให้แก้ไข

ในแอปรุ่นเก่าที่จะถูกแทนที่ข้อผิดพลาดประเภทใดประเภทหนึ่งเหล่านี้เท่านั้นที่ควรเกี่ยวข้องกับคุณ สุดท้าย.

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

• ข้อผิดพลาดซึ่งตอนนี้มีคุณสมบัติ

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

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

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

สิ่งที่คุณถามไม่ใช่คำถามด้านเทคนิคและไม่มีใครที่นี่สามารถตอบได้

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

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

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

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

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

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

เหตุผลที่จะไม่ทำการเปลี่ยนแปลงครั้งใหญ่:

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

สอง: ถ้าคุณทำการเปลี่ยนแปลงมากมายโดยเฉพาะอย่างยิ่งการค้นหาและแทนที่ด้วยจำนวนมากคุณจะแนะนำข้อบกพร่อง ไม่ใช่คุณอาจแนะนำบั๊ก: คุณจะ สมมติว่าคุณทำ S&R และเปลี่ยน "width = 200" เป็น "width: 200px" มีรหัส C # หรือ VB ใน ASP ของคุณหรือไม่ เพราะถ้าคุณมีตัวแปรชื่อ "ความกว้าง" ที่คุณตั้งไว้ที่ 200 คุณก็ทำลายมัน (หรือสำหรับเรื่องนั้นคุณคิดว่าจะ จำกัด S&R เป็นหน้า ASP หรือไม่) หรือหากคุณเปลี่ยน "width: 200" เป็น "width: 200px" จะเกิดอะไรขึ้นถ้ามีรหัสที่ระบุว่า "width: 200mm" "? ตอนนี้มันบอกว่า "width: 200pxmm" เอาล่ะสมมติว่าคุณคิดถึงสิ่งเหล่านั้น เกิดอะไรขึ้นถ้ามีบางแห่งที่มีสเปคความกว้างที่ไม่ถูกต้องซึ่งแน่นอนว่าไม่สนใจ คุณ "แก้ไข" ความกว้างและตอนนี้วางไว้ที่ 200px ... และหน้าจอถูกทำให้เมาขึ้นเนื่องจากในความเป็นจริงแล้วความละเอียดที่ผิดจะให้ความกว้างผิด 200px และใช้งานได้เพราะค่านั้นถูกเพิกเฉยเท่านั้น? Mass S & R นั้นอันตรายมากเพราะคุณเกือบจะไม่ได้เรียนทุกที่ที่คุณเปลี่ยนไป คุณอาจไม่แน่ใจว่าจะต้องทดสอบอะไร

สาม: รหัสที่ "ชัด" ผิดอาจเป็นสิ่งที่ผู้ใช้ต้องการ ฉันเห็นข้อกำหนดจำนวนมากที่เรียกร้องให้มีพฤติกรรมที่ผิดและบ้าไปแล้ว ... จากนั้นฉันกลับไปที่ผู้ใช้และถามสิ่งที่พวกเขาต้องการจริงๆและปรากฎว่าพวกเขาต้องการพฤติกรรมที่บ้าคลั่งจริง ๆ เพราะนั่นคือ ธุรกิจของพวกเขาทำงานอย่างไรหรือระเบียบข้อบังคับของรัฐบาลต้องการหรืออะไรก็ตาม

แม้ว่าพฤติกรรมนั้นผิดปกติ แต่ผู้ใช้อาจคาดหวังและพวกเขาพยายามแก้ไขมันเป็นประจำและโดยการแก้ไขคุณจะทำลายวิธีแก้ปัญหาของพวกเขา ตัวอย่าง: ฉันทำงานในระบบที่เรามีสถานที่ที่คุณระบุจากและถึงวันที่มีการขายให้แก่สาธารณะ ทั้งสองวันเป็นเที่ยงคืนที่เริ่มต้นในวันนั้นดังนั้นถ้าคุณพูดว่า "ถึง 30 กรกฎาคม" นั่นหมายความว่ามันจบลงด้วยการสิ้นสุดของวันที่ 29 กรกฎาคมนั่นคือหนึ่งนาทีก่อน 12:01 น. 30 กรกฎาคมไม่ใช่ตอนท้ายของวันที่ 30 กรกฎาคม มีอยู่ช่วงหนึ่งที่ฉันแก้ไขสิ่งนี้ แต่ฉันทำได้เพียงเพราะมีคนไม่ถึงครึ่งโหลที่มีอำนาจใช้หน้าจอนั้นและฉันสามารถบอกพวกเขาทั้งหมดว่าฉันได้แก้ไขแล้ว หากมีผู้ใช้หลายร้อยคนและพวกเขาก็รู้ว่าตอนนี้คุณต้องให้วันหลังจากวันที่ผ่านไปจริงๆ "การแก้ไข" ของฉัน

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

ฉันไม่เห็นว่าทำไม ความมุ่งมั่นควรเป็นแนวคิดหนึ่งสิ่ง แต่ฉันเห็นว่าไม่มีเหตุผลว่าทำไมคนทั่วโลกค้นหาและแทนที่จากstyle="width=20"ถึงstyle="width: 20px"จะไม่นับว่าเป็น "สิ่งเดียว" ซึ่งเป็นแนวคิดการพูด และถ้ามันจะช่วยให้คุณนอนหลับได้ดีขึ้นช่วยให้คุณประหยัดสมาธิในขณะที่คุณแก้ไขสิ่งอื่น ๆ และไม่ทำให้สกปรกมากขึ้นทำไมล่ะ?

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

สิ่งที่ฉันจะทำในสถานการณ์ของคุณคือจะทำให้รายการของชั้นเรียนปัญหาที่ฉันต้องการจะดู เช่นการแทนที่style="width=(\d+)"ด้วยstyle="width: \1px"(ซึ่งอาจแก้ไขได้ด้วยการค้นหาทั่วโลก / แทนที่โดยใช้ regexp - ขออภัยถ้าของฉันไม่ได้ 100%) จะเป็นหนึ่งชั้นและถ้ามีเพียงหนึ่งเกิดขึ้นดังนั้นไม่ว่าจะเป็น สำหรับแต่ละหมวดหมู่รายการลำดับความสำคัญ (เร่งด่วนมากแค่ไหนในการทำสิ่งนี้) และการประเมินผลงาน (ใช้เวลานานแค่ไหนในการทำหมวดหมู่นี้)

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

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