1. مقدمه:
مستندات را فراموش و سرعت تولید نرم‌افزار را بالا ببرید. شما می‌خواهید نرم‌افزار را سریع‌تر تحویل دهید. اما قرار نیست فقط در ابتدای راه سرعت کار بالا باشد، باید به گونه‌ای رفتار کنیم که در طولانی مدت نیز سرعت کار حفظ شود. از منظری دیگر اگر به کار نگاه کنیم قرار نیست تنها شما سریع کار کنید، بلکه همه همکاران و کل شرکت باید بتوانند با سرعتی معقول کار انجام دهند. وقتی در مورد تولید نرم‌افزار صحبت می‌کنیم، در ابتدا بیشتر به زبان‌ها و فریمورک‌های برنامه‌نویسی مولدتر، ابزارهای بهتر و مهارت‌های بالاتر می‌اندیشیم. اما هرچه صنعت در همه این جنبه‌ها پیشرفت می‌کند، باید به سایر گلوگاه‌ها نیز نگاه کنیم. توسعه‌ی نرم‌افزار فراتر از فناوری است و در اغلب موارد به تصمیم‌گیری‌های مبتنی بر دانش وابسته است. وقتی دانش کافی ندارید، باید آموزش ببینید و دائما آزمایش‌های آموزشی انجام دهید و با دیگران همکاری کنید تا دانش جدیدی به دست آورید. این فرایند زمانگیراست، که به این معنی است که این دانش گرانقیمت و ارزشمند است. سریع پیش رفتن یعنی هنگامی که نیاز به دانش جدیدی دارید آن را خیلی سریع به دست آورید یا اگر از قبل دانشی را داشتید هنگام نیاز خیلی سریع توانایی بازیابی آن را داشته باشید. اجازه دهید این موضوع را با داستانک‌هایی توضیح دهیم.
2. قصه‌هایی از سرزمین موعود:
تصور کنید یک پروژه نرم‌افزاری برای توسعه یک برنامه جدید به عنوان بخشی از یک سیستم اطلاعاتی بزرگتر در شرکت شما در حال توسعه است و شما توسعه‌دهنده‌ای در این پروژه هستید. وظیفه شما اضافه کردن مدل جدید تخفیف برای مشتریان وفادار جدید است.
2.1. یک ملاقات کاری:
شما با محمد از تیم بازاریابی و رضا، از تیم تست جلسه دارید و شروع به صحبت در مورد ویژگی جدید، پرسیدن سوالات و جستجوی مثال‌های عینی می‌کنید. رضا می‌پرسد: «چرا این ویژگی؟» محمد توضیح می‌دهد که دلیل آن این است که به مشتریان وفادار جدید پاداش بدهیم تا از طریق رویکرد بازی‌سازی، نگهداری مشتریان را افزایش دهیم و یک لینک در ویکی‌پدیا در مورد آن موضوع نمایش می‌دهد. رضا در مورد نکات اصلی و سناریوهای اصلی یادداشت‌برداری می‌کند. همه این اتفاقات سریع پیش می‌رود زیرا همه دور یک میز هستید و ارتباط بسیار ساده است. همچنین، مثال‌های واقعی، فهم و روشن کردن هر چیز مبهمی را ساده‌تر می‌کند. وقتی همه چیز روشن شد، همه به کار خود بر می‌گردند. نوبت رضا است که مهم‌ترین سناریوها را نوشته و آن‌ها را برای همه ارسال کند. (دفعه قبل نوبت محمد بود.) حالا شما می‌توانید کدنویسی را آن شروع کنید. در تجربه‌ی کاری قبلی شما، فرآیند این‌گونه نبود. تیم‌ها از طریق مستنداتی که پر از ابهامات بود و خوانش سختی داشت با یکدیگر ارتباط برقرار می‌کردند.لبخندی از سر رضایت می‌زنید. به سرعت اولین سناریو را به یک تست پذیرش خودکار تبدیل می‌کنید، می‌بینید که شکست خورد و شروع به نوشتن کد می‌کنید تا آن تست موفق شود. احساس خوبی دارید که می‌توانید زمان ارزشمند خود را بر روی چیزهای مهم صرف کنید و از حاشیه‌های دور هستید.
2.2. فقط یک روز بهش نیاز دارم:
بعدازظهر، دو نفر از همکاران، حسین و امیر، از تیم در مورد تصمیمی که در زمینه طراحی باید گرفته شود، سوال می‌کنند. کنار تخته وایت برد می‌روید و طرح‌های ممکن مختلف را کشیده و ارزیابی می‌کنید. نیازی به استفاده از UML و ابزارهای رسمی نیست و صرفا چند مربع و فلش کار شما را راه می‌اندازد. هدف انجام کاری رسمی نیست، فقط می‌خواهید مطمئن شوید که همه درک مشترکی از طرح‌ها دارید. چند دقیقه بعد یک راه حل انتخاب می‌شود. در مورد موضوع پیام رسانی در دو بخش مختلف گفتگو می‌کنید و در نهایت تصمیم می‌گیرید از دو کانال مختلف برای ارسال پیام استفاده کنید چون نیاز به جداسازی کامل بین سفارش‌های ورودی و درخواست‌های حمل و نقل است. امیر از تخته عکس می‌گیرد چون ممکن است کسی تخته را پاک کند. او میداند که در کمتر از یک روز، پیاده‌سازی انجام خواهد شد و سپس می‌تواند با خیال راحت عکس را از گوشی خود پاک کند. یک ساعت بعد، وقتی پیاده سازی انجام شد، هنگام Commit کردن او دقت می‌کند ک «جداسازی بین سفارش‌های ورودی و درخواست‌های حمل و نقل» را روی Commit به درستی ثبت کند. روز بعد، وحید که دیروز مرخصی بود، متوجه تغییر در کد می‌شود و می‌خواهد بداند چرا این اتفاق افتاده است. او git blame را اجرا کرده و بلافاصله پاسخ را دریافت می‌کند.
2.3. مستندات بازاریابی نداریم:
مدیر بازاریابی جدیدی به نام داوود وارد شرکت می‌شود. او نسبت به مدیر قبلی بیشتر به نگهداری مشتریان علاقه‌مند است. می‌خواهد بداند چه ویژگی‌هایی در برنامه در برای نگهداری مشتریان پیاده‌سازی شده است، بنابراین درخواست مستندات بازاریابی مربوطه را می‌کند و با تعجب می‌فهمد که هیچ مستندی وجود ندارد. داوود با تعجب می‌گوید: «جدی نمی‌گی!». اما شما سریعاً سایتی را با تمام تست‌های پذیرش که در طول هر بیلد تولید شده‌اند به او نشان می‌دهید که قسمتی برای جستجو دارد. داوود «نگهداری مشتریان» را وارد می‌کند و روی جستجو کلیک کند. نتایجی به او نشان داده می‌شود.
لیست نتایج، سناریوهای زیادی درباره تخفیف ویژه برای مشتریان وفادار جدید را نمایش می‌دهد. داوود لبخند می‌زند. حتی نیازی به مرور مستندات بازاریابی برای یافتن دانش مورد نیازش را نیز نداشت. سطح دقت این سناریوها به مراتب بیش از چیزی بود که او انتظار داشت. داوود پرسید «آیا می‌توانیم همین تخفیف را برای خریدها به دلار اعمال کنیم؟». شما پاسخ می‌دهید: «مطمئن نیستم که کد در حال حاضر ارزهای مختلف را به خوبی مدیریت می‌کند، اما بیایید امتحان کنیم.» ویژوال استودیو را باز کرده و ارز را در تست پذیرش تغییر می‌دهید و دوباره تست‌ها را اجرا می‌کنید. تست‌ها با خطا متوقف می‌شوند و متوجه می‌شوید برای انجام شدن کار نیاز به توسعه و تغییر کد دارید. داوود پاسخ خود را در عرض چند دقیقه دریافت می‌کند.او به فکر فرو می‌رود و میداند که شما چیزی دارید که هرگز در محیط‌های کاری قبلی خود تجربه نکرده بود.
2.4. این کلمات معنایی متفاوت دارند:
فردا داوود در مورد خرید و سفارش از شما سوال می‌پرسد. معمولاً از توسعه‌دهندگان می‌خواهد که در کد جستجو کرده و منطق و تفاوت‌های موجود در کد را برای او شرح دهند. اما اینجا شرایط متفاوت است. تیم فرهنگ لغاتی دارد که همه چیز در آن مستند شده است. او می‌پرسد: «آیا این فرهنگ‌نامه به‌روز است؟» شما پاسخ می‌دهید: «بله، در طول هر بیلد به طور خودکار از روی کد به‌روزرسانی می‌شود» او شگفت‌زده می‌شود. چرا همه این کار را نمی‌کنند؟ شما به سادگی می‌گویید: «باید کد و دامنه کسب و کاری شما با هم هنگاهنگی کامل داشته باشند تا این کار امکانپذیز باشد.» در این زمان می‌خواهید درباره DDD و Ubiquitous language و دیگر اصول آن شروع به سخنرانی کنید که داوید ابهامی در فرهنگ لغات پیدا می‌کند که قبلا کسی به آن توجه نکرده بود. او می‌گوید این کلمات باید اصلاح شوند. اما روش کار در شرکت شما متفاوت است. شما ابتدا کد را اصلاح می‌کنید و کلاس را تغییر نام می‌دهید و دوباره بیلد را اجرا می‌کنید فرهنگ لغات نیز کاملا خودکار اصلاح می‌شود. همه خوشحال هستند و تیم چیز جدیدی درباره‌ی کسب‌وکار تجارت الکترونیک یاد گرفته است.
2.5. کشف مشکل با دیدی جامع:
دو ماژول دارید که وابستگی اشتباهی به هم دارند و می‌خواهید آن را اصلاح کنید، اما با کل کدبیس آشنا نیستید، بنابراین از امیر یک نمودار وابستگی می‌خواهید، زیرا او بیشترین دانش را دارد. اما حتی او هم همه‌ی وابستگی‌ها را به خاطر ندارد. امیر می‌گوید: «من یک نمودار وابستگی از کد تولید می‌کنم. این کاری است که مدت‌هاست می‌خواستم انجام دهم. این کار چند ساعت طول می‌کشد، اما اگر انجام شود برای همیشه مشکل مرتفع خواهد شد.». امیر از قبل درباره‌ی چند کتابخانه که می‌توانند وابستگی‌ها را از یک کلاس یا بسته استخراج کرده و نمودارهای جادویی که به‌طور خودکار چیدمان خوبی نیز ایجاد می‌کنند را بررسی کرده است. چند ساعت بعد، ابزار کوچک او نمودار وابستگی‌ها را تولید می‌کند. شما چیزی را که می‌خواستید دریافت می‌کنید و خوشحال هستید. او سپس یک ساعتی را صرف یکپارچه‌سازی این ابزار در فرایند بیلد می‌کند. اما نکته جالب این است که وقتی امیر برای اولین بار به نمودار تولید شده نگاه می‌کند، متوجه نکته جذابی می‌شود: وابستگی بین دو ماژولی که نباید وجود داشته باشد. با مقایسه دید ذهنی او از سیستم با دید تولید شده از سیستم واقعی، شناسایی ضعف در طراحی سادگی اتفاق افتاد. در تکرار بعدی پروژه، ضعف طراحی برطرف می‌شود و در بیلد بعدی، نمودار وابستگی به‌طور خودکار به‌روزرسانی می‌شود. نمودار بسیار تمیزتر می‌شود.
2.6. آینده همین امروز است:
مطالب بالا در مورد آینده‌ای خیالی نیست بلکه مربوط به همین امروز است و سال‌هاست که اینجا بوده است. ویلیام گیبسون نویسنده‌ی داستان‌های تخیلی می‌گویند
future has arrived, it’s just not evenly distributed yet.
ابزارها و تکنیک‌ها اینجا هستند.سال‌هاست که این کارها انجام می‌شود، اما هنوز به‌طور گسترده‌ای مورد استفاده قرار نگرفته‌اند.
عدم فراگیری این تکنیک‌ها تأسف‌بار است زیرا ایدههای قدرتمندی برای تیم‌های توسعه نرم‌افزار هستند. در آینده، ما به بخشی از این رویکردها دیگر می‌پردازیم و یاد خواهید گرفت که چگونه آن‌ها را در پروژه‌های خود پیاده‌سازی کنید.
3. مشکل مستندات سنتی:
معمولات مدیران فکر می‌کنند مستندات چیز خوبی است و بهتر است برنامه‌نویسان سراغ مستندات بروند و برنامه نویسان نیز از آن متنفر هستند. مستندات موضوع خسته‌کننده‌ای است. تجربیات شما را نمی‌دانم اما برای من مستندات اغلب نا امید کننده بوده‌اند. خیلی وقت‌ها سراغ مستنداتی رفته‌ام و دادههایی که نیاز داشتم در آن‌ها نبوده است. وقتی هم که داده ها وجود دارد، اغلب منسوخ و گمراه‌کننده است، بنابراین حتی نمی‌توانم به مستندات اعتماد کنم. ایجاد مستندات برای دیگران یک کار خسته‌کننده است و همیشه ترجیح می‌دهم به جای تولید مستند، برنامه‌نویسی کنم. اما نباید کارها به این‌گونه باشد. بارها درباره آن‌ها شنیده‌ام و برخی از آن‌ها را نیز امتحان کرده‌ام. راه بهتری برای مستندسازی وجود دارد وجود دارد، اما برای بهره‌مندی از آن نیاز به پذیرش ذهنیتی جدید درباره مستندات است. با این ذهنیت و تکنیک‌هایی که با آن همراه است، ممکن است مستندات به اندازه برنامه‌نویسی لذت‌بخش باشد.
3.1. مستندات معمولاً جذاب نیست:
وقتی کلمه مستندات را می‌شنوید، چه چیزی به ذهن شما خطور می‌کند؟ چند پاسخ احتمالی در اینجا وجود دارد:
3.2. اشکالات مستندات:
مثل ذغال بی کیفیت که زود خاموش شده و سردرد آور است، مستندات کاغذی به سرعت منسوخ می‌شود و باعث سردرد می‌شود.روال مستندسازی سنتی اشکالات زیادی دارد و از چندین ضدالگوی رایج رنج می‌برد. همانطور که می‌دانید ضدالگو پاسخی مرسوم به مشکلی پر تکرار است که ایده‌ی خوبی نبوده و باید از آن اجتناب کرد. برخی از رایج‌ترین اشکالات و ضدالگوهای مستندات در ادامه توصیف شده‌اند. آیا برخی از آن‌ها را می‌شناسید؟
3.2.1. فعالیت‌های جداگانه:
حتی در پروژه‌های توسعه نرم‌افزار که ادعای چابکی دارند، تصمیم‌گیری در مورد آنچه باید ساخته شود و انجام کدنویسی، تست و تهیه مستندات اغلب فعالیت‌های جداگانه‌ای هستند .این فعالیت‌های جداگانه اغلب موجب هدر رفت منابع و از دست رفتن فرصت‌ها می‌شود. اساساً هنگام تولید یک نرم‌افزار دانشی داریم که، همان دانش در فعالیت‌های مختلف دست‌کاری شده و در اشکال مختلف و در مصنوعات مختلف - و احتمالاً با مقداری تکرار ظهور و بروز پیدا می‌کند.وقتی در فرایند‌های مختلفی با دانشی سر و کار داریم و بر اساس آن مصنوعاتی را ایجاد می‌کنیم، ممکن است به مرور دانش ما تکامل یابد و این تکامل باعث می‌شود مصنوعات مراحل مختلف با هم یکسان نباشند.
3.2.2. رونوشت دستی:
هنگامیکه زمان مستندسازی می‌رسد، اعضای تیم بخشی از دانشی که در ذهن دارند و با آن کار را انجام داده‌اند را انتخاب می‌کنند و رونوشتی دستی از آن‌ها در قالب مناسب برای مخاطب مورد نظر انجام می‌دهند. اساساً، اینکار به معنای نوشتن یک سند متنی درباره‌ی آنچیزی است که در کد انجام شده است. این کار تکرار مکررات و بی‌فایده است. مانند زمانی که هنوز دستگاه چاپ اختراع نشده بود و برای تهیه‌ی نسخه از کتاب، مجددا از آن رونویسی انجام می‌شد.
3.2.3. دانش تکراری:
رونوشت دستی توضیح داده شده منجر به دانش تکراری می‌شود. در پروژه‌های نرم‌افزاری شما با منبع اصلی حقیقت که معمولاً کد است و یک دسته نسخه‌هایی که این دانش را در اشکال مختلف تکرار می‌کنند، به پایان مستندسازی می‌رسید. متأسفانه، وقتیکه یکی از مصنوعات تغییر می‌کند - برای مثال، کد - اینکه به خاطر بسپاریم مستندات هم باید به روز شوند کار سختی است. در نتیجه، مستندات به سرعت منسوخ می‌شود و شما با مستندات ناقصی که نمی‌توانید به آن اعتماد کنید مواجه می‌شوید.چنین مستنداتی چقدر مفید است؟
3.2.4. وقت‌کشی خسته‌کننده:
مدیران می‌خواهند مستنداتی برای کاربران و همچنین برای ایجاد امکان جابجایی کارکنان در تیم داشته باشند. با این حال، توسعه‌دهندگان از نوشتن مستندات متنفرند. این کار در مقایسه با نوشتن کد یا خودکارسازی یک فرایند اصلا جذاب نیست. مستند متن مرده‌ای است که به سرعت منسوخ می‌شود و اجرا نمی‌شود، برای یک توسعه‌دهنده نوشتن آن هیچ جاذبه‌ای ندارد. توسعه‌دهندگان همیشه تمایل دارند روی کد زمان بگذارند نه روی مستندات و همین توسعه‌دهندگان هنگامی که سراغ نرم‌افزار شخص ثالثی می‌روند از نبود مستندات کافی شکایت می‌کنند و این خود پارادوکس است. نویسندگان فنی دوست دارند مستندات بنویسند و برای آن دستمزد می‌گیرند. ولی برای دسترسی به دانش فنی مورد نیاز، معمولاً به توسعه‌دهندگان نیاز دارند، ضمن اینکه اغلب آن‌ها هنوز رونوشت دستی از دانش انجام می‌دهند.این کار خسته‌کننده است و زمان ارزشمند زیادی را مصرف می‌کند.
3.2.5. خالی‌کردن مغز:
از آنجائیکه نوشتن مستندات جذاب نیست ولی کاری است که باید انجام شود، اغلب بدون قاعده و فکر زیاد انجام می‌شود. نتیجه یک تخلیه مغزی تصادفی از آنچه نویسنده در زمان نوشتن در ذهن دارد، است. مشکل اصلی این است که این تخلیه‌ی مغزی تصادفی برای کسی مفید نیست.
3.2.6. نمودارهای زیبا:
این ضدالگو، در تیم‌هایی که دوست دارند از ابزارهایCASE استفاده کنند بسیار رایج است. این ابزارها برای طراحی نیستند. در عوض، آن‌ها تشویق به ایجاد نمودارهای پالوده و بزرگ می‌کنند، با چیدمان‌های مختلف و اعتبارسنجی در برابر یک مرجع مدل‌سازی. همه‌ی این کارها زمان زیادی می‌برد. حتی با همه‌ی ویژگی‌های چیدمان خودکار این ابزارها، ایجاد یک نمودار ساده هنوز زمان زیادی می‌برد.
3.2.7. وسواس به نشانه‌گذاری:
این روز‌ها دیگر UML مثل گذشته محبوب نیست، اما در دهه‌ی پس از تصویب آن به عنوان یک استاندارد در سال 1997، این نشانه‌گذاری جهانی برای هر کار نرم‌افزاری مورد استفاده بود،حتی اگر برای آن کار مناسب نبود. هیچ نشانه‌گذاری دیگری از آن زمان محبوب نشده است و تیم‌های سراسر جهان هنوز از UML برای مستندسازی استفاده می‌کنند، حتی وقتی که برای آن مناسب نیست. وقتی تنها چیزی که می‌دانید UML است، همه چیز شبیه به یکی از نمودارهای استاندارد آن به نظر می‌رسد.
3.2.8. عدم استفاده از نشانه‌گذاری:
در واقع، عدم استفاده از نشانه‌گذاری به طرز عجیبی محبوب شده است. بسیاری از افراد به سادگی UML را نادیده گرفته‌اند و با نشانه‌گذاری‌های سفارشی نمودارهایی رسم می‌کنند که هیچ دو نفری آن‌ها را به یک شکل درک نمی‌کند و نگرانی‌های مختلفی مانند وابستگی‌های بیلد، جریان داده و نگرانی‌های استقرار را با خوشحالی با هم ترکیب کرده و آشوب ایجاد می‌کنند.
3.2.9. گورستان اطلاعات:
اغلب، راه‌حل‌های مدیریت دانش سازمانی به زباله‌دان‌هایی برای مرگ دانش تبدیل می‌شوند. به این‌ها فکر کنید:
3.2.10. کمک گمراه‌کننده:
مستنداتی که به‌طور دقیق به‌روز نگه داشته نشود، گمراه‌کننده است. آیا برای شما پیش آمده کهدر یکی از کمد‌های خانه، جعبه‌ی بیسکوئیتی را یافته‌اید و وقتی با شوق و ذوق فراوان درب آن را بازکرده‌اید و در کمال تعجب با انبوهی از نخ و سوزن مواجه شوید؟ این همان مستندات گمراه کننده است. اگرچه این مستندات ادعا می‌کنند که کمک می‌کنند، اما نادرست است. در نتیجه، چنین مستنداتی ممکن است برای خواندن جالب باشد، اما بار شناختی اضافی برای پیدا کردن آنچه که هنوز درست است در مقابل آنچه که نادرست شده است وجود دارد. اگر به مثال خانه بازگردیم، برای یافتن بیسکوئیت احتمالا باید به دنبال جعبه ای با علامت مرگ و نوشته مرگ موش باشید.
3.2.11. همیشه چیز مهم‌تری وجود دارد:
نوشتن مستندات خوب زمان زیادی می‌طلبد و نگهداری آن زمان بیشتری می‌طلبد. کسانی که تحت فشار زمانی هستند اغلب وظایف مستندسازی را نادیده می‌گیرند یا سریع و بد انجام می‌دهند.
3.3. مانفیست چابک و مستندات:
مانفیست چابک توسط گروهی از توسعه‌دهندگان نرم‌افزار در سال 2001 نوشته شد. در این مانیفست، آن‌ها مواردی را که به آن‌ها ارزش داده‌اند فهرست می‌کنند، از جمله:
اولویت دوم، «نرم‌افزار کارآمد بیش از مستندات جامع»، اغلب نادرست تفسیر می‌شود. بسیاری از مردم باور دارند که به‌طور کامل مستندات را باید نادیده گرفت. در واقع، مانفیست چابک نمی‌گوید «مستندسازی نکنید». این فقط یک مسئله اولویت است. به گفته‌ی نویسندگان مانفیست، «ما مستندات را می‌پذیریم، اما نه به منظور هدر دادن کاغذهای بی‌شماری که نادیده‌گرفته می‌شوند.» هنوز هم، با رویکردهای چابک که در شرکت‌های بزرگ به جریان اصلی تبدیل شده‌اند،سوءتفاهم در اینباره وجود داشته و بسیاری از تیم‌ها مستندات را نادیده می‌گیرند.
با این حال، مشاهداتم نشان می‌دهد نبود یا کمبود مستندات باعث ایجاد مشکل و نا امیدی در بسیاری از مشتریان و همکارانم شده است و این مشکل در حال رشد است.
3.4. مستندات سنتی مشکل دارد، اما اکنون بهتر می‌دانیم:
از اواخر دهه‌ی 90 میلادی، روش‌ها و اصولی مانند کدنویسی تمیز، توسعه‌ی مبتنی بر تست (TDD)، توسعه‌ی مبتنی بر رفتار (BDD)، طراحی مبتنی بر دامنه (DDD) و تحویل مداوم به‌طور فزاینده‌ای محبوب شده‌اند. همه این روش‌ها نحوه‌ی تفکر ما در مورد تحویل نرم‌افزار را تغییر داده‌اند.
وقتی TDD را انتخاب می‌کنیم، تست‌ها ابتدا به عنوان مشخصات در نظر گرفته می‌شوند. با DDD، کد و مدل‌سازی دامنه‌ی کسب‌وکار را شناسایی می‌کنیم و از روش سنتی نگهداری مدل‌ها و کدها به صورت جداگانه فاصله می‌گیریم. یکی از نتایج این رویکردی این است که انتظار داریم کد تمام داستان را درباره‌ی دامنه بیان کند. BDD ایدههای زبان کسب‌وکار را قرض گرفته و آن را به‌طور مستقیم‌تری با پشتیبانی ابزاری‌هایی مورد استفاده قرار می‌دهد. در نهایت، تحویل مداوم نشان می‌دهد که ایده‌ای که چند سال پیش مضحک به نظر می‌رسید (تحویل چندین بار در روز به صورت غیررویدادی) در واقع ممکن و حتی مطلوب است اگر تصمیم بگیریم و بتوانیم به روش‌های پیشنهادی کامل پایبند بمانیم.
4. مستندات درباره‌ی دانش است:
همانطور که گفتیم، توسعه‌ی نرم‌افزار تماماً درباره دانش و تصمیم‌گیری بر اساس آن دانش است، که به نوبه‌ی خود دانش اضافی ایجاد می‌کند. مشکل موجود، تصمیمی که گرفته شد، دلیل آن تصمیم، حقایقی که به آن تصمیم منجر شد، و گزینه‌های در نظر گرفته شده همگی دانش هستند.
ممکن است تاکنون به این شکل به آن فکر نکرده باشید، اما هر دستوری که در یک زبان برنامه‌نویسی تایپ می‌شود یک تصمیم است. تصمیمات بزرگ و کوچک وجود دارند، اما بدون توجه به اندازه، همه‌ی آن‌ها تصمیم هستند. در توسعه‌ی نرم‌افزار، هیچ مرحله‌ی ساخت گرانی پس از مرحله‌ی طراحی وجود ندارد: ساخت ( یا دقیق‌تر اگر بگویم اجرای کامپایلر برای تبدیل کد طراحی شده به زبان ماشین) آنقدر ارزان است که به راحتی بارها و بارها آن را اجرا می‌کنیم.کار اصلی و گرانقیمت طراحی است.
طراحی نرم‌افزار می‌تواند مدت زیادی طول بکشد. می‌تواند به اندازه کافی طول بکشد تا تصمیمات قبلی و زمینه‌هایی که در آن تصمیمات گرفته شده اند فراموش شوند. می‌تواند به اندازه‌ی کافی طول بکشد تا افراد نیز از تیم بروند و دانش خود را ببرند و افراد جدیدی بپیوندند که فاقد دانش هستند. دانش در مرکز فرایند توسعه نرم‌افزار قرار دارد.
بیشتر اوقات فعالیت طراحی، تلاشی تیمی است که بیش از یک نفر را درگیر می‌کند. کار کردن با هم به معنای تصمیم‌گیری با هم یا تصمیم‌گیری بر اساس دانش شخصی دیگر است.
چیزی که توسعه نرم‌افزار را منحصر به فرد می‌کند این است که طراحی نه تنها افراد بلکه ماشین‌ها را نیز درگیر می‌کند. کامپیوترها بخشی از فرایند کلی هستند و بسیاری از تصمیماتی که گرفته می‌شود به سادگی به کامپیوتر داده می‌شود تا اجرا کند. اینکار معمولاً از طریق مستنداتی به نام سورس کد انجام می‌شود. با استفاده از یک زبان برنامه‌نویسی، ما دانش و تصمیمات را به شکلی برای کامپیوتر قابل درک باشد به آن منتقل می‌کنیم.
درک سورس برای کامپیوتر بخش سختی نیست. حتی توسعه‌دهندگان بی‌تجربه هم معمولاً موفق به توسعه کد قابل درک برای کامپیوتر می‌شوند. سخت‌ترین بخش این است که سایر افراد درک کنند چه کاری انجام شده است تا بتوانند کار بهتر و سریع‌تری را انجام دهند.
هرچه جاه‌طلبی بیشتر باشد، مستندات بیشتری لازم می‌شود تا یک فرآیند تجمعی مدیریت دانش را امکان‌پذیر کند که فراتر از آنچه در ذهن ما جا می‌گیرد، مقیاس‌پذیر باشد. هنگامی که مغز و حافظه‌ی ما کافی نیستند، به فناوری‌هایی مانند نوشتن، چاپ و نرم‌افزار نیاز داریم تا به یادآوری و سازماندهی مجموعه‌های بزرگتر دانش کمک کنند.
4.1. منشاء دانش
دانش از کجا می‌آید؟ دانش عمدتاً از مکالمات حاصل می‌شود. ما از طریق مکالمه با دیگران، دانش زیادی به دست می‌آوریم. این مکالمات در طول کار گروهی مانند XP، یا در طول جلسات، یا در محل‌های غیررسمی مانند حیاط شرکت یا از طریق چت شرکتی یا ایمیل‌ها اتفاق می‌افتد. نمونه‌هایی از مکالمات شامل کارگاه‌های مشخصات BDD و 3amigos در چابک هستند.
با این حال، به عنوان توسعه‌دهندگان نرم‌افزار، ما با ماشین‌ها نیز مکالمه داریم و این مکالمات را تست می‌نامیم. ما چیزی را به یک ماشین می‌گوییم با استفاده از کد در یک زبان برنامه‌نویسی، و ماشین آن را اجرا می‌کند و به ما چیزی می‌گوید: تست شکست می‌خورد یا موفق می‌شود، رابط کاربری طبق انتظار واکنش نشان می‌دهد، یا نتیجه چیزی نیست که می‌خواستیم، در این صورت ما چیز جدیدی یاد می‌گیریم. نمونه‌هایی از تست ها شامل TDD، طراحی در حال ظهور، و آزمایش‌های Lean Startup است.
دانش همچنین از مشاهده محیط به دست می‌آید. در یک شرکت، شما با حضور در آنجا و توجه به مکالمات، رفتارها و احساسات دیگران، چیزهای زیادی یاد می‌گیرید. نمونه‌هایی از مشاهده شامل غرق شدن در دامنه، دیوارهای وسواسی، رادیاتورهای اطلاعاتی، و مشاهده "از ساختمان بیرون برو" در Lean Startup است.
4.2. تکامل دانش:
رخی از دانش‌ها می‌توانند برای سال‌ها پایدار بمانند، در حالی که برخی دیگر از دانش‌ها به طور مکرر در طول ماه‌ها یا حتی ساعت‌ها تغییر می‌کنند.
هر شکلی از مستندات باید هزینه‌ی نگهداری را در نظر بگیرد و آن را تا حد ممکن به صفر نزدیک کند. برای دانش پایدار، روش‌های سنتی مستندسازی کارساز هستند. اما با دانش‌هایی که به طور مکرر تغییر می‌کنند، نوشتن متن و به‌روزرسانی آن بعد از هر تغییر، گزینه‌ی نامناسبی است.
تأثیر شتاب در صنعت نرم‌افزار این است که ما می‌خواهیم در موقعیتی باشیم که بتوانیم نرم‌افزار را بسیار سریع تکامل دهیم. سرعت به حدی است که نمی‌توان زمان صرف نوشتن صفحات زیادی از مستندات کرد، با این حال ما می‌خواهیم و نیاز داریم از تمامی مزایای مستندات بهره‌مند شویم.
4.3. چرا دانش ضروری است؟
هنگام ایجاد نرم‌افزار، ما با سوالات، تصمیمات و تنظیمات زیادی روبرو می‌شویم و یاد می‌گیریم که:
با نرم‌افزار موجود، وقتی دانش توسعه یافته‌ی قبلی را از دست می‌دهیم، مجبور به دوباره‌کاری آنچه قبلاً انجام شده است می‌شویم زیرا نمی‌دانیم که کاری از قبل انجام شده است. همچنین ممکن است یک ویژگی را در یک مؤلفه‌ی غیر مرتبط قرار دهیم زیرا نمی‌دانیم که باید کجا باشد، و این باعث می‌شود نرم‌افزار حجیم شود. یا کد مربوط به ویژگی در بین مؤلفه‌های مختلف پراکنده می‌شود.
اگر فقط دانش لازم برای پاسخ به سوالات روزمره مانند سوالات زیر را در دسترس داشتیم:
کمبود دانش به دو هزینه منجر می‌شود:
این دو هزینه در طول زمان ترکیب می‌شوند: زمان صرف شده برای یافتن دانش گم شده زمانی نیست که برای گرفتن تصمیمات بهتر صرف شود. در نتیجه، تصمیمات غیر بهینه ترکیب می‌شوند و زندگی ما را به تدریج ناخوشایندتر می‌کنند تا زمانی که چاره‌ای جز تصمیم‌گیری مبتنی بر غیرقابل نگهداری بودن نرم‌افزار و بازنویسی آن نداریم.
به نظر می‌رسد ایده خوبی است که بتوانیم به دانشی که برای انجام وظایف توسعه مفید است، دسترسی داشته باشیم.
4.4. برنامه‌نویسی، نظریه‌سازی و انتقال:
در سال 1985، مقاله مشهور پیتر نائور با عنوان "برنامه‌نویسی به عنوان نظریه‌سازی" به خوبی حقیقت برنامه‌نویسی به عنوان یک تلاش جمعی را آشکار کرد: او گفت که برنامه‌نویسی بیشتر درباره به اشتراک گذاشتن نظریه‌ای از جهان (فکر کنید "مدل ذهنی") با دیگر توسعه‌دهندگان است که به طور صبورانه از طریق یادگیری، آزمایش، مکالمات و تأملات عمیق ایجاد شده است. به گفته خود او:
"برنامه‌نویسی به درستی باید به عنوان فعالیتی در نظر گرفته شود که توسط آن برنامه‌نویسان به نوعی از بینش، نظریه، درباره موضوعات در دست اقدام دست می‌یابند. این پیشنهاد در تضاد با آن چیزی است که به نظر می‌رسد مفهوم رایج‌تر باشد، که برنامه‌نویسی باید به عنوان تولید یک برنامه و متون دیگر در نظر گرفته شود."
مشکل این است که بیشتر نظریه ضمنی است. کد فقط نوک کوه یخ را نشان می‌دهد. کد بیشتر نتیجه‌ای از نظریه‌ی در ذهن توسعه‌دهندگان است تا نمایشی از خود نظریه. از دیدگاه پیتر نائور، این نظریه سه حوزه اصلی دانش را در بر می‌گیرد:
با گذشت زمان، تعدادی تکنیک یاد گرفته‌ایم که به افراد اجازه می‌دهد نظریه‌ها را بین خود منتقل کنند. کد تمیز و DDD برنامه‌نویسان را تشویق می‌کند تا راه‌هایی برای بیان نظریه در سر خود به شکلی واقعی‌تر در کد پیدا کنند. به عنوان مثال، ubiquitous language در DDD فاصله‌ی بین زبان جهان و زبان کد را پر می‌کند و به حل مشکل نقشه‌برداری کمک می‌کند. امیدوارم زبان‌های برنامه‌نویسی آینده نیاز به نمایش نه تنها رفتار کد بلکه مدل ذهنی بزرگتر برنامه‌نویسان، که کد نتیجه آن است، را به رسمیت بشناسند.
الگوها و زبان‌های الگو نیز به عنوان تلاش‌های صریح برای بسته‌بندی بخش‌هایی از نظریه‌ها به ذهن می‌رسند. هرچه الگوهای بیشتری بشناسیم، بیشتر می‌توانیم نظریه‌ی ضمنی را رمزگذاری کنیم و آن را به شکل گسترده‌تر و قابل انتقال‌تر تبدیل کنیم. الگوها در توضیحات نیروهای خود عناصر کلیدی منطق انتخاب آن‌ها را تجسم می‌کنند و گاهی اوقات اشاره می‌کنند که چگونه توسعه باید اتفاق بیفتد. آن‌ها ممکن است به پتانسیل برنامه اشاره کنند؛ به عنوان مثال، الگوی استراتژی قرار است با افزودن استراتژی‌های جدید گسترش یابد.
اما همانطور که در رمزگذاری فهم خود پیشرفت می‌کنیم، با چالش‌های بلندپروازانه‌تری نیز مواجه می‌شویم، بنابراین ناامیدی ما همچنان باقی می‌ماند. من معتقدم جمله نائور از سال 1985 در دهه‌های آینده همچنان معتبر خواهد بود: "برای یک برنامه‌نویس جدید که بخواهد نظریه موجود از یک برنامه را به دست آورد، فرصت آشنایی با متن برنامه و سایر مستندات کافی نیست."
ما هرگز مشکل انتقال دانش را به طور کامل حل نخواهیم کرد، اما می‌توانیم آن را به عنوان یک واقعیت بپذیریم و یاد بگیریم با آن زندگی کنیم. نظریه‌ای که به عنوان یک مدل ذهنی در ذهن برنامه‌نویسان است، هرگز نمی‌تواند به طور کامل با افرادی که بخشی از فرآیند فکری‌ای که منجر به ایجاد آن شده، نبوده‌اند، به اشتراک گذاشته شود.
شایان ذکر است که تیم‌های دائمی که به طور منظم به صورت جمعی کار می‌کنند، از این مشکل انتقال نظریه زیاد رنج نمی‌برند.
5. مستندات درباره انتقال دانش است:
کلمه مستندات اغلب تداعی‌های زیادی را به ذهن می‌آورد: اسناد نوشته شده، اسناد Microsoft Word یا PowerPoint، اسنادی بر اساس الگوهای شرکت، اسناد چاپ شده، متن بزرگ، سنگین و خسته‌کننده در یک وب‌سایت یا ویکی، و غیره. با این حال، همه‌ی این تداعی‌ها ما را به شیوه‌های گذشته متصل می‌کنند و بسیاری از شیوه‌های جدیدتر و کارآمدتر را نادیده می‌گیرند.
برای اهداف این نوشته، ما یک تعریف بسیار گسترده‌تر از مستندات را اتخاذ خواهیم کرد:
فرآیند انتقال دانش ارزشمند به افراد دیگر در حال حاضر و همچنین به افراد در آینده.
مستندات یک جنبه‌ی لجستیکی دارد. این کار مربوط به انتقال دانش در فضای بین افراد و همچنین انتقال آن در طول زمان است که افراد فنی آن را ماندگاری یا ذخیره‌سازی می‌نامند. به طور کلی، تعریف ما از مستندات شبیه به حمل و انبار کردن کالاها است، با این تفاوت که کالاها دانش هستند.
انتقال دانش بین افراد در واقع انتقال دانش بین مغزها است. این انتقال می‌تواند از یک مغز به مغزهای دیگر در حال حاضر باشد که این مسئله این یک مسئله انتقال یا انتشار نامیده می‌شود. در حالت دیگری این انتقال می‌تواند از مغزها در حال حاضر به مغزهایی در آینده باشد، این نوع انتقال مربوط به ماندگاری دانش و یک مسئله‌ی حافظه است.
آیا می‌دانستید؟ نیمه‌ی عمر دوره توسعه 3.1 سال است، در حالی که نیمه‌ی عمر کد 13 سال است. مستندات باید با این ناسازگاری مقابله کنند.
انتقال دانش از مغز یک فرد فنی به مغزهای افراد غیر فنی نیز یک مسئله‌ی دسترسی به دانش است. یک مورد دیگر از دسترسی به دانش، کارآمدتر کردن جستجوی آن است.
و موارد دیگری نیز وجود دارد، مانند نیاز به قرار دادن دانش در قالب یک سند خاص به دلیل مطابقت با یک استاندارد زیرا شما فقط مجبور به رعایت آن استاندارد هستید.
5.1. تمرکز بر آنچه اهمیت دارد:
به عنوان وسیله‌ای برای انتقال دانش ارزشمند، مستندات می‌تواند اشکال مختلفی داشته باشد: اسناد نوشتاری، مکالمات رو در رو، کد، فعالیت در ابزارهای اجتماعی، یا هیچ چیز وقتی که ضروری نیست.
با این تعریف از مستندات، می‌توانیم برخی از اصول مهم را بیان کنیم:
از سوی دیگر، مستندسازی دانشی که در هیچ یک از موارد بالا نیست ارزشی ندارد و صرف زمان یا تلاش برای آن بیهوده خواهد بود.
توجه کنید که ارزشمند بودن دانش مورد نظر اهمیت دارد. تلاش برای انتقال دانشی که در دراز مدت افراد کافی به آن نیاز ندارند ارزشمند نیست. اگر دانشی از قبل به خوبی شناخته شده است یا فقط برای یک نفر مفید است، یا فقط تا پایان روز مورد به آن نیاز داریم، پس نیازی به انتقال یا ذخیره‌ی آن نیست.
به صورت پیشفرض مستندسازی نکنید:
هیچ دلیلی برای انجام هیچ تلاش خاصی در مستندسازی دانش وجود ندارد مگر اینکه دلیلی قانع‌کننده برای انجام آن وجود داشته باشد؛ در غیر این صورت، این یک اتلاف وقت است. احساس بدی نداشته باشید اگر چیزی را که نیازی به مستندسازی ندارد، مستندسازی نمی‌کنید.
6. جمع بندی:
در این نوشته تلاش کردیم دنیایی که باید به سمت آن برویم و مشکلات فعلی در حوزه‌ی مستند سازی را بررسی کنیم. با بازنگری در مورد اینکه مستندات واقعاً چیست، از نظر انتقال و حفظ دانش، و برخی نتایج اولیه در نحوه‌ی مدیریت آن، اکنون زمان معرفی ایده مرکزی مستندات زنده و اصول اصلی آن فرا رسیده است. در قسمت بعد به تعریف اصول مستند سازی مدرن خواهیم پرداخت.
پ.ن: منبع اصلی قسمت‌های مرتبط با مستندسازی در این سری نوشتار از کتاب Living Documentation: Continuous Knowledge Sharing by Design نوشته‌ی آقای Cyrille Martraire است که خواندن کتاب اصلی را به همه مهندسین نرم‌افزار و علاقه‌مندان به DDD پیشنهاد می‌کنم.
