برنامه نویسی چیست؟

*KhatKhati* · 18/9/20

نود و هفت چیزی که هر برنامه‌نویسی باید بداند: کدنویسی تمیز و اصولی یک باید است

وقتی دولوپری به تنهایی کد می‌زند، وی تفسیری شخصی از مسألهٔ پیش‌رو خواهد داشت و بالتبع هم راه‌کاری که اتخاذ می‌کند کاملاً شخصی خواهد بود. جالب است بدانیم گرچه برخی دیگر دولوپرها در یک تیم کار می‌کنند، اما باز هم ممکن است راه‌کارهایی که به کار می‌گیرند تکی و کاملاً شخصی باشند غافل از اینکه کدی که می‌نویسند، روزی می‌بایست توسط دیگر دولوپرها دیباگ شود، توسعه داده شود و یا نگهداری گردد.

آنچه در مورد توسعهٔ نرم‌افزار امروزه خیلی مورد توجه نمی‌گیرد این است که برخی کدنویسی را صرفاً یک مهارت فنی تلقی می‌کنند اما این در حالی است که توسعهٔ نرم‌افزار ترکیبی از مهارت‌های فنی + مهارت‌های اجتماعی و ارتباطی است!

زمانی که ما در یک تیم نرم‌افزاری کد می‌زنیم، بایستی توجه داشته باشیم که کیفیت کد ما می‌تواند کیفیت کد سایر دولوپرها را نیز تحت تأثیر خود قرار دهد. به عبارت دیگر، اگر یکی از اعضای تیم توسعه به کار با کیفیت اعتقاد نداشته باشد و یا آن‌طور که باید و شاید حرفه‌ای نباشد، این عدم مهارت وی می‌تواند سطح کدنویسی دیگر اعضای تیم را هم پایین بکشاند و این در حالی است که تأثیرات منفی این قضیه کل تیم را تحت‌الشعاع خود قرار خواهد داد.

در واقع، وقتی که ما تمیز کدنویسی کنیم، سورس‌کدی که از ما به دیگر همکارانمان به ارث می‌رسد منجر به این خواهد گشت که ایشان هم با همان فرمان پروژه را ادامه دهند و این بدان معنا است که اگر ما خشت اول را درست بنا نهیم، این فرهنگ در میان تک‌تک اعضای تیم شکل خواهد گرفت که به کار باکیفیت، کدنویسی تمیز و اصولی پایبند باشند (البته عکس این موضوع هم کاملاً صادق است).

*KhatKhati* · 18/9/20

نود و هفت چیزی که هر برنامه‌نویسی باید بداند: منفی در مفنی می‌شود مثبت!

دولوپرها به خوبی می‌دانند که سورس‌کد هیچ وقت دروغ نمی‌گوید اما این در حالی است که همین سورس‌کد گاهی اوقات تضادهایی دارا است و برخی از همین تضادها است که منجر به این سؤال می‌گردد «چه‌طور ممکنه با این شرایط نرم‌افزار کار کنه؟»

یکی از دولوپرهای نرم‌افزار آپولو ۱۱ به نام Allan Klumpp در مصاحبه‌ای گفت که در این نرم‌افزار باگی وجود داشت که فرود آپولو را با مشکل مواجه می‌کرد اما این در حالی بود که باگی دیگری منجر به این شد که باگ اول خنثی گشته و این نرم‌افزار بدون هیچ مشکلی کار خود را انجام می‌داد و قبل از اینکه کشف گردد، در نرم‌افزار کنترل کنندهٔ موتورهای آپولو ۱۱ و آپولو ۱۲ مورد استفاده قرار می‌گرفت.

برای روشن‌تر شدن این مسأله، فانکشنی را در نظر بگیرید که این وظیفه را دارا است تا استاتوس (وضعیت) چیزی را برگرداند. گرچه این فانکشن می‌بایست در شرایط خاصی مقدار True را باز گرداند، اما خروجی همواره False است. علاوه بر این، فانکشنی که این فانکشن را صدا زده، هرگز مقداری بازگشتی را چک نمی‌کند! در چنین شرایطی، همه چیز به خوبی کار می‌کند تا اینکه دولوپری به این قضیه پی‌ببرد.

