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

*KhatKhati* · 18/9/20

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

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

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

نکتهٔ دیگری که در این رابـ ـطه وجود دارد این است که اکثر مشتریان پروژه‌های نرم‌افزاری ابتدا به ساکن نمی‌دانند که چه کاربردهایی از نرم‌افزار مد نظرشان انتظار دارند و به مرور زمان ایده‌های جدیدی به ذهن ایشان می‌رسد. به عبارت دیگر، ایشان به خوبی Big Picture (تصویر کلی) از اپلیکیشنی که می‌خواهند را مد نظر دارند اما وقتی که پای جزئیات به میان می‌آید، هرگز دید روشنی از آنچه می‌خواهند ندارند.

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

در یک کلام، بایستی گفت که تعامل بیشتر با یکدیگر منجر به این خواهد شد تا جزئیات بیشتری مابین کارفرما (مشتری) و مجری (دولوپر) رد و بدل گردد.

وقتی پای مذاکره با مشتریان به میان می‌آید، همواره این نکته را مد نظر داشته باشید که ممکن است برخی از ایشان اصطلاحاً Technophobia (ترس از تکنولوژی) داشته باشند؛ لذا هرگز از Jargon (اصلاحات فنی) در مکالمه با ایشان استفاده نکنید و سعی کنید به ساده‌ترین شکل ممکن به صحبت با ایشان بپردازید.

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

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

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

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

*KhatKhati* · 18/9/20

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

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

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

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

- تحت هر شرایطی، صرفاً به کار کردن کد تحت شرایط عادی رضایت ندهید؛ بلکه تمام تلاش خود را به کار گیرید تا تمامی جوانب کار را بسنجید. در واقع، از سالم بودن کد (قابل اجرا بودن کد تحت هر شرایطی) اطمینان حاصل کنید.

- کدی بنویسید که از یک سو هر دولوپر دیگری بتواند از آن سر در بیاورد و از سوی دیگر، قابل پشتیبانی و گسترش باشد.

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

- هر موقعی که با کدی برخورد کردید، تمام تلاش خود را به کار گیرید تا حتی اگر شده اندکی آن را بهبود بخشید (اگر توانستید که ساختار را بهبود بخشید و اگر امکان‌پذیر نبود، حداقل با کامنت‌گذاری درک آن را بهبود بخشید).

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

*KhatKhati* · 18/9/20

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

اگر شما جزو دولوپرهایی هستید که در حین پیاده‌سازی پروژه‌های نرم‌افزاری اقدام به نوشتن Automated Test می‌کنید،‌ بایستی بدانید که این کار بسیار روند توسعهٔ نرم‌افزار شما را اثربخش می‌سازد و اگر هم جزو آن دسته از دولوپرهایی هستید که قبل از نوشتن کدهای اصلی، ابتدا به ساکن اقدام به نوشتن تست می‌کنید، بایستی به شما تبریک گفت؛ اما در عین حال سؤال اینجا است که آیا تست‌هایی که می‌نویسید خوب هستند؟

برای یافتن پاسخ به این سؤال، بایستی از خود بپرسید که «تست‌های نرم‌افزاری برای چه کسی نوشته می‌شوند؟» و چنانچه پاسخ به این سؤال چیزهایی همچون «برای خود دولوپر» یا «برای کامپایلر» باشد، این حاکی از آن است که تست‌های خوبی ننوشته‌اید!

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

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

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

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

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

*KhatKhati* · 18/9/20

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

وقتی که صحبت از اندازهٔ (Size) یک فانکشن یا تابع به میان می‌آید، منظور هم می‌تواند تعداد خطوطی که داخل فانکشن مد نظر نوشته شده باشد و هم تعداد تَسک‌هایی که آن فانکشن قرار است انجام دهد.

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

به عبارت دیگر، هر فانکشن نباید بیش از یک تَسک (کار) را انجام دهد که در چنین حالتی می‌گوییم فانکشن مد نظر دارای قابلیت Single Responsibility است

*KhatKhati* · 18/9/20

نود و هفت چیزی که هر برنامه‌نویسی باید بداند: طوری کد بزنید که گویی قرار است تا آخر عمر سورس‌کدتان را ساپورت کنید!

