برخی از کسانی که تازه از رشتهٔ نرمافزار فارغالتحصیل میشوند و یا کلاسهای حضوری کدنویسی را با نمرهٔ عالی پشت سر میگذارند بر این باورند که یک برنامهنویس حرفهای هستند و بلافاصله میتوانند اصطلاحاً دست به کد شوند اما خبر ناامیدوارکننده برای ایشان این است که بازار کار برنامهنویسی به مراتب دشوارتر از آنی است که تصور میشود که در همین راستا در این مقاله قصد داریم به بیان راهکارهایی بپردازیم که از آن طریق هم برنامهنویسان حرفهای و نیمهحرفهای و هم کسانی که تازهکار هستند میتوانند اپلیکیشنهای حرفهایتری طراحی کرده که در نهایت تجربهٔ کاربری بهتری برای کاربران به ارمغان خواهند آورد.
حرفهٔ توسعهٔ نرمافزار کاری است خلاقانه، پولساز و در عین حال مترقی اما در کنار این ویژگیها باید دشواری کار در این صنعت را هم افزود چرا که حساسیت این کار نسبت به خیلی از مهارتها و رشتههای دیگر بیشتر است (از معدود رشتههایی که اشتباه در آن مهلکتر از برنامهنویسی است، شاید بتوان به علم پزشکی اشاره کرد که اشتباه مساوی است با مرگ البته همانطور که در مقالهٔ آشنایی با مفهوم Defensive Programming در صنعت توسعهٔ نرمافزار اشاره شد، گاهی اوقات باگهای نرمافزاری نیز منجر به کشته شدن انسانها میشوند!)
اهمیت تست اپلیکیشن
خیلی از دولوپرها هستند که کدهای تمیزی مینویسند، الگوریتمها را به خوبی پیادهسازی میکنند، مفاهیم شیئگرایی را میدانند، به برنامهنویسی سهلایه تسلط دارند اما غافل از اینکه کدهای خود را آنطور که باید و شاید تست نمیکنند و این عدم تست کامل و جامع اپلیکیشن منجر میگردد تا کاربران بالقوهٔ خود را به تِستِرهای نرمافزار مبدل ساخته و به جای آنکه خود به سردردهای شدید به خاطر کار نکردن بخشهایی از اپلیکیشن دچار شویم، ایشان را به چالش خواهیم کشاند.
در یک کلام، آشنایی با مهارتهای تست اپلیکیشن و به نوعی رحم نکردن به کدهایی که خود نوشتهایم، به منزلهٔ یکی از اساسیترین معیارهای انتخاب یک برنامهنویس خوب است چرا که در غیر این صورت، به هر میزان هم که اپلیکیشن ما کاربردی باشد، کاربر عادی حوصلهٔ سر و کله زدن با باگها را نداشته و آن را ترک خواهد کرد.
حال ممکن است این پرسش پیش آید که پس در اینجا نقش مسئول Quality Assurance یا به اختصار AQ چیست؟ کاری که یک متخصص یا کارشناس کنترل کیفیت انجام میدهد این است که مثلاً برای فرمهای وبسایت یک بار عدد ۰ را وارد میکند و بار دیگر عدد ۹۹۹۹۹۹۹۹۹۹۹۹ و گاهی هم به جای وارد کردن آدرس ایمیل، آدرسی همچون lkjfdapifkn;dajf d را وارد میکند و این در حالی است که یک اپلیکیشن اینترپرایز (تجاری) که قرار است به هزاران کاربران سرویس دهد، نیاز تستی به مراتب جامعتر از این دارد.
گفته میشود که بزرگترین دشمن هر دولوپری خود است بدین شکل که اگر شما یک دولوپر فرانتاند هستید، باید رابط کاربری را در مرورگرهای مختلف تست کنید تا از واکنشگرا بودن آن اطمینان حاصل کنید و به عنوان یک دولوپر بکاند در ورودی فرمهای خود هر چیزی وارد کنید تا اطمینان حاصل کنید که مثلاً رجیکس شما به خوبی کار میکند (برای آشنایی بیشتر با این اصطلاح، به دورهٔ آموزش رگیولار اکسپرشن مراجعه نمایید.)
برای روشنتر شدن این مسأله، مثالی در مورد نام در پروسهٔ ثبتنام کاربران میزنیم. فرض کنیم اپلیکیشنی نوشتهایم که در آن کاربران باید نام خود را وارد کنند. به طور معمول، برنامهنویسان چنین پیشفرضهایی در مورد اسامی کاربران دارند:
- کاربران یک نامخانوادگی بیشتر ندارند و در همه جا هم آن را استفاده میکنند.
- کاربران همواره یک اسم و فامیل واحد دارند.
- به هر میزان هم که نام شخصی طولانی باشد، بیش از یک فضای استاندارد (مثلاً ۲۰ کاراکتر) نیست.
- نام کاربران هرگز تغییر نمیکند.
- کاربران در نوشتن نام خود از علائم خاصی استفاده نمیکنند و همانطور که نامشان روی کارت ملیشان نوشته شده از آن استفاده میکنند.
در واقع، پیشفرضهایی اینچنین باعث میشوند تا ما خیلی از شرایط استثنایی را نادیده بگیریم که در نهایت منجر به رقم خوردن تجربهٔ کاربری بدی برای مخاطبین اپلیکیشن میشود. به عنوان مثالی دیگر، بسیاری از برنامهنویسان دیدگاه اشتباهی در مورد زمان دارند که در ادامه به برخی از مهمترین آنها اشاره میکنیم:
- ماههای سال صرفاً ۳۰ یا ۳۱ روزه هستند.
- تعداد روزهای یک سال ۳۶۵ روز است.
- سروری که نرمافزار ما روی آن نصب است همواره بر اساس GMT کار میکند.
- سروری که نرمافزار ما روی آن نصب میباشد همیشه دقیق است (اگر هم زمان سرور اشتباه باشد، این اختلاف ساعت صرفاً در حد ثانیه است.)
- زمان سرور و زمان سِتشده روی سیستم کاربر یکسان هستند.
در حقیقت، پیشفرضهایی که ما برنامهنویسان در مورد زمان داریم، گاهی اوقات کاملاً اشتباه از آب درآمده و همین مسئله منجر میگردد تا کاربران سردرگم شوند. به عنوان مثالی دیگر هم میتوان جنسیت کاربران را مد نظر قرار داد. خیلی از برنامهنویسان بر این باورند که:
- کاربران یا مذکر هستند یا مؤنث.
- جنسیت صرفاً از روی بیولوژی یک فرد تعیین میشود.
- وقتی کاربری در حین ثبتنام جنسیت خود را تعیین کرد، این جنسیت دیگر تغییر نخواهد کرد.
- آدم بدون جنسیت نداریم.
فرض کنید که وبمستر فروشگاه آنلاینی هستید که بر اساس جنسیت کاربران، یکسری محصولات خاص را قرار است تا در معرض دید ایشان قرار دهید. حال اگر برنامهنویس فروشگاه آنلاین شما پیشفرضهایی همچون موارد فوق داشته و بر همین اساس محصولات خاصی را برای جنسیت خاصی به نمایش درآورید، ممکن است برخی کاربران سایت گیج شوند. به عنوان مثال آخر هم میتوان به باورهای نادرست در مورد مکانیهای جغرافیایی که برنامهنویسان دارند اشاره کرد که برخی از مهمترین آنها عبارتند از:
- مکانها صرفاً دارای یک نام رسمی هستند.
- شهرها و کشورهای مختلف دنیا در تمامی زبانها یکجور تلفظ میشوند.
- نام مکانهای جغرافیایی با استفاده از استانداردهای زبان معیار همان کشور نوشته میشود.
- با کاراکترهای رایج هر رسمالخطی میتوان نام مکانهای جغرافیایی را نوشت.
- در هر شهری در ایران، صرفاً یک خیابان با نام مثلاً «ولیعصر» وجود دارد.
نتیجهگیری
یک برنامهنویس خوب کسی نیست که فقط خوب کد بزند بلکه کسی است که به سایر مهارتها همچون تفکر انتقادی، تفکر الگوریتمیک و ... نیز تسلط داشته و یک تِستِر خوب به معنای واقعی کلمه باشد و از همه مهمتر اینکه به مسائل از زوایای مختلفی نگاه کند تا در نهایت بتواند اپلیکیشنی روانهٔ بازار کند که کاربران از تعامل با آن لذت میبرند.
علاوه بر این، با قرار دادن اپلیکیشن در شرایطی دشوار و بیثبات میتوان از بُعد فنی هم برخی باورهای پیشفرض خود را به چالش کشیده و از عملکرد صحیح سیستم در شرایط مختلف اطمینان حاصل کرد که در همین راستا میتوانید به مقالهٔ چگونه اپلیکیشن خود را به چالش بکشیم تا از عملکردش اطمینان حاصل کنیم؟ مراجعه نمایید.
حال نوبت به نظرات شما میرسد. آیا با آنچه در این پست مطرح شد موافقید؟ همچنین اگر به غیر از موارد فوقالذکر پیشفرضهای اشتباه دیگری که برخی برنامهنویسان دارند را به خاطر میآورید، میتوانید نظرات و دیدگاههای خود را با سایر کاربران سکان آکادمی به اشتراک بگذارید.