چطور (تقریباً) هر چیزی را در git به حالت قبلی برگردانیم؟ قسمت اول

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

در این تغییرات، بخش‌هایی از تولید محتوای آرایه دچار تغییراتی شده‌اند که به تدریج شاهد این تغییرات خواهید بود. برای یک شروع خوب در مطالب آرایه بعد از وقفه چند ماهه، از Git‌ خواهیم نوشت.

در آرایه از Git بر روی TFS به عنوان Source Control استفاده می‌کنیم، کدهای backup‌ گرفته شده روی اینترنت نیز از Git به عنوان سورس کنترل استفاده می‌کنند.

این نوشته ترجمه خلاصه شده‌ای است از How to undo (almost) anything with Git که در وبلاگ گیت‌هاب انتشار یافته است و از سهیل رشیدی برای معرفی آن در خبرنامه iDevCenter تشکر می‌کنیم.

undo کردن تغییر عمومی (Public)

سناریو: شما از دستور git push  استفاده کردید و تغییرات را به گیت‌هاب فرستادید و حالا متوجه شدید که یکی از commit ها مشکلی دارد، می‌خواهید آن commit را undo کنید.

دستور Undo: برای سناریو بالا از دستور زیر استفاده کنید:

git revert 
تعمیر توضیح آخرین commit

سناریو: در آخرین commit اشتباه تایپی دارید، دستور شما مثلاً  git commit -m "Fxies bug #42" بوده است اما قبل از git push متوجه شدید که Fixes اشتباه تایپ شده است.

دستور Undo: برای سناریو بالا از دستور زیر استفاده کنید:

git commit --amend or git commit --amend -m "Fixes bug #42"
Undo کردن تغییرات محلی (local changes)

سناریو: گربه‌ای روی کیبورد راه رفته و تغییرات ایجاد شده هم به شکلی ذخیره شده‌اند.، بعد ادیتور هم crash کرده است. شما این تغییرات را commit نکرده‌اید و می‌خواهید فایل را به حالت قبلی‌اش (آخرین commit) برگردانید.

دستور Undo: برای سناریو بالا از دستور زیر استفاده کنید

git checkout --

به یاد داشته باشید هر تغییری که به این شیوه Undo می‌کنید واقعاً از بین خواهد رفت. در واقع تغییرات در این حالت هیچ وقت commit‌ نمی‌شوند و لذا git در بازیابی ‌آن‌ها به ما کمکی نخواهد کرد. بنابراین پیش از استفاده از این دستور، مطمئن شوید می‌دانید چه چیزهایی را دور می‌ریزید. از git diff استفاده کنید تا مطمئن شوید کارتان برای undo کردن درست است

پی‌نوشت: به خاطر طولانی بودن مطلب اصلی، ترجمه آن در قالب چند نوشته مجزا منتشر خواهد شد


به اشتراک گذاری این نوشته در شبکه‌های اجتماعی

۱۰ اصل برای داشتن یک رابط کاربری خوب

یک قول قدیمی

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

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


اصل اول: شفافیت وضعیت سیستم

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

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

اصل دوم: هماهنگی بین سیستم و دنیای واقعی

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

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

اصل سوم: کنترل و آزادی کاربر

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

اصل چهارم: ثبات و استانداردها

کاربران نباید درگیر کلمات، شرایط یا کارهای به ظاهر متفاوتی که معنی یکسانی دارند بشوند.

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

اصل پنجم: جلوگیری از خطا

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

اصل ششم: شناسایی بهتر از به خاطر آوردن

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

اصل هفتم: انعطاف پذیری و کارآمدی در استفاده

هر نرم‌افزاری ممکن است توسط کاربران مبتدی یا کاربران حرفه‌ای مورد استفاده قرار گیرد. به کاربران اجازه بدهید که کارهای تکراری را ساده‌تر کنند.

اصل هشتم: طراحی زیبا و مینیمال

دیالوگ‌های بین انسان و نرم‌افزار نباید حاوی اطلاعات غیرمرتبط یا اطلاعاتی که کمتر مورد نیاز هستند باشند. 

اصل نهم: به کاربران کمک کنید تا خطاها را بشناسند، تشخیص بدهند و ترمیم کنند

پیغام‌های خطا باید به زبان طبیعی انسانی بیان شوند و نه با کد. این پیغام‌ها باید به طور مشخص، مشکل را بیان کنند و به شکل سازنده، راه حلی برایش ارائه کنند.

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

اصل دهم: راهنما و مستندات 

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

