در حین کدنویسی به اطلاعات عمومی پیش‌فرض خود رحم نکنید چرا که خیلی از آنها اشتباه هستند!

در حین کدنویسی به اطلاعات عمومی پیش‌فرض خود رحم نکنید چرا که خیلی از آنها اشتباه هستند!

برخی از کسانی که تازه از دانشگاه از رشتهٔ نرم‌افزار فارغ‌التحصیل می‌شوند و یا کلاس‌های حضوری کدنویسی را با نمرهٔ ۹۰ پشت سر می‌گذارند، بر این باورند که یک برنامه‌نویس حرفه‌ای هستند و از فردا می‌توانند مشغول به کار شده و اصطلاحاً دست به کد شوند. خبر ناامیدوارکننده برای این دست افراد فعال در رشتهٔ نرم‌افزار این است که بازار کار برنامه‌نویسی به مراتب بی‌رحم‌تر از آنی است که تصور می‌شود! 

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

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

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

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

حال ممکن است این سؤال برای شما پیش بیاید که پس در اینجا نقش کارشناس AQ یا Quality Assurance چیست؟ کاری که یک متخصص یا کارشناس کنترل کیفیت انجام می‌دهد این است که مثلاً برای فرم‌های وب‌سایت طراحی شده توسط شما یک بار عدد ۰ را وارد می‌کند و بار دیگر عدد ۹۹۹۹۹۹۹۹۹۹۹۹. گاهی هم به جای وارد کردن آدرس ایمیل، آدرسی همچون lkjfdapifkn;dajf d را وارد می‌کند؛ همین و بس! و این در حالی است که یک اپلیکیشن اینترپرایز (تجاری) که قرار است به هزاران کاربران سرویس دهد، نیاز به چیزی بیش از این حرف‌ها دارد.

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

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

در واقع، پیش‌فرض‌هایی این‌چنین، باعث می‌شوند تا ما خیلی از شرایط استثنایی را نادیده بگیریم که در نهایت منجر به اذیت شدن کاربران می‌شود. به عنوان مثالی دیگر، بسیاری از برنامه‌نویسان دیدگاه اشتباهی در مورد زمان دارند که در ادامه به برخی از مهم‌ترین آن‌ها اشاره می‌کنیم:
- ماه‌های سال صرفاً ۳۰ یا ۳۱ روزه هستند.
- تعداد روزهای یک سال ۳۶۵ روز است.
- سروری که نرم‌افزار ما روی آن نصب است همواره بر اساس زمان GMT کار می‌کند.
- سروری که نرم‌افزار ما روی آن نصب هست، همواره مثل ساعت کار می‌کند!
- اگر هم‌ زمان سرور اشتباه باشد، این اختلاف ساعت صرفاً در حد ثانیه است.
- زمان سرور و زمان ست شده روی سیستم کاربر همواره یکسان هستند و ...

در واقع، پیش‌فرض‌هایی که ما برنامه‌نویسان در مورد زمان داریم، گاهی‌اوقات کاملاً اشتباه از آب درآمده و همین مسئله منجر می گردد تا کاربران اپلیکیشن، وب اپلیکیشن یا نرم‌افزار ما سردرگم شوند. به عنوان مثالی دیگر هم می‌توان جنسیت کاربران را مد نظر قرار داد. خیلی از برنامه‌نویسان بر این باورند که:
- کاربران یا مذکر هستند یا مؤنث.
- جنسیت صرفاً از روی بیولوژی یک فرد تعیین می‌شود.
- وقتی کاربری در حین ثبت‌نام جنسیت خود را تعیین کرد، این جنسیت دیگر تغییر نخواهد کرد!
- آدم بدون جنسیت نداریم و …

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

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

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