ฉันจะโน้มน้าวให้ทีมของฉันใช้คลาส / วิธีการที่เล็กลงได้อย่างไร

คำเตือน: ฉันเป็นผู้มาใหม่ (นี่เป็นวันที่สามของการทำงาน) และเพื่อนร่วมทีมส่วนใหญ่ของฉันมีประสบการณ์มากกว่าฉัน

เมื่อฉันดูรหัสของฉันฉันเห็นกลิ่นของรหัสและวิธีปฏิบัติทางวิศวกรรมที่ไม่ดีเช่นดังต่อไปนี้:

• หลักเกณฑ์การตั้งชื่อค่อนข้างไม่สอดคล้องกัน
• คุณสมบัติไม่ถูกทำเครื่องหมายว่าอ่านได้อย่างเดียวเมื่อเป็นไปได้
• คลาสขนาดใหญ่ - ฉันสังเกตเห็นคลาสยูทิลิตี้ที่ประกอบด้วยวิธีการขยายหลายร้อยรายการ (สำหรับหลายประเภท) มันยาวกว่า 2,500 บรรทัด!
• วิธีการขนาดใหญ่ - ฉันกำลังพยายามปรับวิธีการที่มีความยาว 150 บรรทัด

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

ทีมของฉันได้รับที่ปรึกษาจากทีมหลัก (เราเป็นทีมดาวเทียม) ฉันควรไปหาเขาก่อนไหม

UPDATE : เนื่องจากคำตอบบางอย่างถามเกี่ยวกับโครงการโปรดทราบว่าเป็นโครงการที่ทำงานได้ และ IMHO คลาส / วิธีการขนาดใหญ่นั้นไม่ดีเสมอไป

ยังไงก็ตามฉันไม่ต้องการที่จะฉี่ทีมของฉันออก นั่นเป็นเหตุผลที่ฉันถาม - ฉันควรทำอย่างนั้นหรือไม่และถ้าใช่แล้วฉันจะทำอย่างนั้นเบา ๆ ?

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

ขอขอบคุณ.

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

Code Complete โดย Steve McConnell มีสถิติที่ดีมากมายในหัวข้อที่คุณกำลังพูดถึง ฉันไม่จำตัวเลขทั้งหมดได้ แต่เขาพูดถึงจำนวนข้อบกพร่องที่เพิ่มขึ้นด้วยวิธี / คลาสที่ยาวขึ้นใช้เวลาในการดีบักนานเท่าไรเป็นต้น

คุณสามารถซื้อสำเนาของหนังสือและแสดงผลการศึกษาบางส่วนของคุณ ... สถิติ (แม้ว่าพวกเขาโกหกตลอดเวลา) มักจะโน้มน้าวใจผู้คน

ข้อจำกัดความรับผิดชอบ: ฉันเป็นผู้มาใหม่ (นี่เป็นวันที่สามของการทำงาน) และทีมงานส่วนใหญ่ของฉันมีประสบการณ์มากกว่าฉัน

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

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

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

มันเป็นยังไง "วัดสองครั้งตัดครั้งเดียว .. " บางอย่างเช่นนั้น

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

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

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

ขอให้โชคดี

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

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

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

และใช่โดยทั้งหมดแสดงสิ่งต่าง ๆ จาก Code Complete ให้กับทุกคน

นี่เป็นเทคนิคสองสามข้อ:

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

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

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

• แนะนำกลไกการป้องกันในอนาคต - ตัวอย่างเช่นทีมสามารถยอมรับเป้าหมายที่จะไม่เพิ่มในชั้นเรียนที่ใหญ่ที่สุดสองสามแห่ง แต่จะ refactor เมื่อมีความต้องการที่จะเติบโตต่อไป

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

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

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

ฉันจะโน้มน้าวให้ทีมของฉันใช้คลาส / วิธีการที่เล็กลงได้อย่างไร

อย่า

ซื้อสิทธิ์ใช้งาน Resharper ด้วยตนเองและนำตัวอย่าง [พึ่งพาอย่างมากในการรีแฟคเตอร์' แยกวิธี ']

เมื่อเวลาผ่านไปผู้อื่นควรชื่นชมโค้ดที่อ่านได้มากขึ้นของคุณและโน้มน้าวให้ทำเช่นเดียวกัน *

• ใช่ - มีโอกาสที่พวกเขาจะไม่ถูกชักชวน แต่มันก็ยังเป็นทางออกที่ดีที่สุดของคุณ

IMO - มันไม่คุ้มค่าที่พยางค์ของคุณจะพยายามเกลี้ยกล่อมเพื่อนร่วมทีมให้เป็นโปรแกรมเมอร์ที่ดีขึ้นอ่าน ' Code Complete ' ตาม @ Uncle Bob หลักการของ SOLID และเป็นโปรแกรมเมอร์ที่ดีขึ้นหากพวกเขายังไม่ได้ชักชวน

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

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

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

ทีมบางคนไม่ทำการควบคุมคุณภาพสำหรับรหัสเพราะพวกเขาไม่รู้เครื่องมือที่เหมาะสมสำหรับมัน มีเครื่องมือมากมายที่สามารถช่วยให้รหัสทีมดีขึ้น

Visual Studio มี "การวิเคราะห์รหัส" ที่อาจช่วยจัดการเรื่องการตั้งชื่อ

นอกจากนี้ยังสามารถใช้การวัดรหัสเช่นความซับซ้อนของวงจร สิ่งนี้ช่วยชี้ให้เห็นคลาสและวิธีการที่ซับซ้อนเกินไป

การเก็บบันทึกเป็นความคิดที่ดี หากสมาชิกในทีมแสดงออกด้วยวาจาในสิ่งที่ต้องทำผู้คนก็ต้องลืม มนุษย์มีความทรงจำที่อ่อนแอมาก! =)

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

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

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

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

ดังนั้นถ้ามันใช้งานได้ดีเท่าที่คุณอาจเกลียดคุณอาจต้องทิ้งมันไว้ตามลำพัง

ตอนนี้รหัสใหม่มันแตกต่างกัน นั่นควรเป็นรหัสที่ดี

วิธีการที่มี 150 บรรทัด ... ฉันเคยเห็นวิธีการที่มี 10.000 บรรทัดของรหัส

สองปัญหาของคุณสามารถแก้ไขได้ด้วยเครื่องมือภายนอก :

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

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

เครื่องมือเหล่านี้ยังสามารถช่วยแยกวิธีการขนาดใหญ่ให้เล็กลงได้หลายอย่างด้วยการปรับโครงสร้างใหม่

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

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

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

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

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