หน้าแรก>การเขียนโปรแกรมที่เกี่ยวข้อง>ซอร์สโค้ดอื่น ๆ
ดาวน์โหลด 
        ooooooooo.   ooooooooo.             oooo   o8o
        `888   `Y88. `888   `Y88.           `888   `"'
         888   .d88'  888   .d88'  .ooooo.   888  oooo   .ooooo.   .ooooo.
         888ooo88P'   888ooo88P'  d88' `88b  888  `888  d88' `"Y8 d88' `88b
         888          888`88b.    888   888  888   888  888       888ooo888
         888          888  `88b.  888   888  888   888  888   .o8 888    .o
        o888o        o888o  o888o `Y8bod8P' o888o o888o `Y8bod8P' `Y8bod8P'
        ------------ What you gonna do when they come for you -------------

การแนะนำ

Prolice (การหดตัวของ ตำรวจประชาสัมพันธ์ ) เป็นเครื่องมือจัดการวิศวกรรมสำหรับการทิ้งและวัดข้อมูลคำขอดึงจากที่เก็บ GitHub

สิ่งนี้มีไว้เพื่ออะไร?

ตะโกนออกไปที่ Sourcelevel และบล็อกโพสต์ที่ยอดเยี่ยมของพวกเขาเกี่ยวกับตัวชี้วัด (ส่วนใหญ่มีการใช้งานโดยแอปพลิเคชันนี้):

ผู้จัดการฝ่ายวิศวกรรมหลายคนส่งเสริมการร้องขอการดึงซึ่งเป็นส่วนหนึ่งของเวิร์กโฟลว์การพัฒนา มันเป็นวิธีการรวมที่นำมาซึ่งประโยชน์มากมาย ประกอบด้วยการเปรียบเทียบการเปลี่ยนแปลงของสาขากับสาขาฐานที่เก็บ (เรียกว่ามาสเตอร์ตามอัตภาพ)

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

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

การเตือนล่วงหน้า

ตะโกนออกไปที่บล็อกโพสต์ของ Sourcelevel อีกครั้ง (อย่างจริงจังอ่านถ้าคุณยังไม่ได้):

ก่อนที่จะเข้าสู่การวัดฉันต้องการปฏิเสธความรับผิดชอบ: อย่าใช้ตัวเลขเหล่านี้เพื่อเปรียบเทียบบุคคล

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

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

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

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

เข้าสู่การดำเนินการ

สิ่งที่ต้องมีก่อน

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

โทเค็นจะต้องอ่านการเข้าถึงที่เก็บและดึงคำขอเพื่อให้ prolice ทำงานได้ อะไรแบบนี้:

IMG

การใช้งานขั้นพื้นฐาน

ด้วยโทเค็นการเข้าถึงส่วนบุคคลของคุณที่มีอยู่และมีการดาวน์โหลดไบนารีจากส่วนของรุ่นรีลีสให้เรียก prolice ภายในเทอร์มินัลที่คุณชื่นชอบ - ปัจจุบัน Linux และ MacOS (ดาร์วิน) ได้รับการสนับสนุน: 

prolice --owner < owner > --repository < repository > --github-token < github-token >

ตัวอย่างเช่นหากเราต้องการวัดตัวชี้วัดที่เก็บอย่างเป็นทางการของ Rust ( หมายเหตุ : ค่าเริ่มต้นนี้เป็นตัวอย่าง 100 PRS): 

prolice --owner rust-lang --repository rust --github-token < github-token >

ตัวชี้วัดการประชาสัมพันธ์ของแต่ละบุคคลได้รับการสนับสนุนเช่นกัน: 

prolice --owner rust-lang --repository rust --pr-number 32000 --github-token < github-token >

การใช้งานขั้นสูง

Prolice มีธงสองตัวและพารามิเตอร์เสริมที่สามารถใช้ในการปรับคำสั่งและขนาดตัวอย่าง: 

prolice --help
USAGE:
    prolice [FLAGS] [OPTIONS] --owner < owner > --repository < repository > --sample-size < sample-size > --github-token < github-token >

FLAGS:
    -h, --help                 Prints help information
    -m, --include-merge-prs    Marks merge-PRs as valid targets for analysis (by default these are
                               excluded). Valid only for whole Repository analysis ; for individual
                               PR analysis this flag is ignored
    -l, --print-legends        Prints the metrics ' legends before sending the operation results to
                               stdout.
    -s, --silent-mode          Marks the operation as silent, which turns off all logging and
                               printing to stdout, with the sole exception of the analysis results.
                               This makes it useful for piping just the results, without the added
                               ' noise ' . (NOTE: piping is automatically detected, which activates
                               silent-mode without having to explicitly add the flag to the command)
    -V, --version              Prints version information

OPTIONS:
    -G, --github-token <github-token>
            Sets the personal access token under which to perform the PR analysis

    -L, --log-level <log-level>
            Overrides the logging verbosity for the whole application [default: INFO] [possible
            values: INFO, DEBUG, TRACE, WARN, ERROR, OFF]

    -O, --owner <owner>                  The owner of the repository under scrutiny
    -P, --pr-number <pr-number>
            A specific pull-request to be selected as target for the analysis.

    -R, --repository <repository>        The repository under scrutiny
    -S, --sample-size <sample-size>
            The amount of PRs that will be fetched as sample for the analysis (unless a specific PR
            number is selected as individual target) [default: 100]

หมายเหตุเกี่ยวกับการใช้งานขั้นสูง

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

ตัวอย่างเช่น: 

prolice --owner rust-lang --repository rust --github-token < github-token > >> results.json

จะสร้างไฟล์ results.json ที่มีเนื้อหาต่อไปนี้ (ในขณะที่เขียน readme นี้): 

