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

*KhatKhati* · 18/9/20

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

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

اگر دوست دارید برچسب حرفه‌ای روی شما بخورد، همواره می‌بایست مسئولیت کاری که انجام می‌دهید را بپذیرید؛ شما در قبال به‌روز بودن در حوزهٔ کاری خود و آخرین تکنولوژی‌های عرضه شده به بازار مسئول هستید. جالب است بدانید بسیار از دولوپرهای تازه‌کار هستند که بر این باورند وظیفهٔ کارفرمای ایشان است که به ایشان آموزش دهد که این تصور کاملاً اشتباه است! هیچ کارفرمایی آن‌قدر وقت و هزینه ندارد که شروع به آموزش و به‌روز کردن تک‌تک اعضای تیم توسعهٔ نرم‌افزار خود کند با علم به این که در آینده‌ای نه‌چندان دور، دولوپر خود را از دست خواهد داد (لازم به‌ذکر است که عمر دولوپرها در شرکت‌های نرم‌افزاری بیش از ۳ الی ۴ سال نیست).

بازهم اگر دوست دارید حرفه‌ای دیده شوید، می‌بایست مسئولیت کدی که می‌زنید را ۱۰۰٪ قبول کنید. هیچ دولوپر حرفه‌ای را سراغ نداریم که پیش از اطمینان حاصل کردن از عملکرد کدش، آن‌را ریلیس کند. درواقع، دولوپرهای حرفه‌ای اصلاً واهمه‌ای از متخصصین QA (این اصطلاح مخفف واژگان Quality Assurance به‌معنی تضمین کیفیت است) ندارند چراکه می‌دانند ایشان هیچ باگی در کدی که ایشان نوشته‌اند نخواهند یافت.

یکی دیگر از خصیصه‌های دولوپرهای حرفه‌ای این است که ایشان در کار تیمی (Team Work) مهارت دارند. ایشان مسئولیت خروجی کار کل تیم را برعهده می‌گیرند و تحت هیچ عنوان از زبان ایشان نمی‌شنویم که «من فقط فلان X رو نوشتم و این کد مال من نیست». دولوپرهای حرفه‌ای به دیگر همکاران خود -به‌خصوص کسانی‌که تازه‌کار هستند- کمک می‌کنند، به یکدیگر یاد می‌دهند، از همدیگر یاد می‌گیرند و در یک کلام، دیگران را ساپورت می‌کنند.

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

کدنویسی تمیز هم یکی دیگر از خصیصه‌های دولوپرهای حرفه‌ای است. کدی که یک دولوپر حرفه‌ای زده باشد در مقایسه با یک شخص غیرحرفه‌ای، بسیار تمیز با ساختاری قابل‌درک و درعین‌حال قابل‌ خواندن است. دولوپرهای حرفه‌ای همواره از استانداردهای کدنویسی (Best Practices) در حین کدنویسی استفاده می‌کنند و همین مسئله منجر به این خواهد گشت که دیگر دولوپرها در خواندن سورس‌کد ایشان به مشکل برنخواهند خورد.

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

*KhatKhati* · 18/9/20

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

پیام‌های خطا (Error Messages) یکی از رایج‌ترین راه‌های ارتباطی کاربران با سیستم پیش‌رویشان است و درواقع این پیام‌‌ها خبر از اتفاقی غیرمنتظره می‌دهند.

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

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

علاوه‌بر این، گاهی‌اوقات تنبلی دولوپرها هم منجر به سختی کشیدن بیشتر کاربران درحین استفاده از اپلیکیشن می‌شود. برای روشن‌تر شدن این مسأله، مجدد به مثال فوق بازمی‌گردیم؛ وقتی که کاربران با فیلدی که برای درج تاریخ درمعرض دیدشان قرار می‌گیرند مواجه می‌شوند، ممکن است تاریخ مدنظر خود را به‌صورت مثلاً 14-12-1390 وارد کنند اما این درحالی است که پس از ارسال دیتا برای سرور، صرفاً فرمتی همچون ۱۳۹۰/۱۲/۱۴ قابل‌قبول است و دادهٔ ورودی کاربر غیرقابل‌قبول تلقی می‌گردد.

