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

ฉันทำงานในโครงการขนาดใหญ่ (เช่นการรวมกันของโครงการขนาดเล็กจำนวนมากที่ไม่สามารถแยกออกจากกันได้ง่ายเนื่องจากการจัดการการพึ่งพาที่ไม่ดี แต่เป็นการสนทนาที่แตกต่างกัน) ใน Java โดยใช้ eclipse เราได้ปิดคำเตือนจำนวนหนึ่งจากการตั้งค่าคอมไพเลอร์และโครงการยังคงมีคำเตือนมากกว่า 10,000 รายการ

ฉันเป็นผู้สนับสนุนที่ยิ่งใหญ่ในการพยายามจัดการกับคำเตือนทั้งหมดแก้ไขทั้งหมดถ้าเป็นไปได้และสำหรับผู้ที่ถูกมองว่าปลอดภัยและปราบปรามพวกเขา (เช่นเดียวกับความหลงใหลในศาสนาของฉันด้วยการทำเครื่องหมายวิธีการที่นำไปใช้ / overriden ทั้งหมดเป็น @Override) ข้อโต้แย้งที่ใหญ่ที่สุดของฉันคือคำเตือนทั่วไปช่วยให้คุณพบข้อบกพร่องที่อาจเกิดขึ้นระหว่างการรวบรวม อาจจะหมดไป 99 จาก 100 ครั้งคำเตือนนั้นไม่มีนัยสำคัญ แต่ฉันคิดว่าหัวหน้าเกาว่าประหยัดได้หนึ่งครั้งเพื่อป้องกันข้อผิดพลาดที่สำคัญมันคุ้มค่า (เหตุผลอื่นของฉันคือ OCD ของฉันชัดเจนด้วยรหัสความสะอาด)

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

ฉันจะโน้มน้าวให้เพื่อนร่วมทีมของฉัน (หรืออำนาจที่เป็น) ว่าคำเตือนต้องได้รับการแก้ไข (หรือระงับเมื่อสอบสวนอย่างเต็มที่) ได้อย่างไร หรือฉันควรโน้มน้าวตัวเองว่าฉันบ้า?

ขอบคุณ

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

คุณสามารถทำสองสิ่ง

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

2. รวบรวมประวัติศาสตร์ของความล้มเหลวที่น่าทึ่งที่เกิดขึ้นจากการเตือนที่ไม่สนใจ การค้นหาเว็บสำหรับ "ใส่ใจกับคำเตือนของคอมไพเลอร์" จะส่งคืนเกร็ดเล็กเกร็ดน้อย

ความหลงใหลในตัวคุณ@Overrideไม่ใช่ "ความหลงใหล" นั่นคือสิ่งที่ดี เคยสะกดชื่อวิธีหรือไม่?

การอ่านที่เกี่ยวข้องที่นี่ C ++ แต่ยังเกี่ยวข้อง ฉันชอบตัวอย่างนี้โดยเฉพาะ (ความคิดเห็นรหัสเป็นของฉัน):

int searchArray(int to_search[], int len, int to_find)
{
    int i;
    for( i = 0; i < len; ++i )
    {       
        if ( to_search[i] == to_find )
        {
            return i;
        }
    }
    // should be returning designated 'not found' value (0, -1, etc)
}

บ่อยครั้งที่คำเตือนจะหมายถึงความแตกต่างระหว่างแอปพลิเคชันที่ล้มเหลวด้วยข้อผิดพลาดซึ่งจริง ๆ แล้วจะช่วยให้คุณติดตามข้อบกพร่องในการออกแบบและแก้ไข (เช่นการพิมพ์ที่ปลอดภัย ) หรือแอปพลิเคชัน หรือมีลักษณะผิดพลาด (ซึ่งเป็นกรณีที่มีการพิมพ์ผิดที่ไม่ปลอดภัย ) ในทำนองเดียวกันพวกเขายังชี้ให้เห็นรหัส cruft หรือ dead ซึ่งสามารถลบออกได้ (บล็อกโค้ดที่ไม่สามารถเข้าถึงตัวแปรที่ไม่ได้ใช้) ซึ่งสามารถพิจารณาการเพิ่มประสิทธิภาพโค้ดหรือ unaccounted สำหรับกรณีที่จะแสดงในการทดสอบเช่นตัวอย่างข้างต้นสำหรับ C ++ โปรดทราบว่าตัวอย่างนี้ส่งผลให้เกิดข้อผิดพลาดในการคอมไพล์ใน Java