زمانی‌ که در سورس‌کدی ۲ باگ وجود داشته باشد که با همکاری یکدیگر منجر به این خواهند گشت تا نرم‌افزار در ظاهر بدون مشکل کار کند، وقتی یکی از باگ‌ها مرتفع گردد و باگ دیگر بابرجا باقی بماند، نرم‌افزار به مشکل برخواهد خورد. به عبارت دیگر، دولوپری که مسئولیت نگهداری کد را بر عهده دارد، ریپورتی دریافت می‌کند مبنی بر وجود باگی در سیستم؛ وی باگ را یافته و آن را رفع می‌کند اما مشاهده می‌شود که مشکل کماکان پابرجا است چرا که باگ دوم هنوز به قوت خود باقی است. در چنین شرایطی، وی باگ اول را به حالت اولیهٔ خود بازگردانده و کد را بررسی می‌کند تا به باگ دوم دست یابد و آن را فیکس می‌کند اما مشاهده می‌شود که مجدد مشکل نرم‌افزار پابرجا است. بنابراین مشکل دوم نرم‌افزار که ریفکتور شده بود را به حالت قبل بازمی‌گرداند و در چنین شرایطی دولوپر به دنبال یک باگ سومی می‌گردد که چیزی بیش از یک دور باطل نخواهد بود چرا که اصلاً باگ سومی در کار نیست!

در چنین شرایطی، تعامل مابین ۲ باگ که منجر به ایجاد نتایج منتظره‌ای می‌شوند باعث می‌شود تا فرایند دیباگینگ نرم‌افزار بسیار دشوار گردد (جالب است بدانیم که چنین مسأله‌ای ممکن است در مستندات پروژه هم ایجاد گردد به طوری که اروری در کد با همکاری مشکلی در نوشتن مستندات پروژه دست به دست یکدیگر داده تا دولوپرها سردرگم شوند).

در یک کلام، بایستی گفت که هیچ راه‌کار عملی برای موقعیت‌هایی اینچنین وجود ندارد و چنانچه دولوپری در موقعیت‌هایی از این دست قرار گیرد، می‌توان این انتظار را داشت که روزها و شاید هفته‌ها یا ماه‌ها درگیر فرایند دیباگینگ گردد.

*KhatKhati* · 18/9/20

نود و هفت چیزی که هر برنامه‌نویسی باید بداند: اهمیت برنامه‌نویسی دونفره در کدنویسی را هرگز نادیده نگیرید

نیاز به توضیح نیست که کدنویسی نیاز به تفکر عمیقی دارد و تفکر عمیق هم در محیط‌های شلوغ امکان‌پذیر نبوده و نیازمند محیطی آرام و تنها است اما آنچه مسلم است اینکه در دنیای امروز فقط و فقط با تکیه بر داشته‌های خود نمی‌توان در حوزهٔ توسعهٔ نرم‌افزار به موفقیت‌های چندانی دست یافت و آشنایی با مهارت Team Work (کار گروهی) چیزی است که از دولوپرها، خواه فریلنسر باشند و خواه در تیم کد بزنند، انتظار می‌رود.

اما به خاطر داشته باشیم که منظور از کار گروهی این نیست که به سؤالات دیگر دولوپرها پاسخ دهیم، در جلسات شرکت کنیم، ایده بدهیم و کارهایی از این دست بلکه منظور کلی این است که به شکلی کاملاً پویا و فعال به همکاری با دیگر اعضای تیم بپردازیم.

در همین راستا، یکی از راه‌های پیاده‌سازی کار گروهی چیزی است تحت‌ عنوان Pair Programming (برنامه‌نویسی دونفره) که مزایای بسیاری برای هر دو دولوپر دارا است. اگر فرض را بر این بگذاریم که شما از همکارتان حرفه‌ای‌تر باشید، مسلماً با انتقال دانش خود منجر به ارتقاء مهارت‌های تیم توسعه خواهید شد و همچنین به توانایی‌های خود بیشتر واقف می‌گردید؛ اگر هم همکارتان از شما حرفه‌ای‌تر باشد، دیگر نیاز به توضیح نیست که این نوع کدنویسی می‌تواند در بالا بردن سطح مهارت‌های شما مفید واقع گردد (برای آشنایی بیشتر با تکنیک‌های این حوزه، به مجموعه مقالات برنامه‌نویسی دونفره در وبلاگ سکان آکادمی مراجعه نمایید).