در چنین شرایطی، دولوپرها ۲ راه‌کار پیش‌رو دارند؛ راه‌کار اول این که انواع فرمت‌هایی که کاربر می‌تواند وارد کند را تفسیر کرده و در دیتابیس ذخیره سازند (مثلاً فرمت‌هایی همچون 14-12-1390 یا ۱۳۹۰/۱۲/۱۴ یا حتی بااستفاده از اسپیس و به‌صورت 14 12 1390) و راه‌کار دوم این که صرفاً یک فرمت را مدنظر قرار داده و اگر کاربری چیزی به غیر از آن‌را وارد ساخت، خیلی ساده یک پیام خطا درمعرض دیدش قرار دهند.

از آنجا که راه‌کار دوم بار کدنویسی کمتری روی دولوپر دارا است، اکثر دولوپرها چنین راه‌کاری را انتخاب می‌کنند غافل از این‌که انتخاب چنین رویکردی باعث سردرگمی بیشتر کاربران می‌شود!

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

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

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

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

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

*KhatKhati* · 18/9/20

نود و هفت چیزی که هر برنامه‌نویسی باید بداند: آشنایی با تفاوت Static Typing و Dynamic Typing در برنامه‌نویسی

پیش از هرچیز، به این نکته توجه داشته باشیم که در اینجا منظور از Type، نوع داده‌ای است که با آن سرورکار خواهیم داشت. به‌طورکلی، زبانی که به‌اصطلاح Statically Typed است در آن نوع متغیرها در زمان کامپایل شدن (Compile Time) برنامه‌ مشخص می‌گردد که از آن جمله می‌توان به زبان‌های جاوا، اسکالا، سی‌شارپ، سی و سی‌پلاس‌پلاس اشاره کرد و همین مسأله منجر به این خواهد گشت که پرفورمنس برنامه بالا رود چراکه هر دفعه که برنامه اجرا می‌گردد، دیگر نیازی به چک کردن نوع متغیرها نخواهد بود (لازم به‌ذکر است که این فیچر به‌عنوان یکی از برگ‌برنده‌های زبان‌هایی از این دست است).

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

String str = "Hello World";
str = 7;
همان‌طور که در کد فوق ملاحظه می‌شود، ابتدا متغیری از جنس String با مقدار Hello World ایجاد کرده‌ایم که در این صورت برنامه بدون هیچ مشکلی کامپایل خواهد شد اما در خط دوم، مجدد مقدار این متغیر را برابر با یک عدد صحیح درنظر گرفته‌ایم و از آنجا که تایپ عدد صحیح با تایپ استرینگ متفاوت است، در حین کامپایل شدن برنامه با اکسپشن مواجه خواهیم شد.

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

زبانی هم که به‌اصطلاح Dynamically Typed است در آن نوع متغیرها در حین اجرای برنامه‌ (Run Time) مشخص می‌شود و دولوپر در حین کدنویسی نیازی به مشخص کردن دیتاتایپ‌ متغیر نخواهد داشت که از آن جمله می‌توان به زبان‌های پایتون، جاوااسکریپت و پی‌اچ‌پی اشاره کرد.

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

$str = "Hello World";
$str = 7;
می‌بینیم که در خط اول متغیری تحت‌عنوان str$ ساخته‌ایم که حاوی مقدار Hello World است و در خط دوم هم این مقدار که پیش از این استرینگ بود را به یک عدد صحیح (Integer) تغییر داده و برنامه هم بدون هیچ مشکلی اجرا خواهد شد.

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

*KhatKhati* · 18/9/20

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

یکی از چیزهایی که باعث ارتقاء تیم‌های برنامه‌نویسی می‌شود، Pair Programming یا «برنامه‌نویسی دونفره» است؛ اگر شما برنامه‌نویس تازه‌کاری هستید که زیردست یک برنامه‌نویس ارشد هستید، می‌بایست به‌معنای واقعی کلمه صبور بوده و از مواجهه با دولوپرهای باتجربه‌تر از خود ترس به دلتان راه ندهید چراکه ایشان به‌منزلهٔ منبع ارزشمندی از اطلاعات هستند که چیزهای بسیاری از آن‌ها می‌توانید یاد بگیرید.

