วิธีจัดการกับสไตล์การเขียนโปรแกรมที่แตกต่างกันในทีม?


14

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

คำถามของฉันคือถ้าคนอื่นเคยประสบกับสถานการณ์เช่นนี้มาก่อนและถ้าใครมีเคล็ดลับในการพูดคุยกับเขา


2
พิจารณาใช้การตรวจสอบโดยเพื่อนเพื่อจับแฮ็กและทางลัดที่น่าเกลียดก่อนที่พวกเขาจะไปถึงที่เก็บ?

ใช้เครื่องมืออัตโนมัติที่ดีไม่เอนเอียงเมื่อใดก็ตามที่คุณทำได้
งาน

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

คำตอบ:


22

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

สิ่งที่เราทำคือ:

มาตรฐานการเข้ารหัสงานวิจัย

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

พวกเราสามคนตัดสินใจว่ามาตรฐานการเข้ารหัสที่ดีที่สุดสำหรับโครงการ PHP ที่จัดตั้งขึ้นนั้นตามมาด้วย Zend Framework โชคดีที่คน Zend Framework ให้ครอบคลุมมากเอกสารมาตรฐานการเข้ารหัส

สร้างมาตรฐานการเข้ารหัสของเราเอง

แน่นอนว่าการใช้มาตรฐานการเข้ารหัสของโครงการอื่นในโครงการของเรานั้นไม่สมเหตุสมผล เราใช้เอกสาร Zend Framework เป็นแม่แบบ:

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

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

ปฏิบัติตามคำสัญญาของเรา

codebase ของเราในเวลานั้นประมาณ 1 * 10 ^ 6 sloc เรารู้ว่าเนื่องจากเราใช้มาตรฐานการเข้ารหัสที่เป็นทางการเราจึงต้องเริ่มปรับโครงสร้างรหัสของเราใหม่ แต่ในเวลานั้นเราได้รับผลกระทบจากปัญหาอื่น ๆ ดังนั้นเราจึงตัดสินใจปรับโครงสร้างห้องสมุดหลักของเราเพียง 5 * 10 ^ 3 sloc

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

เรามีการสนทนาใหม่หลายครั้งและภาคผนวกเล็ก ๆ ของเอกสารต้นฉบับในระหว่างที่ฉันดำรงตำแหน่งและในที่สุดเราก็มีเอกสารที่ค่อนข้างคงที่ เราเปลี่ยนมันทุก ๆ ครั้ง แต่การเปลี่ยนแปลงเหล่านี้ส่วนใหญ่อยู่ในฟีเจอร์ใหม่ของภาษาเนื่องจาก PHP 5.3 เป็นรุ่นที่สำคัญในทุก ๆ ด้านยกเว้นชื่อ

จัดการกับคนใหม่

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

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

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

ในอีกไม่กี่สัปดาห์ข้างหน้าเขาก็ได้รับมอบหมายงานง่าย ๆ : นำ codebase ของเราหลายส่วนให้ทันสมัยด้วยมาตรฐาน ฉันต้องเลือกชิ้นส่วนเหล่านั้นอย่างรอบคอบตามกฎสองสามข้อ:

  • รหัสควรจะค่อนข้างง่ายสำหรับคนที่ไม่คุ้นเคยกับ codebase ของเรา (และ PHP โดยทั่วไป)
  • รหัสควรเป็นสิ่งที่เขาได้รับการว่าจ้างให้ทำ

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

จากนั้นคนใหม่ก็มาถึง เราทำขั้นตอนนี้ซ้ำ (อาจารย์ต่างเวลานี้) และทำงานได้อีกครั้ง และอีกครั้ง.

สรุปแล้ว

  1. สร้างเอกสารมาตรฐานการเข้ารหัส แต่ตรวจสอบให้แน่ใจว่ามาตรฐานของคุณไม่ได้เป็นของคุณเอง แต่สะท้อนถึงมาตรฐานทั่วไปในชุมชนที่กว้างขึ้นของแพลตฟอร์มของคุณ
  2. กำหนดบทบาทที่คล้ายคลึงกับต้นแบบมาตรฐานการเข้ารหัสของเรา มีคนตรวจสอบรหัสใหม่อย่างน้อยและโดยเฉพาะอย่างยิ่งรหัสใหม่จากสมาชิกใหม่ รีไซเคิลบทบาทเพราะน่าเบื่ออย่างยิ่ง
  3. ประเมินอินพุตจากสมาชิกใหม่เสมอ ทบทวนมาตรฐานของคุณทุกครั้งหากเหมาะสม เอกสารมาตรฐานการเข้ารหัสของคุณควรมีการพัฒนา แต่อย่างช้าๆ คุณไม่ต้องการ refactor codebase ของคุณอีกครั้งในแต่ละการวนซ้ำ
  4. ให้เวลาสมาชิกใหม่แต่ละคนเรียนรู้และปรับตัวให้เข้ากับมาตรฐานและการประชุมของคุณ เรียนรู้โดยการทำงานได้ดีที่สุดในสถานการณ์เหล่านี้
  5. Wiki ทำงานมหัศจรรย์สำหรับเอกสารดังกล่าว
  6. ความคิดเห็นเกี่ยวกับรหัสทำงานได้อย่างมหัศจรรย์สำหรับทุกสถานการณ์!