آنچه مسلم است اینکه نگاه هیچ ۲ دولوپری در حین فرایند توسعهٔ نرم‌افزار ۱۰۰٪ شبیه به یکدیگر نیست و همین مسأله اهمیت برنامه‌نویسی دونفره را دوچندان می‌سازد چرا که دولوپرها می‌توانند از زوایای مختلفی به مسألهٔ پیش‌رویشان نگاه کرده و بهترین راه‌کار را برایش اتخاذ کنند.

حال بایستی از نقطه‌نظر مدیران شرکت‌های نرم‌افزاری هم به این قضیه نگاه کنیم؛ این دست مدیران که عموماً طرفدار مدیریت پروژه به سبک اجایل هستند بر این باورند که گماشتن ۲ دولوپر روی پروژه‌ای که ۱ دولوپر هم به خوبی از عهدهٔ آن برمی‌آید، کاری غیرمنطقی است!

چنین دیدگاهی کاملاً درست و به‌جا است و ما هرگز نمی‌گوییم که «باید» همواره کلیهٔ پروژه‌ها را با گماشتن ۲ دولوپر پیاده‌سازی کرد اما در اینجا بحث بالا بردن کیفیت کار از یک سو و انتقال دانش و ارتقاء مهارت‌های تک‌تک اعضای تیم توسعهٔ نرم‌افزار از سوی دیگر است.

نیاز به توضیح نیست که بازار کار همواره به دنبال بهترین دولوپرها است و اگر شرکت‌های نرم‌افزاری این شانس را داشته باشند که دولوپرهایی از این دست را به استخدام خود درآورده باشند، همواره بایستی این نگرانی را داشته باشند که روزی دولوپرهای درجه ۱ خود را از دست بدهند و این در حالی است که پیروی کردن از سـ*ـیاست برنامه‌نویسی دونفره می‌تواند دانش، مهارت و تجربیات دولوپرهای حرفه‌ای تیم را تا حد امکان به دولوپرهای مبتدی‌تر انتقال دهد و چنانچه روزی برسد که دولوپر یا دولوپرهای حرفه‌ای تیم بخواهند شرکت را ترک کنند، می‌توان این اطمینان را داشت که بخش قابل‌توجهی از دانش ایشان با سایرین به اشتراک گذاشته شده است.

چه نوع دولوپرهایی می‌بایست با یکدیگر در یک تیم قرار بگیرند؟
اگر به طور مثال شما دولوپری مبتدی هستید، خیلی مهم است که در صورت داشتن امکان برنامه‌نویسی دونفره در شرکت به جای دولوپری مبتدی همچون خودتان، با فردی ماهرتر هم‌ گروه شوید اما بایستی به خاطر داشته باشیم که مهارت‌های فنی برای هم گروه شده صرفاً کافی نیستند بلکه فردی که قرار است هم گروه ما شود، می‌بایست از مهارت‌های برقراری ارتباط با دیگران و مربی‌گری نیز برخوردار باشد که در این صورت بهترین نتیجهٔ ممکن را خواهیم گرفت.

*KhatKhati* · 18/9/20

نود و هفت چیزی که هر برنامه‌نویسی باید بداند: از نوشتن کدهای اضافی پرهیز کنید

فرض کنیم که در حال طراحی یک فروشگاه آنلاین بوده و درصدد هستیم تا بخش سبد خرید را کدنویسی کنیم. برای این منظور، کلاسی داریم تحت عنوان Order که حاوی متدهای مختلفی است من‌جمله ()isComplete که حاوی کدهای زیر است:

function boolean isComplete()
{
return isPaid() && hasShipped();
}
منطقاً یک سفارش قبل از اینکه پرداخت شود نمی‌تواند به دست مشتری برسد؛ لذا ()hasShipped نمی‌توان True باشد مگر اینکه ()isPaid برابر با True باشد و به خاطر همین مسأله است که بخشی از کد اضافی بوده و کد بالا را می‌توان به صورت زیر تغییر داد:

function boolean isComplete()
{
return hasShipped();
}
در تفسیر کدهای فوق بایستی گفت که به طور کلی، وقتی که در حال کار روی یک Order (سفارش) هستیم، ۳ وضعیت مختلف می‌تواند وجود داشته باشد:
- در جریان: مشتری می‌تواند آیتم‌هایی را به سبد خرید خود اضافه کرده و یا برخی موارد را حذف کند.
- پرداخت شده: مشتری دیگر نمی‌تواند آیتمی را حذف کند.
- ارسال شده: کار به اتمام رسیده است و هیچ‌گونه تغییری رخ نخواهد داد.

