ฉันจะขอให้เจ้านายของฉันแสดงความคิดเห็นรหัสของเขาได้อย่างไร?

ฉันได้รับการสอนจากหัวหน้าของฉัน (ฉันเพิ่งเรียนจบและเขาต้องการใครสักคนที่มีประสบการณ์การเขียนโปรแกรมเล็กน้อยดังนั้นเขาจึงเลือกให้ฉันสอนสิ่งที่ บริษัท เชี่ยวชาญ) และเริ่มทำงานกับแอปพลิเคชันASP.NET MVC , HTML และ CSS บางตัว . ฉันพอใจกับการออกแบบเว็บไซต์ที่เขาให้ฉัน (มันค่อนข้างง่ายที่จะเข้าใจโดยไม่ต้องชี้แจง)

แต่ตัวอย่างเช่นเขาให้ฉันทำงานกับ ASP.NET MVC เขาอธิบายได้ดีจริงๆ แต่เขาไม่ได้อธิบายอะไรในรหัสที่เขาเพิ่งให้ฉัน (เราใช้การควบคุมแหล่งที่มาในVisual Studio 2013 ) ดังนั้นจึงเป็นโค้ดหลายร้อยบรรทัดโดยไม่มีพื้นหลังเกี่ยวกับสิ่งที่ควรทำ รหัสที่ฉันเห็นคือรหัสที่ฉันไม่เคยเห็นมาก่อนดังนั้นจึงเป็นเรื่องยากที่จะลองและคิดออก

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

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

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

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

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

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

ความแตกต่างที่ใหญ่ที่สุดระหว่างคุณกับโปรแกรมเมอร์ที่มีประสบการณ์คือคุณไม่คุ้นเคยกับมัน

จุดที่ควรทราบ:

1. มีความพยายามเพียงพอรหัสทุกบิตสามารถเข้าใจได้ ผู้คนจำนวนมากรู้สึกผิดหวังถ้าพวกเขาไม่สามารถคิดอะไรออกภายในไม่กี่นาที จงอดทนยิ่งกว่านั้น

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

3. การขัดจังหวะมีค่าใช้จ่ายมากกว่าคำถาม คุณสามารถใช้เวลาและเจ้านายของคุณให้ดีขึ้นด้วยการรวบรวมการสนทนาของคุณและไม่ทำให้การสนทนาสิ้นสุดลง

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

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

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

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

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

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

ก่อนอื่นให้นี่เป็นตัวอย่างให้คุณแสดงความคิดเห็นรหัสของคุณอย่างถูกต้องตั๊กแตน!

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

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

เป็นความเปลี่ยนแปลงที่คุณต้องการเห็นในโลก

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

• คุณเป็นเชิงรุกมากกว่าจู้จี้
• คุณกำลังเป็นตัวอย่างที่ดี ในกรณีที่ดีที่สุดหัวหน้า / ทีมของคุณจะเห็นประโยชน์และทำตามความเหมาะสม
• ความคิดเห็นบางส่วนอาจจะพูด/* Mystery parameter 3 */หรือ/* 2015-02-09 AidanQuinn: Is this code ever called? */- ผู้ที่มีโอกาสในการร่วมงานของคุณไปยังเอกสารทั้งรหัสถูกต้องหรือแก้ไขข้อบกพร่องที่ซ่อนเร้น
• หากในระหว่างการตรวจสอบล่วงหน้าพบว่าความคิดเห็นที่คุณเขียนนั้นไม่ถูกต้องตอนนี้เพื่อนร่วมงานของคุณจะรู้ว่ารหัสไม่ชัดเจน

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

(ก่อนที่คุณจะเริ่มดำเนินการในโครงการนี้ แต่ต้องแน่ใจว่าคาดหวังของคุณสำหรับความคิดเห็นมีความเหมาะสม. หากความคิดของคุณรหัสดีแสดงความคิดเห็นอยู่นอกบรรทัดฐาน ( ตัวอย่างที่ 1 , ตัวอย่างที่ 2 ) จากนั้นคุณจะได้รับการหลอกของ ด้วยตัวคุณเอง.)

ฉันจะไม่ขอความคิดเห็นเพิ่มเติม แต่นี่เป็นแนวคิดสำหรับคุณ:

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

ความเห็นเป็นปกติ แต่ถ้ารหัสถูกเขียนในลักษณะตรงไปตรงมาก็ควรจะเข้าใจได้หลังจากไม่กี่วัน

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

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

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

นอกจากนี้ฉันต้องเห็นด้วยกับ @AK_ ซึ่งกล่าวว่าคุณไม่ต้องการความคิดเห็นใน C # นั่นอาจไม่ถูกต้อง 100% (ฉันรู้สึกว่ามีบางพื้นที่ที่ความคิดเห็นช่วยได้เช่นรหัส Reflection-heavy) แต่โดยพื้นฐานแล้วมันคือ หากคุณเขียน 'โค้ดสะอาด' จริงๆด้วยวิธีการและตัวแปรที่มีชื่อดีและมีโค้ด 'กัด' จำนวนน้อยจำนวนมากพวกเขาจะแทบไม่จำเป็นเลย ทุกครั้งที่ฉันรู้สึกว่าจำเป็นต้องมีความคิดเห็นเมื่ออ่านรหัสจนถึงตอนนั้นหลังจากที่ฉันเข้าใจในสิ่งที่มันทำฉันก็ไม่มีความสุขกับวิธีที่มันทำและคิดว่ามันจะชัดเจนขึ้นในตอนแรกโดยการปรับสภาพที่ดี แก้ไข:ฉันกำลังพูดถึงเฉพาะเกี่ยวกับความคิดเห็น C # ที่นี่ไม่ใช่เอกสาร (ไม่ว่าจะเป็นเอกสารแยกต่างหากหรือความคิดเห็น XML) เนื่องจากฉันคิดว่าเอกสารมีความสำคัญเสมอ

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

