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

*KhatKhati* · 18/9/20

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

به نوعی می‌توان برنامه نویسان را به ۲ گروه مختلف تقسیم‌بندی کرد: گروهی که وقتی از ایشان می‌پرسید که مشغول به چه کاری هستند، به وضوح می‌توانند بگویند که مثلاً «در حال کار کردن روی کلاس مرتبط با یوزر هستم» و گروهی که پاسخی همچون «در تلاش برای بهبود روند سرویس یوزرها ام» که به نظر می‌رسد برنامه نویسی که پاسخ اول را داده است، دقیقاً می‌داند در حال انجام دادن چه کاری است اما در این در حالی است که برنامه نویس دوم بیشتر یک دید کلی نسبت به پروژه دارا است!

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

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

برنامه نویسان گروه اول همواره این شانس را دارند که اگر بخواهند به گذشته بازگردند، این کار را به سادگی با چند بار Ctrl +Z انجام دهند اما این قضیه در مورد برنامه نویسان گروه دوم اصلاً صدق نمی‌کند! پس به خاطر داشته باشیم که در انجام پروژه های نرم افزاری، همواره تسک ها را به بخش های کوچک و قابل کنترلی تقسیم بندی کرده، برای هر کدام از آن ها یک Deadline (ددلاین یا ضرب الاجل) در نظر بگیریم و در آن واحد فقط و فقط روی یکی از آن ها کار کرده و به محض تکمیل یک تسک، با خیال راحت سراغ تسک بعدی برویم.

*KhatKhati* · 18/9/20

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

در دهه ی ۸۰ میلادی، برنامه نویسان محدود بودند به ویرایشگرهای کد ساده یی که اگر خیلی خوش شانس بودند، ویرایشگر کد ایشان به Syntax Highlighting مجهز بود! در آن دوران اگر کسی می‌خواست برنامه ی خود را دیباگ کند، می بایست ابزارهای مجزایی نصب کند و اصلاً این‌ گونه نبود که با یک کلیک، فرایند دیباگ آغاز شود بلکه نیاز به انجام فرایندهای مختلفی بود.

در دهه ی ۹۰، شرکت های نرم‌افزار متوجه خلائی در بازار برنامه نویسی شدند و آن هم چیزی نبود جز برنامه‌هایی کاربردی که می توانستند زندگی برنامه نویسان را ساده‌تر و در عین حال لـ*ـذت بخش تر سازند و نتیجه این که IDE های مختلف به بازار عرضه شدند که قابلیت‌های جدید همچون کامپایلر، دیباگر و … را به نرم افزارهای ویرایشگر کد معمولی افزوده بودند.

در همین دوران بود که برنامه‌های کامپیوتری به «منو» های مختلف مجهز شدند و با‌ عرضه ی دیوایس «ماوس» به بازار، برنامه نویسان دیگر مجبور نبودند تا برای انجام کاری خاص، از ترکیب کلیدهای مختلف استفاده کنند بلکه به سادگی با نشانگر ماوس خود، می توانستند روی یکی از منوهای نرم‌افزار کلیک کرده و پشت پرده، کامند خاصی اجرا گردد.

پس از سال ۲۰۰۰، محیط های توسعه ی یکپارچه ی نرم‌افزار آنقدر رایج شدند که بسیاری از شرکت های نرم افزاری این IDE ها را به رایگان در اختیار برنامه نویسان قرار می‌دادند تا از این طریق شناخته تر شده و بتوانند سایر سرویس ها و محصولات خود را به فروش برسانند. این نرم‌افزارها از آن زمان تاکنون، روز به روز به ابزارهای بهتر و بیشتری مجهز شده اند به طوری که امروزه شاهد IDE هایی هستیم که قابلیت‌های منحصر به فردی همچون Automated Refactoring و یا Extract Method دارند.

