ฉันจะทำให้โค้ดของฉันพร้อมสำหรับ OpenSourcing และวางบน GitHub ได้อย่างไร


9

ในอีกไม่กี่สัปดาห์โครงการของฉันจะเสร็จและฉันต้องการเริ่มเตรียมโค้ดของฉันให้ผู้อื่นใช้

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

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

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


คำตอบ:


12
  • ตรวจสอบให้แน่ใจว่ามีไฟล์ README.txt ในรูทของพื้นที่เก็บข้อมูลที่ชี้ให้ผู้คนได้รับคำแนะนำเกี่ยวกับวิธีการสร้าง คำแนะนำอาจอยู่ในไฟล์นั้นหรืออาจอยู่ในไฟล์หรือหน้าวิกิอื่น
  • เป็นการดีที่ทำเพื่อให้คุณสามารถสร้างและทดสอบรหัสด้วยคำสั่งเดียว ไม่ต้องใช้ขั้นตอนแบบแมนนวล
  • ตรวจสอบให้แน่ใจว่าคุณมีการทดสอบรหัส นี่เป็นสถานที่ที่สะดวกสำหรับนักพัฒนาซอฟต์แวร์คนอื่น ๆ ในการดูว่ารหัสของคุณถูกใช้งานอย่างไรรวมถึงเป็นเครือข่ายความปลอดภัยสำหรับผู้ที่แก้ไขรหัสของคุณ รู้ว่าฉันสามารถแก้ไขรหัสของคุณแล้วเรียกใช้ชุดเพื่อดูว่าฉันทำลายสิ่งที่ล้ำค่า
  • ปฏิบัติตามมาตรฐานการเข้ารหัสทั่วไปหรือเผยแพร่มาตรฐานที่คุณใช้
  • หากรหัสของคุณใช้ OO ตรวจสอบให้แน่ใจว่าอย่างน้อยที่สุดวิธีการและคุณลักษณะสาธารณะทั้งหมดมีเอกสารเพียงพอ
  • ตรวจสอบให้แน่ใจว่าเป็นสิ่งที่ชัดเจนว่ารหัสใบอนุญาตของคุณใช้ โดยทั่วไปหมายถึงการรวมไฟล์ LICENSE.txt หรือทำตามกลไกใดก็ตามที่ใบอนุญาตของคุณต้องการ นอกจากนี้ให้เลือกอย่างมีสติเกี่ยวกับใบอนุญาต อย่าเพิ่งใช้ GPL เพราะนั่นคือทั้งหมดที่คุณรู้ ในทำนองเดียวกันอย่าใช้ BSD หรือ MIT หรือ Apache ถ้านั่นคือทั้งหมดที่คุณคุ้นเคย ... ใช้เวลาหนึ่งชั่วโมงทำการวิจัยเหล่านั้นเพื่อให้คุณเข้าใจความแตกต่างพื้นฐานระหว่างใบอนุญาต GPL และไม่ใช่ GPL
  • ลบข้อมูลที่ละเอียดอ่อนทั้งหมดออกจากรหัสเช่นชื่อผู้ใช้รหัสผ่านที่อยู่อีเมลรหัสที่อยู่ IP คีย์ API และอื่น ๆ (ขอบคุณ Hakan Deryal สำหรับคำแนะนำ)

คำปรึกษาที่ดี. อีกสิ่งหนึ่งที่จะเพิ่ม: ลบข้อมูลส่วนตัวเช่นรหัสผ่าน / คีย์ API หากมี
Hakan Deryal

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

3

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

การพยายามทำงานในโครงการที่มีเอกสารรหัสต้นฉบับนั้นเป็นสิ่งที่น่าผิดหวัง


1

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

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

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

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

รุ่น A:

class Foo {
private:
   SomeType some_name; //!< State machine state

public:
   ...

   /**
    * Get the some_name data member.
    * @return Value of the some_name data member.
    */
   SomeType get_some_name () const { return some_name; }

   ...
};

รุ่น B:

/**
 * A big long comment that describes the class. This class header comment is very
 * important, but also is the most overlooked. The class is not self-documenting.
 * Why is that class here? Your comments inside the class will say what individual parts
 * do, but not what the class as a whole does. For a class, the whole is, or should be,
 * greater than the parts. Do not forget to write this very important comment.
 */
class Foo {
private:

   /**
    * A big long comment that describes the variable. Just because the variable is
    * private doesn't mean you don't have to describe it. You might have getters and
    * setters for the variable, for example.
    */
   SomeType some_name;

public:
   ...

   // Getters and setters
   ...

   // Getter for some_name. Note that there is no setter.
   SomeType get_some_name () const { return some_name; }

   ...

};

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

ในเวอร์ชัน B ฉันได้ทำเอกสารสิ่งที่ต้องการแสดงความคิดเห็น ผู้ทะเยอทะยานไม่ได้มีความคิดเห็น doxygen แต่มันมีความคิดเห็นที่กล่าวถึงว่าไม่มี setter

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

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