สิ่งที่ต้องทำความคิดเห็นทำให้รู้สึก? [ปิด]

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

//TODO translations

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

มันสมเหตุสมผลหรือไม่ที่จะเขียนความคิดเห็นนี้หรือควรเขียนลงในไวท์บอร์ด / กระดาษ / อย่างอื่นที่พวกเขายังคงอยู่ในความสนใจของนักพัฒนา?

ฉันมักจะใช้// todoความคิดเห็นสำหรับสิ่งที่ต้องเกิดขึ้น แต่ฉันไม่สามารถทำได้ทันที

ฉันยังตรวจสอบให้แน่ใจว่าฉันไล่ล่าพวกเขา - ฉันค้นหาพวกเขา (Visual Studio มีคุณสมบัติที่ดีที่มันจะแสดงรายการความคิดเห็นดังกล่าวสำหรับคุณ) และให้แน่ใจว่าสิ่งที่ทำ

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

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

IDEs สมัยใหม่รับรู้ถึงTODOความคิดเห็นและพวกเขาสามารถมองเห็นได้ในพาเนล / หน้าต่าง / แท็บของตัวเองดังนั้นพวกเขาจึงไม่หลงทางในทางทฤษฎี (ฉันกำลังคิด Eclipse และ Visual Studio ทั้งสองฉันรู้พอที่จะจำได้ว่าพวกเขาจำมันได้)

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

ตอนนี้ฉันเขียนว่า "ตามหลักวิชา" เพราะถึงแม้จะไม่หลงทางสิ่งที่ต้องทำมักจะเกี่ยวข้องกับบางสิ่งที่ไม่จำเป็นสำหรับแอปพลิเคชันในการทำงานอย่างถูกต้อง "ในขณะนี้" และ "ในขณะนี้" อาจขยายได้ 5 นาทีถึง 5 ปีขึ้นอยู่กับประเภท / ขนาดของโครงการ :-)

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

แก้ไข: ตามที่เขียนไว้ในบทความของ Wikipedia เกี่ยวกับความคิดเห็นรวมถึงวันที่และเจ้าของสิ่งที่ต้องทำถือเป็นแนวทางปฏิบัติที่ดี

อาจทำให้รู้สึกบางอย่างฉันใช้บางครั้ง จุดสำคัญคือการใช้แท็กที่สอดคล้องเช่นTODOหรือFIXMEเพื่อให้สามารถค้นหาได้ง่ายด้วยการค้นหาข้อความแบบง่าย

ตัวอย่างเช่นโซลูชัน "ฉบับย่อ" สกปรก "สะดวกต่อการติดป้ายกำกับเช่น:

ConnManager.getConnection("mydatabase"); // FIXME: DB name should be configurable

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

ในอุตสาหกรรมของฉันผู้พัฒนาได้รับการสนับสนุนให้สร้างรายการ JIRA (หรืออื่น ๆ ) แทนที่จะแสดงความคิดเห็นเพราะทุกคนไม่ได้มีโอกาสเห็น// todoรายการ แต่บางครั้งในโครงการขนาดใหญ่แอตทริบิวต์แบบกำหนดเองจะถูกกำหนดตามบรรทัดของ:

[AttributeUsageAttribute(AttributeTargets.All, AllowMultiple = true)]
public class DeveloperNote : Attribute
{
    public DateTime EntryDate { get; set; }
    public string Description { get; set; }
    public DeveloperNote(int year, int month, int day, string desc)
    {
        EntryDate = new DateTime(year, month, day);
        Description = desc;
    }
}

และจากนั้นวิธีการก็สามารถตกแต่งด้วยวิธีนี้ ...

[DeveloperNote(2011, 12, 13, "Make the db connection configurable")]

และอัพที่สูงขึ้นสามารถเข้ามาเก็บเกี่ยวได้โดยอัตโนมัติ มันอาจ overkill สำหรับการ// todoแจ้งเตือนที่เรียบง่ายแต่มีประสิทธิภาพ นอกจากนี้ยังต้องใช้แพลตฟอร์ม. NET

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

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

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

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

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

