คำถามติดแท็ก code-reviews

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

71 code-quality  code-reviews 

ฉันเพิ่งเริ่มทำงานในที่ที่มีผู้พัฒนาอายุมาก (ประมาณ 50 ปีขึ้นไป) พวกเขาทำงานเกี่ยวกับแอพพลิเคชั่นที่สำคัญเกี่ยวกับการบินที่ระบบไม่สามารถลงได้ เป็นผลให้โปรแกรมเมอร์ที่มีอายุมากกว่ามีแนวโน้มที่จะรหัสด้วยวิธีนี้ เขามีแนวโน้มที่จะวางบูลีนในวัตถุเพื่อระบุว่าควรโยนข้อยกเว้นหรือไม่ ตัวอย่าง public class AreaCalculator { AreaCalculator(bool shouldThrowExceptions) { ... } CalculateArea(int x, int y) { if(x < 0 || y < 0) { if(shouldThrowExceptions) throwException; else return 0; } } } (ในโครงการของเราวิธีการอาจล้มเหลวเนื่องจากเราพยายามใช้อุปกรณ์เครือข่ายที่ไม่สามารถแสดงได้ในเวลาตัวอย่างพื้นที่เป็นเพียงตัวอย่างของการตั้งค่าสถานะข้อยกเว้น) สำหรับฉันนี่ดูเหมือนรหัสกลิ่น การเขียนการทดสอบหน่วยจะซับซ้อนกว่าเล็กน้อยเนื่องจากคุณต้องทดสอบการตั้งค่าสถานะข้อยกเว้นในแต่ละครั้ง นอกจากนี้หากมีสิ่งผิดปกติคุณไม่ต้องการรู้ทันทีหรือไม่? ไม่ควรเป็นความรับผิดชอบของผู้โทรที่จะกำหนดวิธีดำเนินการต่อ ตรรกะ / เหตุผลของเขาคือโปรแกรมของเราต้องการทำสิ่งหนึ่งแสดงข้อมูลให้ผู้ใช้ ข้อยกเว้นอื่นใดที่ไม่ได้ห้ามไม่ให้เราทำเช่นนั้นควรเพิกเฉย ฉันยอมรับว่าพวกเขาไม่ควรเพิกเฉย แต่ควรทำให้เกิดฟองและจัดการโดยบุคคลที่เหมาะสมและไม่จำเป็นต้องจัดการกับสถานะสำหรับสิ่งนั้น นี่เป็นวิธีที่ดีในการจัดการข้อยกเว้นหรือไม่ …

64 c#  design  object-oriented-design  exceptions  code-reviews 

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

64 code-quality  code-reviews 

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

55 teamwork  code-reviews  pair-programming 