۹۶ چیزی که در این دورهٔ آموزشی مطرح شده یک طرف، پیاده‌سازی آنچه در ادامه می‌بینید طرف دیگر:

طوری کد بزنید که گویی قرار است تا آخر عمر سورس‌کدتان را ساپورت کنید!

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

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

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

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

*KhatKhati* · 18/9/20

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

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

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

آنچه مسلم است اینکه دولوپرها و تسترها هرگز نباید یکدیگر را «دشمن» تلقی کنند بدین صورت که مثلاً تسترها تمام تلاش خود را به کار بندند تا اپلیکیشنی که توسط همکارانشان کدنویسی شده را هک کنند تا به ایشان ثابت کنند که کار خود را بلد نیستند؛ بلکه هدف ارتقاء کیفیت کار است.

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

*KhatKhati* · 18/9/20

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

در کدنویسی مفهومی داریم تحت عنوان DRY که مخفف واژگان Don`t Repeat Yourself و به طور خلاصه این مفهوم حاکی از آن است که در کدنویسی هیچ‌گاه نمی‌بایست فانکشنی -یا به طور کلی کدی- که کار یکسانی انجام می‌دهد را دو بار بنویسیم. به عبارت دیگر،‌ در کدنویسی سیستم مد نظر، دوباره‌کاری ممنوع است.

نقطهٔ مقابل DRY،‌ مفهوم دیگری است تحت عنوان WET که مخفف واژگان Write Every Time است. به عبارت دیگر، وقتی برای کار واحد یا یکسانی بیش از یک بار فانکشنی -یا به طور کلی کدی- را بنویسیم، سورس‌کد ما اصطلاحاً WET شده است.

وقتی پای پرفورمنس (عملکرد) به میان می‌آید، تفاوت فاحشی مابین سورس‌کدهای به اصطلاح DRY و WET به میان می‌آید. برای روشن‌تر شدن این مسأله، مثالی می‌زنیم.

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

اما اگر فرض کنیم که متوجه شدیم که مشکل از همین X می‌باشد، اینجا است که اگر از رویکرد WET استفاده کرده باشیم، از این پس بایستی به دنبال هر ده جایی که X در آن استفاده شده گشته و مشکل آنها تک به تک رفع کنیم اما این در حالی است که اگر از رویکرد DRY در کدنویسی پروژه استفاده کرده باشیم، صرفاً در یک جا کد را می‌بایست ریفکتور کرده و به یک‌باره ۳۰٪ بهبود پرفورمنس را مشاهده خواهیم کرد.

به طور کلی، مزیت DRY نسبت به WET علاوه بر پرفورمنس بالاتر و سورس‌کد تمیزتر، امکان دیباگ کردن سریع‌تر سورس‌کد خواهد بود که این مسأله در پروژه‌های بزرگ بسیار حیاتی است.

*KhatKhati* · 18/9/20

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

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

نکته
به طور کلی، منظور از Verbose Loggin نوعی از لاگ‌گیری است که در آن اطلاعاتی بیش از آنچه لازم است ذخیره خواهیم ساخت (Verbose در لغت به معنای «استفاده از واژگان بیش از حد» است). در واقع، Verbose Loggin زمان به کار می‌آید که نیاز به موشکافی دقیق یک سیستم نرم‌افزاری داشته باشیم و بخواهیم آن را دیباگ کنیم و در حالت عادی غیرفعال می‌گردد چرا که منجر به ایجاد لاگ فایل‌های بسیار حجیم خواهد شد.
برای درک بهتر این مسأله، بایستی فرایند لاگ‌گیری نرم‌افزار را به علائم بیماری تشبیه کنیم. در حقیقت، ورم زیاد در ناحیهٔ شکم یک نوع علامت است و سرفه کردن هم‌ نوع دیگری از علائم بیماری. مسلماً کمتر کسی را می‌توان یافت که ورم ناحیهٔ شکم را جدی نگیرد و به آن بی‌توجهی کند چرا که از یک مشکل ساده در معده تا خدای ناکرده وجود یک غدهٔ سرطانی را می‌تواند شامل گردد اما این در حالی است که در بسیاری از مواقع، سرفه کردن صرفاً نشان از یک سرماخوردگی ساده دارد (البته همواره استثناء‌هایی وجود دارد).

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

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

*KhatKhati* · 18/9/20

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

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

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

for (i=0; i < strlen(s); ++i) {
if (... s ...) ...
}
در واقع، در تحلیل کد فوق بایستی گفت که استرینگ s به طور میانگین حاوی هزاران کاراکتر بود و با ایجاد یکسری تغییر در کد، مشکل بانک به سادگی حل شد! به عبارت دیگر، فراخوانی متد ()strlen تک‌تک هزاران کاراکتر موجود در s را شامل می‌شد و این در حالی بود که اگر دولوپر این کد از قبل طول این استرینگ را مشخص می‌کرد، می‌توانست هزاران فراخوانی متد ()strlen و بالتبع میلیون‌ها اجرای لوپ را از سیستم حذف کند. کد فوق به صورت زیر به سادگی بهینه شد:

n = strlen(s);
for (i=0; i < n; ++i) {
if (... s ...) ...
}
برخی دولوپرها بر این باورند که استراتژی «اول کدی بنویس که کار کند، سپس آن را بهینه کن» خیلی عالی است اما می‌بینیم که گاهی‌اوقات -همچون مثال فوق- چنین ایده‌ای اصلاً کار نمی‌کند و سیستم را با مشکل مواجه می‌سازد. اینجا است که اهمیت استفاده از یک الگوریتم مناسب دوچندان می‌گردد.

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

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

برخی بر این باروند که مهم‌ترین استراتژی در کدنویسی استفاده از کدهایی است که قبلاً نوشته شده است اما نکتهٔ مهم اینجا است که ما به عنوان یک دولوپر حرفه‌ای می‌بایست بدانیم که چه چیزی را چگونه و در چه زمانی استفاده کنیم (شاید مدیر آی‌تی بانک مذکور کد فوق را از داخل پروژه‌ای دیگر برداشته باشد که قرار بوده صرفاً تعداد کاراکتر معدودی به فانکشن ()strlen پاس داده شود که مسلماً در چنین شرایطی کد به خوبی کار می‌کرده است)

*KhatKhati* · 18/9/20

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

فارغ از اینکه با چه زبانی کد بزنیم، در چه حوزه‌ای به توسعهٔ اپلیکیشن بپردازیم و از چه ابزارهایی برای کدنویسی استفاده کنیم، برای دولوپرها استفاده از ابزارهایی که برای UNIX به بازار عرضه شده‌اند یک باید است.

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

نکتهٔ دیگری که در ارتباط با تفاوت‌های یک IDE با یک UNIX Tool وجود دارد این است که معمولاً محیط‌های توسعهٔ یکپارچه (IDE) از یکسری کامندهای از پیش‌ تعریف شده برخوردارند که دولوپرها با استفاده از آنها به کدنویسی می‌پردازند،؛ اما دولوپرها با استفاده از ابزارهای یونیکسی می‌توانند محیط‌های توسعهٔ نرم‌افزار کاستومایز شدهٔ خود را ایجاد کنند و بسته به تمایلات شخصی خود، دست به ساخت محیطی بزنند که سرعت توسعهٔ ایشان را چند برابر کند.

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

نکته
البته به خاطر داشته باشیم که در IDEها به سادگی می‌توان کلیدهای میانبر را شخصی‌سازی کرد و همین مسأله منجر به این خواهد گشت که مهاجرت از یک نرم‌افزار به نرم‌افزاری دیگر خیلی چالش‌برانگیز نباشد.
جالب است بدانیم که ابزارهای UNIX در عصری ابداع شدند که یک سیستم چندکاربره (Multiuser) حافظهٔ رَمی برابر با ۱۲۸ کیلوبایت داشت و طراحان چنین ابزارهایی می‌بایست به بهینه‌ترین شکل ممکن به کدنویسی ابزارهای مد نظرشان می‌پرداختند تا با استفاده از کمترین منابع سیستمی، کار چنین کاربر را راه بیندازند.

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

نکتهٔ دیگری که در ارتباط با ابزارهای یونیکسی که در سیستم‌عامل‌های مبتنی بر UNIX همچون لینوکس و مکینتاش وجود دارند این است که اکثر این ابزارها اپن‌سورس و رایگان هستند و همین مسأله میزان محبوبیت آنها را در میان دولوپرها دوچندان کرده است.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

درباره ما

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

آمار آنلاین