شما چه ایده‌ای برای بهتر شدن تعامل بین کاربران و نرم‌افزارها و ایجاد نرم‌افزارهای بهتر دارید؟

به اشتراک گذاری این نوشته در شبکه‌های اجتماعی

رفع خطاهای معمول و تکمیل راه‌اندازی Build Server برای TFS 2013

Build به کمک  TFS

اگر سری نوشته‌های تست جوئل را دنبال کرده باشید، حتماً درباره اهمیت build روزانه خوانده‌اید. برای داشتن یک روال build خوب ابتدا باید یک build serer داشته باشید. خوشبختانه TFS به خصوص در نسخه‌های جدید، کار build را برای پروژه‌های تیمی بسیار ساده کرده است. در این نوشته درباره خطاهایی که پس از نصب سرویس build در TFS ممکن است با آن‌ها برخورد داشته باشید و راه حل آن‌ها صحبت می‌کنیم.

در توسعه نرم‌افزار آرایه، ما به صورت گسترده از TFS 2013 استفاده می‌‌کنیم. از میان ویژگی‌های اصلی TFS در حوزه Source Control پیشتر از نرم‌افزار داخلی TFS و به تازگی از Git بر روی TFS استفاده می‌کنیم. در حوزه برنامه‌ریزی کارها، از نسخه سفارشی شده‌‌ای از فرم‌های TFS برای ایجاد و رهگیری وظایف برنامه‌نویسی استفاده می‌کنیم که به زودی از آن خواهیم نوشت. در حوزه build نیز از امکان سرویس build موجود در TFS بهره می‌گیریم. به کمک این سرویس انجام آزمون‌های واحد را نیز در هر build کنترل می‌کنیم. در شش ماه دوم سال ۹۳ همچنین برنامه گسترده‌ای برای استفاده از قابلیت‌های Test (به جز اجرای اتوماتیک آزمون‌ها در هنگام build) و Microsoft Test Manager داریم.

در این نوشته درباره خطاها و هشدارهایی که پس از نصب سرویس build به آن‌ها برخورد کردیم و روش حل آن‌ها می‌نویسیم. لازم به ذکر است پیش‌فرض این نوشته این است که شما TFS و Build Controller و Build Agent مورد نظر را نصب و تنظیم کرده‌اید. build server ما بر روی ویندوز سرور ۲۰۱۲ ایجاد شده است و بر مبنای TFS 2013 می‌باشد.

رفع خطای WebApplication.Targets

پس از نصب و تنظیم build service نخستین خطایی که به خصوص هنگام build کردن پروژه‌های تحت وب ممکن است به آن برخورد داشته باشید، خطای WebApplication.Targets به شرح زیر است:

error MSB4019: The imported project “C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\WebApplications\Microsoft.WebApplication.targets” was not found. Confirm that the path in the declaration is correct, and that the file exists on disk.

برای رفع این خطا، از روی سیستم برنامه‌نویسی که در آن Visual Studio 2013 نصب شده است پوشه موجود در مسیر زیر را به مسیر مشابه در مسیر build server کپی کنید.

C:\Program Files(x86)\MSBuild\Microsoft\VisualStudio\v12.0
پیشنهاد آرایه: همان‌طور که در ادامه این نوشته می‌آید، پیشنهاد می‌کنیم بر روی build server خود Visual Studio 2013 را نصب کنید.

رفع هشدار نصب دات نت فریمورک ۴.۵

یکی دیگر از مواردی که موقع build پروژه‌های تحت وب به آن برخورد می‌کنید، هشدار زیر است.

warning MSB3644: The reference assemblies for framework “.NETFramework,Version=v4.5″ were not found.

برای رفع این هشدار همانطور که مشخص است باید دات نت فریمورک ۴.۵ را نصب کنید. البته در حقیقت باید  .NET Framework 4.5.1 SDK را نصب نمایید. برای نصب آن به صفحه دانلود Windows Software Development Kit (SDK) for Windows 8 بروید و پس از دانلود فایل و اجرای آن SDK اشاره شده را نصب نمایید. البته این SDK برای ویندوز ۸.۱ را هم می‌توانید از این صفحه دانلود کنید. SDK نصب شده برای ویندوز سرور ۲۰۱۲ نیز معتبر است.

رفع خطای Visual Studio Test Runner

اگر build خود را برای اجرای تست‌ها تنظیم کرده باشید، ممکن است به خطای زیر برخورد کنید.