ฉันเป็นผู้ศรัทธาที่ยิ่งใหญ่ในกฎลูกเสือ : ตรวจสอบโมดูลที่สะอาดกว่าทุกครั้งที่คุณตรวจสอบ "ไม่ว่าใครจะเป็นคนเขียนต้นฉบับจะทำอย่างไรถ้าเราใช้ความพยายามไม่ว่าจะเล็กแค่ไหนในการปรับปรุงโมดูล ทั้งหมดตามกฎง่ายๆนั้นเราจะเห็นจุดจบของการเสื่อมของระบบซอฟต์แวร์ของเราอย่างไม่หยุดยั้งแทนระบบของเราจะค่อยๆดีขึ้นและดีขึ้นตามที่วิวัฒนาการเรายังเห็นทีมที่ดูแลระบบโดยรวมค่อนข้าง มากกว่าเพียงแค่บุคคลที่ดูแลส่วนเล็ก ๆ ของตัวเอง ฉันยังเป็นผู้เชื่อที่ยอดเยี่ยมในแนวคิดที่เกี่ยวข้องกับการปรับโครงสร้างแบบฉวยโอกาส : แม้ว่าจะมีสถานที่สำหรับความพยายาม refactoring ที่กำหนดไว้บางอย่างฉันต้องการส่งเสริมให้ refactoring เป็นกิจกรรมที่มีโอกาสทำทุกครั้งและทุกที่ที่รหัสจำเป็นต้องทำความสะอาด - โดยใครก็ตาม สิ่งนี้หมายความว่าเมื่อใดก็ตามที่มีคนเห็นรหัสบางอย่างที่ไม่ชัดเจนอย่างที่ควรจะเป็นพวกเขาควรมีโอกาสแก้ไขมันที่นั่นแล้ว - หรืออย่างน้อยก็ภายในไม่กี่นาที ข้อความที่ตัดตอนมาต่อไปนี้โดยเฉพาะอย่างยิ่งจากบทความ refactoring: ฉันระวังวิธีการพัฒนาใด ๆ ที่ทำให้เกิดแรงเสียดทานสำหรับการปรับโครงสร้างแบบฉวยโอกาส ... ความรู้สึกของฉันคือทีมส่วนใหญ่ไม่ได้ทำการปรับโครงสร้างใหม่ให้เพียงพอดังนั้นจึงเป็นเรื่องสำคัญที่จะต้องใส่ใจกับทุกสิ่งที่ทำให้คนไม่สนใจ เพื่อช่วยในการชะล้างสิ่งนี้ให้ระวังเมื่อใดก็ตามที่คุณรู้สึกท้อแท้ที่จะทำการปรับโครงสร้างเล็ก ๆ ซึ่งคุณมั่นใจว่าจะใช้เวลาเพียงหนึ่งหรือสองนาทีเท่านั้น สิ่งกีดขวางใด ๆ นั้นเป็นกลิ่นที่น่าจะกระตุ้นการสนทนา ดังนั้นจดบันทึกความท้อแท้และนำมันขึ้นมาพร้อมกับทีม อย่างน้อยที่สุดมันก็ควรจะพูดคุยในช่วงหลังของคุณย้อนหลัง ที่ที่ฉันทำงานมีการพัฒนาวิธีปฏิบัติหนึ่งที่ทำให้เกิดการเสียดทานอย่างหนัก - Code Review (CR) เมื่อใดก็ตามที่ฉันเปลี่ยนแปลงสิ่งใดก็ตามที่ไม่อยู่ในขอบเขตของ "การมอบหมาย" ของฉันฉันกำลังถูกตำหนิโดยผู้ตรวจสอบของฉันว่าฉันกำลังทำการเปลี่ยนแปลงให้ยากขึ้น นี่เป็นเรื่องจริงโดยเฉพาะอย่างยิ่งเมื่อมีการ refactoring เนื่องจากทำให้การเปรียบเทียบแบบ "ต่อบรรทัด" เป็นเรื่องยาก วิธีการนี้เป็นมาตรฐานที่นี่ซึ่งหมายถึงการปรับโครงสร้างแบบฉวยโอกาสเกิดขึ้นได้ยากและต้องมีการปรับโครงสร้างใหม่ "ตามแผน" …

55 refactoring  code-reviews 

ฉันกำลังรวบรวมแนวทางสำหรับการตรวจสอบโค้ด เรายังไม่มีกระบวนการที่เป็นทางการและกำลังพยายามทำให้เป็นระเบียบ และทีมของเรามีการกระจายทางภูมิศาสตร์ เราใช้TFSสำหรับการควบคุมแหล่งข้อมูล (เราใช้สำหรับการติดตามงาน / ข้อบกพร่อง / การจัดการโครงการเช่นกัน แต่เราย้ายข้อมูลไปยังJIRA ) ด้วย Visual Studio 2008 เพื่อการพัฒนา สิ่งที่คุณมองหาเมื่อทำการตรวจสอบรหัสคืออะไร? นี่คือสิ่งที่ฉันคิดขึ้นมา บังคับใช้กฎFxCop (เราเป็นร้านค้าของ Microsoft) ตรวจสอบประสิทธิภาพ (เครื่องมือใด ๆ ) และความปลอดภัย (คิดถึงการใช้ OWASP - โปรแกรมรวบรวมข้อมูลโค้ด ) และความปลอดภัยของเธรด ยึดมั่นในการตั้งชื่ออนุสัญญา รหัสควรครอบคลุมกรณีขอบและเงื่อนไขขอบเขต ควรจัดการข้อยกเว้นอย่างถูกต้อง (อย่ากลืนข้อยกเว้น) ตรวจสอบว่าการทำงานซ้ำซ้อนที่อื่นหรือไม่ ร่างกายวิธีการควรมีขนาดเล็ก (20-30 บรรทัด) และวิธีการควรทำสิ่งหนึ่งและสิ่งเดียวเท่านั้น (ไม่มีผลข้างเคียงและหลีกเลี่ยงการมีเพศสัมพันธ์ชั่วคราว -) ห้ามส่ง / คืนค่า null ในเมธอด หลีกเลี่ยงรหัสที่ตายแล้ว เอกสารสาธารณะและวิธีการป้องกัน …

55 code-reviews 

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

53 agile  code-reviews 

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

52 refactoring  code-reviews  clean-code  code-smell 

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

51 open-source  self-improvement  code-reviews  personal-projects 

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

48 code-reviews 