برنامه‌نویسی دونفره در تیم‌های نرم‌افزاری کمک به انتقال دانش مابین اعضای تیم می‌کند گرچه درظاهر ممکن است به‌نوعی اتلاف وقت تلقی گردد. برنامه‌نویسی دونفره مزایای بسیاری دارا است که در ادامه برخی از مهم‌ترین آن‌ها را برخواهیم شمرد:

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

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

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

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

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

*KhatKhati* · 18/9/20

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

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

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

اسکریپت‌نویسی معمولاًً به زبانی به غیر از زبان اصلی دولوپر صورت‌ می‌گیرد و همین مسأله منجر به این خواهد گشت تا دولوپرها خیلی تمایلی به این کار نداشته و این‌گونه اسکریپت‌نویسی‌ها را به دیگر اعضای تیم واگذار کنند!

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

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

*KhatKhati* · 18/9/20

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

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

در همین راستا، در حین کدنویسی همواره این سؤال را از خود بپرسید که آیا سورس‌کدتان به‌وضوح کامل چند و چون نرم‌افزار را هم برای خودتان و هم برای دیگر دولوپرها بیان می‌کند؟

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

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

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

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

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

نکته
به‌طور‌کلی، منظور از سورس‌کدهای Legacy کدهایی است که خیلی قدیمی هستند و دیگر ساپورت نمی‌شوند.

*KhatKhati* · 18/9/20

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

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

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

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

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

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

*KhatKhati* · 18/9/20

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

کسانی که اقدام به تست نرم‌افزار به‌منظور اطمینان حاصل کردن از صحت عملکردش می‌کنند معمولاً با نام‌هایی همچون Quality Assurance ،Quality Control و یا Tester شناخته می‌شوند اما از دید دولوپرها فرقی نمی‌کند این متخصصین را چه بنامیم چراکه ایشان این گروه از افراد را «معضل» قلمداد می‌کنند!

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

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

برای روشن‌تر شدن اهمیت این مسأله، مثالی می‌زنیم؛ فرض کنیم شما دولوپری هستید که روی پروژه‌ای مرتبط با هوش مصنوعی کار می‌کنید (یکی از پیچیده‌ترین نمونه نرم‌افزارهایی که در صنعت IT می‌توان پیاده‌سازی کرد).

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

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

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

*KhatKhati* · 18/9/20

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

Polymorphism (پالیمورفیزم یا چندشکلی) یکی از ستون‌های برنامه‌نویسی شیٔ‌گرایی است؛ این اصلاح ریشهٔ یونانی دارد که از ۲ بخش Poly به‌معنی «چند» و Morph به‌معنی «شکل» تشکیل شده است و این اصطلاح در برنامه‌نویسی شیٔ‌گرایی به الگویی اشاره دارد که بر آن اساس، کلاس‌های مختلف با عملکردهای مجزا از یکدیگر می‌توانند از ساختار و کاربری یکسانی بهره‌مند گردند.

پالیمورفیزم یا چندشکلی در برنامه‌نویسی مفهوم نسبتاً پیچده است که صرفاً با ذکر مثال می‌توان به‌خوبی مفهوم آن را درک کرد؛ لذا در ادامه سعی خواهیم کرد این مفهوم را بااستفاده از زبان PHP تشریح کنیم.

فرض کنیم یکسری کلاس داریم که مسئول ایجاد اشکالی همچون، دایره، مستطیل و … هستند؛ هریک از این اشکال دارای شکل متفاوتی نسبت به بقیه هستند اما همگی در یک چیز مشترک هستند و آن‌هم این که همهٔ اشکال دارای مساحتی هستند که بااستفاده از یک فانکشن می‌توان آن‌را محاسبه کرد.

