การควบคุมเวอร์ชันการอ่านของผู้จัดการยอมรับ


18

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

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

มีวิธีแก้ปัญหาทางสังคมหรือทางเทคนิคหรือไม่?

ข้อมูลเพิ่มเติม: นี่คือโครงการบำรุงรักษาดังนั้นจึงมีกลุ่มของ "ต้องทำ A แล้ว B แล้ว C และจากนั้น D และในที่สุดก็ต้องใช้ X" งานที่เกิดขึ้น

ข้อมูลเพิ่มเติม: ข้อความการส่งข้อความพิเศษที่ยกธงกับผู้จัดการนั้นอยู่ใกล้กับ "รวมวิธีที่ดีกว่าในการ X, Y และ Z" ซึ่งเป็นข้อความการปรับโครงสร้างมากกว่าการแก้ไขโวหารง่าย ๆ



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

9
การปรับโครงสร้างที่แท้จริงนั้นสำคัญยิ่งกว่าการจับภาพมากกว่าการเปลี่ยนแปลงทางโวหาร อย่างน้อยที่สุดข้อความยืนยันควรจะบอกว่าสิ่งที่ถูก refactored แต่จริง ๆ แล้วฉันต้องการให้มันติดตามเพื่อให้ทุกคนรู้ว่าสิ่งที่ถูก refactored, QA รู้ว่าสิ่งที่จะทดสอบอย่างระมัดระวังมากขึ้น
Gort the Robot

3
^^^ สิ่งที่ @StevenBurnap พูด - นี่เป็นวิธีปฏิบัติที่ดีมาก เพียงแค่สามารถอ้างถึงรหัสตั๋วแทนการสร้างมลภาวะข้อความที่มีคำอธิบายที่ยาวนานเกี่ยวกับสิ่งที่การปรับปรุง / การเปลี่ยนรูปแบบของประเภทนั้นอยู่ที่นั่นและทำไมสิ่งเหล่านี้จึงเป็นที่ต้องการ และยิ่งไปกว่านั้นการติดตามความพยายามการสื่อสารกับการจัดการ / QA ฯลฯ และอย่าให้ฉันเริ่มต้นว่าจะสะดวกอย่างไรเมื่อตัวติดตามบั๊กทำงานร่วมกับ VCS / เครื่องมือตรวจสอบโค้ด
gnat

1
มันขึ้นอยู่กับสถานการณ์อย่างสมบูรณ์ ผู้จัดการตอบสนองต่อสมาชิกของทีมที่ใช้เวลา 50% ในการปรับโครงสร้างหรือการกระทำครั้งเดียวโดยไม่มีการอ้างอิงตั๋วหรือไม่?
winkbrace

คำตอบ:


42

มีวิธีแก้ปัญหาทางสังคมหรือทางเทคนิคหรือไม่?

ฉันคิดว่า แต่นี้ไม่ได้เป็นปัญหา

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

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


14

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

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

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

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


1
โอเค แต่ถ้ามันเป็นเรื่องเล็กน้อยแล้วนี่มันโง่อย่างสมบูรณ์
การแข่งขัน Lightness กับโมนิก้า

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

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

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

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

1

สิ่งนี้ทำให้ฉันเหมือนกัน (ไม่ตั้งใจเล่น :)

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

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

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.