การกำหนดปริมาณเอกสารที่ถูกต้อง


10

ที่ฉันทำงานอยู่วิธีการทั่วไปคือ -

หลีกเลี่ยงเอกสารให้มากที่สุด

จัดทำเอกสารเฉพาะในกรณีที่ทีมอื่นต้องการเท่านั้น

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

ฉันจะแสดงเหตุผลของบอสที่จะไม่ทำเอกสาร:

  1. ใช้เวลานาน - มุ่งเน้นไปที่การนำไปใช้
  2. หากการเปลี่ยนแปลงการออกแบบ - แล้วเอกสารควรเปลี่ยนปัญหาสองครั้ง
  3. ในที่สุดคุณก็จะได้รับหลายร้อยหน้าไม่มีใครอยากอ่านและไม่มีใครแก้ไขดังนั้นตามเวลามันจะล้าสมัย
  4. มันเจ็บปวด - ไม่มีใครอยากทำ

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

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

ฉันคิดว่าการขาดการจัดทำเอกสารส่งเสริมแพทช์ประเภทนี้และขาดความเข้าใจระบบในวงกว้าง

คำถามของฉันคือ:

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


ฉันมีปัญหาเดียวกันในสถานที่ของฉัน - ยกเว้นทีมของฉันไม่ได้เขียนรหัสความคิดเห็น!
MattDavey

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

โดยเฉพาะอย่างยิ่งกับภาษาสมัยใหม่เอกสารทางเทคนิคมีความสำคัญมากกว่านั้นการบันทึกรหัส รหัสควรอธิบายตนเอง
AK_

ในขณะที่มันเป็นความคิดที่ดีที่จะหลีกเลี่ยงเอกสารมากเกินไปเจ้านายของคุณก็ทำด้วยเหตุผลที่ผิดทั้งหมด
Christian Rau

คุณสามารถให้ความเห็นเกี่ยวกับอุตสาหกรรมที่ บริษัท ของคุณดำเนินงานอยู่ได้หรือไม่? อุตสาหกรรมบางประเภทมีข้อกำหนดทางกฎหมายว่าต้องการเอกสารระดับต่ำสุดเพียงใด
tehnyit

คำตอบ:


5

ฉันพบเอกสารใด ๆ นั้นดีกว่าไม่มีเอกสาร จำนวนที่เหมาะสมมักจะถูกกำหนดโดยจำนวนเวลาที่เราต้องทำหรือโดยจำนวนที่เราเกลียดการสนับสนุนโทรศัพท์และอีเมล

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

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

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

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

ทีมของคุณมีปัญหาเดียวกันกับการทดสอบหรือการเขียนรหัสทดสอบหรือไม่? ถ้าไม่เช่นนี้จะเป็นการขายที่ง่ายขึ้น

เอกสารของคุณมีประโยชน์ในหลาย ๆ ด้าน:
1) สำหรับคุณในตอนนี้และกับเพื่อนร่วมงานของคุณเมื่อคุณทำงานในโครงการ

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

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

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


1
+1 สำหรับจุด # 3 เอกสารส่วนตัวของฉันเองช่วยฉันได้หลายครั้ง
แบรนดอน

ฉันโยนของฉันใน repo คอมไพล์เดียวกับรหัสมักจะอยู่ใน Markdown (บางครั้งใน LaTeX เมื่อมีคณิตศาสตร์ที่เกี่ยวข้องเล็กน้อย)
TRiG

4

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

สิ่งที่ดีเกี่ยวกับการมีในรูปแบบ wiki คือคุณไม่อยากทำรูปแบบ Word ที่สวยงามทั้งหมดและเพียงแค่เขียนข้อมูลจริงที่คุณต้องการบันทึก แพ็คเกจวิกิส่วนใหญ่ (ถ้าไม่ใช่ทั้งหมด) จะช่วยให้คุณอัปโหลดเอกสารหรือรูปภาพ (เช่น Visio UML diagrams หรือ UI wireframes) ดังนั้นคุณจึงสามารถมีชิ้นส่วนที่มองเห็นได้เช่นกัน

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


นี่คือข้อเสนอแนะที่ดี วิกิบางตัวอนุญาตให้ส่งออกเนื้อหาไปยังเอกสาร. rtf เกือบจะสมบูรณ์แบบสำหรับ PHB
tehnyit

เราใช้ XWiki โดยเฉพาะสำหรับความสามารถในการสร้างเอกสารใน PDF, RTF และ HTML ความชั่วร้ายที่ดี
Jennifer S

2

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


1

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

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

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


1

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

มันใช้งานได้ดีจริง ๆ เพราะความซับซ้อนทั้งหมดทำใน BackOffice ที่ระดับโมเดล ฉันสามารถ refactor โครงการของฉันเขียน java doc หรือเขียนเอกสาร uml ในรูปแบบ เป็นการคลิกและไป เมื่อคุณคลิกคุณจะได้รับเอกสารสด หากบางสิ่งไม่ชัดเจนให้ฉันเปิดคลาสไดอะแกรมและเริ่มเล่นกับมัน ลบออกจากตัวแยกประเภทไดอะแกรมเพิ่มตัวแยกประเภทใหม่ซูมเข้าและออกแสดงการเชื่อมโยงลบการเชื่อมโยงเป็นต้น ... รูปแบบไม่เปลี่ยนแปลงเนื่องจากฉันไม่ได้สร้างข้อมูลรุ่นใหม่ใด ๆ ฉันเพิ่งใช้พวกเขา

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

UML นั้นยอดเยี่ยมมีประโยชน์จริง ๆ แต่เราควรหยุดใช้ Model Driven Devleopment เพื่อให้มีความยืดหยุ่นและย้ำมากขึ้นในขั้นตอนการสร้างแบบจำลอง / การพัฒนา แผนภาพคลาสได้รับการอัปเดตสดๆจากรหัสและเอกสารมีความถูกต้องและพร้อมใช้งานเพียงคลิกเดียว ฉันจะไม่พูดถึงเครื่องมือ แต่ถ้าคุณใช้ Java และ Eclipse ง่ายต่อการค้นหาเครื่องมือที่ฉันใช้ :-)

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