<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0">
    <channel>
        <title>نوشته های محمد مهدوی کیا</title>
        <link>https://virgool.io/feed/@mahdavikia</link>
        <description>معمار و مشاور توسعه‌ی نرم افزار https://diasoft.ir</description>
        <language>fa</language>
        <pubDate>2026-06-16 15:08:21</pubDate>
        <image>
            <url>https://files.virgool.io/upload/users/1021995/avatar/Iickpc.jpeg?height=120&amp;width=120</url>
            <title>محمد مهدوی کیا</title>
            <link>https://virgool.io/@mahdavikia</link>
        </image>

                    <item>
                <title>درک الگوی &quot;پله برقی&quot; در طراحی سیستم</title>
                <link>https://virgool.io/@mahdavikia/escalator-software-architecure-qezcj98vye8q</link>
                <description>چطور میتوانیم سیستمی طراحی کنیم که اگر بخشی از آن کار نکرد، بقیه ی سیستم به عملکرد خودش ادامه دهد؟ پله برقی ها نمونه ای آشنا در دنیای واقعی از همین مفهوم هستند. وقتی کار را متوقف می کنند، هنوز هم می توانند با ایفای نقش پله، افراد را از یک طبقه به طبقه دیگر ببرند. آنها ممکن است به اندازه معمول عملکردی نداشته باشند، اما کاملاً بی فایده نیستند.در زبان جهانی به این رویکرد Graceful Degradation میگویند که در ترجمه ی فارسی واژه ی نا آشنای &quot;تنزل برازنده&quot; را به ما میدهد. به بیانی عامیانه تر سیستم ما آن کارایی اولیه و واقعی خودش را ندارد اما به شکلی غیر مفتضحانه به کار خودش ادامه میدهد. در تصویر زیر، محصول Abode Flash به شکل غیر برازنده ای کاربر را محدود کرده و عملا محتوایی ارائه نمیکند. مثل این است که پله برقی از کار افتاده باشد و پله ها هم وارونه شده باشند!از کار افتادن محتوای فلشصفحه وب بی‌بی‌سی نیوز نمونه خوبی از این تنزل برازنده در طراحی وب است. همانطور که تصویر پایین نشان می دهد، سایت بارگیریِ منو و متن یک خبر را به تصاویر اولویت می دهد. در نتیجه، سرعت پایین یا پلاگین های قدیمی و ناسازگار مرورگر ممکن است تصاویر را از دسترس خارج کنند، اما عملکرد اصلی سایت - اشتراک گذاری اخبار - هنوز قابل دسترسی است.اولویت متن بر عکس در تنزل برازنده ی وب سایت خبری بی بی سی</description>
                <category>محمد مهدوی کیا</category>
                <author>محمد مهدوی کیا</author>
                <pubDate>Mon, 09 Dec 2024 08:30:20 +0330</pubDate>
            </item>
                    <item>
                <title>دو بار اندازه بگیرید، یک بار برش دهید!</title>
                <link>https://virgool.io/@mahdavikia/%D8%AF%D9%88-%D8%A8%D8%A7%D8%B1-%D8%A7%D9%86%D8%AF%D8%A7%D8%B2%D9%87-%D8%A8%DA%AF%DB%8C%D8%B1%DB%8C%D8%AF-%DB%8C%DA%A9-%D8%A8%D8%A7%D8%B1-%D8%A8%D8%B1%D8%B4-%D8%AF%D9%87%DB%8C%D8%AF-wngg4tskfbfk</link>
                <description>Write. Rewrite. Revise. Then doاین یک جمله ی تاکیدی معروف است که در همه ی مشاغل می تواند صدق کند تا تضمین کند کار نهایی بی نقص است.اما برای ما که کارمان تولید نرم‌افزار است، می‌توان به این شکل هم نوشت:&quot;بهترین راه برای ساختن یک محصول عالی این است که ابتدا کل ایده را بنویسید. بازنویسی کنید. تجدید نظر کنید. سپس انجام دهید.&quot;جف بزوس، بنیانگذار آمازون، اصرار داشت هر جلسه ای با یادداشت های حداقل 4 صفحه ای برگزار شود بجای ارائه پاورپوینت.بزوس در یک ایمیل داخلی نوشت: «دلیل اینکه نوشتن یک یادداشت 4 صفحه‌ای خوب سخت‌تر از «نوشتن» یک پاورپوینت 20 صفحه‌ای است، لذا ساختار روایی یک یادداشت خوب باعث می‌شود فکر بهتری داشته باشید و درک بهتری از آنچه مهم‌تر از بقیه است، و اینکه چگونه چیزها به هم مرتبط هستند.&quot;وسوسه این است که مستقیماً به حالت ساختن بپرید، کد بنویسید یا وایرفریم بسازید یا پیش نویس هایی را که می خواهید ایجاد کنید ترسیم کنید.اما روش بهتر این است که ایده خود را به عنوان راهی برای فکر کردن و بهبود آن بنویسید.سپس، هنگامی که ساخت و ساز را شروع می کنید، دقیقاً می دانید چه چیزی را و چرا باید بسازید، و در هنگام راه اندازی اسناد از پیش نوشته شده هم خواهید داشت.سوئیفت چندین دهه پیش نوشت: «نوشتن راهی برای کشف کردن است، بازنویسی کلید بهبود تفکر است.&quot;</description>
                <category>محمد مهدوی کیا</category>
                <author>محمد مهدوی کیا</author>
                <pubDate>Sun, 16 Jul 2023 07:31:03 +0330</pubDate>
            </item>
                    <item>
                <title>چرا بسته بندی نرم‌افزار هنوز مهم است؟</title>
                <link>https://virgool.io/@mahdavikia/%DA%86%D8%B1%D8%A7-%D8%A8%D8%B3%D8%AA%D9%87-%D8%A8%D9%86%D8%AF%DB%8C-%D9%86%D8%B1%D9%85-%D8%A7%D9%81%D8%B2%D8%A7%D8%B1-%D9%87%D9%86%D9%88%D8%B2-%D9%85%D9%87%D9%85-%D8%A7%D8%B3%D8%AA-xxjm9gmisd0q</link>
                <description>باکس‌های جعبه‌ای نرم افزارها غالبا حاوی کتابچه‌ی راهنما، کاتالوگ،کارت فعالسازی، لوح فشرده،فلاپی(قدیم‌ترها) و یا فلش حاوی نرم افزار است که در مجموع پکیج فیزیکی نرم‌افزار را تشکیل می‌دهد و از آنجا که نرم افزار یک محصول غیرفیزیکی‌ست، ارزش آن را بعنوان یک کالا در بازار و پشت ویترین تثبیت می‌کند.با اینکه همه‌ی ما می‌دانیم امروزه نرم افزارها را می‌توان دانلود و فعالسازی کرد، اصرار شرکت‌های معتبر نرم افزاری به پکیج‌سازی فیزیکی نشان می‌دهد که مشتریان هنوز «لمس محصول خریداری شده» را به صرفا دانلود آن ترجیح می‌دهند، حتی اگر بدانند که چه چیزی خریده اند، دریافت و آنباکس جعبه‌ی رنگارنگ نرم افزار برایشان یک تجربه‌ی خوشایند است.</description>
                <category>محمد مهدوی کیا</category>
                <author>محمد مهدوی کیا</author>
                <pubDate>Wed, 12 Jul 2023 08:03:03 +0330</pubDate>
            </item>
                    <item>
                <title>اهمیت مستندسازی در توسعه نرم افزار</title>
                <link>https://virgool.io/@mahdavikia/%D8%A7%D9%87%D9%85%DB%8C%D8%AA-%D9%85%D8%B3%D8%AA%D9%86%D8%AF%D8%B3%D8%A7%D8%B2%DB%8C-%D8%AF%D8%B1-%D8%AA%D9%88%D8%B3%D8%B9%D9%87-%D9%86%D8%B1%D9%85-%D8%A7%D9%81%D8%B2%D8%A7%D8%B1-dkauxkm8uzts</link>
                <description>اهمیت مستندسازی در توسعه نرم افزارمستندسازی بخش بزرگی از روند تولید نرم افزار است که متاسفانه نادیده گرفته می‌شود. خوب است یادآوری کنم که در شرکت‌های مطرح نرم افزاری دنیا، مستندسازی جزو پرهزینه‌ترین واحد‌هاست.  روش کار به این صورت است که کارشناسان مستندسازی در جلسات متعدد و منظم با تیم توسعه، به تدریج اسناد لازم را که شامل مستندات تجربه کاربری، مستندات فنی و راهنمای کاربر است را تهیه، آرشیو و بروزرسانی می‌کنند. ما در ایران کمتر تولیدکننده‌ای می‌شناسیم که به طور جدی به این ردیف شغلی مهم توجه کند و شاید واقعا علت عمر پایین محصولاتی که تولید می‌کنیم همین باشد.  با این حال من بعنوان یک توسعه‌دهنده یک کار روزانه به مجموعه وظایفم به طور روتین اضافه کردم که حداقل بتوانم در یادآوری آنچه مثلا در شش ماه گذشته بعنوان کد نوشته ام کمکی کرده باشم. همچنین به تدریج می‌توان از دست نوشته های هر روز یک سندفنی معتبر از چیزی که تولید کرده‌ام ایجاد و به توسعه‌دهنده‌ی بعدی منتقل کنم.  سند سورس کد (Source code document)  یک سند سورس کد بخشی فنی است که تشریح می کند کدها چگونه کار می کنند. درحالی که ضروری نیست جنبه هایی که بیشترین پتانسیل سردرگمکی را دارند، پوشانده شوند. کاربران اصلی اسناد سورس کد مهندسین نرم افزار یا برنامه نویسان دیگر هستند. اسناد سورس کد ممکن است شامل موارد زیر باشند (توجه داشته باشید محدود به این موارد نمی شود): - چارچوب تولید، زبان و دیگر فریمورک های استفاده شده - نوع اتصال داده ها (data binding) - الگوهای طراحی با مثال (model-view-controller) - معیارهای امنیت - دیگر الگوها و اصول  به نظر من اگر در جایی کار می‌کنید که فعلا همکاری بعنوان کارشناسان مستندسازی در کنارتان نیستند، از همین امروز و به تدریج شروع به ایجاد مستندات فنی کنید.  * لینک زیر یک قالب نمونه بعنوان سندفنی نرم افزار ارائه کرده که می تواند سرنخ کاملی از یک مستند استاندارد باشد:https://readthedocs.org/projects/roboy-sw-documentation-template/downloads/pdf/lite/</description>
                <category>محمد مهدوی کیا</category>
                <author>محمد مهدوی کیا</author>
                <pubDate>Sun, 09 Jul 2023 08:34:19 +0330</pubDate>
            </item>
                    <item>
                <title>ماهیت توکن در JWT</title>
                <link>https://virgool.io/@mahdavikia/%D9%85%D8%A7%D9%87%DB%8C%D8%AA-%D8%AA%D9%88%DA%A9%D9%86-%D8%AF%D8%B1-jwt-pr9r3z2hjzvs</link>
                <description>اجزای تشکیل دهنده یک توکن در JWTدر مبحث طراحی سیستم‌های غیر مونولیتیک (Non-Monolithic) مبتنی بر سرویس و میکروسرویس، مساله‌ی توکن‌ها یک موضوع مهم و قابل تامل است. امروزه برای برقراری ارتباط امن بین سرور و کلاینت از توکن‌های JWT یا همان JSON Web Token استفاده می‌شود. در این روش با از بین بردن درگیری سشن و کوکی در موضوع authorization؛ عملیات لاگین، ریفرش توکن و درنهایت اجرای امن سرویس اتفاق می‌افتد.این نوع توکن که شامل اطلاعاتی از اصالت ارسال کننده‌ی درخواست از سمت کلاینت به سرور همراه با امضا می‌باشد، در هدرِ درخواست سرویس همراه با واژه‌ی Bearer ارسال می شود.لینک زیر معرفی کامل و عملی از این سیستم را در Laravel Lumen ارائه کرده است:https://www.laravelia.com/post/lumen-10-jwt-api-authentication-tutorial#google_vignette</description>
                <category>محمد مهدوی کیا</category>
                <author>محمد مهدوی کیا</author>
                <pubDate>Sun, 09 Jul 2023 08:31:41 +0330</pubDate>
            </item>
                    <item>
                <title>مستندسازی میکروسرویس ها با Microservice Canvas</title>
                <link>https://virgool.io/@mahdavikia/%D9%85%D8%B3%D8%AA%D9%86%D8%AF%D8%B3%D8%A7%D8%B2%DB%8C-%D9%85%DB%8C%DA%A9%D8%B1%D9%88%D8%B3%D8%B1%D9%88%DB%8C%D8%B3-%D9%87%D8%A7-%D8%A8%D8%A7-microservice-canvas-unciqahnei4x</link>
                <description>یک قالب نمونه استاندارد برای یک بوم میکروسرویسدر مبحث معماری بر مبنای میکروسرویس‌ها، مساله‌ی مستندسازی آن‌ها مطرح است. معمولا در شرکت‌های نرم افزاری جهت مستندسازی کلاس‌ها از کارت‌هایی تحت عنوان CRC که در توسعه‌ی شئی‌گرایی مورد استفاده قرار میگیرد استفاده می شود. در توسعه‌ی مبتنی بر میکروسرویس ما کارت هایی داریم که Microservice Canvas یا همان &quot;بوم میکروسرویس&quot; نام دارد. در این کارت‌ها تمام ویژگی‌های ممکن و عمومی یک میکروسرویس بعنوان سندی فنی از مجموع اسناد فنی پروژه عموما توسط توسعه دهنده‌گان تکمیل می‌شود تا بعدا توسط تیم مستندساز تبدیل به یک سندفنی معتبر برای محصول نهایی شود. معمولا در یک کارت استاندارد Microservice Canvas موارد زیر تکمیل می شود: نام سرویس، توضیحات،قابلیت ها،جزئیات API شامل تمام توابع کاربردی، کوئری‌ها و رویدادها، دامین بیزینس و مواردی از این دست.تکمیل کارت‌های Canvas به ازای هر سرویس در جریان توسعه ی هر میکروسرویس، روند مستندسازی محصول نهایی را بسیار سریعتر و دقیتر پیش خواهد برد.</description>
                <category>محمد مهدوی کیا</category>
                <author>محمد مهدوی کیا</author>
                <pubDate>Sun, 09 Jul 2023 08:22:28 +0330</pubDate>
            </item>
            </channel>
</rss>