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

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

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

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

ฉันไม่แน่ใจว่าเหมาะสมหรือไม่ที่จะขัดกับอนุสัญญาการเข้ารหัสปัจจุบันหรือว่าฉันควรกัดสัญลักษณ์แสดงหัวข้อย่อยและทำให้รหัสสับสนมากขึ้นสำหรับฉันในการเขียน

โดยสรุปฉันกำลังเปรียบเทียบ

showAlarms(){
    // tons of code
}

ต่อต้าน

showAlarms(){
   alarm1();
   alarm2();
   return;
}

alarm1(){
    ...
    printf(...);
    return;
}

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

UPDATE: พวกเขาจบลงด้วยความสุขกับรหัสที่แยกเป็นสัดส่วนและมีคนมากกว่าหนึ่งคนที่ขอบคุณฉันสำหรับการตั้งค่าแบบอย่างนี้

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

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

lockMutex(&mutex);
int rval;
if (...)
{
    ...
    rval = foo();
}
else
{
    ...
    rval = bar();
}
unlockMutex(&mutex);
return rval;

เป็น OO สดใสและเงางาม c ++ นักพัฒนาฉันเป็นฉันทันทีเรียกว่าพวกเขาออกมาเกี่ยวกับความเสี่ยงข้อผิดพลาดที่พวกเขาได้โดยการล็อกและปลดล็อก mutexes แทนที่จะใช้RAII ฉันยืนยันว่าสิ่งนี้ดีกว่า:

MutexLocker lock(mutex);
if (...)
{
    ...
    return foo();
}
else
{
    ...
    return bar();
}

ง่ายกว่ามากและปลอดภัยกว่าใช่มั้ย! เหตุใดจึงต้องให้นักพัฒนาซอฟต์แวร์ต้องจำเพื่อปลดล็อก mutexes ของพวกเขาบนเส้นทางการควบคุมทั้งหมดเมื่อคอมไพเลอร์สามารถทำเพื่อคุณ!

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

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

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

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

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

ภาคผนวกเนื่องจากความคิดเห็นที่: "300 บรรทัด" และ "ยากต่อการใช้" เป็นตัวบ่งชี้ที่แข็งแกร่งของ IMHO สำหรับรหัสที่ไม่ดี จากประสบการณ์ของฉันมันไม่น่าเป็นไปได้มากที่จะมี "เหตุผลทางเทคนิคที่ซ่อนอยู่" ทำไมรหัสดังกล่าวไม่สามารถนำไปใช้ในรูปแบบที่อ่านได้มากขึ้นเทียบได้กับตัวอย่างของคำตอบของ Cort Ammon อย่างไรก็ตามฉันเห็นด้วยกับ Cort คุณควรปรึกษาเรื่องนี้กับผู้รับผิดชอบในทีม - เพื่อไม่หาเหตุผลที่คลุมเครือว่าทำไมรหัสหรือสไตล์ "แบบนี้" ไม่สามารถเปลี่ยนแปลงได้ .

เลขที่

ในหนังสือเล่มนี้Programmer ศาสตร์การเจรจาเขียนเกี่ยวกับทฤษฎีหน้าต่างแตกสลาย

ทฤษฎีนี้รัฐ:

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

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

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

และคำตอบคือ: ไม่

เมื่อคุณออกจากหน้าต่างที่เสียหาย - ในกรณีของเรารหัสที่ไม่ถูกต้อง - สิ่งนี้จะสร้างเอฟเฟกต์ที่ทุกคนจะทิ้งหน้าต่างแตกไว้ข้างหลัง

และวันหนึ่งรหัสก็จะ colapse

มอบสำเนาของClean CodeและClean Coderให้กับทุกคน

และในขณะที่คุณอยู่ในหัวข้อสำเนาของTDDก็เป็นสิ่งที่ดีเช่นกัน

ใช่ไปเลย โครงสร้าง! = สไตล์

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

ระวัง

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

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

สุภาพอ่อนโยน

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

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

คำตอบคือในการตรวจสอบรหัส

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

ฉันก็เหมือนกับคนส่วนใหญ่ที่นี่เชื่อว่า 300 ฟังก์ชั่นสายเป็นสิ่งที่น่ารังเกียจ อย่างไรก็ตามการพา Windex ไปที่หลุมฝังกลบจะไม่ทำสิ่งที่ดีมาก ปัญหาไม่ใช่รหัส แต่เป็นตัวแปลงสัญญาณ

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

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

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

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

บางครั้งคุณต้องไปกับกระแส

อย่างที่คุณบอกว่าคุณได้รับมอบหมายให้ใช้งานฟังก์ชั่นใน codebase ที่ใช้งานอยู่

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

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

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

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

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

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

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

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

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

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

มีทางเดียวเท่านั้นที่จะหา ถาม

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

มี "สไตล์" ในระดับต่าง ๆ

ในระดับหนึ่งมักจะเป็นส่วนหนึ่งของการประชุมรหัสซึ่งหมายความว่าจะใส่ช่องว่างสีขาวบรรทัดว่างวงเล็บและวิธีการตั้งชื่อสิ่งต่าง ๆ (กรณีผสม, ขีดล่าง, ฯลฯ .. )

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

จากนั้นก็มีห้องสมุดและกรอบงานที่โครงการใช้อยู่

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

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

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