مثلاً برای این‌کار می‌توان فانکشنی تحت‌عنوان ()calcArea درنظر گرفت که در تمامی کلاس‌ها وجود دارد، اما در کلاس دایره مساحت را به یک شکل (Morph) محاسبه می‌کند و در کلاس مستطیل به شکلی دیگر.

چگونه پالیمورفیزم را پیاده‌سازی کنیم؟
به‌منظور پیاده‌سازی این مفهوم در برنامه‌نویسی شیٔ‌گرایی، یا باید از Interfaceها استفاده نمود و یا از کلاس‌های به‌اصطلاح Abstract؛ که در ادامه استفاده از اینترفیس‌ها را با ذکر مثال توضیح خواهیم داد (جهت آشنایی بیشتر با مفهوم اینترفیس، به آموزش نود و هفت چیزی که هر برنامه‌نویسی باید بداند: استفادهٔ نادرست از اینترفیس‌ها را غیرممکن سازید مراجعه نمایید).

همان‌طور که در ادامه مشاهده می‌کنید، اینترفیسی داریم تحت‌عنوان Shape که حاوی فانکشنی تحت‌عنوان ()calcArea است و هر کلاسی که از این اینترفیس استفاده کند، باید دارای چنین فانکشنی باشد:

interface Shape {
public function calcArea();
}
حال اقدام به نوشتن کلاس مربوط به دایره می‌کنیم که اینترفیس فوق‌الذکر روی آن اعمال شده است:

class Circle implements Shape {
private $radius;

public function __construct($radius) {
$this->radius = $radius;
}

// calcArea calculates the area of circles
public function calcArea() {
return $this->radius * $this->radius * pi();
}
}
مجدد دست به ساخت کلاس دیگری این‌بار برای شکل مستطیل می‌زنیم که همانند کلاس مربوط به دایره است با این تفاوت که کدهای قرار گرفته داخل فانکش ()calcArea متفاوت است:

class Rectangle implements Shape {
private $width;
private $height;

public function __construct($width, $height) {
$this->width = $width;
$this->height = $height;
}

// calcArea calculates the area of rectangles
public function calcArea() {
return $this->width * $this->height;
}
}
حال اقدام به ساخت آبجکت‌هایی از روی این ۲ کلاس کرده سپس بااستفاده از فانکشن ()calcArea مساحت شکل را محاسبه می‌کنیم:

$circ = new Circle(3);
echo $circ->calcArea();

$rect = new Rectangle(3, 4);
echo $rect->calcArea();
خروجی کدهای فوق به‌صورت زیر خواهد بود:

28.274333882308
12
در حقیقت، چندشکلی یا پالیمورفیزم این‌گونه تفسیر می‌شود که ما فانکشنی ثابت داریم تحت‌عنوان ()calcArea اما این درحالی است که این فانکشن بسته به این‌که در کدام کلاس قرار گرفته باشد، عملکردی متفاوت از خود نشان خواهد داد و به‌نوعی خود را در چند شکل مختلف عرضه می‌کند.

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

*KhatKhati* · 18/9/20

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

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

در عصر حاضر کدام رمان‌نویس مشهوری را می‌شناسید که در نگارش رمانش از لغات سخت، پیچیده و تاریخ‌گذشته استفاده کند؟ مگر غیر از این است که رمان‌هایی که امروزه در بازار به چاپ صدم و بالاتر می‌رسند همگی از نثری ساده و قابل‌فهم -حتی برای گروه‌های سنی پایین- برخورداند. اصلاً منکر فاخر بودن گلستان سعدی نیستیم، اما بعید به‌نظر می‌رسد که نثر زیر به‌سادگی قابل درک باشد:

یاد دارم که در ایام طفلی متعبد بودمی و شب‌خیز و مولع زهد و پرهیز. شبی در خدمت پدر -علیه الرحمه- نشسته بودم و همه شب دیده برهم نبسته و مُصحف عزیز در کنار گرفته و طایفه‌ای گرد ما خفته. پدر را گفتم یکی از اینان سر بر نمی‌دارد که دوگانه‌ای بگذارد و چنان خواب غفلت بـرده‌اند که گویی نخفته‌اند که مرده‌اند. گفت جان پدر! تو نیز اگر بخفتی به که در پوستین خلق افتی.