در فرایند توسعهٔ نرم‌افزار، بسیاری مواقع پیش می‌آید که شاهد کدهای اضافی هستیم که این مسأله به خاطر عدم توجه به State (وضعیت) قرار گرفته در آن صورت می‌گیرد. به عبارت دیگر، ما می‌بایست ببینیم که در چه وضعیتی قرار داریم، سپس بسته به شرایطی که پیش روی ما است، فرایندها را تعریف کنیم.

یکی از راه‌های خوب برای توجه به این مسأله، استفاده از متدهایی بامعنی، همچون چیزی که در بالا مشاهده کردیم، برای پیاده‌سازی دستوراتی است که مد نظر داریم. در یک کلام، به خاطر داشته باشیم که اگر فرایندی را روی تسکی در State (وضعیت) نادرستی انجام دهیم، کدهای ما منجر به ایجاد باگ‌ خواهد شد.

*KhatKhati* · 18/9/20

نود و هفت چیزی که هر برنامه‌نویسی باید بداند: مقایسه‌ای مابین مهندسین نرم‌افزار و دیگر مهندسان

مهندسانی همچون متخصصین راه و ساختمان، مکانیک‌ها و غیره در طول صدها سال بر اساس قوانین ریاضیات و فیزیک، به یکسری اصول و اصطلاحاً Best Practice دست یافته‌اند که می‌تواند ساخته‌‌های ایشان را ایمن سازد. به طور مثال، وقتی که یک مهندس راه و ساختمان پلی می‌سازد، تست آن پل بدین گونه خواهد بود که ماشینی با بار سنگین از روی آن عبور می‌دهند و چناچه پل بدون هیچ‌گونه لغزش و سستی پابرجا باقی بماند، این بدان معنا است که مهندسی به درستی کارش را انجام داده است.

خوشبختانه یا متأسفانه در مهندسی نرم‌افزار تست محصول بدین گونه نخواهد بود چرا که ماهیت مهندسی نرم‌افزار با گونه‌های دیگر مهندسی کاملاً متفاوت است. وقتی پای اطمینان حاصل کردن از خروجی کار به میان می‌آید، هیچ‌وقت از یک مدیر پروژهٔ راه و ساختمان جمله‌ای همچون «ما زمان کافی برای تست این پل نداریم» نخواهیم شنید اما متأسفانه بسیاری از مدیران پروژه در صنعت توسعهٔ نرم‌افزار به خاطر وجود ددلاین‌های فشرده و گاهی‌اوقات غیرواقعی، اهمیت تست‌ نهایی نرم‌افزار را نادیده گرفته و تمام تمرکزشان روی این موضوع است که پروژه هرچه سریع‌تر به دست مشتری برسد.

در چنین شرایطی، این وظیفهٔ دولوپرها است که تحت هیچ شرایطی زیر بار ریلیس کردن نرم‌افزار بدون تست کامل و جامع آن نروند. در واقع، تست نرم‌افزار نه تنها کافی نیست، بلکه ضروری هم هست و دولوپرهای حرفه‌ای می‌توانند با ابزارهای تستی که امروزه به بازار عرضه شده‌اند و بسیاری از کارهای دولوپرها را به صورت خودکار انجام می‌دهند خود را از دیگر دولوپرهای غیرحرفه‌ای متمایز سازند.

*KhatKhati* · 18/9/20

نود و هفت چیزی که هر برنامه‌نویسی باید بداند: تست نرم‌افزار و سورس‌کد را آخر شب‌ها و آخر هفته‌ها انجام دهید!

یکی از مسائلی که باعث می‌گردد دولوپرها پیش از تست کردن تغییرات خود، اقدام به کامیت آنها روی یک سیستم ورژن کنترل همچون گیت کنند این است که معمولاً تست‌ها زمان قابل‌توجهی برای تکمیل شدن به خود اختصاص می‌دهند. به همین دلیل، توصیه می‌شود که از زمان‌هایی که کار نمی‌کنید، مثل شب‌ها و آخر هفته‌ها، برای کارهای اتوماسیون همچون تست‌های طولانی و زمان‌بر استفاده نمایید و به سادگی صبح روز بعد خواهید توانست نتایج، لاگ‌ها و غیره را مشاهده کنید.

