คุณจะตอบสนองอย่างไรถ้ามีคนบอกว่ารหัสของคุณยุ่งเหยิง?

ฉันเป็นโปรแกรมเมอร์ที่ดีหรือฉันคิดอย่างนั้นมาก่อน ฉันรักการเขียนโปรแกรมเสมอ และฉันต้องการเรียนรู้หลายสิ่งหลายอย่างเกี่ยวกับการเขียนโปรแกรมเพื่อทำให้ฉันเป็นโปรแกรมเมอร์ที่ดีขึ้น ฉันศึกษาการเขียนโปรแกรมเป็นเวลา 1 ปีและตอนนี้ฉันทำงานเป็นโปรแกรมเมอร์เกือบ 2 ปี ดังนั้นในระยะสั้นฉันมีประสบการณ์การเขียนโปรแกรมเกือบ 3 ปี

ทีมงานของเราประกอบด้วยโปรแกรมเมอร์ 5 คนและเรา 4 คนใหม่ 1 คนมีประสบการณ์มากกว่า 3 ปี เราได้ทำงานกับโปรแกรมมาเกือบปีแล้วและไม่มีใครเคยตรวจสอบรหัสของฉันและฉันได้รับหน้าที่ให้ทำงานด้วย เราไม่เคยมีรีวิวรหัสและเราใหม่ทั้งหมดดังนั้นเราไม่ทราบว่ารหัสที่สะอาดดูเหมือนอะไร ฉันคิดว่าโปรแกรมเมอร์เรียนรู้ด้วยตัวเองเหรอ?

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

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

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

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

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

อ่านhttp://www.perlmonks.org/?node_id=270083หากคุณไม่รู้ว่าฉันกำลังพูดถึงอะไร

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

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

คำเตือน: สิ่งนี้ไม่ควรอ่านในฐานะ "รหัสไม่ดีก็โอเค"

รหัสของทุกคนไม่เป็นระเบียบและไม่มีโปรแกรมเมอร์ที่ดี

มี:

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

พวกเขาแทบจะไม่เคยเป็นคนเดียวกันเลย

และมีโปรแกรมเมอร์ butthurt ที่ต้องเติบโตและ:

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

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

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

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

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

คุณได้อ่านส่วนที่เก่ากว่าของรหัสที่คุณเขียนไปหรือไม่? คุณอาจเห็นสิ่งต่าง ๆ ที่คุณต้องการจะทำตอนนี้หรือสร้างใหม่

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

ฉันรู้สึกเศร้าและเจ็บปวดมาก ฉันรักการเขียนโปรแกรมและทำให้พวกเขาพูดอะไรบางอย่างที่ทำให้ฉันเจ็บจริงๆ ฉันต้องการพัฒนาตนเอง

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

แต่ดูเหมือนว่าฉันไม่ใช่โปรแกรมเมอร์อัจฉริยะเหมือนในภาพยนตร์

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

คุณสามารถให้คำแนะนำกับฉันให้ดีขึ้นได้อย่างไร

อ่านและฝึกหัด ตรวจสอบหนังสือเช่นรหัสสินค้าหรือโปรแกรมเมอร์ศาสตร์ มองหา Amazon สำหรับหนังสือที่คล้ายกัน

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

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

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

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

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

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

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

พวกเขาจะต้องตอบคุณและคุณจะสามารถ:

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

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

Our team is composed of 5 programmers, and 4 of us are new

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

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

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

"หากมีผู้ตรวจสอบมากพอปัญหาทั้งหมดก็จะแก้ไขได้ง่าย"

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

I feel so sad and hurt. 

ไปสร้างแอปพลิเคชั่นความเศร้าเพื่อดูว่าคุณอารมณ์เสียแค่ไหนเมื่อคุณไม่ได้สมัครด้วยตัวเอง

คุณตอบปัญหาของคุณ ... คุณไม่ได้ทดสอบ!

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

ในนั้นมีการถู

"เราปรับใช้โปรแกรมของเรากับโปรแกรมโดยไม่ต้องทดสอบอย่างละเอียด"

การลักขโมยของผู้สร้าง UML Grady Booch ...

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

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

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

Outro ... คุณทำได้ดี - อย่าเพิ่งสะอื้น ก้าวต่อไปในการพัฒนาฝีมือของคุณ โชคดี :-)

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

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

รหัสของคุณไม่ใช่คุณ จำไว้.

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

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

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

จำไว้ว่านี่คือรหัสที่แย่ที่สุดที่คุณจะเห็นว่าเป็นของคุณ!

Jeff Atwood จาก codinghorror.com เขียนมากเกี่ยวกับหัวข้อคุณอาจต้องการเริ่มต้นที่นี่: http://www.codinghorror.com/blog/2009/07/nobody-hates-software-more-than-software-developers.html

หากคุณต้องการปรับปรุงให้เริ่มอ่านเนื้อหาเกี่ยวกับรูปแบบการเข้ารหัสรูปแบบขั้นตอนการทำงานโดยทั่วไปแล้วทุกอย่างที่คุณสามารถทำได้ เรียนรู้ภาษาการเขียนโปรแกรมเพิ่มเติมดูวิธีการทำงาน หากคุณกำลังทำ OOP อ่านสิ่งนี้: http://en.wikipedia.org/wiki/Design_Patterns

พูดคุยกับโปรแกรมเมอร์คนอื่น ๆ และทำการจับคู่การเขียนโปรแกรมหรือดูรหัสอื่น ๆ

การทำผิดพลาดเป็นสิ่งที่หลีกเลี่ยงไม่ได้