نکته
کاری که Extract Method انجام می‌دهد این است که بخشی از کد را انتخاب کرده، سپس نرم‌افزار آن بلوک کد را به یک متد با نامی خاص برایمان تبدیل می‌کند.
یکی دیگر از قابلیت‌های محیط های توسعه ی یکپارچه ی نرم‌افزار امروزی -IDE- این است که می‌توان در تنظیمات نرم‌افزار یکسری «قوانین» وضع کرد و از آن پس، هر موقع که آن قانون را نقض کنیم، یک هشدار در معرض دیدمان قرار خواهد گرفت. به طور مثال، می خواهیم در زبان پی اچ پی قانونی را نظر بگیریم که هر پراپرتی که در بدنه ی کلاس خود تعریف می‌کنیم، protected باشد؛ در چنین شرایطی، هر موقعی که فراموش کنیم کلیدواژه ی protected را استفاده کنیم، نرم‌افزار به ما هشدار خواهد داد.

تفاوتی که نرم افزارهایی همچون vi که در سیستم عامل های مبتنی بری یونیکس همچون گنو/لینوکس در دسترس کاربران قرار دارد با IDE های مدرن این است که استفاده از نرم افزاری همچون vi نیاز به مطالعه ی زیادی صرفاً برای یادگیری کار کردن با این نرم‌افزار است اما محیط گرافیکی بسیاری از IDE های مدرن به گونه یی طراحی شده است که برنامه نویس طی چند ساعت می‌تواند کار با آن را یاد بگیرد اما در طول زمان، بسیاری از برنامه نویسان به همان کارهای ابتدایی که یاد می‌گیرند با نرم‌افزار مد نظر خود انجام دهند اکتفا کرده و خیلی علاقه یی به کشف زیر و بم IDE از خود نشان نمی‌دهند!

برای روشن‌تر شدن این مسأله مثالی می‌زنیم. امروزه هر کاری که قبلاً از طریق کامند می‌شد انجام داد را می‌توان از طریق ماوس و منوهای تعبیه شده در نرم‌افزار انجام داد و برخی برنامه نویسان در طول زمان به استفاده از ماوس عادت می‌کنند اما غافل از این که برداشتن دست خود از روی کیبورد و استفاده از ماوس، زمان ایشان را هدر می‌دهد؛ برای کلیه ی کارهایی که از طریق ماوس می‌توان انجام داد، همچنین می‌توان «کلیدهای میانبر» نیز تعریف کرد به طوری که مثلاً برای باز کردن یک پنجره ی جدید، بستن پنجره، تغییر نام و … می‌توان بدون آن که دست خود را از روی کیبورد برداریم، کار مد نظر را انجام دهیم.

اگر بخواهیم چکیده یی از این آموزش به دست آوریم، بایستی بگوییم که در توسعه ی نرم‌افزار زمان و مهم‌تر از آن صرفه جویی در زمان نقش بسیار تعیین کننده یی در موفقیت پروژه دارد و یکی از چیزهایی که می‌تواند به ما به عنوان یک برنامه نویس کمک کند، صرفه جویی در زمان کدنویسی با مسلط شدن به IDE مد نظر خود است؛

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

شاید در ابتدای راه استفاده ی صرف از کلیدهای میانبر کمی سخت باشد و به خاطر سپردن آن‌ها کاری دشوار، اما در طول زمان کدنویسی برایمان به مراتب لـ*ـذت بخش تر خواهد شد.

*KhatKhati* · 18/9/20

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

فلسفه ی برنامه نویسی حاکی از آن است که «مهارت برنامه نویسی مستقیماً وابسته به پارادایم های مختلف برنامه نویسی که یک برنامه نویس برای کدنویسی مورد استفاده قرار می‌دهد و با آن‌ها احساس راحتی می‌کند است نه دانش اندکی که وی ممکن است از یک زبان برنامه نویسی دیگر داشته باشد!»

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

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

در‌ واقع پارادایم های برنامه نویسی مختلف من جمله Procedural یا رویه یی، Object-oriented یا شیء گرا، Functional یا تابعی و … وجود دارند که از لحاظ ساختاری دارای تفاوت‌هایی با یکدیگر هستند و در صورت مهاجرت در میان این پارادایم ها، می بایست منتظر چالش های فراوانی هم باشیم!

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

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

مدیران شرکت های نرم‌افزار می بایست بخشی از تایم کاری تیم توسعه ی نرم‌افزار خود را به یادگیری زبان‌های جدید اختصاص دهند حتی اگر قرار نباشد هیچ پروژه یی با زبان‌های جدید نوشته شود چرا که اتخاذ چنین رویکردی منجر به بازتر شدن دید برنامه نویسان شرکت نسبت به همان زبانی که به صورت روزمره مورد استفاده قرار می‌دهند می‌شود.