نکته‌ای که در ارتباط با تست نرم‌افزار در زمان‌های فوق‌الذکر وجود دارد این است که شبکه و همچنین سرورها در چنین زمان‌هایی بار و فشار زیادی رویشان نبوده و بالتبع با سرعت‌ بیشتری می‌توانند تسک‌های در نظر گرفته شده را تکمیل کنند.

با انجام کمی محاسبات و برخورداری از دانشی نسبی در مورد اسکریپت‌نویسی، می‌توان به سادگی تعدادی کرون جاب ایجاد کرد تا تست‌های مدنظرمان را در شب‌ها، آخر هفته‌ها و دیگر روزهای تعطیل رسمی تکمیل کنند.

*KhatKhati* · 18/9/20

نود و هفت چیزی که هر برنامه‌نویسی باید بداند: تست‌ها علاوه بر صحیح بودن، می‌بایست دقیق هم باشند

در آموزش قبل گفتیم که در حین فرایند تست نرم‌افزار، ضروری است که عملکرد مورد انتظار از نرم‌افزار را تست کرد تا اینکه خصوصیات جانبی و حاشیه‌ای نرم‌افزار که ربطی هم به عملکردش ندارند مورد ارزیابی قرار گیرند اما این در حالی است که این سوء‌تفاهم نمی‌بایست پیش بیاید که تست‌های نرم‌افزاری می‌توانند کلی و دقیق نباشند! به‌ عنوان یک قانون کلی، یک تست خوب می‌بایست دقت و درستی عملکرد کد را بسنجد.

برای روشن‌تر شدن این مسأله، مثالی از دنیای واقعی برنامه‌نویسی می‌زنیم. الگوریتم سورت کردن یکسری داده (مثلاً از بزرگ به کوچک یا به ترتیب حروف الفبا) چیزی است که معمولاً دولوپرها با آن سروکار دارند. وقتی از دولوپری این سؤال پرسیده شود که هدف از تست چنین الگوریتمی چیست، پاسخی که معمولاً با آن مواجه می‌شویم این است که «داده‌ها باید به درستی یا از بزرگ به کوچک و با بالعکس سورت شوند».

گرچه چنین پاسخی کاملاً درست است، اما تمام ماجرا نیست! در واقع، یک تست دقیق برای سنجش چنین الگوریتمی این‌گونه عمل می‌کند که پس از سورت شدن، طول عناصر آرایهٔ مد نظر می‌بایست با طول آرایه قبل از سورت شدن یکسان باشد. گرچه چنین دیدگاهی درست است،‌ اما باز هم کافی نیست! به عنوان نمونه داریم:

3 1 4 1 5 9
خروجی زیر مجموعه اعدادی را نشان می‌دهد که هم از نظر طول با آرایهٔ اورجینال برابری می‌کند و هم اعداد از کوچک به بزرگ سورت شده‌اند:

3 3 3 3 3 3
اما می‌بینیم که تک‌تک المان‌های آرایه در خروجی وجود ندارند. این مثال برگرفته از کدی واقعی است که خوشبختانه پیش از ریلیس، باگ آن رفع شد؛ در واقع،‌ مشکل از اینجا ناشی می‌شد که کل خروجی با اولین عضو آرایه (عدد ۳) پر می‌شد.

پس ما می‌بایست تستی می‌نوشتیم که بسنجد کلیهٔ اعضای آرایه سورت شده، طول آن‌ها برابر با آرایهٔ اصلی باشد و از همه مهم‌تر، اعضا دقیقاً همان اعضای اورجینال باشند.

اگر بخواهیم تستی به معنای واقعی کلمه حرفه‌ای بنویسیم، باز هم شرایط توصیف شدهٔ بالا کفایت نمی‌کنند! در حقیقت، یک تست خوب باید خوانا، قابل‌فهم و در عین حال ساده باشد تا یک تستر به سادگی بتواند متوجه شود که آیا نتیجهٔ آن درست است یا غلط به طوری که یک دولوپر صاحب‌نام به اسم Hoare در این باره می‌گوید:

