ฉันเคยเขียนเรื่อง SoftwareEngineering.SE มากมายในอดีตและอยู่ในสถานการณ์ที่คล้ายกันด้วยตัวเอง ดังนั้นฉันจะพยายามให้คำแนะนำเล็กน้อยและเน้นประเด็นที่ฉันสังเกตเห็นเมื่ออ่านคำถามของคุณ
แต่ก่อนอื่นเรามาพูดถึงสิ่งสำคัญ: บทบาทของคุณใน บริษัท
บทบาทของคุณ
คุณอาจจะมีเอกสารที่ชัดเจนจากเจ้านายของคุณเพื่อเพิ่มสิ่งและยังเป็นสถานที่ในลำดับชั้นที่นักพัฒนาอื่น ๆ ที่มีการฟังที่คุณสั่งซื้อ หรือคุณอาจจะอยู่ในหมู่เพื่อนร่วมงานที่มีบทบาทเดียวกันและผู้มีอำนาจเดียวกันตัวเลือกของคุณเป็นเพียง ... ดี ... ความคิดเห็น
ในทั้งสองกรณีสิ่งที่สำคัญคือตำแหน่งของคุณน้อยลงในลำดับชั้นและอื่น ๆ :
นักพัฒนาคนอื่น ๆ คิดอย่างไรกับคุณ หากพวกเขาปฏิบัติต่อคุณในฐานะคนที่น่ารำคาญที่ถามพวกเขาถึงสิ่งที่โง่คุณจะไม่ไปไกล ฉันได้เห็นหลายกรณีที่ผู้นำด้านเทคนิคและผู้จัดการโครงการไม่มีอิทธิพลต่อทีมอย่างแท้จริงเพราะทีมรู้ว่า (หรือคิด) ว่า "ผู้นำ" เหล่านั้นไม่มีพื้นฐานด้านเทคนิคที่จำเป็นในการตัดสินใจที่พวกเขากำลังทำ ในทางกลับกันฉันได้เห็นนักพัฒนาซอฟต์แวร์หลายคนที่ฟังโดยเพื่อนของพวกเขาเพราะพวกเขารู้ว่านักพัฒนาเหล่านั้นเก่งและมีประสบการณ์
ทีมของคุณแข็งแกร่งแค่ไหนและอะไรเป็นแรงจูงใจให้พวกเขา ลองนึกภาพ บริษัท ที่นักพัฒนาซอฟต์แวร์ทุกคนจ่ายให้กับ KLOC / เดือน อะไรที่คุณจะพูดเกี่ยวกับสไตล์มีความสำคัญกับเพื่อนร่วมงานของคุณ? อาจจะไม่ใช่เพราะหายากเป็นคนที่ต้องการได้รับเงินน้อย โดยทั่วไปหากนี่ไม่ใช่ทีม แต่เป็นเพียงกลุ่มคนที่ทำงานในโครงการเดียวกันคุณจะไม่สามารถปรับปรุงอะไรได้
คุณอาจตัดสินใจได้ว่าจะคุ้มค่ากับความพยายามในการเปลี่ยนแปลงหรือไม่ หากคุณไม่มีเสียงและไม่มีการทำงานร่วมกันของทีมเพียงแค่ไปหางานอื่น หากคุณรู้จักในฐานะนักพัฒนาที่มีความสามารถและมีความเคารพและมีความรู้สึกเป็นทีมที่แข็งแกร่งคุณจะสามารถพัฒนาสิ่งต่าง ๆ ได้ง่ายแม้ว่าจะต้องเผชิญกับความเป็นศัตรูจากหัวหน้าหรือทีมอื่น ๆ
ในทุกกรณีมันเป็นสิ่งสำคัญที่จะไม่กดดันทีมของคุณ ทำงานกับพวกเขาไม่ใช่กับพวกเขา อย่าให้คำสั่งซื้อ แต่ให้นำพวกเขาไปสู่เป้าหมาย
ตอนนี้คำแนะนำ
สไตล์
ฉันเคยขอให้ทำตามสไตล์การเข้ารหัสและการจัดรูปแบบของโค้ดที่มีอยู่ส่วนใหญ่ (น่าเศร้าที่เราไม่มีเอกสารสไตล์การเข้ารหัสที่เป็นทางการ) แต่มันไม่ทำงาน ...
แน่นอนมันไม่ได้เพราะนี่ไม่ใช่วิธีที่ควรจะทำ
สไตล์ที่น่าเบื่อ
รูปแบบต่อไปนี้เป็นที่น่าเบื่อ
การเขียนเอกสารสไตล์การเขียนรหัสเป็นสิ่งที่น่าเบื่อ ( และยากมากอย่าลองทำมันจนกว่าคุณจะได้ทำงานกับภาษามานานกว่าสิบปีแล้ว)
อ่านเอกสารรูปแบบที่น่าเบื่อ
รหัสการตรวจสอบความผิดพลาดสไตล์ที่น่าเบื่อ
การยั่วเย้าว่าสไตล์ของฉันดีกว่าของคุณน่าตื่นเต้นโดยเฉพาะอย่างยิ่งเมื่อไม่มีประโยชน์กับสไตล์หนึ่งมากกว่าอีกสไตล์อย่างแน่นอน อย่างจริงจังทุกคนที่มีสติรู้ว่าวิธีการเขียนที่if (x)ถูกต้องเป็นวิธีที่ฉันเขียนไม่ใช่if(x)หรือif ( x )!
ดังนั้น:
อย่าทำรีวิวสไตล์ นี่คืองานของตัวตรวจสอบสไตล์ แอปพลิเคชั่นน่ารักเหล่านี้มีประโยชน์กับสมองของคุณเล็กน้อย: ตรวจสอบโครงการทั้งหมดในเวลาไม่กี่ชั่วโมงไม่กี่ชั่วโมงหรือหลายวันและพวกเขาไม่ทำผิดพลาดและไม่พลาดข้อผิดพลาดแบบ
อย่าเขียนมาตรฐานสไตล์ของคุณเอง คุณจะทำผิดแล้วและเพื่อนร่วมงานของคุณจะหมุนรอบคุณว่าคุณเลือกไม่ดี
อย่าบังคับนักพัฒนาให้แก้ไขข้อผิดพลาดของสไตล์ 2 000
บังคับใช้สไตล์โดยอัตโนมัติเมื่อคอมมิต รหัสที่มีข้อผิดพลาดสไตล์ไม่มีที่ในการควบคุมเวอร์ชัน
ทำตั้งแต่เริ่มโครงการ การตั้งค่าการควบคุมสไตล์ในโครงการที่มีอยู่นั้นเป็นไปไม่ได้ยาก
สำหรับข้อมูลเพิ่มเติมเกี่ยวที่อ่านส่วนแรกของคำตอบอื่น ๆ เกี่ยวกับเรื่องนี้ SE.SE
นอกจากนี้:
- อย่าเข้มงวดเกินไป ตัวอย่างเช่นการเขียน
jslintรหัสที่เข้ากันได้นั้นค่อนข้างน่ารำคาญดังนั้นควรทำเฉพาะเมื่อจำเป็นอย่างยิ่ง (หรือหากสมาชิกทุกคนในทีมของคุณมีความสุขที่ได้ใช้มัน) เช่นเดียวกันสำหรับเครื่องมือตรวจสอบแบบคงที่ ตัวอย่างเช่นการวิเคราะห์รหัสของ. NET ในระดับสูงสุดอาจกดดันและกดดันน้อยมากในขณะที่ให้ผลประโยชน์เพียงเล็กน้อย เครื่องมือชุดเดียวกันในระดับปานกลางในทางกลับกันพิสูจน์ว่ามีประโยชน์มาก
บทวิจารณ์โค้ด
ตอนนี้คุณไม่จำเป็นต้องกังวลเกี่ยวกับสไตล์ระหว่างการตรวจสอบโค้ดคุณสามารถมุ่งเน้นไปที่สิ่งที่น่าสนใจมากขึ้น: การปรับปรุง (เทียบกับการแก้ไข) ซอร์สโค้ด
บุคคลที่แตกต่างกันตอบสนองต่อบทวิจารณ์โค้ดต่างกัน บางคนคิดว่าเป็นโอกาส คนอื่นเกลียดมัน บางคนฟังทุกสิ่งที่คุณบอกพวกเขาจดบันทึกและไม่พูดถึงแม้ว่าพวกเขาจะพูดถูก คนอื่นพยายามที่จะโต้แย้งในทุกประเด็น มันขึ้นอยู่กับคุณแล้วที่จะหาวิธีจัดการกับนักพัฒนาทุกคนตามบุคลิกของเธอ มักจะเป็นประโยชน์ในการ:
ทำรีวิวรหัสในส่วนตัวโดยเฉพาะเมื่อนักพัฒนาเป็นผู้อยู่ใต้บังคับบัญชาและเขียนรหัสไม่ดีจริงๆ
แสดงว่าไม่มีอะไรเป็นส่วนตัว: คุณกำลังทบทวนรหัสไม่ใช่ทักษะของบุคคลนั้น
แสดงเป้าหมายที่แท้จริงของการตรวจสอบโค้ด เป้าหมายไม่ใช่เพื่อแสดงว่านักพัฒนาซอฟต์แวร์แย่แค่ไหน เป้าหมายคือการให้โอกาสในการปรับปรุง
ไม่เคยเถียง คุณไม่ได้อยู่ที่นี่เพื่อโน้มน้าวใจ แต่เพื่อมอบความเชี่ยวชาญของคุณ
ไม่คิดว่าผู้ตรวจสอบจะเป็นคนเดียวที่สามารถเรียนรู้บางสิ่งจากบทวิจารณ์ได้ คุณอยู่ที่นี่เพื่อเรียนรู้ทั้งโดยการอ่านรหัสและถามคำอธิบายเกี่ยวกับส่วนที่คุณไม่เข้าใจ
เมื่อตรวจสอบโค้ดเสร็จแล้วตรวจสอบให้แน่ใจว่าบุคคลนั้นปรับปรุงโค้ดของเธอจริง ฉันมีบางกรณีที่ผู้พัฒนาคิดว่าการตรวจสอบรหัสสิ้นสุดเมื่อการประชุมจริงสิ้นสุดลง พวกเขาออกไปและกลับไปที่คุณสมบัติใหม่ของพวกเขาพยายามที่จะใช้สิ่งที่คุณแบ่งปันกับพวกเขาสำหรับรหัสใหม่เท่านั้น การมีเครื่องมือติดตามที่ดีสำหรับการตรวจสอบโค้ดช่วย
โปรดทราบว่าบทบาทของคุณใน บริษัท และความเชี่ยวชาญของคุณเมื่อเปรียบเทียบกับคนอื่น ๆ นั้นรหัสของคุณก็ควรได้รับการตรวจสอบเช่นกัน คุณไม่ควรเป็นคนเดียวที่ตรวจสอบรหัสของผู้อื่น
ในโครงการเมื่อเร็ว ๆ นี้ที่ฉันทำงานในฐานะผู้นำทางเทคนิคฉันมีเวลายากลำบากในการอธิบายเพื่อนร่วมงานของฉันว่ามันเป็นหน้าที่ของพวกเขาในการตรวจสอบรหัสของกันและกันรวมถึงของฉันด้วย ความกลัวของผู้ฝึกงานที่กำลังจะทบทวนรหัสของผู้นำทางเทคนิคของเขาหายไปทันทีที่เขาพบปัญหาแรกในรหัส - และในหมู่พวกเราที่เขียนรหัสไร้ที่ติ?
การอบรม
การตรวจสอบรหัสเป็นโอกาสที่ดีในการสอนและเรียนรู้แง่มุมต่าง ๆ ของการเขียนโปรแกรมและการออกแบบซอฟต์แวร์ แต่ผู้อื่นจำเป็นต้องได้รับการฝึกอบรม
หากคุณสามารถฝึกผู้ร่วมงานได้ให้ทำเช่นนั้น หากฝ่ายบริหารของคุณไม่เห็นด้วยกับการฝึกอบรมให้ทำอย่างไม่เป็นทางการ ฉันได้ทำการฝึกอบรมในรูปแบบของการประชุมแบบไม่เป็นทางการหรือบางครั้งเป็นการสนทนาที่เรียบง่ายบางครั้งถูกขัดจังหวะโดยฝ่ายบริหารและติดตามในภายหลัง
นอกเหนือจากการฝึกอบรมโดยตรงให้แน่ใจว่าคุณรู้หนังสือที่เพียงพอเช่นรหัสของ McConnel ที่สมบูรณ์และพูดคุยเกี่ยวกับหนังสือเหล่านั้นกับเพื่อนร่วมงานของคุณ แนะนำพวกเขาให้อ่านซอร์สโค้ดของโปรเจ็กต์โอเพนซอร์ซให้ตัวอย่างเฉพาะของโค้ดคุณภาพสูง และแน่นอนว่าเขียนโค้ดคุณภาพสูงด้วยตัวคุณเอง
เน้นบริบทไม่ใช่คน
ฉันจะจัดการกับสถานการณ์นี้ได้อย่างไรโดยไม่เพียง แต่มุ่งเน้นไปที่ 'วัฒนธรรมของ บริษัท ที่ไม่ดี', 'บัณฑิตที่ไม่มีประสบการณ์' เป็นต้น
ผู้สำเร็จการศึกษาเหล่านั้นมีเป้าหมาย: ได้รับประสบการณ์เรียนรู้สิ่งต่าง ๆ และมีทักษะมากขึ้น หากปีแล้วปีเล่าพวกเขาเขียนรหัสเส็งเคร็งและไม่รู้อะไรเกี่ยวกับการเขียนโปรแกรมอาจเป็นเพราะทีมของคุณหรือ บริษัท ของคุณไม่ได้ให้โอกาสพวกเขา
หากคุณกำลังมุ่งเน้นไปที่ความจริงที่ว่าทีมของคุณมีบัณฑิตที่ไม่มีประสบการณ์สิ่งนี้จะไม่ช่วย ให้มุ่งเน้นไปที่สิ่งที่คุณสามารถทำได้เพื่อพวกเขาและกับพวกเขา การตรวจสอบรหัสและการฝึกอบรมเป็นสองเทคนิคในการปรับปรุงสถานการณ์
วัฒนธรรมของ บริษัท ที่ไม่ดีเป็นสัตว์ร้ายที่แตกต่างกัน บางครั้งมันสามารถเปลี่ยนแปลงได้ บางครั้งมันไม่สามารถ ในทุกกรณีโปรดจำไว้ว่าคุณเป็นส่วนหนึ่งของ บริษัท นี้ดังนั้นคุณจึงเป็นส่วนหนึ่งของวัฒนธรรมของ บริษัท หากคุณไม่สามารถเปลี่ยนได้และพบว่าไม่ดีโดยเนื้อแท้ไม่ช้าก็เร็วคุณจะต้องจากไป
รับตัวชี้วัดของคุณถูกต้อง
ตอนนี้คุณวัดรหัสได้อย่างไร คุณวัดจำนวนข้อผูกพันต่อวันต่อนักพัฒนาหรือไม่ หรือ KLOC ต่อเดือนต่อโปรแกรมเมอร์? หรืออาจจะครอบคลุมรหัส? หรือจำนวนข้อบกพร่องที่พบและแก้ไขแล้ว? หรือจำนวนข้อบกพร่องที่อาจเกิดขึ้นจากการทดสอบการถดถอย? หรือจำนวนการย้อนกลับที่ทำโดยเซิร์ฟเวอร์การปรับใช้ต่อเนื่อง
สิ่งที่คุณวัดความสำคัญเนื่องจากสมาชิกในทีมกำลังปรับการทำงานให้เข้ากับปัจจัยที่วัด ตัวอย่างเช่นใน บริษัท หนึ่งที่ฉันต้องทำงานเมื่อไม่กี่ปีก่อนสิ่งเดียวที่วัดได้คือเวลาที่ใช้ในสำนักงาน ไม่จำเป็นต้องพูดว่าสิ่งนี้ไม่ได้เป็นการกระตุ้นให้ส่งมอบรหัสที่ดีกว่าหรือทำงานอย่างชาญฉลาดหรือดีกว่าเพื่อทำงานทั้งหมด
การหาการเสริมแรงทางบวกและลบและการปรับปัจจัยที่วัดตลอดเวลานั้นเป็นสิ่งสำคัญที่คุณมีต่อสมาชิกในทีม เมื่อทำอย่างถูกต้องจะทำให้สามารถบรรลุผลลัพธ์ที่ไม่สามารถทำได้โดยการเรียงลำดับอย่างง่าย
สิ่งที่รบกวนคุณทำให้วัดได้ วัดพวกเขาและทำให้ผลลัพธ์เป็นแบบสาธารณะ จากนั้นทำงานร่วมกับสมาชิกในทีมอื่นเพื่อปรับปรุงผลลัพธ์
ตัวอย่างเช่นลองพิจารณาว่าสมาชิกในทีมมีการสะกดคำผิดมากเกินไปในชื่อของคลาสสมาชิกในคลาสและตัวแปร มันน่ารำคาญ คุณวัดได้อย่างไร ด้วยตัวแยกวิเคราะห์คุณสามารถแยกคำทั้งหมดออกจากรหัสและใช้เครื่องตรวจตัวสะกดตรวจสอบอัตราส่วนของคำที่มีข้อผิดพลาดและการพิมพ์ผิดพูด 16.7%
ขั้นตอนต่อไปคือการเห็นด้วยกับทีมของคุณในอัตราส่วนเป้าหมาย อาจเป็น 15% สำหรับการวิ่งครั้งต่อไป, 10% สำหรับการวิ่งครั้งต่อไป, 5% ในหกสัปดาห์, และ 0% ในสองเดือน ตัวชี้วัดเหล่านั้นจะคำนวณใหม่โดยอัตโนมัติในทุกการกระทำและแสดงบนหน้าจอขนาดใหญ่ในสำนักงาน
หากคุณไม่บรรลุอัตราส่วนเป้าหมายทีมของคุณอาจตัดสินใจใช้เวลาในการแก้ไขข้อผิดพลาดในการสะกดคำมากขึ้น หรือทีมของคุณอาจพิจารณาการคำนวณอัตราส่วนต่อผู้พัฒนาและแสดงข้อมูลนี้บนหน้าจอขนาดใหญ่ได้ดียิ่งขึ้น หรือทีมของคุณอาจพบว่าเป้าหมายในแง่ดีเกินไปและคุณควรตรวจสอบ
หากคุณบรรลุอัตราส่วนเป้าหมายขั้นตอนต่อไปคือตรวจสอบให้แน่ใจว่าจำนวนข้อผิดพลาดและการพิมพ์ผิดจะไม่เพิ่มขึ้นเมื่อเวลาผ่านไป สำหรับสิ่งนั้นคุณสามารถสร้างงานเพิ่มเติมในงานสร้างของคุณซึ่งตรวจสอบข้อผิดพลาดในการสะกดและไม่สร้างงานสร้างหากพบข้อผิดพลาดอย่างน้อยหนึ่งรายการ เมื่อคุณกำจัดปัญหานี้แล้วหน้าจอขนาดใหญ่ของคุณอาจถูกนำมาใช้ซ้ำเพื่อแสดงสถิติที่เกี่ยวข้องใหม่
ข้อสรุป
ฉันเชื่อว่าทุกด้านที่กล่าวถึงในคำถามของคุณสามารถแก้ไขได้ด้วยเทคนิคที่ฉันรวมไว้ในคำตอบของฉัน:
เมื่อผู้พัฒนารายอื่นเข้าร่วมโครงการฉันสังเกตเห็นว่าพวกเขาใช้รูปแบบการเข้ารหัสที่แตกต่างกัน (บางครั้งก็เป็นสไตล์ที่แตกต่างอย่างสิ้นเชิง)
คุณต้องบังคับใช้สไตล์อัตโนมัติ
และมักจะไม่ใช้คุณสมบัติภาษาที่ทันสมัยเช่นตัวเข้าถึงคุณสมบัติ (ค่อนข้างใหม่ใน Objective-C)
ทั้งบทวิจารณ์โค้ดและการฝึกอบรมอยู่ที่นี่เพื่อถ่ายทอดความรู้ภาษา
บางครั้งพวกเขาก็คิดค้นจักรยานของตัวเองแทนที่จะใช้คุณสมบัติที่คล้ายกันของกรอบ
ทั้งบทวิจารณ์โค้ดและการฝึกอบรมอยู่ที่นี่เพื่อถ่ายทอดความรู้เกี่ยวกับกรอบงาน
หรือถ่ายโอนแนวคิดจากภาษาโปรแกรมหรือ patters อื่น ๆ ที่พวกเขาเรียนรู้ลงในฐานรหัสของเรา
นี่คือสิ่งที่ยอดเยี่ยม ดูเหมือนว่าเป็นโอกาสสำหรับคุณที่จะเรียนรู้จากพวกเขา
บ่อยครั้งที่พวกเขาไม่สามารถตั้งชื่อวิธีการหรือตัวแปรได้อย่างเหมาะสมเนื่องจากภาษาอังกฤษไม่ดี
การตรวจสอบรหัสควรเน้นที่การตั้งชื่อที่เหมาะสม IDE บางตัวมีตัวตรวจสอบการสะกดด้วยเช่นกัน
บางครั้งฉันคิดว่าถ้าไม่ใช่สำหรับ IDE ฉันคิดว่าพวกเขาจะเขียนโค้ดทั้งหมดโดยไม่มีการเยื้องหรือการจัดรูปแบบเลย
แน่นอนว่าพวกเขาจะ สไตล์น่าเบื่อและควรเป็นแบบอัตโนมัติ
โดยทั่วไปฉันเกลียดโค้ดที่เขียน
โปรดจำไว้ว่าจากบทวิจารณ์ของรหัส:“ เป้าหมายไม่ใช่เพื่อแสดงว่านักพัฒนาซอฟต์แวร์นั้นแย่เพียงใด เป้าหมายคือการให้โอกาสในการปรับปรุง”
มันมีการจัดรูปแบบ / จัดระเบียบไม่ดีและบางครั้งก็แตกต่างอย่างสิ้นเชิงจากส่วนที่เหลือของโครงการ
การตรวจสอบรูปแบบอัตโนมัติ
ฉันรู้สึกหงุดหงิดมากเมื่อพวกเขาเพิ่มสปาเก็ตตี้ในชิ้นงานศิลปะของฉัน
รออะไร?! ผลงานศิลปะ! คาดเดาอะไร บางคน (รวมถึงคุณในหกเดือน) อาจพบว่ารหัสของคุณอยู่ไกลจากการเป็นงานศิลปะ ในขณะเดียวกันให้เข้าใจว่าการพิจารณางานของคุณเป็นงานศิลปะและงานของพวกเขาเนื่องจากอึจะไม่ช่วยใคร รวมถึงคุณ.
มันให้ความรู้สึกมากขึ้นเรื่อย ๆ เช่นพวกเขาไม่สามารถใส่ใจเรียนรู้หรือไม่สนใจพวกเขาทำสิ่งที่พวกเขาต้องการและกลับบ้าน
แน่นอนพวกเขาจะทำสิ่งที่ต้องการจากพวกเขา จำเอาไว้: บริบทบุคคลที่ไม่ได้และได้รับตัวชี้วัดของคุณได้ หากบริบทต้องการจากพวกเขาให้ดีที่สุดในสิ่งที่พวกเขาทำพวกเขาจะทำ หากบริบทนั้นต้องการผลิต KLOC ให้ได้มากที่สุดต่อเดือนเท่าที่จะทำได้และไม่มีอะไรเพิ่มเติมพวกเขาก็จะทำเช่นกัน