ดังนั้นการแก้ไขคำเตือนจึงมีข้อดีหลายประการสำหรับการจัดการ:

1. โอกาสที่รหัสน้อยลงจะทำงานอย่างไม่ถูกต้องกับข้อมูลที่ผู้ใช้ป้อนซึ่งสำหรับผู้ที่เกี่ยวข้องกับภาพลักษณ์ของ บริษัท และการจัดการข้อมูลลูกค้าควรเป็นเรื่องใหญ่ (tm) การหยุดทำงานเพื่อป้องกันผู้ใช้จากการทำสิ่งที่โง่นั้นดีกว่าไม่กระแทกและปล่อยให้พวกเขาทำ
2. หากพวกเขาต้องการที่จะสับเปลี่ยนบุคลากรผู้คนสามารถเข้าใช้งานโค๊ดเบสได้โดยไม่มีการเตือน (และไม่ทำให้ประหลาดใจหรือบ่นมาก .. ) บางทีนี่อาจลดปริมาณการบ่นที่เกิดขึ้นหรือความคิดเห็นเกี่ยวกับความสามารถในการบำรุงรักษาหรือคุณภาพของการสนับสนุนของ Team X ต่อ Project Y
3. การปรับโค้ดให้เหมาะสมโดยการลบคำเตือนของคอมไพเลอร์ในขณะที่ไม่ให้การปรับปรุงที่สำคัญกับเวลาทำงานจะเป็นการปรับปรุงคะแนนจำนวนมากเมื่อมาถึงการทดสอบ:
   • คะแนนความครอบคลุมโค้ดใด ๆ จะเพิ่มขึ้น
   • การทดสอบขอบเขตและกรณีทดสอบที่ไม่ถูกต้องอาจประสบความสำเร็จได้บ่อยกว่า (เนื่องจากการพิมพ์ที่ปลอดภัยดังกล่าวข้างต้นและอื่น ๆ )
   • เมื่อกรณีทดสอบล้มเหลวคุณไม่ต้องคิดว่าเป็นเพราะคำเตือนของคอมไพเลอร์ในไฟล์ต้นฉบับนั้นหรือไม่
   • มันง่ายที่จะพิสูจน์ว่าศูนย์เตือนคอมไพเลอร์ดีกว่าหลายพัน ไม่มีคำเตือนหรือข้อผิดพลาดพูดเกี่ยวกับคุณภาพของรหัสดังนั้นคุณสามารถยืนยันได้ว่าคุณภาพของรหัสปรับปรุงการแจ้งเตือนที่น้อยลง
4. หากคุณไม่มีคำเตือนของคอมไพเลอร์และมีคำแนะนำอย่างน้อยหนึ่งอย่างมันจะง่ายกว่าที่คุณจะรู้ว่าใครเป็นสาเหตุให้สิ่งเหล่านั้นปรากฏใน codebase หากคุณมีนโยบาย "ไม่มีคำเตือน" นั่นจะช่วยให้พวกเขาระบุคนที่ไม่ทำงานอย่างถูกต้องหรือไม่? เขียนโค้ดไม่ได้เป็นเพียงเกี่ยวกับการทำงานของบางสิ่งบางอย่างมันเป็นเรื่องของการทำให้มันทำงานได้ดี

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

ฉันเคยทำงานในโครงการที่มีลักษณะคล้ายกันในอดีต โดยเฉพาะอย่างยิ่งสิ่งนี้ถูกเขียนขึ้นครั้งแรกใน Java 1.4 เมื่อ Java 5 ที่มี generics ออกมาแล้วสามารถจินตนาการได้ว่าจำนวนคำเตือนที่คอมไพเลอร์โยนสำหรับการใช้ Collections API ทุกครั้ง

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

