https://virgool.io/feed/@easazade fa 2026-06-21 11:42:01 https://files.virgool.io/upload/users/23370/avatar/avatar.png?height=120&width=120 https://virgool.io/@easazade https://virgool.io/coderlife/%D8%AA%D8%B3%D8%AA-%DA%A9%D8%B1%D8%AF%D9%86-%DA%86%DB%8C%D8%B3%D8%AA-%DA%86%D8%B1%D8%A7-%D8%A8%D8%B1%D9%86%D8%A7%D9%85%D9%87-%D9%86%D9%88%DB%8C%D8%B3%DB%8C-%D8%B1%D8%A7-%D8%A2%D8%B3%D8%A7%D9%86-%D8%AA%D8%B1-%D9%85%DB%8C-%DA%A9%D9%86%D8%AF-ewkt7qevkxvr در این مقاله قدم به قدم بررسی خواهیم کرد که مزایای تست کردن به صورت اتوماتیک چیست؟ و چرا نوشتن تست برای برنامه مان باعث راحت تر شدن برنامه نویسی می شود ،چرا برنامه نویسان حرفه ای و با تجربه ترجیح می دهند برای برنامه شان تست بنویسند و چرا بعضی از برنامه نویسان این کار را نمی کنند تست به طور کل چرا برنامه را تست می کنیمکدی قابل اعتماد است که خطا ندهد و عملیاتی که از آن انتظار می رود را درست انجام دهد. اگر کدی که نوشتیم یک بار در برنامه مان اجرا شد به این معنا نیست که قابل اعتماد است.خب برای اعتماد پیدا کردن از کد خودمان چه کار کنیم؟ کافی است برنامه مان را اجرا کنیم تا همه حالت های مختلفی که مورد نظرمان است را مورد تست قرار بدهیم. و از درست اجرا شدن کدمان اطمینان حاصل کنیم کد ما ممکن است نسبت به وضعیت سیستم و وضعیت اپلیکیشن رفتارهای متفاوتی از خود نشان دهد و مثلاً توابع مختلفی را در هر وضعیت صدا کند. مهم آن است که از درست رفتار کردن کد مان در تمام حالت ها اطمینان حاصل کنیم تا مطمئن شویم که کدمان درست اجرا می شود. توجه کنید که کد ما باید همه عملیات های مورد انتظار ما را به صورت درست انجام دهد و هیچ خطایی ندهد در آن لحظه ما از کدمان می‌توانیم اطمینان حاصل کنیم. این روش تست کردن، تست کردن به صورت دستی نام دارد و بسیار زمان بر است.تست های اتوماتیک نیز تست هایی هستند که برنامه نویس به صورت برنامه می نویسد تا قادر باشد هر طور که می خواهد هر قسمت از برنامه را که می خواهد مورد تست قرار دهد. آن هم تنها با یک یونیت تست ( توضیح: هر یونیت تست تنها یک تابع است ). اگر بخواهیم به صورت ساده این مسئله را توضیح دهیم و خلاصه کنیم ، تست کردن به صورت دستی در مقایسه با تست کردن به صورت اتوماتیک مثل کندن پی یک ساختمان با کلنگ در مقایسه با یک بیل مکانیکی میباشد. در ادامه بیشتر به این مسئله خواهیم پرداخت و مشکلات و محدودیت هایی که تست دستی برای ما ایجاد می کند بررسی می کنیم مشکلات و محدودیتهای تست کردن به صورت غیر اتوماتیک یا دستیمشکل اول : زیاد بودن موارد مورد تست که باید تست شوندمعمولاً برنامه هایی که می نویسیم شامل اجزای بسیاری می شود. هر کدام از این اجزا مسئولیت های متفاوتی دارند و ممکن است بسته به شرایط هر کدام رفتارهای متفاوتی از خود نشان دهند. تست کردن اجزای برنامه مان به صورت دستی در تمام این حالت ها و وضعیت ها بسیار سخت و زمانبر خواهد شد در حالی که اگر برای برنامه مان تست بنویسیم می توانیم آنها را با یک کلیک به صورت اتوماتیک اجرا کنیم هر تست تنها در کسری از ثانیه انجام خواهد گرفت و در چند ثانیه می توانیم همه تست های مان را اجرا کنیم و همه اجزای برنامه مان را تست کنیم. البته در شرایطی که اپلیکیشن ما بسیار کوچک است احتمالاً موارد مورد تست هم بسیار کم خواهد بود اما به ندرت این مسئله پیش می آیدمشکل دوم : سخت بودن یا زمانبر بودن بازسازی مراحل قبل از رسیدن به مرحله تستخیلی اوقات پیش می آید برای اینکه در برنامه مان به مرحله‌ای برسیم که قسمت مورد نظر ما اجرا شود تا بتوانیم رفتار آن را تست کنیم ، باید مراحل زیادی را طی کنیم این عمل می‌تواند بسیار زمان‌بر باشد و رسیدن به این مرحله شاید بسیار سخت باشد. در چنین شرایطی هر بار اجرای این تست زمان بسیاری از ما میگیرد. حال فرض کنید همین قسمت برنامه در حال توسعه است و ما با یک خطا روبرو شده ایم و ما دستی این قسمت را تست می کنیم کدمان را تغییر میدهیم دوباره تست می‌کنیم تا نتایج را مشاهده کنیم و اینقدر این کار را تکرار می کنیم تا خطا را برطرف کنیم.این مسئله برای همه ما پیش آمده است که می تواند بسیار طاقت فرسا باشد. مخصوصاً در برنامه نویسی اندروید که حتی بیلد کردن و اجرای اپلیکیشن بر روی دستگاه زمان بر است. حال اگر برای این قسمت از برنامه به جای تست غیر اتوماتیک یک یونیت تست بنویسیم می توانیم با فشار دادن یک دکمه آن را به صورت اتوماتیک اجرا کنیم که در چند ثانیه اجرا خواهد شد و نتایج را به ما اطلاع خواهد دادمشکل سوم : زیاد بودن وضعیت های دستگاه یا برنامه مایک سیستم را که در حال نوشتن برنامه برای آن هستیم تصور کنید این سیستم می تواند وضعیت های متفاوتی داشته باشد. مثلاً وضعیتی که اتصال اینترنت قطع یا وصل باشد. کاربر در حال استفاده از هدفون باشد یا نه. علاوه بر این خود برنامه ما نیز می تواند دارای وضعیت های متفاوتی باشد. مثلاً کاربر لاگین باشد یا نباشد. خیلی اوقات وقتی در حال توسعه قسمتی از برنامه هستیم نیاز داریم که آن قسمت از کد برنامه مان را طوری توسعه دهیم که رفتار های متفاوتی نسبت به هر کدام از این وضعیت ها از خود نشان دهد. مثلا وقتی کاربر بر روی دکمه لاگین کلیک می کند اگر اینترنت قطع باشد پیام قطع بودن اینترنت نمایش داده شود در غیر اینصورت درخواست لاگین به سرور ارسال شود. تست کردن این قسمت از برنامه در تمام این حالت ها زمانبر و سخت است. سخت به این دلیل که بازسازی این وضعیت ها برای ما می تواند خود به تنهایی زمان‌بر باشد. اما اگر کدهای قابل تست نوشته باشیم به راحتی می‌توانیم با نوشتن چند یونیت تست کد مان را در تمام این وضعیت ها تست کنیم. با یک کلیک همه این تست ها را اجرا کنیم تا در چند ثانیه از درست اجرا شدن کد این قسمت از برنامه مان در تمام این وضعیت ها اطمینان حاصل کرده باشیممشکل چهارم : عدم تست پذیری به صورت دستیخیلی اوقات قسمت هایی از برنامه مان را نمی توانیم به صورت دستی تست کنیم. این مشکل معمولا مواقعی است که نیاز داریم از ابزاری مثل لاگر برای پرینت کردن در کنسول یا از ابزاری مثل دیباگر استفاده کنیم ، تا رفتار کد های نوشته شده در این قسمت از برنامه اطلاع حاصل کنیم. همه ما زمان های زیادی را سرفه دیباگ کردن برنامه مان با این ابزارها کرده‌ایم. دفعات بسیاری سعی کرده ایم تا با لاگ کردن یک آبجکت در کنسول متوجه شویم که این قسمت از کدمان چه رفتاری دارد و آیا نتایجی که ما می‌خواهیم را به ما می دهند یا نه یا در شرایط پیچیده تر از دیباگر استفاده می کنیم. که به ما این اجازه را می دهد که کد های مان را خط به خط بررسی بکنیم استفاده از این ابزارها در برخی مواقع می‌تواند زمانبر به و بسیار کسل کننده باشد. در حالی که با نوشتن یک یا چند یونیت تست می توانیم همه این تست ها را به صورت اتوماتیک در یک یا چند ثانیه انجام دهیم و از این همه هدر رفت وقت ، انرژی و خرد شدن اعصابمان جلوگیری کنیممشکل پنجم : هزینه زیاد برطرف کردن باگ بعد از انتشار برنامههزینه ای که باید برای برطرف کردن یک باگ بعد از انتشار برنامه بپردازیم می تواند به مراتب بیشتر از هزینه ای باشد که می توانیم برای برطرف کردن آن قبل از انتشار بپردازیم. یکی از دلایلی که در شرکت‌های حرفه‌ای اقدام به تست برنامه به صورت اتوماتیک می کنند یا در این زمینه سرمایه گذاری می کنند همین مسئله می باشد ، صرفه جویی در هزینه ها. در تحقیقات انجام شده توسط لینکدین، این آمار به دست آمد که هزینه ای که برای برطرف کردن یک باگ بعد از انتشار اپلیکیشن می شود می تواند ۴ تا ۵ بار بیشتر از آن هزینه برای برطرف کردن همان باگ قبل از انتشار باشد. علاوه بر هزینه های مالی هزینه های دیگری نیز می تواند وجود داشته باشد. مثل از دست دادن کاربران برنامه، خطشه دار شدن اعتبار برنامه نویس یا شرکت ، عدم رضایت مشتریان و …مشکل ششم : طولانی شدن زمان توسعهیکی از توجیه هایی که برنامه نویسان برای فرار از نوشتن تست برای برنامه شان به کار می‌برند ، این است که زمان توسعه برنامه افزایش پیدا میکند این توجیه شاید ساده لوحانه باشد. زیرا که این برنامه نویسان فقط زمان نوشتن کدهای بیشتر که تست ها میباشند را در نظر میگیرند ، اما زمان هایی را که با عدم نوشتن این تست ها از دست می‌دهند را اصلاً در نظر نمی‌گیرند مثل زمان هدر رفت در ریفکتور کردن (refactoring) های الکی به خاطر اینکه کدمان را درست و در همه حالت ها تست نکرده ایم و بر مبنای این کد تست نشده به سراغ توسعه قسمت های دیگر از برنامه می‌رویم و آن قسمت ها را برمبنای کدهای تست نشده قبلی‌مان توسعه می دهیم.هیچ تضمینی وجود ندارد که ما چه زمانی همه تست های دستی را انجام دهیم تا از این مشکلات که وجود داشتند باخبر شویم در این قسمت متوجه می شویم که دوباره نیاز به ریفکتور کردن برنامه داریم و این چرخه همینطور ادامه دارد. این مسئله می‌توانست به سادگی با نوشتن همان تست ها به صورت یونیت تست و اجرای همه آن ها با یک کلیک به صورت اتوماتیک جلوگیری شود. مسلماً کسی که در نوشتن این تست ها تنبل است بعد از توسعه دادن یکی از قسمتهای برنامه نیز تصمیم نمی‌گیرد که تمام قسمت های دیگر برنامه را که به این قسمت نیز وابسته هستند آن هم در تمام حالت ها تست کند. این رفتار غلط در بسیاری از این برنامه نویسان وجود دارد. و راه حل این مشکل نوشتن تست هایی که به صورت دستی انجام می دهیم به صورت یونیت تست و اجرای اتوماتیک آنها است.یکی دیگر از مسائلی که برنامه نویسانی که از نوشتن تست برای برنامه شان فرار می کنند در نظر نمی‌گیرند ، صرف انرژی است که در دیباگ کردن و ریفکتور کردن های بی مورد از دست می دهند. این مسئله برای بسیاری از ما پیش آمده است همان زمان هایی که مدام صرف دیباگ کردن برنامه می‌کنیم. همه ما از این مشکل خسته می شویم و اعصابمان خرد می شود. اگر یک دلیل وجود داشته باشد که یک برنامه نویس بخواهد برای برنامه ای که توسعه می دهد یونیت تست بنویسد این بهترین دلیل استموارد بالا ضعف های تست کردن دستی را بیان می کنند اما مشکل وقتی خود را واقعاً نشان می دهد که ما در توسعه برنامه نیاز پیدا می کنیم بارها و بارها این تستها را تکرار کنیم در چنین شرایطی نیاز به تست کردن اجرای این تست ها به صورت اتوماتیک بسیار احساس می شود (توجه کنید که تکرار تست کردن قسمت‌های مختلف برنامه کاری کاملاً طبیعی است حتی قسمتی که مدتها پیش نوشته شده است و تست هم شده است).در زیر به مواردی که باعث می شود که ما نیاز داشته باشیم که همه تست هایی که قبلا برای برنامه مان انجام داده ایم را ، دوباره انجام دهیم ذکر می کنیم توجه کنید که تاکید می کنیم که اجرای دوباره تست ها عملی منطقی است و یکی از نیازهای توسعه برنامه میباشدمواردی که باعث میشود تا همه تست های انجام شده قبلی را ، دوباره انجام دهیممورد اول : تغییر دادن قسمت مورد نظر در برنامه مانفرض کنید قسمتی از برنامه مان را نوشتیم تکمیل کردیم و تست(دستی) هم کردیم. ولی مدتی بعد به هر دلیلی نیاز داریم که این قسمت را تغییر بدهیم یا چیزی به آن اضافه کنیم یا کم کنیم. حالا این قسمت دیگر آن قسمت قبلی نیست چون کد های نوشته شده ما دیگر آن کدهای قبلی نیستند. پس دوباره نیاز به تست کردن دارد. بسیاری از برنامه نویسانی که از تست نوشتن فرار می‌کنند با خود می‌گویند که فقط چند خط را تغییر دادند و حتما کدشان مانند قبل کار خواهد کرد و حتی تست دستی را هم انجام نمی دهد. ولی همه ما خوب می‌دانیم حذف یا اضافه ی حتی یک خط می تواند مشکلات زیادی را در برنامه‌مان به بار آوردمورد دوم : تغییر یکی از وابستگی ها مربوط به قسمت مورد نظر مابرنامه ما از اجزای متفاوتی تشکیل شده اند شده است و این اجزا در تعامل با یکدیگر کار می کنند تا برنامه ما اجرا شود این اجزا هرکدام ممکن است بر چند جزء دیگر وابسته باشند. تغییر یکی از این وابستگی ها بر قسمت مورد نظر برنامه ما تاثیر می گذارد. فرض کنید برنامه شما دارای یک لوکال دیتابیس می باشد مسلما قسمت های مختلف برنامه شما بر این دیتابیس وابسته می باشند چون از آن استفاده می کنند. آیا شما با انجام یک تغییر در دیتابیس تک تک قسمت هایی که از دیتابیس استفاده می کنند را در تمام حالت ها مورد تست دستی قرار می دهید؟ مسلما نه. برنامه نویسی که از یونیت تست هم فرار می‌کند این کار را نیز انجام نمی دهد. اصلا هیچ برنامه نویسی این کار را انجام نمی‌دهد راه حل این است که هر تست را به صورت یونیت تست در آورده تا هر زمان که میخواهیم با یک کلیک همه را اجرا کنیم تا اگر تغییر در یک بخش باعث شد که بخش های وابسته به آن درست اجرا نشوند یا باعث خطا در آنها شد خیلی سریع مطلع شویم.برای رهایی از مشکلات ذکر شده چه گزینه هایی داریمراه حل اول : بی توجهی به مشکلات و تظاهر به عدم وجود آنها نکنیمخیلی اوقات ما برنامه‌نویسان می‌دانیم که نیاز داریم چیزی را یاد بگیریم و یا کاری را انجام دهیم یا اینکه روش برنامه نویسی جدیدی به کار گیریم. ولی سختی یادگیری و تنبلی باعث می شود که این کار را پشت گوش بیاندازیم. گاهی با دلایل مختلف توجیه میکنیم که این ها مشکلات نیستند و طبیعی هستند و می گوییم یاد گرفتن و استفاده از روشی پیشرفته‌تر برای برنامه نویسی باعث مشکلات بیشتری می شود مثلاً یکی از توجیه های معمول این است که زمان بیشتری برای نوشتن برنامه نیاز خواهد یود که با توجه به مواردی که قبلا اشاره کردیم مشخص شد که این توجیه کاملاً غلط است از همین رو بسیاری از ما تصمیم می گیریم که به جای تمام حل این مشکلات، آنها در کمدی بزرگ قرار دهیم و در کمد را قفل کنیم و تظاهر کنیم که این مشکلات اصلا وجود ندارند.راه حل دوم : فرار از تست کردن را کنار بگذاریمبسیاری از برنامه نویسانی که برای برنامه شان یونیت تست نمی‌نویسند از اجرای تست به صورت دستی نیز خودداری می‌کند منطقی است که وقتی یک قسمت از برنامه را توسعه دادیم یا تغییر دادیم قسمت های دیگری را که وابسته به این قسمت جدید هستند نیز دوباره تست کنیم مطمئناً هیچ برنامه نویسی وقتی یک قسمت را توسعه می‌دهد تمام قسمت های قبلی را که توسعه داده است به خاطر قسمت جدید دوباره به صورت دستی تست نمیکند. از این رو بسیاری از این برنامه نویسان با دلایلی نظیر اینکه بعدا تست میکنیم، در انتهای کار تست میکنیم، هر وقت به مشکل خورد آن موقع مشکل را برطرف می‌کنیم و از همه بدتر این توجیه که مطمئناً کار می کند نیازی به تست نیست از تست کردن فرار می کنند.راه حل چهارم : قبول مشکلات بیان شده و حل این مشکلات با استفاده از تست کردن به صورت اتوماتیکوقتی همه موارد ذکر شده را که باعث طولانی تر شدن توسعه پروژه شما می شود باعث سردرگم شدن شما در توسعه برنامه می‌شود و یا از همه بدتر مجبور هستید که مدام تستهای دستی را تکرار کنید قبول کردید. و نه تنها قبول کردید بلکه به عنوان یک مشکل در توسعه برنامه قبول کردید آنگاه وقت آن است که از مرحله بی‌توجهی به مشکل و فرار از حل مشکل گذشته و به پیدا کردن یک راه حل فکر کنید. خب این راه حل قبلا ارائه شده و بسیاری از برنامه نویسان دیگر هم از آن استفاده می کنند و آن تست کردن برنامه به صورت اتوماتیک می باشد.مزایای دیگر تست کردن علاوه بر حل مشکلات تست دستی چیستوقتی برای برنامه‌تان تست می‌نویسید هر زمان که یک قسمت از برنامه را توسعه داده اید می توانید سریع تست ها را اجرا کنید تا ببینید که کدی که نوشتید در چه حالت هایی مطابق میل شما عمل نمی کند یا خطا می دهد و به سرعت مشکل را پیدا خواهید کرد. علاوه بر این شما می توانید با یک کلیک همه یونیت تستها را اجرا کرده و از این طریق اگر قسمت جدیدی که توسعه داده اید باعث شود دیگر قسمت های برنامه تان که به آن قسمت جدید وابسته می‌باشد خطا بدهند ، مطلع شوید. بدون وجود این تستها چطور از خطاهایی که جدیداً برایتان پیش آمده مطلع میشوید؟ مسلماً هیچ برنامه نویسی بعد از اضافه کردن چند خط کد تصمیم نمی‌گیرد که تک تک قسمت های برنامه را دوباره به صورت دستی تست کند. حتی فکر این کار هم عذاب آور و شکنجه آور است.مزیت دیگر اینکه با خواندن تست های برنامه میتوان رفتار برنامه را تشخیص داد. به این صورت که هر تست یکی از رفتارهای برنامه مان را مشخص میکند. به عبارت دیگر یونیت تست هایی که برای کد های مان می نویسیم مانند یک داکیومنت عمل می کنند.خب حال یک مثال را بیان می‌کنیم. فرض کنید قسمت A از برنامه شما به قسمت های زیادی وابسته است و برای تست کردن قسمت A به طور کامل به صورت دستی نیاز به زمان زیادی داریم. قسمت A را از قبل توسعه دادید و الان در حال کار کردن بر روی قسمت های دیگر هستید. فرض کنید هر چند روز یک بار کد های جدیدی که به برنامه‌ اضافه می‌شود باعث می شود قسمت A با خطای جدیدی روبرو شود زیرا همانطور که بیان کردیم قسمت A به قسمت های بسیاری وابسته است و تغییر هر کدام از این قسمت ها باعث می شود که قسمت A رفتارش تغییر کند و در برخی موارد با خطا همراه باشد.در چنین شرایطی شما هر چند روز یک بار مجبور هستید که دست از کار فعلی خود بکشید و همه تست های قسمت A را اجرا کنید تا خطای مورد نظر را رفع کنید. مهمتر اینکه می دانیم باز هم مجبور هستید این کار را انجام دهید یا اینکه کلا قسمت A را دست نخورده باقی بگذارید تا توسعه تمام قسمت های دیگر تمام شود و بعد دوباره برگردیم سراغ رفع خطا های قسمت A اما به همین سادگی نیست چون برنامه شما از اجزای مختلفی تشکیل شده است و در بسیاری از موارد به یکدیگر وابسته هستند به مثال ساده تر برنامه شما قسمت های بسیاری مانند قسمت A مثال زده شده دارد. فقط تست کردن به صورت اتوماتیک است که از مشکل به محض بوجود آمدنش اطلاع پیدا می کنید که از این همه دردسر جلوگیری می کند.در پایان آیا واقعا هنوز حاضر هستید به این روش غلط برنامه‌نویسی کنید و مدام تستهای دستی را تکرار کنید هر روز وقت زیادی را صرف وصل کردن دیباگر به برنامه و بررسی تک تک خط های کدی که نوشتید بکنید؟ یا نه بلکه تصمیم گرفتید که هر تست را فقط یک بار برای کامپیوتر توضیح دهید، تا خودش در کسری از ثانیه آنرا انجام دهد. اگر دومین گزینه را انتخاب کرده اید منتظر مطلب بعدی باشید که توضیح خواهیم داد که چطور برنامه ای بنویسیم که قابل تست باشد و چطور برای قسمت های مختلف برنامه مان تست بنویسیم. alireza easazade alireza easazade Sun, 27 Jan 2019 14:41:02 +0330 https://virgool.io/@easazade/%D9%BE%D9%86%D8%AC-%D8%AA%D9%81%DA%A9%D8%B1-%D8%BA%D9%84%D8%B7-%D8%AF%D8%B1-%D9%85%D9%88%D8%B1%D8%AF-%D8%A8%D8%B1%D9%86%D8%A7%D9%85%D9%87-%D9%86%D9%88%DB%8C%D8%B3%DB%8C-fhhetdv30ifg همه برنامه نویسان با افکار ها  و برداشت های اشتباه اطرافیان در مورد برنامه نویسی و برنامه نویس ها مواجه می شوند.برخی اوقات این برداشت ها خنده دار و برخی اوقات هم آزار دهنده است. در پایین به بررسی رایج ترین این تفکر ها می پردازیم برنامه نویسی برنامه نویسی آسان استاگر برنامه نویس هستید حتما این جمله را شنیده اید. ممکن است از یکی از اقوامتان که کلا فکر می کند در همه مهارت ها استعداد دارد یا یکی از دوستانتان که در یکی از رشته های مهندسی، مدرک دانشگاهی دهن پر کنی دارد و چند واحدی هم برنامه نویسی در دانشگاه پاس کرده است شنیده باشید. در هر صورت آرامش خود را حفظ کنید شما در چنین مواردی تنها نیستید. به یاد داشته باشید که هر شغلی سختی های خودش را دارد و همیشه عده ای هستند که بدون کار کردن در حرفه های مختلف در مورد هر کدام از آنها نظر می دهند.تفکر درست : برای اظهار نظر در مورد هر شغلی باید تجربه آن را داشت. همچنین تسلط کار کردن با cli ها و اسکریپت نویسی کسی را برنامه نویس نمی کند. برای مثال یک مهندس الکترونیک که به زبان C یا python تسلط دارد یک برنامه نویس نیست یا یک متخصص هک و امنیت شبکه لزوما نمی تواند یک برنامه نویس باشد. برنامه نویسی سخت استدر کنار آدم هایی که باور دارند برنامه نویسی کار آسانی است، عده کثیری باور دارند برنامه نویسی کار سختی است. البته نه از نگاهی که یک برنامه نویس کارش را سخت می بیند. بسیاری از مردم فکر می کنند که برای برنامه نویسی کردن باید دانش قوی از ریاضی داشته باشیم و معمولا باید با معادلات پیچیده ریاضی دست و پنجه نرم کنیم. گرچه تفکر حل مسئله برای حل مسائل برنامه نویسی نیاز برنامه نویس است اما این مسائل ندرتا از نوع ریاضی هستند. یا عده ای این تفکر را دارند که برای برنامه نویس شدن باید حتما تحصیلات دانشگاهی داشت یا اینکه در یکی از دروره های آموزش برنامه نویسی آموزشگاه های معتبر ثبت نام کرد. که هر دو بدون کوچکترین اغراقی تفکری کاملا غلط هستند. به شرط اینکه مهارت شما در زبان انگلیسی خوب باشد شما می توانید برنامه نویس حرفه ای شوید، تنها ابزاری که نیاز دارید یک کامپیوتر و یک خط اینترنت است. ( و البته در ایران فیلتر شکن خوب هم نیاز است)تفکر درست : سختی یک امر نسبی است و وقتی کاری را یاد بگیریم به مرور از سختی انجام آن کاسته می شود اما آن چیزی که برنامه نویسی را از دیگر حرفه ها متمایز می کند این است که برنامه نویس همیشه نیاز به یادگیری دارد و یادگیری بخشی از برنامه نویسی است برنامه نویسی چیست؟معمولا این سوال را بعد از اینکه از شما در مورد شغلتان سوال می کنند می پرسند. گرچه نمی توان این مورد را یک تفکر غلط گفت چون معمولا کسی که این سوال را می پرسد هیچ فکری در مورد برنامه نویسی نمی کند که بخواهد غلط باشد. اما خیلی زود بعد از اینکه به آنها توضیح دادید برنامه نویسی چیست، می توانید نظرات تخصصی آنها را در مورد اینکه برنامه نویسی چقدر آسان یا سخت است را گوش کنید.تفکر درست : برنامه نویسی ، برنامه نویسی است برنامه نویس حرفه ای کسی است که همه دستورات را حفظ باشداحتمالا این تفکر از آن دسته است که زیاد نمی شنوید اما معمولا اکثر کسانی که برنامه نویس نیستند اما اطلاعات مختصری از برنامه نویسی دارند اینطور فکر می کنند که در برنامه نویسی برای هر کاری یک دستور ساخته شده است و برنامه نویس حرفه ای کسی است که این دستورات را کاملا از بر است و در چند ثانیه می تواند هر قسمت از برنامه را تکمیل کند و در غیر این صورت برنامه نویس آماتور است و این تصور را دارند که یاد گیری برنامه نویسی فقط شامل حفظ کردن و شناختن این دستورات است. البته این تفکری است که معمولا تازه وارد های برنامه نویسی هم دارند تا اینکه خیلی زود متوجه می شوند که بهترین زمان یادگیری زمانی است که احساس نیاز روش یا ابزاری جدید می کنیدتفکر درست : یادگیری برنامه نویسی هیچ وقت تمام نمی شود و بخشی از این حرفه است پس حفظ کردن همه دستورات دیوانگی است. آن چیزی که نیاز دارید بدانید این است که هر ابزار ، تکنولوژی ،روش ، معماری ، لایبرری و یا سرویسی که دیگر برنامه نویسان از آن استفاده می کنند برای چه هدفی طراحی و ساخته شده و چه مشکلی را حل می کند. سپس هر زمان با هر مشکلی مواجه شدید، می دانید که باید از کدام ابزار برای حل این مشکل استفاده کرد و اگر بلد نیستید آن وقت بهترین موقع برای یاد گیری است می توان با یک پکیج آموزشی برنامه نویس شدکم نیستند کسانی که به تازگی یک پکیج آموزش برنامه نویسی را به اتمام رسانده اند و یا در یکی از دوره های یادگیری برنامه نویسی برخی آموزشگاه های معتبر شرکت کرده اند و انتظار دارند که با دانش ابتدایی شان کار های بزرگ انجام دهند. این افراد معمولا در شروع پروژه هایی فراتر از توانشان انتخاب می کنند و هیچ احساس نیازی به یادگیری مباحث پیشرفته نمی کنند، قادر به تشخیص مشکلاتی که در توسعه برنامه با آن ها مواجه می شوند نیستند(منظور bug نیست) و در نتیجه این مشکلات تا پایان توسعه برنامه حل نشده باقی می مانند. دلیل وجود چنین تفکر غلطی امکان دارد تبلیغات غلطی باشند که با اهداف مختلف سعی می کنند برنامه نویسی را حرفه ای بی زحمت و بی دردسر جلوه دهندتفکر درست : بهترین پکیج های آموزشی هم نمی توانند کسی را تبدیل به برنامه نویس کنند بلکه فقط می توانند به شما آموزش دهند. یادگیری تکنولوژی های مختلف از شما برنامه نویس نمی سازد تنها کسی که می تواند از شما برنامه نویس بسازد شما و علاقه تان به برنامه نویسی است. alireza easazade alireza easazade Sun, 27 Jan 2019 14:33:13 +0330 https://virgool.io/@easazade/%DA%AF%D8%B1%DB%8C%D8%AF%D9%84gradle-%DA%86%DB%8C%D8%B3%D8%AA-%D9%88-%D9%88%D8%B8%DB%8C%D9%81%D9%87-%D8%A2%D9%86-%D8%AF%D8%B1-%D8%A7%D9%86%D8%AF%D8%B1%D9%88%DB%8C%D8%AF-%D8%A7%D8%B3%D8%AA%D9%88%D8%AF%DB%8C%D9%88-%DA%86%DB%8C%D8%B3%D8%AA-svx7bkodqxhy در این مطلب به بررسی gradle که build system به کار رفته در اندروید استودیو می باشد می پردازیم. گریدل چیست هدف آن چیست و چه مشکلاتی را حل می کند به علاوه مشکلات و خطا های رایج و برخی نکات مهم مربوط به آن را بررسی می کنیم. gradleگریدل (gradle) چیست؟گریدل یک build automation system (سیستم ساخت خودکار) است. اپلیکیشن های امروزی برای مثال یک اپلیکیشن اندروید از نظر ساختاری به سادگی اپلیکیشن های پانزده سال پیش نیستند. در گذشته کد های برنامه توسط برنامه نویس نوشته می شد و پس از کامپایل شدن اجرا می شد. اما امروزه یک برنامه نویس قبل از اجرای برنامه نیاز به انجام عملیات متنوع و متعددی برای ساخت فایل های اجرایی برنامه نظیر یک فایل apk یا exe دارد. برای مثال بررسی خطا های نوشتاری برنامه قبل از کامپایل، قرار گرفتن فایل های media برنامه نظیر فایل های عکس، ویدئو، صوت و … هر کدام به مسیر از پیش تعیین شده انتقال داده شوند. مجموعه ای از کد ها به صورت خودکار و پویا با توجه به کد های نوشته شده توسط برنامه نویس ساخته شوند و در کنار کد های برنامه نویس قرار بگیرند. تست های نوشته شده توسط برنامه نویس اجرا شود و نتیجه آن اعلام شود. در آخر همه فایل های مورد نیاز به همراه کد های کامپایل شده برنامه درون یک فایل zip قرار گرفته و پسوند فایل به apk تغییر کند. بعد از همه این عملیات و ساخته شدن فایل خروجی حالا می توان آن را نصب کرد. نکته مهم و قابل توجه این است که برنامه نویس پس از هر بار تغییر در برنامه برای اجرای مجدد باید این عملیات را تکرار کند. به این عملیات عملیات ساخت گفته می شود. زیاد بودن، زمان بر بودن، پیچیدگی و تنوع مراحل ساخت باعث شده است که برنامه نویسان دست به ساخت سیستم های ساخت اتوماتیک نظیر gradle بزنند.ما روزانه ده ها بار برنامه خود را اجرا می کنیم تا نتایج تغییراتی را که اعمال کرده ایم مشاهده کنیم. مسلما اگر بخواهیم همه این عملیات را خودمان به صورت دستی انجام دهیم وقت بسیار زیادی از ما تلف خواهد شد. پس به صرفه است که از یک build system استفاده کنیم. سیستمی که کافی است تا برای آن لیستی از وظایف را تعیین کنیم تا به صورت خودکار آن وظایف را انجام دهد. نظیر gradlegradle وظایف gradle در اندروید استودیوشاید یک مثال ساده برای درک اهمیت gradle در اندروید استودیو کافی باشد. یکی از وظایفی که بر عهده gradle می باشد code generation است. code generation یعنی کد های شما توسط یکی از task های gradle خوانده می شود و سپس کد هایی جدیدی تولید می شوند که در کنار کد های شما اجرا می شوند. برای مثال کلاس R در اندروید توسط gradle ساخته می شود. هر بار که یک id به عناصر یکی از layout هایمان اضافه می کنیم این id باید در کلاس R  اضافه شود تا از کلاس اکتیویتی مان قادر به پیدا کردن عناصر درون layout مان باشیم. مطمئنا اضافه کردن id ها به کلاس R به صورتی دستی توسط برنامه نویس بسیار وقت گیر است و احتمال بروز اشتباهات زیادی توسط برنامه نویس وجود دارد.از مثال های دیگر می توان به پوشه بندی مجدد resource ها، اجرای lint check، اجرای خودکار تست ها، dependency management، مدیریت flavour ها و buildType ها، ساخت فایل های apk و بسیاری موراد دیگر اشاره کردگریدل (gradle) تنها مختص اندروید استودیو نیست گرچه بیشتر کاربران Gradle توسعه دهنده اندروید هستند ولی از گریدل می توان به عنوان build system در انواع پروژه های php، java ،kotlin ، سی شارپ ، سی پلاس پلاس ، Groovy و حتی java-script استفاده کرد. گرچه برای جاوا اسکریپت سیستم های ساخت مختص آن نظیر web-pack توصیه می شود. گریدل (gradle) یک CLI هست اگر یک برنامه  نویس هستید پس حتما با ابزار های خط فرمان (command line interface) زیادی کار کرده اید. نظیر git ، npm ، composer و یا یکی از هزاران موارد موجود از ابزار ها یا پکیج های قابل دسترس از خط فرمان. اما چیزی که مهم است بدانید این است که gradle نیز یک cli هست و شما به راحتی می توانید از command line با آن کار کرده گرچه برای اکثر موارد مورد نیاز شما در اندروید استودیو رابط های کاربری تعریف شده است، اما از طریق command line شما می توانید هر command را که می خواهید اجرا کنید. نصب gradle برای توسعه اندرویداگر یک اندروید دولوپر هستید نیازی به نگرانی برای نصب دانلود یا نصب دستی gradle ندارید. هر زمان که نسخه مورد استفاده از gradle در کامپیوتر شما موجود نباشد android studio در صورت نیاز نسخه مورد نظر شما را دانلود و نصب می کند. مدیریت وابستگی ها (dependency management) چیست؟یکی از بزرگترین کار هایی که gradle انجام می دهد مدیریت وابستگی(لایبرری) هاست. تقریبا همه اپلیکیشن هایی که می سازیم علاوه بر لایبرری های استاندارد اندروید که در SDK موجود اند و لایبرری های استاندارد جاوا که در JDK موجود اند، از لایبرری های دیگری نیز استفاده می کنیم که آنها را تنها با اضافه کردن یک خط در فایل build.gradle پروژه مان در قسمت dependencies به پروژه مان اضافه می کنیم. به این لایبرری ها اصطلاحا third-party-library نیز گفته می شود. ما می توانیم این کار را به صورت دستی نیز انجام دهیم یعنی به سرور های مورد نظر نظیر maven مراجعه کرده، فایل jar را سرچ کرده، پیدا کنیم درون پروژه مان قرار دهیم و سپس دوباره پروژه را build کنیم. مسلما انجام این کار زمانبر است. علاوه بر این در صورت استفاده از gradle اگر نسخه جدیدی از لایبرری مورد نظر ارائه شود gradle از طریق اعلان های lint به ما اطلاع می دهد. تداخل وابستگی ها (dependency conflict) چیست؟یکی از مشکلاتی که با بزرگ شدن اپلیکیشن می تواند بروز کند، dependency conflict (تداخل وابستگی) است. به طوری که دو یا چند مورد از وابستگی (لایبرری) های پروژه ما خودشان وابسته به یک لایبرری اما از نسخه های متفاوت باشند. که به زبان ساده تر باعث می شود که دو نسخه متفاوت از یک لایبرری در اپلیکیشن ما وجود داشته باشد.در صورتی که تغییرات موجود در این دو نسخه متفاوت با هم اختلاف داشته باشند در پروژه ما مشکلی به اسم dependency conflict به وجود می آید. وجود این تداخل در اپلیکیشن ما باعث بروز خطا هایی غیر قابل پیش بینی از نوع compile-time و یا run-time می شود. تشخیص و حل این تداخل ها بدون ابزاری قدرتمند مثل gradle بسیار طاقت فرسا و زمانبر است. اما وقتی از gradle استفاده می کنیم این مشکل توسط اعلان های lint به ما گزارش می شود. چگونگی حل این مشکلات خارج از موضوع این پست می باشد که در پستی دیگر به توضیح آن خواهیم پرداخت گریدل (gradle) از چه زبانی استفاده می کند؟گریدل با زبان java توسعه داده شده است. و پلاگین های نوسته شده برای این build system نیز به همین زبان می باشند. اما از آنجا که گریدل فقط برای توسعه دهندگان جاوا توسعه داده نشده است. به همین دلیل تیم گریدل تصمیم گرفت تا syntax مورد استفاده در فایل build.gradle را جوری طراحی کند تا به برنامه نویسان زبان های دیگر نیز به راحتی از gradle استفاده کنند. از این رو گریدل از یک dsl بر پایه زبان Groovy استفاده می کند. برخلاف جاوا زبان هایی مثل groovy یا kotlin قابلیت توسعه dsl را دارند. یک dsl به زبان ساده یک زبان تعریف شده در یک زبان دیگر است که فقط در محدوده ای خاص عمل می کند. در مورد DSL تا این حد بدانید که هدف آن افزایش خوانایی و فهم بهتر کد های نوشته شده توسط یک لایبرری است. گریدل (gradle) به صورت پیش فرض از یک  DSL مخفف (domain specific language) بر پایه Groovy استفاده می کند. البته این DSL صرفا برای افزایش خوانایی کد های شما می باشد. و شما میتوانید همه کد های فایل های build.gradle را به زبان Groovy بنویسید لازم به ذکر است که به تازگی گریدل kotlin-dsl را معرفی کرده است که جایگزین groovy-dsl خواهد شد.Taskتسک ها (Tasks)به توضیح ساده هر task شامل دستوراتی می باشد که عملیات خاصی که مربوط به ساخت برنامه می باشد را انجام می دهد. مثل clean که یک task می باشد که در فایل build.gradle پروژه root شما تعریف شده است.در واقع هر زمان که شما در اندروید استودیو از منوی build روی گزینه clean کلیک می کنید این task را اجرا می کنید. وظیفه این task در واقع پاک کردن خروجی های ساخته شده که شامل فایل های apk ساخته شده می شود، می باشد. بقیه task ها نیز توسط پلاگین ها به بیلد شما اضافه می شوند. مثل پلاگین android که شامل task هایی برای ساخت و توسعه اپلیکیشن های اندرویدی است. علاوه بر پلاگین ها شما می توانید task های خودتان را بسازید، که هر کدام وظایفی را که شما برای آنها تعریف می کنید اجرا می کنند.اگر پنل Gradle در Android Studio را باز کنید لیستی از همه task های موجود در پروژه تان خواهید دید که با کلیک کردن بر روی هر  کدام می توانید آنها را اجرا کنید. task ها می توانند بر یکدیگر وابسته باشند در این صورت برای اجرای یک task ابتدا تمام task های دیگری که بر آنها وابسته می باشد به صورت خودکار اجرا می شوند تا task مورد نظر ما اجرا شود. از اندروید استودیو نسخه سه به بعد پنلی به نام build اضافه شده است که در هنگام اجرای هر task یک نمایش درختی از اجرای این task و تمام task های وابسته آن نمایش می دهد.پلاگین ها (Plugins)پلاگین ها چیزی نیستند جز چمدانی از task ها. مثلا پلاگین android شامل task هایی برای توسعه ، ساخت ، دیباگ و تست اپلیکیشن های اندرویدی می باشد. مشکلات کار با gradleاز جمله مشکلات کار با gradle می توان به سرعت بسیار پایین آن اشاره کرد. build هایی که از یک ثانیه شروع می شوند و بعضا ممکن است تا بیست دقیقه هم به طول بیانجامند. این مشکل مخصوصا در دیباگ کردن اپلیکیشن بسیار آزار دهنده خواهد بود چون شما  نیاز دارید که برنامه را بار ها اجرا کنید تا نتیجه تغییرات خود را ببینید. از کجا بیشتر یاد بگیریمآموزش های بسیاری در اینترنت وجود دارند اما جامع ترین آنها داکیومنت ها و مثال های ارائه شده در وبسایت gradle.org می باشند، که با مطالعه آن قادر خواهید بود درک عمیقی از کارکرد gradle ، ساخت task ها و plugin ها پیدا کنید.اگر این مقاله برای شما مفید بود یا می خواهید بیشتر در مورد گریدل بدانیدلطفا با نظر دادن به اطلاع دهید alireza easazade alireza easazade Sun, 27 Jan 2019 14:17:44 +0330