TF900547: The directory containing the assemblies for the Visual Studio Test Runner is not valid ''

برای رفع این خطا دو راه حل وجود دارد. راه ساده‌تر نصب Visual Studio 2013 بر روی سرور build است. این کار مشکل خطای اول اشاره شده در این نوشته را نیز برطرف می‌کند. راه دیگر تغییر template مربوط به گردش کار build برای استفاده از نسخه قدیمی‌تر مربوط به VS 2012 است.

رفع هشدار عدم شناسایی آزمون‌های NUnit

اگر مثل ما از NUnit برای مبحث آزمون‌ها استفاده می‌کنید، ممکن است علیرغم build موفق با هشدار زیر مواجه شوید.

No test found. Make sure that installed test discoverers & executors, platform & framework version settings are appropriate and try again.

برای اینکه پروژه‌های حاوی آزمون‌ها شناسایی شوند، NUnit Test Adapter for VS2012 and VS2013 را از طریق nuget به پروژه حاوی آزمون‌های نرم‌افزاری اضافه کنید.

رفع خطای Timeout برای drop folder

به دلایل مختلف ممکن است با خطای timeout زیر مواجه شوید. 

Exception Message: The HTTP request timed out after 00:01:40. (type TimeoutException) Exception Stack Trace:    at Microsoft.TeamFoundation.Build.Workflow.Activities.FileContainerDropProvider.EndCopyDirectory(IAsyncResult result)

یک راه خوب برای برطرف کردن آن، تغییر اندازه timeout است. برای این کار به مسیر زیر بروید و فایل tfsbuildservicehost.exe.config را پیدا کنید.

C:\Program Files\Microsoft Team Foundation Server 12.0\Tools

در این فایل کدهای زیر را برای تغییر مقدار زمان timeout اضافه کنید. به عنوان مثال کد زیر زمان ۵ دقیقه را برای این timeout تنظیم می‌کند که زمان مناسبی محسوب می‌شود.




با اجرای دستورالعمل‌های فوق در آرایه موفق شدیم build روزانه و انواع build های مورد نیاز برای پروژه‌ها را با استفاده از TFS ایجاد کنیم. به زودی درباره استفاده از TFS در حوزه برنامه‌‌ریزی کارها و سفارشی‌کردن آن بر اساس نیاز تیم خواهیم نوشت.

به اشتراک گذاری این نوشته در شبکه‌های اجتماعی

دیزاین متفاوت سایت‌ها: خوب یا بد؟

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

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

قانون تجربه اینترنتی جیکوب

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

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

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


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

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

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

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

به اشتراک گذاری این نوشته در شبکه‌های اجتماعی

تست جوئل قسمت دوازدهم: کاربردپذیری راهرویی

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

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

تست دوازدهم جوئل: آیا از آزمایش "کاربردپذیری راهرویی" استفاده می‌کنید؟

در ابتدای توضیح درباره آخرین تست جوئل، باید اشاره کنم که کاربردپذیری را به عنوان ترجمه‌ای برای usability به کار بردم و در اینجا منظور از آن طراحی واسط کاربر یا user interface برای نرم‌افزارهاست.

جوئل اشاره می‌کند که "در تست hallway usability، شما خِر اولین فردی را که از راهرو رد می‌شود می‌گیرید و مجبورش می‌کنید بنشیند پای برنامه‌ای که الان نوشته‌اید. اگر با 5 نفر این کار را تکرار کنید، 95 درصد مشکلات usability برنامه‌تان را کشف خواهید کرد"

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

usability در نرم‌افزار و بررسی یک مثال از UI نامناسب

به این توصیه‌ها که به تازگی در اکانتم در توییتر نوشتم توجه کنید:

  • قرار دادن label در بالای textbox ها به جای قرار دادن در کنار، کمک می‌کنه چشم در حال پایین اومدن در صفحه راحت‌تر فرم رو ببینه. 
  • به جای استفاده از yes / no در popup ها که کاربر رو مجبور می‌کنه توضیح رو بخونه، عملیات رو در متن دکمه بنویسیم مثلاً save و don't save
  • از اینکه دکمه‌های عملیاتی (مثل reply) در hover نمایش داده بشن به جا استفاده کنید. مرورگرهای موبایل hover شدن موس رو درک نمی‌کنند.
این توصیه‌ها و سایر موارد مشابه، برای ایجاد ظاهری راحت‌تر برای کاربران نرم‌افزار هستند. در خصوص مواردی که به ایجاد یک UI خوب نرم‌افزاری می‌انجامد، در آینده یک سری نوشته را شروع خواهم کرد، اما تا آن موقع با یک مثال، بحث UI را بیشتر بررسی می‌کنیم.
 