ฉันเคยเขียนมันในอดีต แต่ฉันพบว่าคุณมักจะไม่ตามพวกเขา

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

เพื่อช่วยฉัน CI build ของเราได้รับการตั้งค่าให้ล้มเหลวหากมี FIXMEs อยู่ในรหัส :-)

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

คุณสามารถเลือกใส่สิ่งที่ต้องทำด้วย ID ข้อผิดพลาด :-)

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

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

ConnManager.getConnection("mydatabase"); // FIXME: DB name should be configurable

คุณอาจเปลี่ยนสิ่งนั้นเป็นสิ่งที่ชอบ

ConnManager.getConnection(GetDatabaseName());

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

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

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

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

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

ในความเป็นจริงสิ่งใดที่ควรจะอยู่ในฐานข้อผิดพลาดของคุณที่มันอยู่

มีเสียงรบกวนในชีวิตเราไม่ควรสร้างสิ่งใหม่ที่ตะโกนเรียกร้องความสนใจในขณะที่มันต้องการที่อื่น

2 เซ็นต์ของฉัน

โดยปกติฉันจะไม่แสดงความคิดเห็น // TODO แต่ให้พวกเขาทั้งหมดแยกเป็นไฟล์ ยังคงไม่สามารถค้นหา / เขียนซอฟต์แวร์ออนไลน์เพื่อจัดการได้ง่ายดังนั้นไฟล์ TODO ยังคงมีประโยชน์มากที่สุดสำหรับฉันเพราะเมื่อฉันเปิดโครงการหลังจากช่วงเวลาสั้น ๆ ฉันลืมสิ่งที่ต้องทำตอนนี้จากนั้นฉันดูเป็นไฟล์ TODO และทำงาน . ฉันได้รับ "filename.cpp 354: Recode นี้ bla bla bla" และมันมีประโยชน์มากขึ้นจากนั้นค้นหา // ความคิดเห็น TODO ในไฟล์ ฉันทำ // TODO earler เมื่อฉันขี้เกียจ แต่ฉันเพิ่งลบ // // TODO-s เก่าเหล่านั้นออกจากไฟล์ต้นฉบับและไม่แก้ไขเมื่อโครงการทำงานได้ดี ฉันขอแนะนำให้ย้าย // สิ่งที่ต้องทำทั้งหมดจาก souce ไปยังที่ที่แยกจากกัน ลำดับความสำคัญเป็นสิ่งที่ยากลำบากจริง ๆ เมื่อคุณมีสิ่งที่ต้องทำทั้งหมดในไฟล์ต่าง ๆ และโครงการต่าง ๆ

ฉันคิดว่ามันยอดเยี่ยม แต่ไม่ใช่คนเดียว ตัวอย่างเช่น:

//TODO: ADD MY CLICK EVENT LOGIC
throw new Exception();
//Even a simple messageBox could suffice

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

ข้อได้เปรียบอย่างมากของสิ่งที่ต้องทำในการแสดงความคิดเห็นมากกว่าล้านวิธีอื่น ๆ อย่างใดอย่างหนึ่งสามารถสร้างรายการงานคือความคิดเห็นที่ต้องทำเดินทางด้วยรหัสเพื่อให้พวกเขาไม่สามารถแยก

อาจเป็นสถานที่ที่เหมาะสมกว่าสำหรับสิ่งนี้เป็นตัวติดตามปัญหามากกว่ารหัสแม้ว่า

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

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

บรรทัดล่าง: พวกเขาดีกว่าไม่ได้บันทึกปัญหาเลย แต่คุณต้องรักษาไว้

IntelliJ จะเตือนคุณหากคุณพยายามส่งรหัสที่มีสิ่งที่ต้องทำใหม่ ดังนั้นคุณสามารถตีความสิ่งที่ต้องทำเสมอว่า "สิ่งนี้จะเกิดขึ้นจริงตามเวลาที่ฉันกระทำ"

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

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

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

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

ใน Delphi:

{$message 'todo: free this thing when you know its not going to blow up'}

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

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