รวมลิงก์ไปยังเอกสารที่เกี่ยวข้องในข้อความแสดงข้อผิดพลาดหรือไม่


10

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

นักพัฒนาหลายคนเป็นผู้ใช้ครั้งแรกดังนั้นจึงพบข้อผิดพลาดพื้นฐานมากมาย

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

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

ด้านล่างเป็นตัวอย่างของสิ่งที่ฉันหมายถึงมันเป็นความคิดที่ดีที่จะเพิ่มข้อความหนา?

[ข้อผิดพลาด] ล้มเหลวในการดำเนินการเป้าหมาย org.apache.maven.plugins: maven-archetype-plugin: 1.2.3: สร้าง (default-cli) ในโครงการ standalone-pom: archetype ที่ต้องการไม่มีอยู่ (com.example.library ต้นแบบ: library-archetype-blank: 1.2.3.0) -> โปรดดูhttp://example.com/docs/setting-up-an-archetypeสำหรับข้อมูลเพิ่มเติมและการแก้ไขปัญหาที่เป็นไปได้


5
Imo ข้อผิดพลาดเชิงพรรณนานั้นดีและผู้ให้การช่วยเหลือดียิ่งขึ้น
Cees Timmerman

@CeesTimmerman ฉันเห็นด้วยอย่างเต็มที่ แต่ฉันไม่พบข้อความประเภทนี้ สิ่งนี้ทำให้ฉันลังเลที่จะเริ่มทำเช่นนั้นเนื่องจากอาจมีเหตุผลที่ดีสำหรับสิ่งนี้ ..
ฟอน Lion

ฉันเคยเห็นพวกเขาในหน้า 404 และในซอฟต์แวร์ฉันจำไม่ได้บางที Homebrew
Cees Timmerman

1
สิ่งหนึ่งที่ควรพิจารณาเพิ่มเติมคือความเป็นไปได้ที่มนุษย์จะมองเห็นข้อมูลข้อผิดพลาด (และไม่ได้ตีความโดยซอฟต์แวร์ไคลเอ็นต์เพื่อแปลงเป็นข้อความที่ใช้งานง่าย)
Bart van Ingen Schenau

3
@VonLion: ทำสิ่งต่าง ๆ เพียงเพราะคนอื่นกำลังทำสิ่งเหล่านี้เป็นสูตรสำหรับคนธรรมดา
Robert Harvey

คำตอบ:


8

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

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

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

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


ขอบคุณสำหรับสิ่งนี้! มันค่อนข้างเก่าไปหน่อยปี 2001 ก่อนที่เราจะเข้าใจสิ่ง 'เว็บ' ทั้งหมดนี้ :-)
ฟอน Lion

3
มันยังคงเป็นคำแนะนำที่ดี แต่อาจทวีตล่าสุดโดย John Carmackช่วย
Cees Timmerman

6

ใช่ แต่สุดท้ายแล้ว:

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

หากคุณพัฒนาด้วย Java หรือ. NET เอกสารอาจรวมอยู่ในไฟล์ jar หรือไฟล์ DLL และโดยการเปลี่ยนคำนำหน้ารหัสของคุณสามารถดึงข้อมูลได้ในเครื่องแทน

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

เครื่องมือที่ประสบความสำเร็จสูงสุดบางอย่างที่ฉันสร้างขึ้นนั้นใช้วิธีการที่คล้ายกันซึ่งข้อความแสดงข้อผิดพลาดถูกกำหนดเป้าหมายไปยังผู้ใช้จริงที่น่าจะปฏิบัติงานได้มากที่สุด นั่นหมายความว่าฉันต้องทำข้อยกเว้นมากมายในการจับและตัดเพื่อให้แน่ใจว่าข้อผิดพลาดอยู่ในระดับที่เหมาะสมของนามธรรม ฉันยังแน่ใจด้วยว่าข้อความแสดงข้อผิดพลาดแต่ละรายการจะรวมถึงแหล่งที่มาของข้อผิดพลาดและชี้ไปที่วิธีแก้ปัญหาที่เป็นไปได้ "คุณลืมตั้งค่า xxxx config หรือไม่", "ตรวจสอบให้แน่ใจว่า xxx และ yyy ที่ XXX และ whatnot จะถูกสร้างขึ้นจากบริบทที่เกิดข้อผิดพลาด

วิธีนี้ค่อนข้างง่าย แต่ก็มีข้อ จำกัด มากกว่า อย่างไรก็ตามมีข้อดีที่ว่าเอกสารจะมีอยู่เสมอเมื่อไม่ต้องการการเชื่อมโยงที่เน่า

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


ขอบคุณสำหรับคำตอบมากมาย! การเชื่อมโยงเน่าจะเป็นปัญหา แต่หวังว่าการเฝ้าระวัง 404 การตรวจสอบจะเพียงพอ แน่นอนว่าจะต้องใช้ความมุ่งมั่นและความพยายามอย่างมากจากทีมงาน dev (มันเป็น codebase ที่มีอยู่ ... จะแนะนำได้ง่ายถ้าเป็นของใหม่) แต่อย่างที่คุณบอกว่ากำไรอาจคุ้มค่า!
Von Lion

+1 สำหรับความคิดเห็นเอกสาร
Cees Timmerman

5

คุณควรสนับสนุนให้ชี้ไปที่เอกสารออฟไลน์ที่มาพร้อมกับห้องสมุดแทนที่จะเป็นออนไลน์

(com.example.library.archetypes: library-archetype-blank: 1.2.3.0) -> โปรดดู /usr/share/myprog-3.8.1/docs/setting-up-an-archetype สำหรับข้อมูลเพิ่มเติมและการแก้ไขปัญหาที่เป็นไปได้

(แน่นอนถ้าเป็นห้องสมุด Windows เส้นทางจะแตกต่างกัน)

ประโยชน์ที่นี่คือ:

  • วิธีนี้เอกสารจะซิงค์กับไลบรารีเสมอ คนพัฒนาด้วยและแก้ไขปัญหารุ่นห้องสมุดเก่า และ บริษัท ของคุณอาจเปลี่ยนชื่อ, example.comเปลี่ยนชื่อผลิตภัณฑ์หรือบางคนอาจวางลูกบนต่ออายุ

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

  • การแก้ไขปัญหาแอปพลิเคชันไม่ได้เกิดขึ้นเสมอในสภาพแวดล้อมที่มีการเข้าถึงอินเทอร์เน็ต (หรือการเข้าถึงโดเมนของคุณโดยตรงอย่างน้อย)

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


3

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

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

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

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

ได้ไหม


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