اخیراً با پروژه‌ای درگیر شدم که هدفش ایجاد یک سیستم نظرسنجی ساده است که البته ویژگی‌های خاص خودش را دارد. تصویر زیر، تصویر پیشنهادی برای UI بخش ثبت نظرسنجی و سوالات آن است. 
تصور کنید که من بر اساس تست hallway usability شما را در حین رد شدن در راهرو شکار می‌کنم و می‌نشانم پشت سیستمی که برنامه‌ای با UI بالا در آن اجرا شده. حالا از شما می‌خواهم که یک نظرسنجی جدید ثبت کنید و تعدادی سوال نیز در آن وارد نمایید. سناریوهای انجام کار به شرح زیر هستند:
 
ثبت یک نظرسنجی جدید: شما ابتدا باید در textbox شماره 2 یک نام را برای نظرسنجی وارد کنید،‌ سپس دکمه شماره 6 را بزنید.
 
ثبت سوال برای یک نظرسنجی: ابتدا نظرسنجی مورد نظر را با استفاده از شماره 1 انتخاب کنید، بعد در شماره 3، عنوان سوالتان را بزنید و دکمه شماره 4 را کلیک کنید.
 
با توجه به توضیحات بالا و صرفنظر از اینکه برای همه سناریوها (مثل ویرایش یا حذف نظرسنجی) امکانی در نظر گرفته نشده است، سایر سناریوهای کار کاربر را می‌توانید حدس بزنید که چگونه خواهند بود.
 
خب حالا با شرایط بالا، شما که به خاطر بدشانسی گرفتار hallway usability test‌ من شده‌اید،‌ محو تماشای فرم هستید و خب خبر بد برای من این خواهد بود که نمی‌توانید با این فرم کار کنید!
این کار به نظر ساده خیلی کمک می‌کند که شما به عنوان برنامه‌نویس، اشکالات کاربران را شناسایی کنید. تحویل نرم‌افزار را برای شما ساده‌تر می‌کند و در نهایت کاربران هم، نرم‌افزار شما را قبول می‌کنند. در مورد پذیرش نرم‌افزار توسط کاربران هم باید مطلب جداگانه‌ای بنویسم، فعلاً فقط یادتان باشد که hallway usability test به شما کمک می‌کند تا نرم‌افزارهای قابل پذیرش درست کنید.
 
در خصوص استفاده از این تست، خاطره جالبی دارم. یک بار به یکی از همکاران تازه وارد که برنامه‌نویس قهاری در زمینه تولید نرم‌افزارهای دسکتاپ بود اما تجربه‌ای در تولید نرم‌افزارهای تحت وب نداشت و البته با محیط شیرپوینت نیز آشنایی نداشت، یک راهکار اجرا شده در بستر شیرپوینت را نشان دادیم و خواستیم که با آن کار کند. نتیجه فوق‌العاده بود: چیزهایی که برای ما (به دلیل کار بیش از حد با user intreface شیرپوینت) عادی شده بود برای آن همکارمان تازگی داشت و این یعنی فرض‌هایی که درباره میزان اطلاع کاربران نهایی سیستم از نحوه کار آن داشتیم چندان درست نبودند.
 
به طور کلی، یکی از دام‌هایی که در تولید UI نرم‌افزارها وجود دارد این است که چون من می‌فهمم که چطور باهاش کار کنم، دیگران هم خواهند فهمید. hallway usability test به شما کمک می‌کند که صحت این ادعا را بسنجید!
به اشتراک گذاری این نوشته در شبکه‌های اجتماعی

20 نکته برای اینکه برنامه‌نویس بهتری بشوید

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

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

1- همیشه باید فقط یک راه و نقطه خروج در کد هر متد وجود داشته باشد (از if else فقط هنگامی که لازم است استفاده کنید)

2- وقتی از if else استفاده می‌کنید مطمئن شوید که کد کوتاهتر را در بخش if قرار می‌دهید و کد طولانی‌تر را در بخش else

if (cond) {
   //only a few lines of code
}
else {
   //here you should write the "bigger" case
   //many many lines
}

