จะใส่เอกสารรหัสได้ที่ไหน


13

ขณะนี้ฉันใช้สองระบบเพื่อเขียนเอกสารรหัส (กำลังใช้ C ++):

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

ฉันคิดว่าวิธีนี้ง่ายมากเพราะเอกสารเกี่ยวกับสมาชิกและคลาสนั้นใกล้เคียงกับโค้ดจริง ๆ ในขณะที่หน้าภาพรวมนั้นง่ายต่อการแก้ไขใน Wiki (และยังง่ายต่อการเพิ่มรูปภาพตาราง ... ) เว็บเบราว์เซอร์ช่วยให้คุณดูเอกสารทั้งสอง

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

โครงการโอเพ่นซอร์สขนาดใหญ่ (หรือซอร์สปิด) อะไรที่ใช้ในการเขียนเอกสารรหัส? พวกเขายังแยกสิ่งนี้ระหว่าง Doxygen-style และ Wiki หรือไม่? หรือพวกเขาใช้ระบบอื่น?

วิธีที่เหมาะสมที่สุดในการเปิดเผยเอกสารคืออะไร? ผ่านเว็บเซิร์ฟเวอร์ / เบราว์เซอร์หรือผ่านไฟล์ช่วยเหลือขนาดใหญ่ (หลาย 100MB)

วิธีใดที่คุณใช้เมื่อเขียนเอกสารรหัส?


เปิดโครงการแหล่งงูใหญ่มีแนวโน้มที่จะใส่รหัสเอกสารของพวกเขาใน readthedocs
user16764

คำตอบ:


9

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

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

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


4

ใช้เอกสารรหัสก่อน เพิ่ม Wiki & วิธีอื่น ๆ ถ้าเป็นไปได้

ฉันรู้ว่ามันจะเป็นเรื่องยากที่จะรักษามันไว้

คำตอบที่ปฏิบัติ:

ในแง่การปฏิบัติสิ่งแรกที่นักพัฒนาทำคือตรวจสอบโค้ด

ในฐานะนักพัฒนาฉันต้องการมีเอกสารภายนอกเช่นวิกิคู่มือ แต่สิ่งแรกที่ฉันทำก็คือตรวจสอบรหัส (บางครั้งมาจากนักพัฒนาอื่น ๆ บางครั้งฉันเอง)

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

บางครั้งผู้จัดการโครงการและหัวหน้าคนอื่น ๆ ไม่สนใจเอกสารประกอบบางครั้งนักพัฒนาคนอื่นไม่ทำ

และที่ดีที่สุดที่ฉันสามารถทำได้คือเพิ่มความคิดเห็นลงในโค้ด

โชคดี


3

บางคนใช้ระบบอื่น - ดูSphinxของ Python เช่นพวกเขามีระบบเอกสาร all-in-one ที่สร้างทุกอย่าง (มันใช้ได้กับ C / C ++)

ฉันมักจะคิดว่าเอกสารแยกเป็นรหัส doxygen นั้นยอดเยี่ยม แต่สำหรับภาพรวมของ API ไม่ใช่ 'เอกสาร' สำหรับวิกินั้นยอดเยี่ยม แต่ฉันชอบใช้ASCIIDOCและเก็บผลลัพธ์ของการควบคุมแหล่งที่มาพร้อมกับรหัสส่วนใหญ่เนื่องจากฉันสามารถสร้าง PDF จากมือคนอื่น ๆ (เช่นผู้ทดสอบลูกค้า ฯลฯ )


ขอบคุณที่พูดถึง ASCIIDOC จะดูที่มัน
แพทริค

2

Doxygen ช่วยให้คุณสร้าง PDF, HTML, หน้า wiki เกือบทุกอย่างที่คุณคิด

ความชอบส่วนตัวของฉันคือมีทั้ง Doxygen และ wiki และสคริปต์หรือบางสิ่งที่ต้องตรวจสอบเมื่อพวกมันแตกต่าง



1

กลุ่มเป้าหมาย

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

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

ซ่อมบำรุง

แหล่งที่มาของเอกสารนี้จะขึ้นอยู่กับผู้ชมของคุณและใครเป็นผู้เขียนให้กับผู้ชมของคุณ

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

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

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

การรวมเอกสาร

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

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

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

กรณีของคุณ

ความซื่อสัตย์เอกสารในวิกิของคุณอาจไม่ใช่เอกสารประเภทเดียวกันในรหัสฐานของคุณ มันอาจไม่สมเหตุสมผลที่จะรวมเข้าด้วยกัน

ในอีกทางหนึ่งการบูรณาการทั้งสองสามารถทำได้ด้วยวิธีง่าย ๆ

  • เครื่องมือเอกสารต้นฉบับ (เช่น doxygen) สามารถสร้าง html และ wiki อาศัยอยู่บนเว็บเซิร์ฟเวอร์ มันจะเป็นจุดรวมง่าย ๆ เพียงแค่ให้บริการรุ่นที่สร้างขึ้นข้างวิกิและเชื่อมโยงระหว่างทั้งสอง
  • ผลิตภัณฑ์ wiki บางตัวจะอนุญาตให้คุณเรียกใช้ wiki โดยตรงจากไฟล์ที่คุณสามารถเช็คอินไปยังรหัสฐาน สิ่งนี้จะทำให้เครื่องมือ wysiwyg ง่าย ๆ ในขณะที่รักษาเอกสารที่จับคู่กับรหัส
  • รูปแบบอื่น ๆ เช่น PDF สามารถรองรับได้เช่นกัน แต่สิ่งนี้จะลงไปในเครื่องมือเฉพาะที่คุณต้องการใช้ มันอาจเหมาะสมที่จะขูดวิกิของคุณเป็นไฟล์มาร์กอัปและฟีดที่ผ่าน doxygen (หรือเครื่องมืออื่น ๆ ) มันอาจจะเหมาะสมที่จะ pdf wiki และแหล่งข้อมูลแยกจากกันและใช้เครื่องมือผสาน PDF

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


0

หากคุณใช้ ASCII คุณควรเก็บข้อมูลเอกสารของคุณไว้ในซอร์สโค้ดของคุณ! จากนั้นเฉพาะผู้ใช้ที่ฉลาดที่สุด (อ่าน: สมควร) มีโอกาสใช้เอกสารของคุณ


0

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

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