{
  "score" : [
    {
      "AmountOfParticipants" : 4
    },
    {
      "AmountOfReviewers" : 1
    },
    {
      "Attachments" : 1
    },
    {
      "AuthorCommentaryToChangesRatio" : 31.138690476190472
    },
    {
      "PullRequestsDiscussionSize" : 4065
    },
    {
      "PullRequestFlowRatio" : 1.9121686296350902
    },
    {
      "PullRequestLeadTime" : 1
    },
    {
      "PullRequestSize" : 255
    },
    {
      "TestToCodeRatio" : 0.42988095238095236
    },
    {
      "TimeToMerge" : 4
    }
  ]
}

ตัวชี้วัดที่รองรับ

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

AmountOfParticipants

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

AmountOfReviewers

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

Attachments

สิ่งที่แนบมาอาจเป็นอะไรก็ได้ตั้งแต่ภาพหน้าจอที่เพิ่มไปจนถึงไฟล์ PDF แบบฝัง มีประโยชน์อย่างยิ่งสำหรับ PRS ที่มีองค์ประกอบภาพที่เกี่ยวข้อง

AuthorCommentaryToChangesRatio

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

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

PullRequestsDiscussionSize

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

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

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

PullRequestFlowRatio

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

PullRequestLeadTime

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

PullRequestSize

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

TestToCodeRatio

ตามกฎของหัวแม่มืออย่างน้อยครึ่งหนึ่งของการประชาสัมพันธ์ควรประกอบด้วยการทดสอบทุกครั้งที่ทำได้

TimeToMerge

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

เวลาในการผสานมักจะมีประโยชน์ในขณะที่เปรียบเทียบกับเวลานำคำขอดึง นำตัวอย่างต่อไปนี้:

  • PULL Request LEAD TIME = 3 วัน
  • ถึงเวลาผสาน = 15 วัน

ในสถานการณ์ข้างต้นคำขอดึงใช้เวลาเฉลี่ย 3 วันในการรวม (ซึ่งค่อนข้างดี); แต่เวลาที่จะรวมคือ 15 วัน ซึ่งหมายความว่านักพัฒนาทำงานเฉลี่ย 12 วัน (15 - 3) ก่อนที่จะเปิดคำขอดึง

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

การรวบรวม prolice โดยใช้ cargo

Prolice เขียนเป็นสนิม การรวบรวมแอปพลิเคชันสำหรับการใช้งานในแพลตฟอร์มโฮสต์นั้นง่ายพอ ๆ กับการใช้ cargo build อายุธรรมดา: 

cargo build --release

cross-compiling prolice โดยใช้ cargo-make (Linux to MacOS)

ให้เริ่มส่วนนี้ก่อนด้วยคำนำเล็กน้อยจากบล็อกที่ยอดเยี่ยมนี้:

ฉันเกลียดการรวบรวมข้าม

มีหลายล้านวิธีในการทำลายระบบปฏิบัติการที่คุณกำลังทำอยู่และการรวบรวมข้ามเป็นหนึ่งในนั้น โดยปกติแล้วจะเริ่มต้นด้วยความคิดที่ไร้เดียงสาในการสร้างโซ่การสร้างครั้งหนึ่งที่คุณต้องการสำหรับโปรแกรมขนาดเล็กเพื่อทำงานบน Linksys WRT 1900 ACS (OpenWRT และ ARMV7)

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

การเรียกใช้ทุบตีนั้นอาจทำให้เกิดหนึ่งในสิ่งต่อไปนี้:

  • สร้างห่วงโซ่บิลด์ที่ใช้งานได้ (ไม่น่าเป็นไปได้มาก)
  • สร้างห่วงโซ่การสร้างซึ่งล้มเหลวหลังจาก 80% ของการสร้างของคุณ
  • เพิ่ม bitcoin miner ในท้องถิ่นในขณะที่แกล้งทำเป็นสร้างห่วงโซ่งานสร้างที่ใช้งานได้จริง

เมื่อรู้สึกถึงความเจ็บปวดเหล่านี้ในระดับส่วนบุคคลการรวบรวมข้ามได้ถูกนำมาใช้ในระดับที่ค่อนข้างปราศจากความเจ็บปวดโดยเป้าหมายที่กำหนดไว้ในโครงการขนส่ง cargo-makefile.toml ได้

แน่นอนว่าถ้ารวบรวมเฉพาะสำหรับเครื่องโฮสต์การติดกับ cargo build เก่าแก่เป็นตัวเลือกแรกเสมอ แต่สมมติว่าวัตถุประสงค์คือการรวบรวมจาก linux ไปยัง macOS (ดาร์วิน) ตั้งแต่เริ่มต้นนอกเหนือจากเชน toolchain สนิมปกติคุณจะต้องติดตั้ง cargo-make เช่นนี้: 

cargo install --force cargo-make

หลังจากนั้นขั้นตอนการรวบรวมจะได้รับการดูแลอย่างสมบูรณ์โดยการเรียกใช้: 

cargo make --makefile cargo-makefile.toml release-darwin

สิ่งนี้จะสร้างและสถานที่หลังจากกระบวนการเสร็จสิ้นไบนารีบีบอัดที่:

<your_dir>/target/release/out/prolice_x86_64-apple-darwin.zip

อย่างไรก็ตาม คำนึงถึง การรวบรวม Linux-to-Darwin ต้องใช้ Docker ดังนั้นอีกครั้งคุณอาจช่วยตัวเอง หลาย MBs โดยการติดอยู่ในการสร้างไบนารีสำหรับเครื่องโฮสต์ของคุณโดยเพียงแค่เรียกใช้ cargo build เก่าธรรมดา

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