เมื่อถึงจุดหนึ่งในกระบวนการแนะนำให้เราใช้ฮุกที่ทำล่วงหน้าเพื่อทำการตรวจสอบมาตรฐานโดยอัตโนมัติ เราตัดสินใจต่อต้านด้วยเหตุผลหลายประการมีการอภิปรายที่น่าสนใจเกี่ยวกับ StackOverflow เกี่ยวกับปัญหา:

บางตัวใช้เฉพาะ PHP แต่คำตอบนั้นใช้ได้กับทุกแพลตฟอร์ม


ถ้าเพียงแนวทางการจัดการการพัฒนาเท่านั้นที่สามารถตอบได้เป็นอย่างดี ... ขอบคุณ!
jleach

3

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

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

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

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

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

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


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

3
  1. มีคนรับผิดชอบ - พวกเขาต้องทำตัวเหมือนมัน
  2. หากรูปแบบการเข้ารหัสมีความสำคัญมากเหตุใดจึงไม่อธิบายให้บุคคลนี้ทราบและให้พวกเขารู้ว่าพวกเขาจะไม่สามารถเข้าถึงรหัสใด ๆ จนกว่าพวกเขาจะเรียนรู้กฎ
  3. ตรวจสอบรหัส - เห็นได้ชัดว่าคุณไม่มีหรือมันอ่อนแอมาก ดู # 1

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

.


1

นี่คือสิ่งที่สามารถทำได้:

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

นี่คือสิ่งที่ควรหลีกเลี่ยง:

  1. การตัดสินใจว่ารหัสของใครบางคนดีกว่าหรือแย่กว่าสมาชิกในทีมคนอื่น ๆ มันใช้งานไม่ได้ - ทุกคนรู้บางส่วนของภาษาดีพอที่จะใช้ในโค้ด โปรแกรมเมอร์ทุกคนเลือกเซตย่อยที่แตกต่างกันเพื่อเรียนรู้และหากพวกเขาไม่ได้เรียนรู้ร่วมกันมันก็จะดูแตกต่างกัน
  2. การเปลี่ยนวิธีที่บางคนเขียนโค้ด สิ่งที่คุณได้รับจากการบังคับให้คนเขียนสไตล์ที่ไม่คุ้นเคยคือคุณได้รับบั๊กจำนวนมากในโค้ด ผู้คนแค่ไม่ทราบรายละเอียดเพียงพอของสิ่งที่พวกเขาใช้ในครั้งแรก โปรแกรมเมอร์เลือกชุดย่อยของภาษาและใช้เพียงอย่างเดียว หากโปรแกรมเมอร์ของคุณเขียนโค้ดหลายพันบรรทัดที่เต็มไปด้วย gotos แล้ว gotos จะให้โค้ดที่มีข้อบกพร่องน้อยที่สุด
  3. คุณไม่ควรคิดว่า codebase ที่คุณมีอยู่นั้นดีสะอาดและบำรุงรักษาได้ มีสิ่งที่ต้องปรับปรุงอยู่เสมอ แต่การเปลี่ยนแปลงทุกอย่างทำให้แนวคิดการออกแบบดั้งเดิมที่เขียนนั้นไม่ชัดเจน มุ่งหวังที่จะเขียนโค้ดที่สมบูรณ์แบบในครั้งแรกเพื่อไม่ให้มีการเปลี่ยนแปลงในภายหลัง (คนใหม่ไม่จำเป็นต้อง "ทำลาย" รหัสที่สมบูรณ์แบบของคุณหากทำอย่างถูกต้องในครั้งแรก)

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

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

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

@DXM คุณสมบัติภาษาที่ยอดเยี่ยมมากมายถูกเรียกว่า 'แฮ็กและทางลัดที่น่าเกลียด' โดยผู้ที่ไม่เคยเห็นหรือใช้งานมาก่อน สิ่งที่ดีที่สุดคือการพูดคุยเกี่ยวกับมาตรฐานมากกว่าแค่ตัดสินใจว่าคนใหม่เป็นแฮ็กเกอร์
Kirk Broadhurst

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

1

ฐานรหัสที่มีอยู่ของเรามีรหัสที่สามารถอ่านได้สะอาดและบำรุงรักษาได้เป็นส่วนใหญ่

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

ที่กล่าวว่าคนใหม่ควรเป็นไปตามมาตรฐานของคุณไม่ใช่วิธีอื่น


0

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

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

ระบบ vcs ออนไลน์เช่น bitbucket หรือ github สนับสนุน funtionality นี้ หากคุณต้องการวิธีซ่อนเร้นในสถานที่ดูเหมือนว่าจะเป็นทางออกที่ดีที่สุดในปัจจุบัน


0

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

เหตุผลที่มีข้อโต้แย้งอย่างมากเกี่ยวกับมาตรฐานการเข้ารหัสคือมาตรฐานหนึ่งไม่ดีกว่าหรือแย่กว่าอีกมาตรฐานหนึ่ง (ปกติ) แต่แตกต่างกัน สิ่งเดียวที่เลวร้ายจริงๆคือการผสมผสานรูปแบบการเข้ารหัส

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

ในทางกลับกันก็มีมาตรฐานคุณภาพ อย่ารับรหัสที่ไม่ตรงตามมาตรฐานคุณภาพของคุณ

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.