เวลาส่วนใหญ่คุณควรพูดว่า "ขอบคุณ" กับคนที่บอกเรื่องนี้กับคุณ

โอกาสที่พวกเขาจะสนใจอาชีพของพวกเขาพวกเขาสนใจงานของพวกเขาพวกเขาดูแลทีมของพวกเขาและพวกเขาก็ห่วงใยคุณ

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

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

ลองดูรหัสที่คุณเขียนเมื่อเริ่มอาชีพของคุณ คุณเป็นอย่างไรบ้างตอนนี้ มันดูดีเหมือนที่คุณคิดหรือไม่เมื่อคุณเขียนมัน)

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

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

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

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

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

ในที่สุดฉันขอแนะนำให้อ่าน "รหัสสะอาด" โดย Robert C. Martin มันจะบอกคุณว่าทำไมโค้ดของคุณรกและสิ่งที่คุณสามารถทำได้เพื่อทำความสะอาด

คุณสามารถให้คำแนะนำกับฉันให้ดีขึ้นได้อย่างไร

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

ที่ผ่านมา:

ทีมงานของเราประกอบด้วยโปรแกรมเมอร์ 5 คนและเรา 4 คนใหม่ 1 คนมีประสบการณ์มากกว่า 3 ปี เราได้ทำงานกับโปรแกรมมาเกือบปีแล้วและไม่มีใครเคยตรวจสอบรหัสของฉันและฉันได้รับหน้าที่ให้ทำงานด้วย

นำเสนอ:

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

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

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

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

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

นี่คือการเปลี่ยนแปลงทางวัฒนธรรมซึ่งคุณไม่สามารถบังคับได้ด้วยตัวเอง แต่คุณสามารถช่วยในการสะกิดสิ่งต่าง ๆ ในทิศทางที่ถูกต้อง!

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

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

คำตอบของเรื่องนี้สามารถพบได้ใน บริษัท รุ่นใหม่ ฉันเคยไปที่ บริษัท ต่างๆเช่น Google และ FaceBook และฉันเห็นว่าถ้าคุณทำตามกระบวนการ Agile / Scrum อย่างเคร่งครัดคุณสามารถเขียนรหัสได้ดีขึ้นและปรับปรุงให้ดีขึ้นทุกการวิ่ง

How to be better? 

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

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

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

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

คุณสามารถยกตัวอย่างเฉพาะของสิ่งที่เรียกว่า "ระเบียบ" ได้หรือไม่?

ก่อนอื่นมีคนบอกว่ารหัสของคุณยุ่งเหยิงและคลุมเครือมาก มันอาจหมายถึงสิ่งต่าง ๆ กับคนอื่น นี่คือเหตุผล; มีสองสิ่งที่แตกต่างที่ต้องพิจารณา

โครงสร้าง

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

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

สไตล์

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

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

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

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

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

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

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

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

ฉันคิดว่ามีสองส่วนในการประมวลผลความคิดเห็นเชิงลบ

1. กำหนดลักษณะของปัญหาที่หยิบยกขึ้นมาและสิ่งที่คุณควรเรียนรู้จากมัน

เมื่อฉันตรวจสอบหรือให้รหัสของฉันได้รับการตรวจสอบฉันจัดเรียงข้อมูลเกี่ยวกับปัญหาเกี่ยวกับรหัสในที่เก็บเช่น:

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

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

2. พิจารณาว่าจะทำการเปลี่ยนแปลงรหัสใดบ้าง (ถ้ามี) ซึ่งเป็นผลการตรวจสอบ

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

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

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

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

ฉันเคยผ่านสถานการณ์นี้และฉันสามารถเข้าใจ

TL; DR

คุณจะตอบสนองอย่างไรถ้ามีคนบอกว่ารหัสของคุณยุ่งเหยิง?

ตรงไปตรงมาของฉัน "นานเกินไปไม่ได้อ่าน (คำตอบทั้งหมด - ขอโทษฉันหวังว่าจะหาเวลาให้ในภายหลังและแก้ไข / แก้ไขในกรณีที่จำเป็น)" คำตอบ / เคล็ดลับ:

• รีวิว Peer เก่าดี ถามทีมงานที่แตกต่างกันด้วยจิตรวมระดับความเชี่ยวชาญและ / หรือระดับของความก้าวร้าวเพื่อตรวจสอบรหัสของคุณ
• เพื่ออธิบายรายละเอียดเล็กน้อยเกี่ยวกับสิ่งที่ฉันหมายถึงโดยกลุ่มเพื่อนที่ "แตกต่าง": กองพลัดถิ่น StackExchange น่าจะเป็นกลุ่มที่มีความเป็นมืออาชีพและนับถือมากที่สุดเพราะความยากลำบากในการเป็นส่วนหนึ่งของมันเมื่อเทียบกับพูดว่า Reddit Reddit มีแนวโน้มที่จะก้าวร้าวมากใน sub-reddits ที่เป็นที่นิยมมากขึ้น - แต่พอ subreddits การเขียนโปรแกรมค่อนข้างเป็นมิตร (จากสิ่งที่ฉันมีประสบการณ์)

ที่ดีบางทีตัวอย่างที่ดีที่สุดของกลุ่มนักคิดที่ก้าวร้าวและอันธพาลคือกลุ่ม XDK Forums และสิ่งที่เลวร้ายที่สุดของถ้วยรางวัลที่แย่ที่สุดที่ฉันมอบให้ CyanogenMod สำหรับ Android และ IRC channel populace

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