به‌طورکلی ۲ راه برای طراحی معماری یک نرم‌افزار وجود داره؛ راه اول این‌که آن‌قدر آن‌را ساده طراحی کنی که هیچ نقصی در آن وجود نداشته باشه و راه دوم این‌که آن‌قدر آن‌را پیچیده طراحی کنی که هیچ نقصی آشکارا در آن دیده نشه!

با این تفاسیر، به این نتیجه می‌رسیم که تست نرم‌افزاری در صنعت برنامه‌نویسی که روز به روز شاهد اپلیکیشن‌های پیچیده‌‌تری در آن هستیم الزامی است اما این در حالی است که تست‌ها علاوه بر سنجش صحت نرم‌افزار یا اپلیکیشن، می‌بایست دقیق هم باشند.

*KhatKhati* · 18/9/20

نود و هفت چیزی که هر برنامه‌نویسی باید بداند: در تست نرم‌افزار فقط رفتار مورد انتظار را بسنجید

یکی از دام‌هایی که دولوپرها در حین تست نرم‌افزار در آن گرفتار می‌شوند این است که بر این باورند آنچه نرم‌افزار انجام می‌دهد دقیقاً همان تسکی است که قصد تست آن را دارند. گرچه در ظاهر چنین چیزی اصلاً دام تلقی نمی‌شود اما اگر کمی بیشتر این موضوع را بشکافیم، منظور واضح‌تر بیان گردد: یک اشتباه رایج در فرایند تست نرم‌افزار این است که تست را برای خصوصیات جانبی نسخهٔ مد نظر نرم‌افزار نوشت و این در حالی است چنین خصوصیاتی جانبی بوده و خیلی سنخیتی با رفتاری از نرم‌افزار که قصد سنجش آن را داریم ندارند!

در چنین شرایطی، یعنی زمانی‌ که تست‌ها به گونه‌ای نوشته می‌شوند که با برخی خصوصیات جانبی نرم‌افزار هماهنگ شده باشند، اعمال تغییرات روی بخش‌هایی از نرم‌افزار که مرتبط با رفتاری است که قرار آن را تست کنیم، منجر به شکست تست می‌شود. در چنین شرایطی، دولوپرها معمولاً یا دست به ریفکتورینگ کد می‌زنند و یا تست را مجدد می‌نویسند که چنین کاری اوضاع را خراب‌تر می‌کند بلکه توصیه می‌شود مشکل ریشه‌ای حل گردد.

برای روشن‌تر شدن این مسأله مثالی می‌زنیم. اگر تستی بنویسیم که علاوه بر سنجش رفتار نرم‌افزار، مثلاً جایگاه قرارگیری اِلِمان‌های روی صفحه را نیز بسنجد، اگر به هر دلیلی تغییری در رابط کاربری بدهیم و سپس نرم‌افزار را تست کنیم، تست ما با شکست مواجه می‌شود و این در حالی است که مد نظر قرار دادن چنین مسائل جانبی و به نوعی حاشیه‌ای، صرفاً به پیچیده‌تر کردن تست‌ها منجر شده و احتمال بروز شکست آنها را بیشتر خواهد کرد.

با این تفاسیر، توصیه می‌شود که در حین نوشتن Unit Test، صرفاً رفتاری که از نرم‌افزار یا اپلیکیشن انتظار داریم را تست کنیم نه مسائل حاشیه‌ای که عملاً تغییری در رفتار اپلیکیشن ایجاد نمی‌کنند.

*KhatKhati* · 18/9/20

نود و هفت چیزی که هر برنامه‌نویسی باید بداند: آشنایی با مزایای ابزارهای تحلیل سورس‌کد

در سال‌های اخیر شاهد آن بوده‌ایم که تست نرم‌افزار به بخشی لاینفک از فرایند توسعه مبدل شده است اما در عین حال، تست صرفاً یکی از ابزارهایی است که از آن طریق می‌توان کیفت کد را بهبود بخشید!

از زمانی که زبان برنامه‌نویسی C یک پدیدهٔ تازه بود تا امروز که زبان‌های سطح‌بالای بسیاری وارد صنعت توسعهٔ نرم‌افزار شده‌اند، ابزارهای تحلیل کد روز به روز پیشرفت بیشتری کرده به طوری که امروزه این دست ابزارها قدرت تحلیل به مراتب بیشتری نسبت به نمونه‌های اولیهٔ‌شان دارند.

