ทำไมและเมื่อสร้างแพ็คเกจ R

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

ในบรรดาประเด็นที่อาจนำไปสู่การตัดสินใจเหล่านี้ฉันได้นึกถึง:

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

และในบรรดาประเด็นที่อาจนำไปสู่การตัดสินใจที่ตรงกันข้าม:

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

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

ฉันไม่ได้เขียนโปรแกรมใน R แต่ฉันเขียนโปรแกรมเป็นอย่างอื่นและฉันไม่เห็นปัญหาเฉพาะ R ที่นี่

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

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

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

อาจมีหนังสือเล่มหนึ่งเกี่ยวกับเรื่องนี้ แต่มีคำแนะนำบางอย่างเกี่ยวกับ:

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

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

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

นี่เป็นคำถามที่สำคัญและเป็นประโยชน์ เริ่มต้นด้วยการแยกแยะระหว่างการเขียนแพ็คเกจและการเผยแพร่บน CRAN

เหตุผลที่ไม่เขียนแพ็คเกจ:

• ประหยัดต้นทุน
• ขาดประสบการณ์.

เหตุผลในการเขียนแพ็คเกจ R:

• แบ่งปันกับผู้คนและแพลตฟอร์ม
• บังคับใช้โค้ดที่เป็นระเบียบและกระบวนการทำงาน
• ใช้งานง่าย (แม้สำหรับตัวเอง) เมื่อฟังก์ชั่นเริ่มสะสม

เหตุผลในการส่งแพ็คเกจ (CRAN, Bioconductor, ... ):

• มีส่วนร่วมในชุมชน
• ความง่ายในการกระจาย

จำไว้ว่ามีตัวเลือก # 3; คุณอาจขอให้ผู้ดูแลแพคเกจที่เกี่ยวข้องรวมรหัสหรือข้อมูลของคุณ

ทริกเกอร์ส่วนตัวของฉันสำหรับบรรจุภัณฑ์คือ:

• ฉันพบว่าฉันใช้รหัสที่ฉันเขียนอีกครั้งสำหรับโครงการวิเคราะห์ข้อมูลอีกครั้ง
• ฉันคิดว่าฉันต้องการวิธีที่ฉันเพิ่งเขียนอีกครั้ง

• เพื่อนร่วมงานขอรหัสให้ฉัน ส่วนสำคัญของรหัสที่ฉันเขียนนั้นเป็นอย่างน้อยที่สุดเมื่อมีการร้องขอจากเพื่อนร่วมงาน (ผู้ใช้ R แต่ไม่ได้เขียนโปรแกรมด้วยตัวเองมาก) สำหรับตัวฉันเอง

• ฉันใช้ข้อกำหนดอย่างเป็นทางการของแพคเกจ (เอกสาร) เพื่อ "บังคับ" ฉันทำความสะอาดและจัดทำเอกสารรหัสของฉัน

ฉันเห็นด้วยกับ @JohnRos ว่ามีความแตกต่างค่อนข้างมากระหว่างการเขียนแพ็คเกจและการเผยแพร่แพ็คเกจ

• ฉันมักจะจัดแพคเกจก่อน แต่จากนั้นทำแพ็กเกจเท่านั้น "semipublic" นั่นคืออาจมีอยู่ในเซิร์ฟเวอร์ภายใน (หรือบน r-forge) ดังนั้นเพื่อนร่วมงานของฉันสามารถเข้าถึงแพ็คเกจได้ แต่ฉันเผยแพร่ให้ CRAN หลังจากใช้งานแพ็คเกจมาหลายเดือนหรือแม้กระทั่งไม่กี่ปีโดยเพื่อนร่วมงานที่สนิท สิ่งนี้ไม่ทำให้เกิดข้อบกพร่องทั้งหมดตามจุดที่ @Nick Cox # 3 แต่มีจำนวนพอสมควร
  แพ็คเกจของรุ่น (ฉันใส่วันที่หลังจากเส้นประในหมายเลขเวอร์ชั่น) ทำให้ง่ายต่อการแก้ไขสิ่งต่าง ๆ ("เพื่อทำสิ่งนี้และให้แน่ใจว่าคุณติดตั้งเวอร์ชันของสัปดาห์ที่แล้วอย่างน้อย")

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

สิ่งที่ฉันทำไม่ได้ยังมีกลยุทธ์ที่ดีสำหรับบรรจุภัณฑ์เป็นข้อมูล

ความเห็นเกี่ยวกับรายการเหตุผลของคุณ:

• การไม่มีอยู่ของแพ็กเกจอื่นในฟิลด์ย่อยเดียวกัน

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

• ความจำเป็นในการแลกเปลี่ยนกับนักวิจัยคนอื่นและอนุญาตให้ทำซ้ำการทดลอง;

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

และในบรรดาประเด็นที่อาจนำไปสู่การตัดสินใจที่ตรงกันข้าม:

• ส่วนหนึ่งของวิธีการที่ใช้ในแพ็คเกจอื่นแล้ว;

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

• จำนวนฟังก์ชั่นใหม่ไม่เพียงพอที่จะปรับให้เหมาะสมเพื่อสร้างแพ็คเกจอิสระใหม่

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

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

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

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

เครื่องมือสามอย่างที่ฉันพูดมีความสำคัญ:

• devtools pkg , เพื่อให้ง่ายต่อการสร้างแพ็คเกจ (ดูวิกิบนหน้า devtools github
• roxygen2 pkgเพื่อให้การเขียนเอกสารสำหรับแพ็คเกจของคุณเป็นเรื่องง่าย
• GitHub คุณสามารถใช้install_github(หรือ install_bitbucket ในทำนองเดียวกันเป็นต้น) เพื่อติดตั้งโดยตรงจาก GitHub ซึ่งเหมาะสำหรับการแบ่งปันกับผู้อื่น

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

เหตุผลเฉพาะสำหรับการเขียนแพ็คเกจ R:

• เพราะคุณเขียนเป็น C

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

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

สิ่งนี้อาจช่วยประหยัดเวลาได้อย่างมากหากต้องทำการวิเคราะห์ซ้ำอีกครั้งหรืออาจตีพิมพ์ (หรือตีพิมพ์ซ้ำ) หากการวิเคราะห์ถูกตีพิมพ์