1. اصول مستندات زنده:
مفهوم مستندات زنده اولین بار در کتاب «Specification by Example» نوشته‌ی Gojko Adzic محبوب شد. آدزیک یکی از مزایای کلیدی تیم‌هایی کهBDD انجام می‌دهند را اینگونه توصیف کرد توصیف کرد:
سناریوهایی که برای تست ومشخصات ایجاد شده بودند به عنوان مستنداتی برای رفتارهای تجاری نیز بسیار مفید بودند. به لطف تست‌های خودکار، این مستندات تا زمانی که همه‌ی تست‌ها در حال اجرا بودند همیشه به‌روز بود.
امکان بهره‌مندی از مزایایی شبیه به مستندات زنده در همه‌ی جنبه‌های یک پروژه‌ی نرم‌افزاری وجود دارد: درست است که رفتارهای تجاری از این مستندات بهره‌مند می‌شوند، اما در کنار آن، دامنه‌های کسب‌وکاری، چشم‌انداز پروژه ، طراحی و معماری، راهنمایی‌های کدنویسی، استقرار و زیرساخت و ... نیز از این قابلیت می‌توانند سود ببرند.
مستندات زنده شامل چهار اصل است:
مستندات زنده و فرایند اجرایی آن به گونه‌ای است که برای توسعه‌دهندگان نیز انجام آن لذت بخش است. آن‌ها می‌توانند روی انجام کارهای مورد علاقه خود تمرکز کنند و در عین حال مستندات زنده را نیز از این کارها به دست آورند.
در ادامه به طور خلاصه چهار اصل اصلی مستندات زنده را توصیف خواهد شد که با هم به عنوان راهنمایی برای بیشترین بهره‌مندی مزایا از این رویکرد عمل می‌کنند. در آینده در مورد این ایده‌ها بیشتر خواهیم نوشت.
1.1. قابل اعتماد:
مستنداتی مفید است که قابل اعتماد باشد؛ به عبارت دیگر، باید صد در صد قابل اعتماد باشند. از آنجایی که انسان‌ها هیچ‌وقت تا این حد قابل اعتماد نیستند، نیاز به فرایند‌ها و ابزارهایی داریم که امر را ممکن سازند. برای دستیابی به مستندات قابل اعتماد، به ایده‌های زیر تکیه می‌کنیم:
1.2. کم هزینه:
برای داشتن مستندات زنده باید هزینه رسیدن به آن را تا حد امکان کاهش دهیم تا در محیط‌هایی که دائماً در حال تغییر هستند ارجای آن امکان‌پذیر و پایدار باشد؛ این هدف را با استفاده از ایده‌های زیر می‌توانید محقق کنید:
1.3. مشارکتی (همکاری‌محور):
مستندات زنده در نظر گرفتن ترجیحات زیر باید همکاری‌محور باشد:
1.4. بینش‌محور:
اصول ذکر شده مفید هستند، اما بینش محور بودن برای برای دستیابی به پتانسیل کامل مستندات زنده ضروری است:
در ادامه کمی بیشتر در مورد این اصول صحبت خواهیم کرد اما الگوها و شیوه‌های مرتبط با اجرای موفقیت‌آمیز رویکرد مستندات زنده را در آینده خواهیم دید. قبل از ادامه بحث بیایید به دنیای حشرات و الهاماتی از آن نگاه کنیم.
1.5. انتقال دانش در مورچه ها: استیگمرژی
اخیراً مایکل فیدرز لینکی به یک مقاله آنلاین فوق‌العاده توسط تد لوئیس به اشتراک گذاشت که مفهوم استیگمرژی را در رابطه با کار ما در نرم‌افزار به عنوان یک تیم معرفی می‌کند:
حشره‌شناس فرانسوی، پیر-پل گراس، مکانیزمی برای هماهنگی حشرات را توصیف کرد که آن را «استیگمرژی» نامیده‌اند - کاری که توسط یک بازیگر انجام می‌شود محرکی برای کار بعدی توسط خودش یا بازیگران دیگر است. یعنی، وضعیت یک ساختمان، پایگاه کد، بزرگراه یا ساختار فیزیکی دیگر تعیین می‌کند که بدون حاکمیت خودکامه و برنامه ریزی مرکزی چه چیزی باید در ادامه انجام شود. بازیگران - حشرات(برنامه‌نویسان) - بر اساس آنچه قبلا انجام شده، می‌دانند که در ادامه چه کاری باید انجام دهند. این تمایل شهودی به گسترش کار دیگران به اصل سازمان‌دهنده توسعه نرم‌افزار مدرن تبدیل می‌شود. مورچه‌ها از نوع خاصی از نشانگرهای شیمیایی یعنی فرومون‌ها برای برجسته کردن نتایج فعالیت خود استفاده می‌کنند.
به طور مشابه، برنامه‌نویسان نشانگرهای خود را از طریق ایمیل‌ها، مسائل GitHub و همه نوع مستنداتی که کد را تکمیل می‌کنند، تولید می‌کنند. همان‌طور که لوئیس نتیجه‌گیری می‌کند:
جوهره‌ی توسعه‌ی نرم‌افزار مدرن، هوش استیگمرژیک و نشانگرهای جاسازی‌شده در منبع کد است. با افزایش تمرکز برنامه‌نویسان بر جنبه‌هایی از کار که نیاز به انجام شدن دارند، نشانگرهای استیگمرژی کارآمدتر می‌شوند.
در حال حاضر، راه غالب ما برای تبادل دانش بین افراد و ماشین‌هایی که هنگام انجام نرم‌افزار درگیر هستند استیگمرژی است. یکی از ایده‌های کلیدی مستندات زنده این است که اثر استیگمرژیک را به حداکثر برساند. این کار با خارج کردن بیشترین دانش از سیستمی که در آن هستید، مانند مورچه‌ها، شروع می‌شود.
2. بیشتر دانش در حال حاضر آنجا هست:
وقتی دانشی از قبل ثبت شده باشد نیازی به ثبت مجدد آن نیست. هر پروژه‌ی جذابی یک سفر یادگیری است که دانش خاصی را تولید می‌کند. ما معمولاً انتظار داریم مستندات دانش خاصی که نیاز داریم را به ما بدهد، اما نکته جالب این است که همه‌ی این دانش از قبل هم آنجا هست: در کد، در فایل‌های پیکربندی، در تست‌ها، در رفتار برنامه در زمان اجرا، در حافظه‌ی ابزارهای مختلف درگیر و البته در ذهن همه‌ی افرادی که روی آن کار می‌کنند. در یک پروژه نرم‌افزاری، بیشتر دانش به نوعی و در جایی از مصنوعات وجود دارد. این شبیه به یادگیری مورچه‌ها برای تکامل لانه خود عمدتاً از خود لانه است. بنابراین احتمالا اذعان می‌کنید که بیشتر دانش در حال حاضر در خود سیستم وجود دارد. هر زمان که لازم است، محل آن را شناسایی کرده و از آن استفاده می‌کنید. باید بدانید وجود دانش از قبل در جایی به معنای عدم نیاز به تلاش نیست. دانشی که در حال حاضر وجود دارد مشکلات زیادی نیز دارد:
2.1. غیرقابل دسترسی: دانشی که در کد و یا سایر مصنوعات ذخیره می‌شود برای افراد غیر فنی قابل دسترسی نیست. به عنوان مثال، کد برنامه برای غیر توسعه‌دهندگان قابل خواندن نیست.
2.2. بیش از حد زیاد: دانش موجود در مصنوعات پروژه بسیار زیاد است و استفاده از آن کارآمد نیست. به عنوان مثال، هر خط از برنامه دانشی در زمینه دامنه‌ی کسب و کار را رمزگذاری می‌کند، اما برای یک سوال خاص، نهایتا یک یا دو خط از برنامه مرتبط است.
2.3. پراکنده: دانشی که از نظر ما یک قطعه واحد است در بخش‌های زیادی از مصنوعات مختلف پراکنده شده است. به عنوان مثال، مفهومی که در حالث ارث بری در سی شارپ توسعه داده می‌شود دانشی را در قالب چندین فایل و بعضا چندین پروژه نگهداری می‌کند. حتی اگر ما این کلاس‌ها و ساختار سلسله مراتبی را یکسان فرض کنیم، اما باز هم در فایل‌های مختلفی نگهداری می‌شود.
2.4. ضمنی: اغلب مصنوعات پروژه، دانش را به صورت ضمنی در خود دارند. ممکن است نود و نه درصد دانش آنجا باشد و برای اینکه این دانش صریح باشد یک درصد نقص داشته باشد. به عنوان مثال، فرض کنید برای توسعه بخشی از کد از الگوی Composit استفاده شود، تنها افرادی که دانش این الگو را دارند هدف آن را درک خواهند کرد و سایرین متوجه وجود این الگو نخواهند شد.
2.5. غیرقابل بازیابی: با اینکه دانشی در جایی وجود دارد، ممکن است به خاطر ابهام زیاد غیر قابل بازیابی باشد. به عنوان مثال با اینکه منطق کسب و کاری در کد پیاده سازی شده است، اما ممکن است کد به قدری کثیف باشد که هیچ کس نتواند متوجه آن شود.
2.6. نانوشته: یک حالت بسیار بد نیز وجود دارد و آنست که دانش فقط در ذهن افراد وجود دارد و اثرات آن در مصنوعات پروژه ایجاد شده است. به عنوان مثال، ممکن است قانونی در کسب‌وکار وجود داشته باشد، اما هیچ جا مستقیما مستند نشده باشد و نهایتا در قالب چندین کلاس و تابع در بخش‌های مختلف پخش شده باشد و هیچ کس از وجود کلی قانون مطلع نباشد.
3. مستندات داخلی:
بهترین مکان برای ذخیره‌ی مستندات روی همان چیزی است که مستند شده است. احتمالاً تصاویر دیتاسنترهای گوگل و مرکز پمپیدو در پاریس را دیده‌اید. آن‌ها لوله‌های رنگی زیادی با برچسب‌های یا حکاکی‌هایی روی لوله‌ها دارند. در مرکز پمپیدو، لوله‌های هوا آبی و لوله‌های آب سبز هستند. این منطق رنگی فراتر از لوله‌ها گسترش می‌یابد: انتقال برق زرد است و هر چیزی مرتبط با جابجایی افراد از جمله آسانسورها و پله‌ها و ... قرمز است. این منطق نیز در دیتاسنترها رایج است و حتی مستندات بیشتری مستقیماً روی لوله‌ها چاپ شده است. برچسب‌هایی برای شناسایی لوله‌ها و پیکان‌هایی برای نشان دادن جهت جریان آب در آن‌ها وجود دارد. در دنیای واقعی، چنین رنگ‌کدگذاری و علامت‌گذاری‌های موقت اغلب برای پیشگیری از حریق و آتشنشانی اجباری است: لوله‌های آب برای آتش‌نشان‌ها برچسب‌های بسیار قابل مشاهده‌ای دارند که منبع آن‌ها را نشان می‌دهند. در ساختمان‌های بزرگ محل خروج اضطراری علامت گذاری و مشخص است. در هواپیماها، علائم روشن در راهروهای مرکزی مستند کرده‌اند که به کجا بروید. در شرایط بحرانی، زمانی برای جستجوی یک راهنمای ندارید؛ شما به پاسخ در آشکارترین مکان نیاز دارید: درست جایی که هستید، روی خود آن چیز. فرض کنید خودرویی آتش گرفته و می‌خواهید از کپسول آتشنشانی استفاده کنید و در همین لحظه نیاز داشته باشید به دنبال دفترچه راهنما برای استفاده از آن بگردید.
3.1. مستندات داخلی در مقابل خارجی:
مستندات پایدار به دو شکل وجود دارند: خارجی و داخلی. با مستندات خارجی، دانش در قالبی بیان می‌شود که هیچ ارتباطی با فناوری‌های پیاده‌سازی انتخاب شده برای پروژه ندارد. نگهداری مستندات در قالب اسناد مایکروسافت آفیس به صورت جداگانه از پروژه شکلی از مستندات سنتی است. یک مزیت مستندات خارجی این است که می‌تواند هر فرمتی و ابزاری که برای مخاطبان و نویسندگان مناسب‌تر است را بگیرد. مشکل اصلی این است که به سختی می‌توان آن‌ها را به روز نگه داشت. مستندات خارجی می‌تواند به سادگی گم شود. در مقابل، مستندات داخلی به‌طور مستقیم دانش را با استفاده از فناوری‌های پیاده‌سازی آن مصنوع از پروژه ثبت و نگهداری می‌کنند. استفاده از کامنت نویسی در زبان‌های برنامه‌نویسی یا قراردادهای نام‌گذاری روی شناسه‌های زبان برای اعلام و توضیح تصمیمات طراحی مثالی خوب از مستندات داخلی است. مزیت مستندات داخلی این است که تقریبا همیشه به‌روز است، زیرا بخشی از کد منبع مصنوعات پروزه است. مستندات داخلی نمی‌تواند گم شود زیرا در خود کد جاسازی شده است. همچنین به راحتی در دسترس است و به چشم هر توسعه‌دهنده‌ای که روی کد کار می‌کند می‌آید. مستندات داخلی همچنین به شما امکان می‌دهد از تمام ابزارها و تمام مزایای IDE فوق‌العاده خود استفاده کنید، مانند تکمیل خودکار، جستجوی فوری و ناوبری یکپارچه درون و بین عناصر. مشکل این است که بیان دانش شما به مکانیزم‌های توسعه‌پذیری موجود در زبان محدود می‌شود. به عنوان مثال، نمی‌توانید خیلی چیزها بهXML های موجود در کد سی شارپ با دانش اضافی در مورد هر وابستگی اضافه کنید. یک مشکل بزرگ دیگر این است که دانش بیان‌شده به‌عنوان مستندات داخلی برای غیر توسعه‌دهندگان به راحتی قابل دسترسی نیست. با این حال، می‌توان این محدودیت را با مکانیزم‌های خودکاری که دانش را استخراج کرده و آن را به اسنادی که برای مخاطبان مناسب قابل دسترسی است تبدیل می‌کند، برطرف کرد. اگر با کتاب «Domain-Specific Languages» نوشته مارتین فاولر و ربکا پارسونز آشنا باشید، مفاهیم مشابهی از زبان‌های خاص دامنه داخلی و خارجی را خواهید شناخت. یک DSL خارجی مستقل از فناوری پیاده‌سازی انتخاب شده است. برای مثال، نحوی که برای عبارات منظم استفاده می‌شود هیچ ارتباطی با زبان برنامه‌نویسی انتخاب شده برای پروژه ندارد. در مقابل، یک DSL داخلی از فناوری پیاده‌سازی انتخاب شده به طور عادی استفاده می‌کند، به گونه‌ای که به نظر می‌رسد یک زبان دیگر باشد. این سبک اغلب به سبک روانی معروف است و در کتابخانه‌های Mock معمول است.
3.2. مثال‌هایی از مستندات داخلی و خارجی:
همیشه آسان نیست تشخیص دهید که مستندات داخلی است یا خارجی ، زیرا گاهی اوقات این بستگی به دیدگاه شما دارد. نظرات کد معمولاً در منطقه خاکستری قرار دارند. آن‌ها به‌طور رسمی بخشی از زبان هستند اما چیزی بیش از متن آزاد ارائه نمی‌دهند. شما باید آن‌ها را با استعداد نوشتاری خود بنویسید و کامپایلر هیچ کمکی برای بررسی املای اشتباه نمی‌کند. از دیدگاه توسعه‌دهنده، هر فناوری استانداردی که برای ساخت یک محصول نرم‌افزاری استفاده می‌شود می‌تواند به عنوان میزبان مستندات داخلی در نظر گرفته شود، از جمله:
3.3. ترجیح مستندات داخلی
به یاد داشته باشید که قبلاً گفته‌ام: بهترین مکان برای قرار دادن مستندات درباره یک چیز روی خود آن چیز است. من قطعاً به مستندات داخلی علاقه‌مندم، این مستندات همراه با خودکارسازی کافی برای مواردی که نیاز به انتشار مستندات سنتی بیشتر است بسیار کارآمد خواهد بود. من پیشنهاد می‌کنم که به‌طور پیش‌فرض مستندات داخلی را انتخاب کنید، حداقل برای همه‌ی دانش‌هایی که در دائما در حال تغییر هستند. حتی برای دانش‌های پایدار، من توصیه می‌کنم ابتدا مستندات داخلی را انتخاب کنید و فقط در مواردی که ارزش افزوده‌ای واضح وجود دارد مستندات خارجی را انتخاب کنید. ممکن است برای اهداف بازاریابی نیاز به ایجاد جاذبه بصری در مستند داشته باشید که در این شرایط مستندات خارجی کارآمد تر است. در این مورد، پیشنهاد می‌کنم اسلایدهای دستی، نمودارهایی با چیدمان دقیق دستی و تصاویر جذاب ایجاد کنید. هدف از استفاده از مستندات خارجی اضافه کردن احساس انسانی به سند نهایی است، بنابراین من از پاورپوینت استفاده می‌کنم، تصاویر با کیفیت زیبا را انتخاب یا ایجاد می‌کنم و اثربخشی مستندات را در یک ارائه به همکاران تست می‌کنم تا مطمئن شوم که به‌خوبی اثرگذار است. توجه داشته باشید که ایجاد جذابیت برای مستندات رسمی یا خودکار سخت است، اما غیرممکن نیست.
3.4. مستندات در محل:
مستندات داخلی، همچنین به‌عنوان مستندات در محل، به معنای مستنداتی است که «در موقعیت یا مکان طبیعی یا اصلی خود» قرار دارد. این به این معنی است که مستندات نه تنها از همان فناوری پیاده‌سازی استفاده می‌کند بلکه به‌طور مستقیم در کد منبع، درون مصنوعی که محصول را ساخته است، ترکیب می‌شود. در محل به معنای آوردن دانش اضافی درباره یک چیز به جایی است که آن چیز قرار دارد، به عنوان مثال درون کد منبع به جای یک مکان دوردست. این نوع مستندات برای توسعه‌دهندگان مناسب است. همان‌طور که در طراحی رابط‌های کاربری، جایی که اصطلاح در محل به معنای این است که یک عمل خاص کاربر می‌تواند بدون رفتن به یک پنجره دیگر انجام شود، استفاده و ویرایش مستندات می‌تواند بدون رفتن به یک فایل دیگر یا ابزار دیگر انجام شود.
3.5. مستندات قابل خواندن توسط ماشین:
مستندات خوب بر دانش سطح بالا، مانند تصمیمات طراحی در بالای کد و منطق پشت این تصمیمات تمرکز می‌کند. ما معمولاً این نوع دانش را فقط برای افراد مفید می‌دانیم، اما حتی ابزارها نیز می‌توانند از آن استفاده کنند. از آنجا که مستندات داخلی با استفاده از فناوری‌های پیاده‌سازی بیان می‌شود، معمولاً می‌تواند توسط ابزارها تجزیه شود. این اتفاق فرصت‌های جدیدی برای ابزارها برای کمک به توسعه‌دهندگان در وظایف روزانه آن‌ها باز می‌کند. به ویژه، این فرایند امکان پردازش خودکار دانش برای نگهداری، تلفیق، تبدیل قالب، انتشار خودکار یا همگام‌سازی را فراهم می‌کند.
4. دانش خاص در مقابل عمومی:
برخی دانش‌ها خاص شرکت، سیستم یا دامنه کسب‌وکار شما است. در مقابل دانشی وجود دارد که عمومی بوده و با بسیاری از افراد دیگر در بسیاری از شرکت‌های دیگر در صنعت به اشتراک گذاشته شده است. دانش درباره زبان‌های برنامه‌نویسی، ابزارهای توسعه‌دهندگان، الگوها و شیوه‌های نرم‌افزار به دسته دانش عمومی تعلق دارد. مثال‌هایی شاملDDD، الگوها، CICD و آموزش‌های Git می‌باشد. دانش درباره‌ی بخش‌های بالغ صنعت کسب‌وکار نیز دانش عمومی است. حتی در حوزه‌های بسیار رقابتی مانند قیمت‌گذاری در مالی یا بهینه‌سازی زنجیره تأمین در تجارت الکترونیک، بیشتر دانش عمومی و موجود در کتاب‌های استاندارد صنعت است و تنها بخش کوچکی از دانش کسب‌وکار خاص و محرمانه است. این خاص و محرمانه بودن نیز تنها برای مدت زمانی کوتاه است. به عنوان مثال، هر دامنه کسب‌وکار فهرست خواندن ضروری خود را دارد و ممکن است کتابی داشته باشد که اغلب به عنوان «انجیل» آن حوزه اشاره شود. برای مثال در صنعت بیمه ممکن است هر کسی بخش زیادی از نیاز دانش خود را در این زمینه از کتاب "اصول، مقررات و رشته‌های بیمه" به دست آورد که در اختیار همگان قرار دارد. خبر خوب این است که دانش عمومی در ادبیات صنعت قبلاً مستند شده است. کتاب‌ها، پست‌های وبلاگی و کنفرانس‌هایی وجود دارد که آن را به‌خوبی توصیف می‌کنند. واژگان استانداردی برای صحبت کردن درباره‌ی آن وجود دارد. آموزش‌هایی در دسترس هستند تا آن را سریع‌تر از افراد آگاه یاد بگیرید.
4.1. یادگیری دانش عمومی:
شما دانش عمومی را با انجام کار خود، همچنین با خواندن کتاب‌ها و حضور در آموزش‌ها و کنفرانس‌ها یاد می‌گیرید. این فقط چند ساعت طول می‌کشد و شما می‌دانید که چه چیزی را یاد خواهید گرفت، چقدر طول می‌کشد و چقدر هزینه خواهد داشت. یادگیری دانش عمومی به اندازه رفتن به فروشگاه برای خرید غذا آسان است. دانش عمومی یک مشکل حل شده است. این دانش آماده استفاده توسط همه است. هنگامی که از آن استفاده می‌کنید، فقط باید به یک منبع معتبر لینک دهید و کار شما در مستندسازی انجام شده است. این به سادگی یادداشت کردن یک لینک اینترنتی یا یک مرجع کتابشناختی است.
4.2. تمرکز بر دانش خاص
از مستندات برای دانش خاص استفاده کنید و دانش عمومی را از آموزش‌ها یاد بگیرید. دانش خاص دانشی است که شرکت یا تیم شما دارد و هنوز با سایر همتایان در همان صنعت به اشتراک گذاشته نشده است. این دانش گران‌تر از دانش عمومی برای یادگیری است؛ زمان تمرین و اشتباه کردن را می‌طلبد. این نوع دانش است که بیشترین توجه را می‌طلبد. دانش خاص ارزشمند است و نمی‌تواند آمادهی استفاده یافت شود، بنابراین این نوع دانش است که باید به آن توجه کنید. دانش خاص بیشترین تلاش‌ها را از شما و همکارانتان می‌طلبد. به عنوان یک حرفه‌ای، باید به اندازه کافی از دانش استاندارد صنعتی عمومی بدانید تا بتوانید بر رشد دانش خاصی که به آرمان‌های خاص شما مربوط می‌شود تمرکز کنید. بنابراین: اطمینان حاصل کنید که همه در مورد دانش عمومی در صنعت شما آموزش دیده‌اند. سپس هر گونه تلاشی برای مستندسازی را بر روی دانش خاص متمرکز کنید.
5. اطمینان از دقت مستندات:
شما تنها در صورتی می‌توانید به مستندات اعتماد کنید که یک مکانیزم برای تضمین دقت آن وجود داشته باشد. وقتی صحبت از مستندات می‌شود، مشکل اصلی اغلب دقیق نبود آن‌ها است و دلیل اصلی عدم دقت کهنگی دانش است. مستنداتی که همیشه 100% دقیق نیست نمی‌تواند مورد اعتماد باشد. به محض اینکه بدانید مستندات ممکن است گاهی اوقات گمراه‌کننده باشد، اعتبار خود را از دست می‌دهد. ممکن است هنوز کمی مفید باشد، اما زمان بیشتری می‌طلبد تا بفهمید چه چیزی درست و چه چیزی نادرست است. وقتی نوبت به ایجاد مستنداتی می‌رسد که می‌دانید برای مدت طولانی دقیق نخواهند بود، سخت است زمانی به آن اختصاص دهید. طول عمر صحت مستندات یک انگیزه کُش بزرگ است. به‌روزرسانی مستندات یکی از وظایفیست که کمتر به آن ارج نهاده شده است. این نوشته‌ها جالب نیست و به نظر نمی‌رسد که ترغیب کننده باشد. با این حال، می‌توانید مستندات خوبی داشته باشید اگر آن را جدی بگیرید و تصمیم بگیرید که با یک مکانیزم خوب انتخاب شده برای تضمین دقت در هر زمان به آن رسیدگی کنید. بنابراین: شما باید در مورد چگونگی پرداختن به دقت مستندات خود فکر کنید.
5.1. مکانیزم دقت برای مستندات قابل اعتماد
همان‌طور که قبلاً ذکر شد، دانش معتبر که می‌تواند مورد اعتماد باشد معمولاً در جایی وجود دارد، و در پروژه‌های نرم افزاری معمولاً به شکل کد است. بنابراین، دانش تکراری مشکل‌ساز است زیرا هزینه به‌روزرسانی آن برای همراهی با تغییرات را چند برابر می‌کند. این برای کد هر مصنوع دیگر نیز صدق می‌کند. ما معمولاً «طراحی» را به عنوان رشته‌ای که مطمئن می‌شود که تغییرات در هر نقطه‌ای از زمان ارزان باقی می‌ماند، می‌نامیم. ما به طراحی برای کد نیاز داریم و البته به همان مهارت‌های طراحی برای همه چیز درباره مستندات نیز نیاز داریم. یک رویکرد خوب برای مستندات مسئله طراحی است. طراحی مستندات که همیشه دقیق است بدون کند کردن کار توسعه نرم‌افزار مهارت‌های طراحی می‌طلبد. با دانشی که می‌تواند در هر زمان تغییر کند، تعدادی رویکرد برای نگه داشتن مستندات دقیق وجود دارد. آن‌ها در بخش‌های زیر توضیح داده شده‌اند، از مطلوب‌ترین تا کمترین مطلوب. بعدها شاید در نوشته‌هایی دیگر دقیق‌تر به این موارد پرداختیم.
5.2. منبع واحد با یک مکانیزم انتشار:
منبع واحد رویکردی است که هر زمان ممکن است ترجیح داده شود. با منبع واحد، دانش در یک منبع واحد نگهداری می‌شود که معتبر است. این مستندات به لطف یک مکانیزم انتشار خودکار به اشکال مختلف به عنوان اسناد منتشر شده و نسخه‌دار شده در دسترس قرار می‌گیرد. هر زمان که تغییری وجود دارد، در آنجا و تنها در آنجا به‌روزرسانی می‌شود. به عنوان مثال، کد منبع و فایل‌های پیکربندی اغلب خانه‌های طبیعی معتبر برای مقدار زیادی از دانش هستند. وقتی لازم است، دانش از چنین منبع واحدی استخراج و به شکل دیگری منتشر می‌شود، اما روشن است که تنها یک مکان معتبر وجود دارد. مکانیزم انتشار نیز باید خودکار باشد تا به طور مکرر اجرا شود؛ خودکارسازی مانع از ایجاد خطاهایی می‌شود که در مستندات دستی رایج است. حتی بدون نظرات اضافی، Javadoc یک مثال خوب از این رویکرد است: مستندات مرجع خود کد منبع است، همان‌طور که توسط Doclet Javadoc تجزیه می‌شود و به‌طور خودکار به عنوان یک وب‌سایت برای همه منتشر می‌شود تا ساختار رابط‌ها، کلاس‌ها و متدها، از جمله سلسله‌مراتب کلاس‌ها را به راحتی مرور کنند.
5.3. منابع تکراری با یک مکانیزم انتشار:
دانش ممکن است در مکان‌های مختلف تکرار شود، اما ابزارهای قابل اعتماد می‌توانند هر تغییری در یک مکان به همه مکان‌های دیگر منتشر کنند. بازسازی‌های خودکار در IDE شما بهترین مثال از این رویکرد است. نام کلاس‌ها، نام رابط‌ها و نام متدها در همه جا در کد تکرار می‌شوند، اما تغییر نام آن‌ها آسان است زیرا IDE می‌داند چگونه به‌طور قابل اعتماد هر مرجع را پیدا کرده و به درستی به‌روزرسانی کند. این بسیار برتر و ایمن‌تر از استفاده ازFind and Replace است، جایی که شما خطر جایگزینی رشته‌های تصادفی به اشتباه را دارید. به طور مشابه، ابزارهای مستنداتی مانندAsciiDoc مکانیزم‌های داخلی برای اعلام ویژگی‌هایی دارند که می‌توانید آن‌ها را در همه جای متن جاسازی کنید. به لطف برخی امکانات در ابزارها، می‌توانید نام‌ها را در یک مکان تغییر دهید و تغییر را به بسیاری از مکان‌ها با هیچ هزینه‌ای منتشر کنید.
5.4. منابع تکراری با یک مکانیزم آشتی:
اگر دانش در دو منبع اعلام شود، یک منبع ممکن است تغییر کند بدون اینکه منبع دیگر تغییر کند - و این یک مشکل است. نیازی به یک مکانیزمی داریم که هر زمان دو منبع مطابقت نداشتند این عدم تطابق را تشخیص دهیم. چنین مکانیزم آشتی باید خودکار و به طور مکرر اجرا شود تا اطمینان حاصل شود که همواره سازگاری وجود دارد. BDD با ابزارهای خودکار مانند Cucumber یک مثال از این رویکرد است. در این مورد، کد و سناریوها دو منبع دانش هستند و هر دو رفتار کسب‌وکار را توصیف می‌کنند. هر زمان که اجرای سناریوهای تست شکست می‌خورد، این یک سیگنال است که سناریوها و کد دیگر هماهنگ نیستند.
5.5. ضد الگویی به نام تعهد انسانی:
تعهد انسانی یک الگوی ضد است. اگر دانش در مکان‌های مختلف تکرار شود، گاهی اطمینان از سازگاری دانش ها به افراد تیم واگذار می‌شود و توقع این وجود دارد که افراد با کار زیاد و متعهدانه از این آزمون بزرگ سربلند خارج شوند. در عمل، این اتفاق نخواهد افتاد و هرگز پیشنهاد نمی‌شود.
5.6. زمانی که مستندات به یک مکانیزم دقت نیاز ندارد:
در برخی موارد، مانند بخش‌های زیر، نیازی به یک مکانیزم دقت برای مستندات خود ندارید.
5.6.1. دانش یک بار مصرف:
گاهی اوقات دقت فقط یک نگرانی نیست زیرا دانشی که ثبت می‌شود ظرف چند ساعت یا چند روز پس از استفاده دور انداخته می‌شود. این نوع دانش گذرا کهنه نمی‌شود و تکامل نمی‌یابد و بنابراین تا زمانی که برای مدت کوتاهی استفاده شود و بلافاصله پس از استفاده دور انداخته شود، نگرانی‌ای درباره‌ی سازگاری آن وجود ندارد.
5.6.2. حساب‌هایی از گذشته
یک حساب از رویدادهای گذشته، مانند یک پست وبلاگ، موضوع دقت نیست زیرا برای خواننده واضح است که هیچ وعده‌ای برای همیشه دقیق بودن متن وجود ندارد. هدف از پست ممکن است، به عنوان مثال، توصیف یک موقعیت همان‌طور که اتفاق افتاده است، شامل تفکرات در زمان و احساسات مرتبط. چنین دانشی که در یک نقطه زمانی دقیق است و در زمینه آن نقطه زمانی ثبت شده است به عنوان مستندات کهنه در نظر گرفته نمی‌شود. دانش در پست وبلاگ به مرور زمان قدیمی می‌شود، اما این مشکلی نیست زیرا واضح است که این پست مربوط به اتفاقی در گذشته است. این یک راه هوشمندانه برای آرشیو کردن قسمت‌های کاری و ایده‌ی بزرگ پشت یک داستان به صورت پایدار است، بدون اینکه تظاهر کند همیشه جدید است. یک پست وبلاگ کسی را گمراه نمی‌کند تا فکر کند که اطلاعات جدید است زیرا واضح است که این یک حساب از یک تفکر گذشته است. به عنوان یک داستان که در گذشته لنگر انداخته است، همیشه یک داستان دقیق است، حتی اگر نتوانید به کد یا مثال‌های خاصی که ممکن است نقل شده باشد اعتماد کنید. این کار مانند خواندن یک کتاب تاریخی است و درس‌های ارزشمندی در آن وجود دارد که می‌توان آموخت، بدون توجه به زمینه‌ای که در آن اتفاق افتاده‌اند. بدترین چیزی که می‌تواند برای یک حساب از گذشته اتفاق بیفتد این است که ممکن است وقتی که نگرانی‌های آن زمان دیگر نگرانی نیستند، بی‌ربط شود.
6. سوالات بزرگ برای به چالش کشیدن مستندات شما:
هر دقیقه‌ای که برای نوشتن مستندات صرف می‌شود، دقیقه‌ای است که برای کارهای دیگر از دست رفته است. آیا این مستند ارزش افزوده دارد؟ تصور کنید که رئیس یا مشتری شما درخواست «مستندات بیشتر» کند. تعدادی سوال مهم وجود دارد که باید پرسیده و پاسخ داده شود تا تصمیم بگیرید چه کاری باید انجام دهید. هدف از این سوالات این است که مطمئن شوید که در بلندمدت وقت خود را به کارآمدترین شکل ممکن استفاده می‌کنید. ترتیبی که سوالات مهم زیر را می‌پرسید بستگی به وضعیت دارد و می‌توانید سوالات را به دلخواه خود رد یا ترتیب دهید. بخش‌های زیر فرآیند فکری دخیل در تعیین چگونگی انجام مستندات را توضیح می‌دهد و پس از درک آن، می‌توانید فرآیند را به روش خود انجام دهید.
6.1. پرسیدن نیاز به مستندات در همه موارد:
مستندات به خودی خود هدف نیست؛ بلکه وسیله‌ای برای هدفی است که باید شناسایی شود. نمی‌توانید چیزی مفید ایجاد کنید مگر اینکه هدف را بفهمید. بنابراین اولین سوال این است:
چرا به این مستندات نیاز داریم؟
اگر به راحتی پاسخی به دست نیاید، پس قطعاً آمادهی سرمایه‌گذاری برای مستندات اضافی نیستید. باید موضوع را به حالت تعلیق درآورید تا زمانی که بهتر بدانید. نمی‌خواهید وقت خود را برای اهداف نامشخص هدر دهید. سپس سوال بعدی بلافاصله به دنبال آن می‌آید:
چه کسی مخاطب هدف است؟
اگر پاسخ نامشخص یا شبیه به «همه» باشد، پس آمادهی شروع هیچ کاری نیستید. مستندات کارآمد باید به یک مخاطب خاص هدفمند باشد. حتی مستنداتی درباره‌ی چیزهایی که «همه باید بدانند» باید به یک مخاطب خاص هدفمند باشد، مانند «افراد غیر فنی با دانش سطحی از دامنه کسب‌وکار». اکنون، همچنان که مصمم به جلوگیری از هدررفت زمان هستید، آمادهی اولین سوال از مستندات هستید.
اولین سوال مستندات: آیا واقعاً به این مستندات نیاز داریم؟
ممکن است کسی وسوسه شود که مستنداتی درباره موضوعی ایجاد کند که فقط برای خودش مفید باشد یا فقط در زمان کار بر روی آن مرتبط باشد. شاید حتی اضافه کردن یک پاراگراف به ویکی هم خیلی منطقی نباشد. اما دلیل بدتر دیگری برای درخواست مستندات وجود دارد.
6.2. نیاز به مستندات به دلیل فقدان اعتماد:
پاسخ به اولین سوال مستندات ممکن است شبیه به این باشد: «من به مستندات نیاز دارم زیرا می‌ترسم که به اندازه‌ی کافی کار نمی‌کنید، بنابراین باید تحویل‌های شما را ببینم تا مطمئن شوم که به اندازه کافی سخت کار می‌کنید.» در این صورت، مشکل اصلی مسئله مستندات نیست.
همان‌طور که مت وین (@mattwynne) و سب رز (@sebrose) در کنفرانس BDD eXchange در سال 2013 گفتند: «نیاز به جزئیات ممکن است نشان‌دهنده‌ی فقدان اعتماد باشد.» در چنین مواردی، فقدان مستندات فقط یک علامت است و مسئله‌ی اصلی فقدان اعتماد است. این مسئله‌ای جدی است که باید ابتدا به آن پرداخته شود و هیچ مقداری از مستندات نمی‌تواند به تنهایی مشکل فقدان اعتماد را حل کند. با این حال، از آنجایی که ارائه‌ی ارزش به طور مکرر راهی برای ساخت اعتماد است، مستندات معقول نیز می‌تواند نقش جانبی در بهبود وضعیت داشته باشد. برای مثال، شفاف کردن کار ممکن است به ساخت اعتماد کمک کند و این نیز نوعی مستندات است.
6.3. مستندات در لحظه یا گزینه ارزان برای دانش آینده:
اگر به مستندات نیاز دارید، ممکن است واقعاً در همان لحظه به آن نیاز نداشته باشید. بنابراین، یک سوال دیگر به عنوان اولین سوال مستندات وجود دارد.
آیا واقعاً به این مستندات در حال حاضر نیاز داریم؟
ایجاد مستندات هزینه دارد و مزیت آن در آینده نامشخص است. مزیت نامشخص است وقتی نمی‌توانید مطمئن باشید که کسی در آینده به این اطلاعات نیاز خواهد داشت.
یکی از چیزهایی که من در طول سال‌ها در توسعه‌ی نرم‌افزار آموخته‌ام این است که مردم در پیش‌بینی آینده ذاتا بد هستند. معمولاً مردم فقط می‌توانند شرط‌بندی کنند و شرط‌بندی‌های آن‌ها اغلب نادرست است. بنابراین، مهم است که از تعدادی استراتژی برای تعیین زمان مهم بودن مستندات استفاده کنید:
6.3.1. درست در لحظه:
ممکن است با توجه به عدم قطعیت اینکه در آینده مفید خواهد بود یا نه، تصمیم بگیرید که مستندسازی اکنون ارزش هزینه‌ی آن را ندارد. در این صورت، ممکن است انجام مستندات را تا زمانی که واقعاً لازم باشد به تعویق بیاندازید. به طور معمول، ایده‌ی خوبی است که صبر کنید تا کسی درخواست مستندات کند. در یک پروژه‌ی بزرگ با تعداد زیادی ذینفع، حتی ممکن است تصمیم بگیرید تا درخواست دوم یا سوم صبر کنید قبل از اینکه زمان و تلاش برای ایجاد مستندات را ارزشمند بدانید.
توجه داشته باشید که این رویکرد فرض می‌کند هنگامی که زمان به اشتراک گذاری دانش فرا می‌رسد، شما هنوز هم دانش را در تیم موجود دارید. همچنین فرض می‌کند که تلاش برای مستندسازی در آینده در مقایسه با الان خیلی زیاد نخواهد بود.
6.3.2. ارزان در ابتدا:
ممکن است تصمیم بگیرید که هزینه‌ی مستندسازی در حال حاضر آنقدر کم است که ارزش به تعویق انداختن آن برای بعد را ندارد، حتی اگر هرگز استفاده نشود. این موضوع به خصوص زمانی صادق است که دانش تازه در ذهن است و شما ریسک فراموشی تمام جزئیات مهم را در آینده دارید. و البته، ایجاد مستندات در ابتدا معنی دارد اگر شما راه‌های ارزان برای انجام آن دارید.
6.3.3. گران در ابتدا:
ممکن است تصمیم بگیرید که ارزش دارد بر روی نیاز آینده به این دانش شرط‌بندی کنید و انتخاب کنید که مستندات را همین حالا ایجاد کنید، حتی اگر انجام آن ارزان نباشد. در این صورت، ریسک این وجود دارد که ممکن است یک هدررفت باشد، اما شما ممکن است خوشحال باشید که این ریسک را بپذیرید - امیدوارم به دلایلی مستند (مثلاً دستورالعمل‌ها یا نیازهای قانونی، اعتماد بالا از بیش از یک نفر که این لازم است).
مهم است که به یاد داشته باشید که هر تلاشی برای مستندات در حال حاضر نیز بر کیفیت کار تأثیر می‌گذارد زیرا بر نحوه انجام آن و دلایل آن تمرکز می‌کند و مانند یک بازبینی عمل می‌کند. این به این معنی است که حتی اگر در آینده هرگز استفاده نشود، حداقل یک بار، در حال حاضر، برای فکر کردن دقیق درباره‌ی تصمیمات و منطق پشت آن‌ها مفید است.
6.4. پرسیدن نیاز به مستندات سنتی:
فرض کنیم که برای یک هدف مشخص و برای یک مخاطب مشخص، نیاز به مستندات اضافی وجود دارد. اکنون آمادهی دومین سوال از مستندات هستید.
سوال دوم مستندات- آیا می‌توانیم فقط از طریق گفتگوها یا کار کردن با هم دانش را به اشتراک بگذاریم؟
مستندات سنتی هرگز نباید انتخاب پیش‌فرض باشد، زیرا بیش از حد هدررفت دارد مگر اینکه کاملاً ضروری باشد. وقتی نیاز به انتقال دانش از برخی افراد به افراد دیگر وجود دارد، بهترین راه حل این است که به سادگی صحبت کنید - با پرسیدن و پاسخ دادن به سوالات به جای تبادل اسناد نوشته شده.
کار کردن به صورت جمعی، با گفتگوهای مکرر، یک شکل مستندات به خصوص مؤثر است. تکنیک‌هایی مانند برنامه‌نویسی جفتی، برنامه‌نویسی متقاطع، سه دوست در اجایل بازی را با توجه به مستندات تغییر می‌دهند، زیرا انتقال دانش بین افراد در همان زمانی که دانش ایجاد یا اعمال می‌شود، به صورت مداوم انجام می‌شود.
گفتگوها و کار کردن به صورت جمعی از اشکال ترجیحی مستندات هستند، اگرچه گاهی اوقات کافی نیستند. گاهی اوقات نیاز واقعی به داشتن دانش به صورت رسمی وجود دارد.
به چالش کشیدن نیاز به مستندات رسمی:
آیا باید پایدار باشد؟ آیا باید به تعداد زیادی از افراد به اشتراک گذاشته شود؟ آیا دانش حیاتی است؟
اگر پاسخ به هر یک از این سوالات «نه» باشد، گفتگوها و کار کردن به صورت جمعی باید کافی باشد و نیازی به مستندات رسمی بیشتر وجود ندارد.
البته، اگر این سوالات را از یک مدیر بپرسید، احتمالاً پاسخ «بله» خواهد بود زیرا این یک انتخاب ایمن است. شما نمی‌توانید با انجام بیشتر اشتباه کنید، درست است؟ این کار مانند تعیین اولویت بر روی وظایف است؛ بسیاری از افراد بر روی همه چیز پرچم اولویت بالا می‌گذارند، که سپس اولویت بالا را بی‌معنی می‌کند. با مستندات، چیزی که به نظر می‌رسد انتخاب ایمن است، هزینه بالاتری دارد که می‌تواند پروژه را به خطر بیاندازد. انتخاب ایمن واقعاً این است که این سه سوال را به روشی متعادل در نظر بگیرید نه این که به صورت خودکار «بله» یا «نه» پاسخ دهید.
حتی برای دانش‌هایی که باید با تعداد زیادی از افراد به اشتراک گذاشته شود، باید برای مدت طولانی پایدار بماند یا حیاتی است، چندین گزینه مستندات وجود دارد:
6.5. به حداقل رساندن کار اضافی در حال حاضر:
فرض کنید که نیاز مشروع به نگهداری برخی دانش‌ها به صورت رسمی وجود دارد. از آنجا که، همان‌طور که یاد گرفته‌اید، بیشتر دانش قبلاً در جایی وجود دارد، شما باید به سوال دیگری پاسخ دهید.
دانش در حال حاضر کجا است؟
اگر دانش فقط در ذهن افراد است، پس نیاز است که به صورت متنی، کد، متاداده یا چیز دیگری رمزگذاری شود. اگر دانش قبلاً در جایی نمایندگی شده است، ایده این است که تا حد ممکن از آن نسخه استفاده کنید (بهره‌برداری از دانش) یا از آن دوباره استفاده کنید (افزایش دانش) . ممکن است شما بتوانید از دانش موجود در کد منبع، در فایل‌های پیکربندی، در تست‌ها، در رفتار برنامه در زمان اجرا و شاید در حافظه‌ی ابزارهای مختلف درگیر استفاده کنید. این فرآیند، که به تفصیل بیشتری نیاز دارد، شامل پرسیدن سوالات زیر است:
وقتی دانش به طور کامل وجود ندارد یا برای قابل استفاده بودن بیش از حد ضمنی است، بازی پیدا کردن راهی برای افزودن دانش به صورت مستقیم در منبع محصول است.
6.6. به حداقل رساندن کار اضافی در آینده:
تنها یک بار ایجاد مستندات کافی نیست؛ شما باید در نظر بگیرید که چگونه آن را به مرور زمان دقیق نگه دارید. بنابراین، یک سوال مهم باقی می‌ماند.
این دانش چقدر پایدار است؟
دانش پایدار آسان است زیرا می‌توانید مسئله‌ی نگهداری آن را نادیده بگیرید. در سوی دیگر طیف، دانش زنده چالش‌برانگیز است. این دانش می‌تواند به طور مکرر یا در هر زمانی تغییر کند و نمی‌خواهید بارها و بارها مصنوعات و اسناد دیگر را به‌روزرسانی کنید. نرخ تغییر معیار مهمی است. دانشی که برای سال‌ها پایدار است می‌تواند با هر شکل نگهداری شود، مانند نوشتن متن به صورت دستی و چاپ آن روی کاغذ. دانشی که برای سال‌ها پایدار است حتی می‌تواند مقدار کمی از تکرار را تحمل کند زیرا نیاز به به‌روزرسانی نخواهد داشت. در مقابل، دانشی که هر ساعت یا بیشتر تغییر می‌کند نمی‌تواند اشکال سنتی مستندات را تحمل کند. نگرانی‌های کلیدی برای حفظ آن به حداقل رساندن هزینه‌ی تکامل و نگهداری مستندات است. تغییر کد منبع و سپس نیاز به به‌روزرسانی دستی سایر اسناد گزینه‌ی مناسبی نیست. این فرآیند، شامل پرسیدن سوالات زیر است:
اگر تغییر کند، چه چیزی در همان زمان تغییر می‌کند؟
اگر دانش تکراری وجود دارد، چگونه منابع تکراری را همگام نگه می‌داریم؟
7. تبدیل یک فعالیت به فعالیتی سرگرم‌کننده:
برای پایدار نگه داشتن یک فعالیت، آن را سرگرم‌کننده کنید. سرگرم‌کننده بودن برای شیوه‌های پایدار مهم است. اگر چیزی سرگرم‌کننده نباشد، کسی نمی‌خواهد آن را دائما انجام دهد آن چیز به تدریج از بین می‌رود. برای پایداری شیوه‌ها، آن‌ها باید سرگرم‌کننده باشند. این نکته، به خصوص در مورد موضوع خسته‌کننده‌ای مانند مستندات اهمیت دارد. بنابراین: شیوه‌های مستندات زنده‌ای را انتخاب کنید که تا حد ممکن سرگرم‌کننده باشند. اگر چیزی سرگرم‌کننده است، بیشتر آن را انجام دهید و اگر اصلاً سرگرم‌کننده نیست، به دنبال گزینه‌های دیگری باشید، مانند حل مسئله به روش دیگر یا از طریق خودکارسازی. این ترجیح برای فعالیت‌های سرگرم‌کننده قطعاً فرض می‌کند که کار با مردم در طرف سرگرم‌کننده قرار دارد زیرا هیچ راه خوبی برای دور زدن این موضوع وجود ندارد. برای مثال، اگر برنامه‌نویسی برای شما سرگرم‌کننده است، شما سعی خواهید کرد تا حد ممکن در کد مستند کنید. این ایده پشت بسیاری از پیشنهادات در این نوشته است. اگر کپی کردن اطلاعات از یک مکان به مکان دیگر یک کار خسته‌کننده است، پس این یک کاندید برای خودکارسازی است یا یافتن راهی برای جلوگیری از نیاز به جابجایی داده‌ها. اصلاح یک فرآیند و خودکارسازی بخشی از یک فرآیند معمولاً سرگرم‌کننده است، بنابراین این‌ها نیز چیزهایی هستند که ممکن است بخواهید انجام دهید - و این خوش‌شانسی است.
7.1. ترکیب سرگرمی و حرفه‌ای بودن:
تا زمانی که در کار خود حرفه‌ای باشید، هیچ مشکلی در داشتن سرگرمی در کار وجود ندارد. این به معنای انجام بهترین تلاش برای حل مشکلاتی است که اهمیت دارند. یعنی ارائه ارزش و کاهش خطر انجام می‌شود. با این ذهنیت، شما آزادید که شیوه‌ها و ابزارهایی را انتخاب کنید که زندگی شما را سرگرم‌کننده‌تر می‌کنند. پس از 21 سال برنامه‌نویسی، اکنون مطمئنم که همیشه می‌توان کار حرفه‌ای انجام داد در حالی که سرگرم هم بود. ایده اینکه کار باید خسته‌کننده و ناخوشایند باشد زیرا کار است یا زیرا برای این ناخوشایندی جبران می‌شوید، احمقانه است. شما پولی دریافت می‌کنید تا ارزشی ارائه دهید که حتی بیشتر از پولی است که دریافت می‌کنید. ارائه ارزش سرگرم‌کننده است و رفتار حرفه‌ای نیز دلپذیر است. و سرگرم‌کننده بودن برای کار کارآمد به عنوان یک تیم در یک جو دلپذیر ضروری است.
8. مستندات زنده: نسخه بسیار کوتاه:
اگر فقط می‌خواهید در یک دقیقه بدانید مستندات زنده چیست، لطفاً به ایده‌های بزرگ زیر توجه کنید:
اگر این لیست به اندازه‌ی کافی واضح است، شما پیام کلیدی این نوشته را درک کرده‌اید.
8.1. رویکردهایی برای مستندات بهتر
راه‌های زیادی برای در نظر گرفتن موضوع مستندات وجود دارد. این رویکردها یک طیف کامل را پوشش می‌دهند که می‌توان آن را به عنوان یک چرخه در نظر گرفت که از اجتناب از مستندات تا مستندات حداکثری و سپس فراتر، به سوال دوباره از نیاز به مستندات و چرخش چرخه به سمت مستندات کمتر دوباره پیش می‌رود. شما همچنین می‌توانید این چرخه را به عنوان رفتن از رویکردهای سبک به رویکردهای سنگین‌تر ببینید.
این چرخه شامل نرخ تغییر (نوسان) دانش مورد بحث، از دانش پایدار تا دانشی که به طور مداوم تغییر می‌کند، است.
8.2. دسته‌های رویکردهای مستندات:
9. دروازه‌ای به طراحی مبتنی بر دامنه (DDD):
با سرمایه‌گذاری در مستندات زنده می‌توانید به طراحی مبتنی بر دامنه نزدیک‌تر شوید. مستندات زنده می‌تواند به هدایت تیم یا مجموعه‌ای از تیم‌ها در پذیرش شیوه‌های DDD کمک کند. این رویه به ملموس کردن این شیوه‌ها و تمرکز برخی از توجهات بر روی مصنوعات حاصل کمک می‌کند. البته، نحوه‌ی کار شما با ذهنیت DDD بسیار مهم‌تر از مصنوعات حاصل است. با این حال، مصنوعات می‌توانند حداقل کمک کنند تا DDD را تجسم کنید و می‌توانند به نمایان کردن هر شیوه‌ی مشکل‌دار و ارائه راهنمایی در مورد میزان خوب انجام شدن آن کمک کنند.
9.1. طراحی مبتنی بر دامنه به طور خلاصه:
طراحی مبتنی بر دامنه رویکردی برای مواجهه با پیچیدگی در قلب توسعه‌ی نرم‌افزار است. این رویکرد به شدت بر تمرکز کامل روی دامنه‌ی کسب‌وکار خاصی که مورد بررسی قرار می‌گیرد، تأکید می‌کند. این شیوه نوشتن کدی که به طور مستقیم دانش دامنه را بیان می‌کند، بدون هیچ گونه ترجمه‌ای بین تحلیل دامنه و کد اجرایی را ترویج می‌کند. به این ترتیب، DDD فراخوانی است برای مدل‌سازی به طور مستقیم در کدی که به زبان برنامه‌نویسی نوشته شده است، در مقابل بسیاری از ادبیات‌های مدل‌سازی دیگر. این اتفاق تنها در صورتی ممکن است که امکان گفتگوهای مکرر و نزدیک با کارشناسان دامنه وجود داشته باشد، با اینکه همه از همان زبان همه‌گیر که زبان دامنه‌ی کسب‌وکار است استفاده می‌کنند.
طراحی مبتنی بر دامنه به تمرکز تلاش‌ها بر روی هسته‌ی اصلی دامنه دعوت می‌کند، یعنی باید روی آن حوزه‌ی کسب‌وکاری که پتانسیل ایجاد تفاوت در برابر رقبا را دارد تمرکز کنیم. به این ترتیب، DDD تشویق می‌کند که توسعه‌دهندگان نه تنها کد را تحویل دهند بلکه به عنوان شرکا با کسب‌وکار در یک رابطه دوطرفه سازنده همکاری کنند که در آن توسعه‌دهندگان به درک عمیق از کسب‌وکار برسند و بینش‌هایی در مورد مهم‌ترین مسائل نیز کسب کنند.
9.2. مستندات زنده به عنوان کاربردی از DDD:
مستندات زنده نه تنها از DDD پشتیبانی می‌کند بلکه به خودی خود نمونه‌ای از به‌کارگیری رویکرد DDD در دامنه مدیریت دانش در طول چرخه عمر آن است. و در بسیاری از موارد، مستندات زنده نمونه‌ای از به‌کارگیری مستقیم DDD تحت نام کمی متفاوت است.
9.3. داستان ریشه‌های مشترک بینBDD، DDD، XP و مستندات زنده:
اصطلاح مستندات زنده توسط گویکو آدزیک در کتاب «مشخصات بر اساس مثال»، که کتابی در مورد توسعه مبتنی بر رفتار (BDD) است، معرفی شد. BDD یک رویکرد شامل همکاری بین همه افراد درگیر در توسعه نرم‌افزار است که توسط دن نورث پیشنهاد شد، کسی که ایده را با ترکیب توسعه مبتنی بر تست (TDD) با زبان همه‌گیر طراحی مبتنی بر دامنه (DDD) معرفی کرد. به همین دلیل، حتی اصطلاح مستندات زنده نیز ریشه‌هایی در طراحی مبتنی بر دامنه دارد!
9.4. تنایج مستندات زنده:
توجه کنید که مستندات زنده به شدت به اصول زیر ازDDD پایبند است:
خلاصه:
مستندات زنده همه چیز درباره توجه به دانش درگیر در ساخت نرم‌افزار است. برخی دانش‌ها مهم‌تر از سایر دانش‌ها هستند و مهم‌ترین دانش تقریباً به طور قطع در جایی در مصنوعات پروژه وجود دارد. هدف و سرگرمی مستندات زنده شناسایی دانش با ارزش، جایی که در حال حاضر وجود دارد، و تعیین آنچه ممکن است از دست رفته باشد و اینکه چگونه اغلب تغییر می‌کند تا بهترین بهره‌برداری را از آن با حداقل هزینه ببرید. به عبارت دیگر، این موضوع درباره‌ی طراحی یک سیستم دانش درون پایگاه کد خود است و نیاز به مهارت‌های طراحی دارد، درست مانند کدنویسی.
