คุณจะโค้ดอย่างไรโดยไม่ละเมิด


27

สิ่งที่ฉันหมายถึงคือคุณจะพัฒนาฐานรหัสที่คุณแบ่งปันกับนักพัฒนาที่ทำงานกับมันมาหลายปีแล้วและคุ้นเคยกับมันอย่างไร

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

ฉันไม่แน่ใจว่าจะทำอย่างไรนอกจากถาม แต่บางทีพวกคุณมีความคิดที่ฉันสามารถนำไปปฏิบัติได้

UPDATE

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

นี่คือร้าน perl แต่ฉันแน่ใจว่าสิ่งเหล่านี้ใช้ได้กับทุกภาษา

อัพเดท 2

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

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

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


3
พวกเขารู้สึกว่าคุณตรวจสอบรหัสบ่อยเกินไปหรือไม่ หรือน้อยเกินไป
Adam Jaskiewicz

3
อย่างน้อยที่สุดการตรวจสอบพอยน์เตอร์ของคุณจะทำให้คุณไม่พอใจคอมพิวเตอร์ ( xkcd.com/371 )
riwalk

4
หากคุณโค้ดใน C # เสนอให้ทุกคนใช้ StyleCop หากคุณใช้รหัสในภาษาอื่นให้มองหาเครื่องมือที่คล้ายกัน ปล่อยให้ชิ้นส่วนซอฟต์แวร์ตาบอดเป็นผู้ตัดสินใน 80% ของคดี
งาน

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

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

คำตอบ:


38

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

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

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

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


14
ทางเลือกอื่นในการแยกสาขาคือการใช้ GIT ภายในเครื่อง มันมีอินเตอร์เฟส SVN ที่ไร้รอยต่อและพวกเขาจะไม่เห็นความมุ่งมั่นของคุณทุกชั่วโมง
mattnz

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

24

เกี่ยวกับช่องว่าง: เพียงแค่ทำอย่างไรก็ตามโค้ดทำมันไปแล้ว ไปกับการไหล

เกี่ยวกับเช็ค SVN: เอกสารให้ชัดเจนมาก ที่ช่วยให้ผู้คนเข้าใจว่าเกิดอะไรขึ้นในรหัส (การติดตามผล: อะไรคือสิ่งที่คัดค้านต่อการเช็คอินบ่อยๆ?)

โดยทั่วไป: เริ่มต้นสร้างเอกสารมาตรฐานการเข้ารหัส อย่าพยายามเติมเต็มด้วย 100 กฎ เพียงเพิ่มกฎตามที่ปรากฏ

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


1
คำตอบที่ดี แต่ฉันไม่ชอบ "ไปกับกระแส" บนช่องว่างจำเป็น ถ้ามันสมเหตุสมผล (แต่ไม่ใช่วิธีที่คุณจะทำ) ใช่ไปกับการไหล แต่อย่างเช่นในกรณีที่มีรหัสที่ฉันเห็นและไม่มีช่องว่างที่สอดคล้องกันจากนั้นการสร้างแนวปฏิบัติที่ดี (ตามที่ Caleb แนะนำ) สามารถไปได้ไกล
JasCav

7

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

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


4

ก่อนอื่นอ่านเอกสารการประชุมการเข้ารหัสของพวกเขา (ถ้าพวกเขาไม่มีให้ขอให้พวกเขาเขียนหนึ่งเพื่อให้คุณสามารถติดตามได้)

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

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


ใช่พวกเขาไม่มีการประชุมใด ๆ พวกเขาไม่ได้มีนักพัฒนาใหม่ ๆ มานานแล้ว
qodeninja

1
@ceneninja แล้วพวกเขาจะบ่นอย่างไรถ้าคุณไม่ติดตามพวกเขา? พวกเขาต้องเห็นด้วยกับชุดของอนุสัญญาก่อนที่พวกเขาจะคาดหวังให้คุณเปลี่ยนวิธีการเข้ารหัสของคุณ บอกพวกเขาว่า
Tom Squires

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

ฉันสังเกตว่าคุณใช้กาลที่ผ่านมา กระโดดขึ้นเรือ? :)
Tom Squires

3

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

นอกจากนี้เข้าใจว่านักพัฒนาใหม่ในโครงการจะมีเวลา"ทางลาด" ที่จำเป็น ดังนั้นอย่ากังวลไปเลย


1

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

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

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


0

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

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