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

คุณควรทำอย่างไรถ้าเพื่อนร่วมงานกำลังแก้ไขรหัสของคุณ

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

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

เพราะคุณอาจผิด นั่นอาจเป็นการแก้ไขข้อบกพร่องที่ละเอียดอ่อนและคุณก็ไม่ได้มองเห็น

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

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

แต่คุณจะไม่มีทางรู้ถ้าคุณถาม

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

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

หากสิ่งอื่นล้มเหลวให้เปลี่ยนการเช็คอินกลับคืน ;)

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

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

หากคุณไม่ได้ใช้มาตรฐานการเข้ารหัสอาร์กิวเมนต์ทั้งหมดของสิ่งที่ถือเป็น 'รหัสที่ดี' จะกลายเป็นเรื่องส่วนตัวเกินไป ดังนั้นทำไมคุณควรใช้มาตรฐานการเข้ารหัส :)

ในฐานะที่เป็นหนึ่งในคนเหล่านั้น (คนที่ปฏิรูปรูปแบบของรหัสของคนอื่น) บางครั้งเหตุผลหลักที่ฉันทำคืออ่านง่าย บางคนเลอะเทอะอย่างยิ่งกับการเยื้องหรือผสมแท็บและช่องว่าง

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

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

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

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

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

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

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

หากเขาเปลี่ยนเพื่อให้เป็นไปตามมาตรฐานการเข้ารหัสของทีมคุณควรปฏิบัติตามมาตรฐานในครั้งต่อไป

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

... ทีมของคุณมีชุดมาตรฐานการจัดรูปแบบโค้ดที่ทุกคนใช้ใช่ไหม

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

แน่นอนว่านี่คือ งานที่เกิดขึ้นครั้งคราวเนื่องจากมันทำลายฟังก์ชันการทำงาน "โทษ" ใน SVN

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

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

ฉันรู้สึกว่าคุณคิดว่าเป็นเรื่องน่ารังเกียจที่จะทำเช่นนั้น ... ? ตัวอย่างเช่นฉันเองจะแก้ไขรหัสนี้ทันที

int myFunction( ) {

    int i ;
  return  0;

}

ที่จะกลายเป็น

int myFunction() {
    int i;
    return 0;
}

ดังนั้น ... ฉันควรถูกลงโทษเนื่องจากการกระทำของฉัน? ในชีวิตจริงฉันมีบันทึก SVN มากมายอ่าน 'การจัดรูปแบบ' ;-)

ใช้เครื่องมือตรวจสอบสไตล์

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

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

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

ทำไม?

มีสองเหตุผลหลักในการ refactor:

1. เพื่อปรับปรุงรหัส / การออกแบบก่อนที่จะสร้างสิ่งที่ดีที่สุด: มันยากที่จะเกิดขึ้นกับรหัสที่ดีในการพยายามครั้งแรก ความพยายามครั้งแรกที่จะใช้การออกแบบเริ่มต้นใด ๆ จะแสดงให้เราเห็นว่าเราตีความผิดหรือลืมตรรกะบางอย่าง

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

เมื่อไหร่?

1. ยิ่งเร็วเท่าไหร่ก็ยิ่งดีเท่านั้น

2. เร็วขึ้นและมีความเสี่ยงน้อยกว่าในการปรับเปลี่ยนรหัสผ่าน refactored เร็ว ๆ นี้แทนที่จะรอ refactor เพื่อให้โค้ดใกล้จะเสร็จสมบูรณ์

อะไร?

1. รหัสทั้งหมดและการออกแบบทั้งหมดเป็นตัวเลือกสำหรับการปรับโครงสร้างใหม่

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

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

ไชโย