ฉันเป็นส่วนหนึ่งของทีมที่ปรึกษาที่ใช้โซลูชันใหม่สำหรับลูกค้า ฉันรับผิดชอบในการทบทวนโค้ดส่วนใหญ่ใน codebase ฝั่งไคลเอ็นต์ (ตอบโต้และจาวาสคริปต์) ฉันสังเกตเห็นว่าสมาชิกในทีมบางคนใช้รูปแบบการเข้ารหัสที่ไม่เหมือนใครจนถึงจุดที่ฉันสามารถเลือกไฟล์แบบสุ่มโดยบอกว่าใครเป็นผู้แต่งจากสไตล์คนเดียว ตัวอย่างที่ 1 (ฟังก์ชั่นอินไลน์แบบครั้งเดียว) React.createClass({ render: function () { var someFunc = function () { ... return someValue; }; return <div>{someFunc()}</div> } }); ผู้เขียนระบุว่าด้วยการกำหนดชื่อที่มีความหมายให้กับบางส่วนการตัดรหัสจะง่ายต่อการอ่าน ฉันเชื่อว่าการใช้ฟังก์ชั่นและเพิ่มความคิดเห็นแทนการใช้เอฟเฟกต์เดียวกันสามารถทำได้ ตัวอย่างที่ 2 (ฟังก์ชันที่ไม่ถูกผูก) function renderSomePart(props, state) { return ( <div> <p>{props.myProp}</p> <p>{state.myState}</p> </div> ); } React.createClass({ render: function () { …

47 javascript  code-quality  code-reviews  reactjs 

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

43 code-quality  git  code-reviews  github  gitflow 

ฉันไม่มีทางเลือกนอกจากต้องทำงานด้วยตัวเองและไม่สามารถหาวิธีแก้ปัญหาที่เพียงพอสำหรับการตรวจสอบงานของฉันตรวจสอบความมีสติมีคนที่จะระดมความคิดด้วยการพูดคุยเกี่ยวกับแนวทางปฏิบัติที่ดีที่สุดและอื่น ๆ ฉันคิดว่าฉันจะได้รับคำตอบผ่านบทความของ Jeff Atwood: ในการเขียนโปรแกรม One Is The Loneliest Numberที่ดีที่สุดที่ฉันสามารถหาได้ในเรื่องนี้ แต่มันกลับกลายเป็นเพียงแค่ย้ำคำถามของฉัน ฉันรู้ว่าเว็บไซต์ Stack Exchange เช่นนี้และการตรวจสอบโค้ดเป็นคำตอบที่เป็นไปได้ชัดเจน แต่หลาย ๆ คนคงชื่นชมมันไกลจากอุดมคติ: ในขณะที่ฉันไม่สามารถเขียนรายการข้อผิดพลาดทั้งหมดบ่อยครั้งการตั้งคำถามและต่อยเป็นปัญหาที่เกิดขึ้นในตัวเองมักจะใช้เวลาทำงานมากจนเมื่อถึงเวลาที่คุณเตรียมไว้อย่างเพียงพอคุณก็ตอบคำถามของคุณเองได้มากขึ้น เวลากว่าที่คิดไว้เป็นอย่างอื่น นอกจากนี้การซ่อนรายละเอียดเพื่อถามคำถามที่กำหนดไว้อย่างดีช่วยลดความเป็นไปได้ที่จะมีคนเจอปัญหาที่คุณไม่ได้คิด นอกจากนี้ในขณะที่ฉันไม่สามารถจับมันได้ แต่การตอบสนองของการสนทนาฟรีไม่สามารถจับคู่ได้โดยการสนทนาทางอินเทอร์เน็ตในรูปแบบใด ๆ ที่ฉันนึกออก ท้ายสุด แต่ไม่ท้ายสุดฉันไม่ต้องการโพสต์โปรเจคทั้งหมดเพื่อให้โลกมองไปที่นิรันดร์ที่เหลือด้วยเหตุผลที่ชัดเจน มีคำตอบอื่นนอกเหนือจากการจ่ายที่ปรึกษาเพื่อดูรหัสของฉัน

39 code-reviews  solo-development 

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

39 code-reviews  junior-programmer 

ฉันเพิ่งเริ่มต้นเป็นนักพัฒนารุ่นน้อง เช่นเดียวกับการเป็นหนึ่งในคนที่มีประสบการณ์น้อยที่สุดในทีมฉันก็เป็นผู้หญิงคนหนึ่งซึ่งมาพร้อมกับความท้าทายทุกประเภทของตัวเองที่ทำงานในสภาพแวดล้อมที่เป็นชาย ฉันมีปัญหาเมื่อเร็ว ๆ นี้เพราะฉันรู้สึกว่าฉันได้รับคำวิจารณ์เชิงวิพากษ์วิจารณ์มากเกินไปในงานของฉัน ผมขอยกตัวอย่างสิ่งที่เกิดขึ้นเมื่อเร็ว ๆ นี้ หัวหน้าทีมยุ่งเกินไปที่จะผลักดันในบางสาขาที่ฉันทำดังนั้นเขาจึงไม่ไปถึงพวกเขาจนกว่าจะถึงสุดสัปดาห์ ฉันตรวจสอบเมลของฉันไม่ได้มีความหมายว่าจะทำงานใด ๆ และพบว่าทั้งสองสาขาของฉันถูกปฏิเสธโดยใช้ชื่อตัวแปรทำให้ข้อความแสดงข้อผิดพลาดมีความหมายมากขึ้นและย้ายค่าบางอย่างไปยังไฟล์ปรับแต่ง ฉันไม่รู้สึกว่าการปฏิเสธสาขาของฉันบนพื้นฐานนี้มีประโยชน์ ผู้คนจำนวนมากทำงานในช่วงสุดสัปดาห์และฉันไม่เคยบอกว่าจะทำงาน อย่างมีประสิทธิภาพบางคนอาจถูกบล็อกเพราะฉันไม่มีเวลาทำการเปลี่ยนแปลงและส่งอีกครั้ง เรากำลังทำงานในโครงการที่มีความอ่อนไหวต่อเวลามากและดูเหมือนว่าสำหรับฉันแล้วมันไม่ได้มีประโยชน์อะไรเลยที่จะปฏิเสธรหัสทันทีตามสิ่งต่าง ๆ ที่โปร่งใสสำหรับลูกค้า ฉันอาจจะผิด แต่ดูเหมือนว่าสิ่งเหล่านี้ควรได้รับการจัดการในประเภทปะแก้เมื่อฉันมีเวลา ตอนนี้ฉันเห็นแล้วว่าในบางสภาพแวดล้อมนี่จะเป็นบรรทัดฐาน อย่างไรก็ตามการวิจารณ์ไม่ได้กระจายเท่ากันซึ่งเป็นสิ่งที่นำไปสู่ปัญหาต่อไปของฉัน พื้นฐานของปัญหาเหล่านี้ส่วนใหญ่เกิดจากความจริงที่ว่าฉันอยู่ใน codebase ที่คนอื่นเขียนและพยายามที่จะบุกรุกน้อยที่สุด ฉันเลียนแบบชื่อตัวแปรที่ใช้ที่อื่นในไฟล์ เมื่อฉันพูดถึงสิ่งนี้ฉันก็บอกอย่างตรงไปตรงมาว่า "อย่าเลียนแบบคนอื่นทำในสิ่งที่ถูกต้อง" นี่อาจเป็นสิ่งที่มีประโยชน์น้อยที่สุดที่ฉันบอกได้ หากรหัสที่เช็คอินแล้วไม่สามารถยอมรับได้ฉันควรจะบอกได้อย่างไรว่าอะไรถูกและผิด? หากพื้นฐานของความสับสนนั้นมาจากรหัสพื้นฐานฉันไม่คิดว่า ' ฉันรู้สึกโดดเดี่ยวและผิดหวังมากในสถานการณ์นี้ ฉันได้รับสิ่งที่ดีกว่ามากเกี่ยวกับการทำตามมาตรฐานที่คาดไว้และฉันรู้สึกหงุดหงิดเช่นเมื่อฉันสร้างรหัสใหม่เพื่อตรวจสอบข้อผิดพลาดของ ADD ที่หายไปก่อนหน้านี้ฉันบอกเพียงว่าฉันไม่ได้ ทำให้เกิดข้อผิดพลาดอย่างเพียงพอ (และสาขาถูกปฏิเสธบนพื้นฐานนี้) จะเกิดอะไรขึ้นถ้าฉันไม่เคยเพิ่มลงไปเพื่อเริ่มต้น มันจะเริ่มต้นอย่างไรในรหัสเพื่อเริ่มต้นถ้ามันผิดดังนั้น? นี่คือเหตุผลที่ฉันรู้สึกแยกออกจากกัน: ฉันพบกับรหัสปัญหาที่มีอยู่นี้อย่างต่อเนื่องซึ่งฉันเลียนแบบหรือปรับเปลี่ยนใหม่ เมื่อฉันเลียนแบบมันเป็น "ผิด" และถ้าฉัน refactor มันฉัน chided สำหรับทำไม่เพียงพอ (และถ้าฉันไปตลอดทางแนะนำแมลง …

39 code-quality  self-improvement  teamwork  code-reviews