Forward from: Software Philosophy
EXACT INSTRUCTIONS
پیشنهاد می‌کنم اول فیلم رو ببنید بعد بقیه مطلب رو بخونید.
https://www.youtube.com/watch?reload=9&v=Ct-lOOUqmyY
خیلی جالب بود و در نگاه اول هیچ ربطی به نرم‌افزار و دنیای نرم‌افزار نداره. ولی وقتی یه خورده عمیق بشیم خیلی جالب میشه.
یکی از مهم‌ترین کارهایی که باید توی شرکت‌های نرم‌افزاری به درستی انجام بشه، داکیومنت کردن است. (داکیومنت به معنی کامنت گذاشتن داخل کد اصلا منظورم نیست، کد باید خودش به قدری خوانا باشه که نیاز به کامنت نداشته باشه یا به اصطلاح Self-Document باشه.)
داکیومنت کردن رو نباید به عنوان یه کار اضافه دید و سرسری انجامش داد.
تمام مراحل انتقال دانش باید به وسیله داکیومنت انجام بشه. نه به صورت نقل قول و سینه به سینه.
اتفاقی که برای خودم افتاد رو براتون تعریف می‌کنم:
در شرکت کرانه ادمین TFS بودم، و یکی از کارهایی که باید انجام می‌دادم و داکیومنت می‌کردم Disaster Recovery خود TFSبود. ۱ روز کامل وقت گذاشتم و Recovery رو انجام دادم و داکیومنتش رو نوشتم، کاری که مدیرمون کرد خیلی خوب بود. داکیومنت رو داد به یکی دیگه گفت TFS رو بیار بالا. حدس می‌زنید چی شد؟ نتونست، چون داکیومنتی که نوشته بودم به درد خودم می‌خورد.
و حرفی که به من زد این بود «داکیومنت باید طوری باشه که اگه دست یه نفر رو از توی خیابون گرفتم و این داکیومنت رو بهش دادم بتونه TFS رو بیاره بالا». بعد از ۳ بار داکیومنت نوشتن بالاخره موفق شدم داکیومنتی بنویستم که به هر کی بدمش فقط با Back up دیتا بیس بتونه TFS رو بالا بیاره.
به نظر من داکیومنت باید طوری باشه تا تمام کسانی که می‌خوننش، همشون یک برداشت رو داشته باشن، داکیومنت نباید وابسته به Context ذهن ما باشه.
خوشحال می‌شم نظر شما رو هم بدونم.
#افشین_علیزاده (http://ow.ly/l7cA30m3OQ9)
کانال تلگرام:
@SoftwarePhilosophy
___
پیشنهاد می‌کنم اول فیلم رو ببنید بعد بقیه مطلب رو بخونید.
https://www.youtube.com/watch?reload=9&v=Ct-lOOUqmyY
خیلی جالب بود و در نگاه اول هیچ ربطی به نرم‌افزار و دنیای نرم‌افزار نداره. ولی وقتی یه خورده عمیق بشیم خیلی جالب میشه.
یکی از مهم‌ترین کارهایی که باید توی شرکت‌های نرم‌افزاری به درستی انجام بشه، داکیومنت کردن است. (داکیومنت به معنی کامنت گذاشتن داخل کد اصلا منظورم نیست، کد باید خودش به قدری خوانا باشه که نیاز به کامنت نداشته باشه یا به اصطلاح Self-Document باشه.)
داکیومنت کردن رو نباید به عنوان یه کار اضافه دید و سرسری انجامش داد.
تمام مراحل انتقال دانش باید به وسیله داکیومنت انجام بشه. نه به صورت نقل قول و سینه به سینه.
اتفاقی که برای خودم افتاد رو براتون تعریف می‌کنم:
در شرکت کرانه ادمین TFS بودم، و یکی از کارهایی که باید انجام می‌دادم و داکیومنت می‌کردم Disaster Recovery خود TFSبود. ۱ روز کامل وقت گذاشتم و Recovery رو انجام دادم و داکیومنتش رو نوشتم، کاری که مدیرمون کرد خیلی خوب بود. داکیومنت رو داد به یکی دیگه گفت TFS رو بیار بالا. حدس می‌زنید چی شد؟ نتونست، چون داکیومنتی که نوشته بودم به درد خودم می‌خورد.
و حرفی که به من زد این بود «داکیومنت باید طوری باشه که اگه دست یه نفر رو از توی خیابون گرفتم و این داکیومنت رو بهش دادم بتونه TFS رو بیاره بالا». بعد از ۳ بار داکیومنت نوشتن بالاخره موفق شدم داکیومنتی بنویستم که به هر کی بدمش فقط با Back up دیتا بیس بتونه TFS رو بالا بیاره.
به نظر من داکیومنت باید طوری باشه تا تمام کسانی که می‌خوننش، همشون یک برداشت رو داشته باشن، داکیومنت نباید وابسته به Context ذهن ما باشه.
خوشحال می‌شم نظر شما رو هم بدونم.
#افشین_علیزاده (http://ow.ly/l7cA30m3OQ9)
کانال تلگرام:
@SoftwarePhilosophy
___