حال به بخشی از کتاب دا نوشته سیده زهرا حسینی تحت‌عنوان «و بالاخره خرمشهر آزاد شد» نگاهی می‌اندازیم:

بالاخره ساعت ۲، روز سوم خرداد سال 1361 اعلام کردند خرمشهر آزاد شد؛ چه‌کسی می‌توانست حال‌و‌هوای ما را از شنیدن این خبر درک کند. توی ساختمان کوشک ولوله‌ای افتاد، همه یکدیگر را بغـ*ـل کرده و از خوشحالی گریه می‌کردند. مردم و همسایه‌های تهرانی ما تبریک می‌گفتند؛ همه خوشحال بودند. از خوشحالی نمی‌دانستیم چه‌کار کنیم و رفتیم بیرون ساختمان؛ مردم و کارمندان اداره‌ها همه از شادی این خبر کارشان را رها کرده و به خیابان آمده بودند. همه‌جا پر از هیاهو و سر‌و‌صدا شده بود. همه‌جا شادی موج می‌زد و ...

از مقایسهٔ این ۲ نثر می‌توان به‌ این نتیجه رسید که فارغ از ارزش ادبی هر کدام، نثر برگرفته از کتاب دا به‌مراتب قابل‌فهم‌تر است. به‌ یاد داشته باشیم که نگـاه دانلـود‌نویس حرفه‌ای می‌داند که خوانندگان از خرید کتابش چند هدف دارند که مهم‌ترین آن‌ها عبارتند از:
- گذران وقت
- آشنایی با تاریخ
- لـ*ـذت بردن
- ارتباط برقرار گرفتن با داستان
- کسب تجربه
- یادگیری و …

حال اگر هریک از پارامترهای فوق -و حتی دیگر ویژگی‌های نگـاه دانلـود خوب- غايب باشند، احتمال فراگیر شدن رمان در بین خوانندگان کم‌رنگ و کم‌رنگ‌تر خواهد شد.

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

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

حال همان‌طور که ۲ نثر متکلف و ساده را در بالا با یکدیگر مقایسه کردیم، در ادامه قصد داریم برنامه‌ٔ معروف Hello World را به ۲ صورت پیچیده و ساده بااستفاده از زبان ++C بنویسیم؛ ابتدا با برنامه‌ٔ پیچیده شروع می‌کنیم:

#include < iostream >

class AbstractHello {
public:
virtual~AbstractHello() {
std::cout << " World!";
}
void Prnt() {
std::cout << "Hello";
}

};

class ChildHello: public AbstractHello {
public:
~ChildHello() {
Prnt();
}
};

int main() {
ChildHello * Obj;
Obj = new ChildHello;
delete Obj;
}
حال همین برنامه‌ را می‌توان با تعداد خطوط کد کمتر و درعین‌حال قابل‌فهم‌تر به‌صورت زیر نوشت:

#include < iostream >

int main() {
std::cout << "Hello World!";
}
به‌عنوان خروجی هر دو برنامه داریم:

Hello World!
به‌طور خلاصه، یک دولوپر خوب کسی است که کدی بنویسد که از ویژگی‌های زیر برخوردار باشد:
- اسامی کلاس‌ها، فانکشن‌ها، متغیرها و … قابل‌فهم اما درعین‌حال ساده باشند.
- ساختار فولدرها و فایل‌ها همگون و سرراست باشند.
- استاندارد کدنویسی یکسانی در جای‌جای پروژه اعمال شده باشد.
- به‌گونه‌ای کدنویسی کند که به‌جای کامنت‌گذاری، خود سورس‌کد گویای ماهیتش باشد.
- و درنهایت کدنویسی‌اش طوری باشد که اگر یک برنامه‌نویس تازه‌کار هم به مرور سورس‌کد پرداخت، بتواند ارتباط بین اجزای مختلف کد را درک کند.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

درباره ما

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

آمار آنلاین