การขัดแย้งสไตล์ Java ภายในทีม

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

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

มีองค์กรดังกล่าวคือ Sun / Oracle เอง เอกสารนี้เรียกว่าCode Conventions สำหรับ Java Programming Languageและมันอธิบายเกี่ยวกับอนุสัญญาส่วนใหญ่ที่คุณต้องการ เพียงให้ทุกคนเห็นด้วยที่จะอ่านและปฏิบัติตามคำแนะนำ

ฉันติดแท็กคำตอบของ Andresจริงๆและมุ่งเน้นที่การจัดรูปแบบโค้ดจาวาอย่างสม่ำเสมอ

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

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

ฉันจะถือว่า Java IDE หลักอื่น ๆ (IntelliJ และ Netbeans) มีคุณสมบัติคล้ายกันสำหรับการส่งออกการตั้งค่ารูปแบบ

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

แท้จริง มันไม่สำคัญ

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

หลังจากอ่านสไตล์มากมายฉันได้เรียนรู้สิ่งนี้

สไตล์ไม่สำคัญ

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

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

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

ความสอดคล้องช่วยปรับปรุงการทำงานร่วมกันการทำงานร่วมกันช่วยปรับปรุงรหัส

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

Sun Java CC ที่กล่าวถึงข้างต้นไม่เพียง แต่มีอายุ 13 ปีและกฎบางอย่างของมันล้าสมัย (เช่น 80 ตัวอักษรต่อบรรทัด) แต่ยังไม่ได้กำหนดการประชุมแบบตั้งชื่อยกเว้นตัวทั่วไปมากที่สุด (ตัวอูฐสำหรับชั้นเรียน สำหรับตัวแปรสุดท้ายคงที่และไม่ชอบ)

คุณต้องกำหนดมาตรฐานของคุณเองสำหรับคลาสประเภทต่างๆเช่น DAOs, EJBs, เอนทิตีหรืออะไรก็ตามที่คุณใช้ Sun Java CC เป็นเหมือนคลาสพื้นฐานที่เป็นนามธรรมสำหรับการขยาย :)

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

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

ดังนั้นจึงเป็นสิ่งสำคัญที่จะต้องพิจารณาสถานการณ์ของคุณเช่นกัน

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

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

ผมขอแนะนำให้คุณมองเข้าไปในโปรแกรมสปาร์ตัน

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