แนวทางปฏิบัติที่ดีที่สุดสำหรับการยกเลิกโค้ดที่ล้าสมัยคืออะไร


9

ฉันต้องการเลิกใช้วิธีที่ล้าสมัย ฉันตระหนักถึง[Obsolete]คุณลักษณะ Microsoft มีแนวทางปฏิบัติที่ดีที่สุดที่แนะนำสำหรับการทำสิ่งนี้หรือไม่?

นี่คือแผนปัจจุบันของฉัน:

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

B. ทำเครื่องหมายวิธีเก่าที่ล้าสมัย

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

ผลลัพธ์:

[Obsolete("Please don't use this anymore because it does not implement IMyDbProvider.  Use XXX instead.")];
        /// <summary>
        /// 
        /// </summary>
        /// <param name="settingName"></param>
        /// <returns></returns>
        public static Dictionary<string, Setting> ReadSettings(string settingName)
        {
            return ReadSettings(settingName, SomeGeneralClass.ConnectionString);
        }

        public Dictionary<string, Setting> ReadSettings2(string settingName)
        {
            return ReadSettings(settingName);// IMyDbProvider.ConnectionString private member added to class.  Probably have to make this an instance method.
        }

คำตอบ:


5

Microsoft ใช้แอตทริบิวต์ [ล้าสมัย] เพื่อบอกนักพัฒนาว่าวิธีการคุณสมบัติหรือคลาสเลิกใช้แล้วและอาจมีการเปลี่ยนแปลง (หรือไม่สนับสนุนเลย) ในการวางจำหน่ายในอนาคต

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

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

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


การปฏิบัติของ Microsoft โดยทั่วไปคือการลบสิ่งที่เลิกใช้แล้วในการออกรุ่นใหญ่ครั้งต่อไป ในทางตรงกันข้าม Java จะไม่ลบสิ่งที่ไม่รองรับดังนั้นมันขึ้นอยู่กับคุณ
— Scott C Wilson

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

4

เนื่องจากการใช้งานมีการเปลี่ยนแปลง (ไม่ใช่ลายเซ็นเมธอด) ฉันต้องเปลี่ยนชื่อเมธอดแทนการสร้างโอเวอร์โหลด

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

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


นั่นเป็นอุดมคติที่ดี ปัญหาคือเราไม่มีสายรัดทดสอบอยู่ นั่นเป็นอีกประเด็นหนึ่งที่ฉันหวังว่าจะได้รับการแก้ไขทั้งหมด ดังนั้นเนื่องจากไม่มีการทดสอบการรวมฉันไม่สามารถทำสิ่งที่คุณแนะนำ ยังมีการขึ้นต่อกันที่ไม่ได้กำหนดจำนวนมากเกินไปซึ่งจะไม่ได้รับการทดสอบ
— P.Brian.Mackey

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

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

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