• ขนานไปกับข้างต้นฉันพยายามทำให้ตัวเองคุ้นเคยกับ 'การเข้ารหัสที่สะอาด' และวิธีปฏิบัติทั่วไปที่ดีที่สุด (ไม่ใช่ภาษาที่เฉพาะเจาะจง) ผลกระทบของสิ่งนี้อาจไม่ได้เกิดขึ้นทันที แต่มันจะจ่ายออกไปไม่ช้าก็เร็วทั้งเมื่อคุณต้องขยายสิ่งที่มีอยู่หรือสงสัยว่าทำไมบางคนสร้างวิธีการเล็ก ๆ มากมายแทนที่จะเป็นวิธีที่ทุกอย่างมีอยู่ ;-)

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

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

คุณอาจจะไม่ให้เขาเปลี่ยนสไตล์ของเขา

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

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

โชคดี!

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

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

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

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

ถ้าคุณจะเรียนรู้จากเจ้านายคุณจะไม่มีวันทำดีไปกว่าเขาตั้งมาตรฐานของคุณเองเรียนรู้การพิมพ์คนตาบอด VIM หรือปลั๊กอิน VIM สำหรับ IDE ของคุณ Linux wmii ดังนั้นคุณจะต้องไปไกลกว่าเจ้านายและดีกว่าเขา!

ในฐานะวิศวกรซอฟต์แวร์อายุ 20 ปีส่วนใหญ่ทำงานเกี่ยวกับความปลอดภัย (SF-PD) ฉันต้องบอกว่าเจ้านายของคุณอาจไม่ใช่คนที่คุณต้องการเป็นตัวอย่างของคุณ การขาดความคิดเห็นเป็นสัญญาณของ coder มือสมัครเล่นที่สอนด้วยตนเองซึ่งไม่เคยเรียนรู้วิธีการทำงานอย่างถูกต้องหรือวิศวกรมือใหม่ หรือบางทีวิศวกรที่ไม่มีเวลา - กำหนดเวลาและความได้เปรียบสามารถทำสิ่งที่น่ากลัวให้กับโค้ดของคุณ! ;) มันเป็นรูปแบบต่อต้านแน่นอนสำหรับวิศวกรซอฟต์แวร์ที่มีความสามารถทุกคน

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

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

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

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

เคยอยู่ในสถานการณ์ที่คล้ายกันฉันจะบอกว่า

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

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

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

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

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

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

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

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

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

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

นี่คือ $ 0.02 ของฉันในเรื่องนี้ ฉันไม่ได้แนะนำคำตอบพิเศษสิ่งที่พูดในที่นี้ค่อนข้างมีความเกี่ยวข้อง

ฉันจะลองวิศวกรรมสังคมสักหน่อยเพื่อจัดเตรียมสิ่งต่าง ๆ เพื่อให้เจ้านายของคุณพบว่าใช้เวลา / ความคิดเห็นในการเขียนโค้ดของเขาน้อยลง

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

ทางเลือกคืออะไร ความคิดบางอย่างขึ้นอยู่กับสถานการณ์

ตัวเลือกที่ 1

1. ใช้เวลาในการทำความเข้าใจชิ้นส่วนของรหัสของเขาเช่นเดียวกับการทำ X
2. ตอนนี้คิดว่าเป็นวิธีที่เหมาะสมเพื่อ Y เข้าใจผิดมัน
3. บอกเจ้านาย (ผ่านอีเมลหรือพูดเรื่องอาหารเช้าหรืออะไรก็ได้) ว่าคุณกำลังพยายามคิดออก
4. เพิ่มความคิดเห็นที่บอกว่ามันไม่ชัดเจนว่ารหัสหมายถึง แต่คุณเข้าใจว่าเป็น Y; พยายามทำให้ความคิดเห็นนี้ปรากฏแก่เขา แต่อย่าพยายามมากเกินไป!
5. ทำหน้าที่สมมติว่า Y - และให้แน่ใจว่าเจ้านายของคุณสังเกตเห็นการกระทำของคุณ (ดังนั้นคุณไม่ต้องเสียเวลาทำงานเป็นเวลานานบนสมมติฐานที่ผิดพลาด)
6. หัวหน้าควรใช้ความคิดริเริ่มเพื่อแก้ไขคุณ ถึงจุดนี้บอกเขาบางอย่างเช่น "ฉันหวังว่ารหัสนี้มีความคิดเห็นสองสามข้อเพื่อป้องกันไม่ให้ฉันทำผิดฉันจะแก้ไขความคิดเห็นที่ฉันเพิ่มด้วยตัวเองหรือไม่คุณคิดว่าคุณสามารถช่วยฉันด้วยคำอธิบายทั่วไปบางอย่าง ของชิ้นส่วนของรหัสนี้และนั้นฉันไม่ได้มีประสบการณ์มากพอที่จะค้นหาความตั้งใจที่แน่นอนและฉันแค่สองสามประโยคที่จะทำเคล็ดลับ " หรือบางสิ่งบางอย่าง..

ตัวเลือก 2

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

ตัวเลือก 3

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

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

หากคุณไม่สามารถเข้าใจโค้ดได้ทำไมคุณคิดว่าความคิดเห็นนั้นเป็นทางออกของคุณ

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

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

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

1. อาจเป็นความคิดเห็นที่ดีในรหัสของเขาหรือ

2. การแสดงความคิดเห็นในรหัสของเขาจะไม่เป็นสิ่งที่ดี

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

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

ดังนั้นถ้าคุณไม่พร้อมที่จะทำสิ่งนี้คุณอาจจะดีกว่าถ้าไม่พูดอะไร