در پایان هم می بایست این نکته را یادآور شد که یادگیری یک زبان صرفاً به یادگیری سینتکس اش و نوشتن یک برنامه ی Hello World خلاصه نمی‌شود بلکه نیاز به ماه ها کار مستمر و نوشتن پروژه های مختلف با آن زبان و درگیر شدن با بخش‌های مختلف زبان دارد.

*KhatKhati* · 18/9/20

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

امروزه بسیاری از ابزارهای توسعه ی نرم‌افزار در IDE ها به صورت پیکج های از پیش نصب شده در اختیار توسعه دهندگان قرار می‌گیرند و همین مسأله منجر به محبوبیت بیش از پیش IDE در مقایسه با ادیتورهای کد در میان توسعه دهندگان می‌شود چرا که نه تنها کدنویسی با این محیط های توسعه راحت تر است، بلکه برنامه نویس دیگر نیازی نخواهد داشت تا به یکسری جزئیات همچون فرایند کامپایل کردن و … فکر کند.

به خاطر داشته باشید
IDE مخفف واژگان Integrated Development Environmnet به معنی «محیط توسعه ی یکپارچه ی نرم افزار» است که از مهم‌ترین آن‌ها می‌توان به ویژوال استودیو، اکلیپس و نت بینز اشاره کرد.
سهولت در استفاده از IDE ها گرچه به عنوان یکی از نقاط قوت این دست نرم‌افزارها محسوب می‌گردد، اما IDE ها عاری از هر گونه عیبی هم نیستند! زمانی که ما می‌گوییم استفاده از یک نرم‌افزار بسیار سهل و آسان است، این بدان معنا است که نرم‌افزار بسیاری از کارها را به صورت خودکار انجام می دهد؛ به عبارت دیگر، بسیاری از تصمیماتی که بر عهده ی توسعه‌دهنده هستند را خود نرم‌افزار می‌گیرد و به همین دلیل هم هست که توسعه دهندگانی که صد در صد وابسته به IDE انتخابی خود هستند -خواه ویژوال استودیوی مایکروسافت یا گزینه های اپن سورسی همچون اکلیپس- در یکسری از مواقع اصلاً متوجه نمی‌شوند که سورس کد ایشان چگونه بیلد می‌شود و ابزارهای مختلف دقیقاً چه کاری انجام می‌دهند (به طور مثال، شما یک دکمه را در اندروید استودیو می‌زنید و خروجی apk حاضر و آماده در اختیار شما قرار می‌گیرد.)

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

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

علاوه بر این که پس از استفاده از ابزارهای کامند لاین برای بیلد کردن سورس کد خود به ماهیت فرایندها پی می برید، یکسری کارهای دیگری نیز می‌توانید انجام دهید که در مقایسه با IDE ها از سهولت و اثربخشی بیشتری برخوردارند؛ برای مثال، ابزارهای جستجو و جایگزین کردنی همچون grep و sed گاهی اوقات از گزینه هایی که در نرم افزارهای گرافیکی در اختیار توسعه دهندگان قرار می‌گیرد اثربخش تر هستند.

در ضمن، ابزارهای کامند لاینی امکان اسکریپت نویسی -خودکار کردن یکسری کارهای تکراری- را نیز به شما می‌دهند تا مثلاً در بازه های زمانی مشخص، نسخه های مختلفی از نرم‌افزار بیلد شده و ذخیره گردد.

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

پاسخ به سؤال فوق «آری» است اما نکته یی که در این آموزش یاد آور شدیم هرگز بدان معنا نیست که شما از امروز باید IDE خود را کنار بگذارید و کلاً به صورت کامند لاینی فرایند توسعه ی نرم‌افزار خود را دنبال کنید بلکه منظور این است که آشنایی با ابزارهای کامند لاینی، دید به مراتب بازتری به شما به عنوان یک برنامه نویس می‌دهند و زمانی که کاری را در نرم افزارهای گرافیکی انجام می‌دهید که صرفا با چند کلیک به هدف خود می‌رسید، متوجه می‌شوید که پشت پرده چه اتفاقاتی رخ می‌دهد و بهترین رویکرد برای درک این موضوع هم استفاده از ابزارهای کامند لاین است.

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

