راهکارهایی برای مشتری، یا رزومه

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

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

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

متاسفانه در دنیای واقعی خیلی این اتفاق نمی افتد. تصمیمات برنامه نویس ها ممکن است بیشتر بر مبنای اثر آن موضوع خاص روی رزومه شخص گرفته شود. مثلا در انتخاب این که یک پروژه تحت وب single page باشد یا نه، قبل از این که به نیاز مشتری توجه شود ممکن است به سابقه کاری و فرصت کسب تجربه شخصی و اثر موضوع sinple page application روی روزمه شخص توجه شود.

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

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

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

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

*ایده اصلی این مطلب از یکی از بخش های کتاب ۹۷Things Every Software Architect Should Know گرفته شده است.


تصمیمات اقتصادی تصمیمات احساسی

درسی از یک نرم افزار ۱۵ دقیقه ای

phonegap و cordova به درد بخور هستند؟

Apache_Cordova1

روش های مختلفی برای تولید نرم افزارهای موبایل وجود دارد. یکی از روش های همیشگی، تهیه برنامه های native مخصوص هر سیستم عامل است. ولی همان طور که cross platform بودن در دنیای دسکتاپ همیشه موضوع جذابی بوده است، در دنیای موبایل هم شرکت های تولید کننده زیرساخت های نرم افزاری، به طور جدی به دنبال آن بوده و هستند.

در مبحث cross platform نیز روش های متفاوتی وجود دارد.

  • نوشتن برنامه با زبان خاص و کامپایل و deploy کردن به چند سیستم عامل (appcelerator, xamarin)
  • نوشتن برنامه با استفاده از webview مانند cordova, phonegap, AppGyver

به خواندن ادامه دهید

رفع مسئولیت!

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

با تشکر

خوب باگ بزنیم (Useful bug reports)

مبحث گزارش خطا یا به اصلاح دنیای نرم افزاری آن باگ زدن (bug report) در تمامی رشته ها و در تمامی محصولاتی که به صورت روزمره از آنها استفاده می کنیم وجود دارد. خطا یا خرابی همیشه وجود داشته و خواهد داشت. مهارت این که به صورت سازنده خطاها و خرابی های یک محصول را به دست اندکاران آن برسانیم نیز مهارت مهمی است. بهتر است نگاهی اجمالی به نکات سازنده در ثبت خطا یا همان باگ زدن داشته باشیم.

چرا خوب گزارش دادن باگ اهمیت دارد؟

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

فاکتور های متفاوتی در سازمان ها وجود دارند که خصویات یک باگ یا به طور کلی (work item) را مشخص می کنند. ولی به طور کلی هر باگ می تواند شامل اطلاعات زیر باشد.

  • عنوان
  • مراحل ایجاد دوباره باگ و نتایج آن
  • اطلاعات فنی مورد نیاز برای بررسی باگ در محیط ایزوله شده (مانند backup پایگاه داده و …)
  • اولویت باگ
  • شدت باگ

بخش های متفاوت دیگری حتما در بدنه هر باگ وجود دارد به طور مثال این که مربوط به چه سیستمی است و …

عنوان

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

همیشه این گونه تصور کنید که کسی آن طرف پنل مدیریت lifecycle نرم افزار قرار دارد (هر سیستمی که هست مثلا TFS) باید عنوان باگ ها به گونه ای انتخاب شود که او به راحتی و با گذر سریع چشمی بتواند باگی را به کسی (یا تیمی) به صورت اولیه assign کند. اگر عنوان به خوبی انتخاب نشود حتما آن فرد (هر کسی که هست) با مشکلات عدیده ای مواجه خواهد شد.چند نمونه از عنوان های خوب و بد را بررسی خواهیم کرد

بد: فرم ویرایش کالا کار نمی کند.

خوب: عدم ذخیره سازی تغییرات دسته بندی ها در فرم ویرایش کالا

بد: enter کار نمی کند.

خوب: دکمه enter در هنگام  inline editing در گرید کالاها فوکوس را به فیلد بعدی نمی برد

مراحل ایجاد دوباره باگ

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

پس از اینکه الگوی باگ را پیدا کردید نیاز است که مراحلی که منجر به برخورد با باگ می شوند را یادداشت کنید. این مورد خیلی مهم است. مراحلی که تهیه میکنید باید خیلی دقیق و کارا باشند.

به عنوان برنامه نویس تنها اطلاعاتی که نیاز دارم تا بتوانم باگ را رفع کنم آیتم های زیر هستند

  • مراحلی که نیاز است باگ را ببینم.
  • نتیجه ای که کاربر انتظار داشت ببیند.
  • چیزی که الان می بیند.

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

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

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

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

دو: ویرایش دسته بندی های کالا

سه: ذخیره تغییرات

اطلاعات فنی مورد نیاز برای بررسی باگ

این اطلاعات عموما شامل backup از پایگاه داده مربوطه یا اطلاعات محیطی مانند سیستم عامل، browser و غیره است.

نکته مهمی که اغلب فراموش می شود تنظیمات general یا تنظیمات مربوط به هر کاربر است. اگر حس می کنید (یا حتی وقتی حس نمی کنید!) که باگ ممکن است به دلیل پاره ای از تنظیمات محیطی یا داخلی نرم افزار است بهتر است، یک کپی از تمام متغیر های محیطی و تنظیمات در کنار باگ بگذارید. تا جایی که مسائل امنیتی بروز نکند.

نکته: یک سری ابزار برای گرفتن متغیر های محیطی وجود دارد. خوب است که نرم افزار شما امکانی مشابه برای dump گرفتن از تنظیمات داخلی خودش داشته باشد.

اولویت باگ

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

شدت باگ

شدت باگ در تعیین اولویت باگ تاثیر بسیار مهمی دارد. اسامی مختلفی در سازمان های مختلف برای شدت باگها می گذارند. ولی به صورت نسبی باگ ها را می توان از “باگ کشنده” تا باگ “پیشنهاد بهبود” دسته بندی کرد. (در میان این دو دسته، دسته های زیادی قرار خواهد گرفت). باگ کشنده باگی است که به هر صورتی مانع ادامه کار با نرم افزار می شود و پیشنهاد بهبود باگی است که معمولا در متن آن شاهد توضیحی مبنی بر این که ” بهتر است کار X انجام شود.” خواهیم بود.

نتیجه

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

تعهد به نوشتن

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

http://www.joelonsoftware.com

http://www.hanselman.com/blog

http://www.codinghorror.com/blog