เวลาที่ใช้ในข้อบกพร่องในรหัสดั้งเดิมหรือรหัสที่ไม่ได้มาตรฐาน (มาตรฐานคือมาตรฐานการเข้ารหัสของโครงการของคุณ) ที่สามารถหลีกเลี่ยงได้

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

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

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

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

1. กำหนด 'บันทึกการกระทำ' สำหรับแต่ละโครงการ Java ของคุณเช่นรหัสการจัดรูปแบบตัวแปรท้องถิ่นที่ไม่ได้ใช้การจัดระเบียบการนำเข้า (ฉันคิดว่าไม่มีใครมีข้อคัดค้านในการทำความสะอาดเช่นนี้)
2. กำหนดตัวเลือกการรวบรวมเฉพาะโครงการสำหรับแต่ละโครงการ ตัวอย่างเช่นระดับการคอมไพล์ (หากรหัสของคุณต้องเข้ากันได้กับ 1.4 เพื่อล้างคำเตือนที่เกี่ยวข้องกับทั่วไป) การกำหนดไม่มีผลกระทบ (เช่น 'x = x') เป็นต้น คุณและเพื่อนร่วมทีมของคุณสามารถทำข้อตกลงสำหรับรายการเหล่านั้นและ Eclipse จะรายงานว่า 'ข้อผิดพลาด' ในขั้นตอนการพัฒนาของคุณหลังจากที่คุณมีข้อตกลงสำหรับข้อผิดพลาดในการรวบรวม

Eclipse จะสร้างไฟล์คุณสมบัติบางไฟล์สำหรับการตั้งค่าเหล่านั้นภายใต้โฟลเดอร์. setset คุณสามารถคัดลอกไฟล์ไปยังโครงการ Java อื่น ๆ และตรวจสอบไฟล์เหล่านั้นใน SCM เป็นส่วนหนึ่งของซอร์สโค้ด

คุณสามารถตรวจสอบรหัสของ Eclipse เพื่อดูว่านักพัฒนา Eclipse ทำอย่างไร

คุณมีสองวิธีในการกำจัดคำเตือนทั้งหมด (และฉันยอมรับว่ามันสามารถซ่อนบั๊กที่บอบบาง):

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

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

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

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

คุณจะต้องใช้ความอดทนอย่างมากในการพยายามโน้มน้าวพวกเขาการลบคำเตือนเมื่อทำการเขียนโปรแกรมคู่จะช่วยให้ผู้อื่นรับนิสัย แนะนำให้อ่าน 'ข้อ 24 ของ Java ที่มีประสิทธิภาพ: กำจัดคำเตือนที่ไม่ได้ตรวจสอบ' (สำหรับคอลเลกชันทั่วไป) และอาจไม่สนใจหลาย ๆ กรณีเมื่อผู้คนไม่ปฏิบัติตามคำแนะนำของคุณ;)

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

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

2. ติดตั้งเซิร์ฟเวอร์ CI ด้วยการทดสอบทั้งหมดที่ผ่าน (ถ้าคุณไม่มีการทดสอบให้เขียนแบบรวดเร็วที่ผ่านเพื่อให้ทุกคนเห็นว่าเป็นสีเขียว)

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

4. อัพเดตเซิร์ฟเวอร์ CI เพื่อให้การทดสอบล้มเหลวหากมีคำเตือนใด ๆ สิ่งนี้จะเห็นได้จากฝ่ายบริหารและทีมงานซึ่งนำไปสู่การเพิ่มวินัยของทีมอย่างเป็นระบบและไม่มีใครต้องการรับผิดชอบต่ออีเมลล้มเหลวทั้งหมดที่เกิดขึ้น

5. (เป็นทางเลือก) เพิ่มความสวยงามและน่ามองด้วยการเพิ่มแดชบอร์ดที่มองเห็นได้โคมลาวาไฟกระพริบ ฯลฯ เพื่อระบุสถานะของงานสร้างและผู้ที่ทำลายมัน / แก้ไข