*KhatKhati* · 18/9/20

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

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

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

یکی از استراتژی های خوب در حین کدنویسی، به کارگیری سـ*ـیاست Zero-tolerance Policy است؛ در‌ واقع این سـ*ـیاست حاکی از آن است که IDE و محیط توسعه ی نرم افزار خود را به گونه یی تنظیم کنیم که هرگونه هشدار، خطا و اروری را به ما گوشزد کند حتی اگر خیلی کوچک و در ظاهر بی اهمیت باشند.

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

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

نکته
به طور کلی، در شاخه ی برنامه نویسی و توسعه ی نرم‌افزار، Build به فرایندی گفته می‌شود که در آن سورس کد به برنامه یی قابل اجرا و قابل استفاده مبدل می‌گردد که معمولاً با یک شناسه -مثلا ۱۷- شناخته می‌شود که قبل از انتشار نهایی نرم‌افزار و در فرایند تست نرم افزار ایجاد می‌گردد. یکی از فرایندهای مهم در بیلد کردن، کامپایل کردن سورس کد است که در این فرایند سورس کد نرم‌افزار به کدهای قابل اجرا توسط ماشین تبدیل می‌شوند.

*KhatKhati* · 18/9/20

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

یکی از چیزهایی که در ارزیابی کیفیت یک نرم‌افزار مورد توجه قرار می‌گیرد، Response Time (ریسپانس تایم یا زمان پاسخگویی) نرم‌افزار است. این نرم‌افزار می‌تواند یک وب سایت آنلاین باشد و یا یک نرم‌افزار حسابداری که روی سیستم خود نصب می‌کنیم؛ هرچه که باشد، اگر نوع کاربری نرم‌افزار به گونه یی باشد که کاربران نیاز به تعامل مکرر با سیستم داشته باشد، ریسپانس تایم نقش تعیین کننده در تجربه ی کاربری نرم‌افزار ایفا می‌کند به طوری که اگر کاربری کاری را انجام دهد و چند ثانیه منتظر بماند تا سیستم پاسخ وی را بدهد، این حس به کاربر نرم افزارمان دست که می‌دهد که وقت اش تلف می‌شود.

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

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

برای رفع این مشکل، راه کارهای متعددی را می‌توان اتخاد نمود؛ به عنوان مثال، می‌توان تعامل نرم‌افزار خود با مثلاً وب سرویس مربوطه را به حداقل رساند و در هر بار ریکوئست فرستادن، کمترین دیتای ممکن را درخواست کرد.

راه‌کار دیگری که می‌توان به کار برد این است که داده‌هایی که قبلاً به دست آمده را Cache کرد، بنابراین کاربران جدیدی که ریکوئست مشابهی ارسال می‌کنند، پاسخ خود را خیلی سریع از روی کش سیستم دریافت می‌کنند.

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

*KhatKhati* · 18/9/20

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

اگر به فولدر Downloads سیستم خود نگاهی بیندازید، و ببینید که پر است از فایل‌های zip و exe که شاید حتی یک بار هم آن‌ها را استفاده نکرده باشید! شما جزو آن دسته از کاربرانی هستید که علاقمند به جمع آوری هرگونه نرم افزاری -از نرم افزاری های گرافیکی گرفته تا هک و غیره- هستید.

در نقطه ی مقابل این دست کاربران، کاربرانی هستند که خیلی وسواسی هستند و دوست دارند که سیستم خود را تا حد ممکن تمیز نگاه دارند و صرفاً نرم افزارهایی را روی آن نصب کنند که به آن ها نیاز دارند. این دست کاربران خیلی برایشان مهم است نرم افزاری که Install می‌کنند، قابلیت Uninstall شدن داشته باشد؛ لذا اگر برنامه یی نوشته‌اید که نمی‌توان را آن را حذف نمود و یا اگر می‌شود، به سختی این کار صورت می‌گیرد، به طور حتم نظر مساعد این دست از کاربران را از دست خواهید داد.