3- اگر می‌توانید از throw کردن execption ها اجتناب کنید، این کار را بکنید. throw کردن execption (به صورت عمدی) باعث کند شدن کد شما می‌شود. اگر حس این رو دارید که یک چیزی رو throw‌ کنید و بعد catch کنید (کنایه به throw کردن و catch کردن exception ها) با سگ‌تون توپ بازی کنید! اگر سگ ندارید یکی بگیرید، فوق‌العاده هستند!

4- کارهای زیادی رو در یک خط کد انجام ندهید، وقتی که به خطا برخورد کنید debug کردن مشکل‌تر می‌شه. به عنوان مثال کدی مشابه کد زیر ننویسید:

String result = hasInformation()? getState() : (hasMoreInformation() ? getOtherState() : getState());

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

5- به قطعه کدهایی که مشابه هم به نظر می‌رسند نگاه کنید و اگر چیزی پیدا کردید: refactor کنید!

6- اسامی با معنی انتخاب کنید. اگر درباره انتخاب اسم مطمئن نیستید، یک دقیقه دیگه هم درباره‌اش فکر کنید. اگر باز هم مطمئن نبودید نظر همکارانتون رو بخواهید.

7- هر جا که می‌توانید از hashmap (یا همان hash table) به جای list و صف استفاده کنید این کار را بکنید.

8- اگر می‌توانید به جای I/O (معمولاً کار با دیتابیس) از مکانیزم‌های کش استفاده کنید، از کش استفاده کنید.

9- اگر یک regex ساده و زیبا می‌تونه کار رو انجام بده ازش استفاده کنید.

10- از regex برای parse کردن (مثلاً HTML/XML/json) استفاده نکنید، در هر زبانی کتابخانه‌های خاصی برای این کار وجود دارد. 

11- log‌ کنید. حداقل باید دو سطح لاگ برای debug و error داشته باشید.

توضیح مترجم: درباره logging به نظرم ایده‌های بهتری وجود دارد، درباره‌شان در نوشته دیگری خواهم نوشت.

12- از stackoverflow استفاده کنید، نه فقط برای سوال پرسیدن. روزی چند دقیقه به پاسخ به سوالات دیگران اختصاص بدید، از اینکه اینطوری چقدر چیزی یاد می‌گیرید شگفت زده خواهید شد!

13- قانون انگشت: اگر متد شما بیشتر از 50 خط است، بشکنیدش. اگر کلاس شما بیشتر از 500 خط است، بشکنیدش. اگر فکر می‌کنید که کدتون رو نمی‌تونید به قطعات کوچکتر بشکنید، یک کاری رو اشتباه انجام دادید. این توصیه بسته به زبان برنامه‌نویسی فرق می‌کنه. مثلاً در جاوا یا سی شارپ 50 خط کد قابل قبول هست ولی مثلاً برای زبان‌هایی مثل Ruby یا Python خیلی زیاد محسوب می‌شه.

14- کدی که فقط برای خودتان قابل توضیح هست خوبه ولی مشکل هم ایجاد می‌کنه. اگر مطمئن نیستید که کدتون چقدر "واضح" هست کامنت بنویسید.

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

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

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

17- تمرین کنید که باعث کامل و بی‌نقص شدن می‌شه: به hackathon‌ها بپیوندید. code-challenge ها رو حل کنید. 

توضیح مترجم: در کار ترجمه عباراتی که در حوزه نرم‌افزار هستند بعضی عبارات رو نمی‌شه ترجمه کرد و کلمه اصلی معنا رو به شکل مناسب‌تری منتقل می‌کنه.

18- با IDE های مختلفی کار کنید تا اونی که براتون راحت تر هست رو پیدا کنید.

توضیح مترجم: این مورد درباره برنامه‌نویسان مایکروسافتی صدق نمی‌کنه، در واقع بهتر از Visual Studio هنوز خلق نشده!

با تشکر از نکته‌سنجی و پیشنهاد درست dotErfan@ عبارت بالا رو این‌طور اصلاح می‌کنم: برای برنامه‌نویسان مایکروسافتی در حوزه IDE انتخاب‌های زیادی وجود ندارد، حتی اگر سوار قایق IDE هایی نظیر SharpDevelop یا MonoDevelop بشوید احتمالاً بعد از مدت کوتاهی شما را بر عرشه کشتی Visual Studio خواهم دید!

19- هر وقتی باگی پیدا می‌کنید قبل از رفع کردنش، یک unit test بنویسید که بتونه این باگ رو بگیره و مطمئن بشید که کار می‌کنه.

20- تنبل نشید RFTM

به اشتراک گذاری این نوشته در شبکه‌های اجتماعی