مثلاً ابزاری همچون Pylint که برای تحلیل کدهای Python به کار می‌رود یا ابزار Splint برای زبان C، این امکان را به دولوپر می‌دهند که تنظیم کند چه نوع هشدارها، ارورها و خطاهایی در معرض دیدش قرار گیرند.

به طور کلی، امروزه در کنار تست نرم‌افزار نیاز به فاز دیگری تحت عنوان تحلیل هم داریم تا این اطمینان را حاصل کنیم که کدها بهینه هستند، مقدار استفاده از منابع سیستمی در بهترین حالت ممکن قرار دارند و در نهایت کدی که نوشته شده است، بهترین کدی است که می‌توانست وجود داشته باشد!

*KhatKhati* · 18/9/20

نود و هفت چیزی که هر برنامه‌نویسی باید بداند: تا حد ممکن همه‌ چیز را خودکار کنید

اگرچه امروزه ابزارهای اتوماسیون توسعهٔ نرم‌افزار بسیار زیادی در اختیار دولوپرها قرار دارد، اما برخی از ایشان ترجیح می‌دهند که به جای استفاده از این ابزارها، کارها را به صورت دستی انجام دهند که شاید دلیل چنین مقاوتی، یکسری باورهای نادرست در مورد اتوماسیون باشد که مهم‌ترین آنها عبارتند از:

باور نادرست ۱: اتوماسیون صرفاً برای تست است
گرچه Automation (اتوماسیون) بیش از هر جای دیگری در فرایند تست نرم‌افزار صورت می‌گیرد اما این در حالی است که اگر اسکریپتی بنویسیم که بسیاری از کارهای روزمهٔ ما همچون گزارش‌گیری، مستندسازی، کامپایل، دیپلویمنت و … را انجام دهد، به مراتب از کلیک‌های ماوس قابل‌اعتمادتر است.

باور نادرست ۲: اگر از IDE استفاده کنیم، نیاز به اتوماسیون نداریم
IDEها دارای تنظیمات بسیار پیشرفته‌ای هستند که بسیاری از کارهای تکراری دولوپرها را انجام می‌دهند اما این در حالی است که به سختی می‌توان این تضمین را ایجاد کرد که در یک تیم توسعهٔ نرم‌افزار، تک‌تک دولوپرها از تنظیمات (Settings) یکسانی برخوردار باشند اما سیستم‌های اتوماسیون بیلدی همچون Ant (برای زبان برنامه‌نویسی جاوا)، iMacros و یا Selenium، به سادگی چنین امکانی را در اختیار ما قرار می‌دهند.

باور نادرست ۳: برای این کار، باید کار با ابزارهای زیادی را یاد گرفت
شما با استفاده از زبان‌های اسکریپت‌نویسی شل همچون بش یا پاورشل به سادگی می‌توانید دست به نوشتن اسکریپت‌هایی بزنید که کلیهٔ کارهای شما را خیلی سریع انجام دهند.

علاوه بر این، برای اسکریپت‌نویسی شما اصلاً نیازی به یادگیری زیر و بم زبانی همچون Bash و یا ابزارهایی که پیش از این معرفی شدند ندارید. در چنین مواقعی، به محض نیاز به انجام کاری، تکنیک‌های مرتبط با همان کار را با سرچ در وب و مطالعهٔ منابع مختلف یاد بگیرید و اصلاً زمان خود را روی یادگیری از ۰ تا ۱۰۰ ابزار مد نظر نگذارید!

خوش آمدید به رمان ۹۸ | بهترین انجمن رمان نویسی

ما را در شبکه‌های اجتماعی دنبال کنید

مدیر بازنشسته رمان ۹۸

مدیر بازنشسته رمان ۹۸

مدیر بازنشسته رمان ۹۸

مدیر بازنشسته رمان ۹۸

مدیر بازنشسته رمان ۹۸

مدیر بازنشسته رمان ۹۸

مدیر بازنشسته رمان ۹۸

مدیر بازنشسته رمان ۹۸

مدیر بازنشسته رمان ۹۸

مدیر بازنشسته رمان ۹۸

ما را در شبکه‌های اجتماعی دنبال کنید

درباره ما

لینک‌های پیشنهادی رمان ۹۸

آمار آنلاین