اگر برنامه یی که نوشته‌اید که Graphical User Interface (یا به اختصار GUI به معنی رابط کاربری گرافیکی) دارد، تا حد ممکن مراحل انجام کار را ساده نگاه دارید و همچون نرم افزارهای شرکت ادوبی، از منوهای تو در تو و گاها گیج‌کننده استفاده نکنید.

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

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

*KhatKhati* · 18/9/20

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

آمریکایی ها شعاری دارند تحت عنوان Less Is More با این مضمون که «هرچه کمتر، بهتر!» و شاید بتوان گفت که این جمله خیلی کلیشه یی است و ممکن است در بسیاری مواقع کاربرد نداشته باشد، اما حداقل در کدنویسی کاربرد دارد به این شکل که با حذف کلاس‌ها، فانکشن ها و بلوک های کد اضافی از سورس کد خود، در نهایت سورس کد به مراتب بهتر و تمیزتری در اختیار خواهید داشت.

گاهی اوقات در حین کدنویسی فکر می‌کنیم که یکسری کارها به بهبود نرم‌افزار ما منجر خواهند شد اما در نهایت کاشف به عمل می‌آید که در حین اجرا، باعث کاهش راندمان نرم‌افزار می‌شوند و تنها در صورت حذف آن‌ها است که بهبودی حاصل می‌شود. در کدنویسی همواره می بایست این نکته را به خاطر داشته باشیم که باید کدی بنویسیم که «ارزشی برای نرم‌افزار ما بیاورد نه این که صرفاً از نوشتن آن لـ*ـذت ببریم».

گاهی اوقات هم در تحلیل نرم‌افزار و مراحل اولیه ی کدنویسی، فکر می‌کنیم که یک قابلیت ممکن است در آینده به کارمان آید، لذا با خود فکر می‌کنیم که زمان زیادی از ما نمی‌برد و آن را در سورس کد خود می گنجانیم اما همواره به یاد داشته باشیم که اگر به قابلیتی در حال حاضر نیاز نداریم، نیاز به نوشتن آن نیست!

*KhatKhati* · 18/9/20

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

برخی توسعه دهندگان برچسب «باگ» روی مسائل خارج از عرف نرم افزاری می‌گذارند و برخی دیگر صرفاً به «مشکل» اکتفا می‌کنند؛ خواه این مسائل را باگ بنامییم خواه مشکل، آن‌ها وجود دارند و به راحتی می‌توانند موفقیت نرم‌افزار ما را تحت الشعاع قرار دهند و یکی از مهارت های اصلی هر توسعه‌دهنده ی حرفه یی، این می‌تواند باشد که چگونه باگ های یک نرم‌افزار را رصد کند و تمام تلاش خود را به کار گیرد تا آن‌ها را مرتفع سازد.

برای رفع باگ ها، ما پیش از هر چیز به یک ‌Bug Report (باگ ریپورت) نیاز داریم تا بیش از پیش، با خصوصیات باگ احتمالی آشنا شده و دیگر اعضای تیم را نیز در جریان قرار دهیم؛ یک باگ ریپورت خوب از ویژگی‌های زیر برخوردار است:
- نحوه ی کار با نرم‌افزار به گونه یی که منجر به مشاهده ی باگ شود را ارائه می‌دهد؛ علاوه بر این، به ما می‌گوید که این باگ هر چند وقت یک بار پدید می‌آید.
- به نظر شما چه اتفاقی باید افتاده باشد که این باگ ایجاد شده؟
- گزارشی کامل از اتفاقاتی که رخ داده‌اند به منظور درک بهتر ماهیت باگ و در صورت امکان، ارائه ی دلیل اصلی پدید آمدن باگ

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

*KhatKhati* · 18/9/20

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

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

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

برنامه نویسی و به طور کلی توسعه ی نرم‌افزار دربرگیرنده ی یادگیری مداوم است؛ هرچه شما بیشتر روی پروژه یی وقت می‌گذارید، بیشتر با جنبه‌های مختلف پروژه آشنا شده و بالتبع زوایای بیشتری از پروژه را درک کرده که در نهایت می‌توانند منجر به یافتن راه کارهای به مراتب بیشتر و بهینه‌تری گردند.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

درباره ما

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

آمار آنلاین