اولویت و شدت باگ


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

اولویت (Priority)

معیار درجه بندی به باگ ها از زاویه کسب و کار و نیازهای مشتری. اولویت یک باگ ترتیب رفع باگ ها را نشان می دهد. مقادیری مناسبی که برای اولویت وجود دارد را می توان به صورت زیر توضیح داد.
اولویت ۱: باگ هایی با این اولویت نشان دهنده این هستند که محصول بدون رفع آنها قابل ارائه نیست و باید در اسرع وقت حل شوند.
اولویت ۲: باگ هایی با این اولویت نشان دهنده این هستند که محصول بدون رفع آنها قابل ارائه نیست ولی نیاز به رفع فوری آنها نیست.
اولویت ۳: رفع باگ اختیاری است و بر اساس منابع و زمان و ریسک می توان برای رفع آن برنامه ریزی کرد.

شدت (Severity)

معیار درجه بندی یک باگ بر اساس تاثیری که روی پروژه یا محصول نرم افزاری دارد. مقادیری که این برای این فاکتور می توان در نظر گرفت به صورت زیر هستند:
Critical: باید رفع شود. اشکالی که باعث از کار افتاد یک بخش یا تمام سیستم نرم افزاری شود و یا منجر به خرابی داده های نرم افزار شود. همچنین راهکار جایگزین قابل قبولی برای گرفتن نتیاج مورد انتظار در محصول وجود ندارد.
High: برای رفع در نظر گرفته شود. بخش اول تعریف این نوع باگ مانند مورد Critical است ولی راهکار جایگزین قابل قبولی برای گرفتن نتایج مورد انتظار در محصول وجود دارد.
Medium: باگی که باعث می شود سیستم نتایج نادرست یا ناقصی ارائه دهد.
Low: اشکال کوچک و تزیینی که راه حل های قابل قبولی در محصول نرم افزاری برای آن وجود دارد به طوری که نتایج مطلوب حاصل شود.

موارد بالا از اینجا نقل قول شده است. برای مطالعه بیشتر در مورد مدیریت باگ ها می توانید به لینک مذکور مراجعه نمایید.

 

نیازمندی های غیر قابل اندازه گیری

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

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

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

  • نرم افزار باید سریع باشد
  • وبسایت باید زیبا باشد
  • نرم افزار باید خوش دست باشد
  • نرم افزار باید کاربران را مدیریت نمایید

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

پس بهتر است چکار کنیم؟ بهترین کار بحث و بررسی و توافق بر سر جزییات است نه کلیات. به طور مثال در مورد اول اگر برنامه به صورت desktop است، کسی که نیازمندی را به شما تحویل داده (تیم تحلیل، همکار تحلیل گر شما در تیم و یا هر کس دیگر) باید به عنوان نمونه به موارد زیر پاسخ دهد:

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

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

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

فاجعه اصلی

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

معمولا تحویل گرفتن نیازمندی ها به صورت غیر قابل اندازه گیری و مشخص مشکلات زیر را بوجود خواهد آورد:

  • تحویل بسیار مشکل کار و عدم رضایت همیشگی مشتری
  • عدم امکان طراحی و پیاده سازی نرم افزار مناسب نرم افزار و تکرار دوباره کارهای انجام شده به دلیل طراحی بد
  • بی انگیزگی تیم تولید به دلیل حاشیه ها و تنش های ایجاد شده در تحویل کارها
  • عدم امکان تهیه و ارائه گزارش پیشرفت پروژه

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

لطفا بدون خطا چک-این (check-in) کنید

تا به حال شده که کدی را get latest کنید. و پروژه شما دیگر build نشود؟ تا به حال شده کسی کاری در سیستم انجام داده باشد. و بعد از آن خطاهای منطقی یا تحلیلی عجیب و غریبی مشاهده شود؟

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

زمان ایجاد تغییرات

هر روز ممکن است تغییراتی را مشاهده کنیم که با بی دقتی در source control وارد شده اند و مشکلات زیادی را به بار آورنده اند. متاسفانه یا خوشبختانه بهترین فرد برای بررسی عوارض یک تغییر همان فردی است که تغییرات را ایجاد کرده. این که شما انتظار داشته باشید بقیه تیم برنامه نویسی مشکلات ناشی از تغییراتتان را در کمترین زمان ممکن رفع کنند انتظاری نابجا است. زیرا تنها کسی که از عمق تغییرات ایجاد شده اطلاع دارد خود شما هستید.

پس خواهش می کنم بدون خطا چک-این کنید. این که پروژه شما build می شود هم کافی نیست. ممکن تغییرات یا کدهای شما مشکلات منطقی در دیگر جاهای سیستم ایجاد کرده باشد. رفع این تغییرات ممکن است برای شما ۱ ساعت زمان ببرد. ولی برای کس دیگری ممکن است خیلی بیشتر از این مقدار زمان بر باشد.

خطاهای شما به نام کس دیگری خواهد خورد

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

ابزار زیادی لازم ندارد

وقتی کاری تست نشده وارد source control می شود و مشکل اساسی پیش می آید، اولین قدم همه ما پیدا کردن مقصر است. معمولا حتی بعد از یافتن مقصر واقعی یا ظاهری موضوع پایان نمی یابد. ممکن است این مشکلات  یک سلسله از تصمیمات فلسفی و مدیریتی در پی داشته باشد. از این که مثلا باید TDD کار کنیم. یا چرا موتور تست اتوماتیک UI نداریم یا هزار موضوع دیگر. وجود همه موارد ذکر شده در یک پروژه و سازمان خیلی خوب است. ولی واقعیت امر این است که برای چک-این کردن کد بدون خطا و عوارض جانبی، تنها امکانی که باید وجود داشته باشد حوصله و تعهد است. بقیه موارد خیلی موارد الزامی ای نیستند.

سعی کنیم با دقت چک-این کنیم.

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

  1. عدم شناخت دقیق نیازمندی ها
  2. تغییرات همیشگی و عدم قطعیت در نیازمندی ها
  3. تغییرات ساختاری زیاد در فناوری ها

این پویایی همه جانبه در پروژه های نرم افزاری مانع از این خواهد شد که مهندسین آن، بدون سبک و سنگین (trade off) کردن شرایط و بررسی شرایط هر لحظه یک پروژه، از یک قاعده و روش کلی به صورت کورکورانه تبعیت کنند.

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

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

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

سبگ و سنگین کردن (trade off) در هر تصمیم روزمره هریک از نیروهای فنی و غیر فنی شاغل در یک پروژه نرم افزاری دخالت دارد.

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

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

این موارد بحث و تبادل نظر در مورد تصمیمات اتخاد شده را بسیار مشکل می کنند.

هزینه دیرکرد

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

این هزینه به صورت دقیق قابل اندازه گیری نیست و الزاما هزینه های مادی را شامل نمی شود. ولی همین که به صورت نسبی به این موضوع دقت شود تاثیر بسیار زیادی در تصمیم گیری ها خواهد داشت.

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

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

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

چگونه یک سوال فوق العاده بپرسیم

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

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

هچنین با گسترش استفاده از وبسایت های پرسش و پاسخ آنلاین مهارت در پرسیدن سوالات خوب و به جا، بیشتر و بیشتر در رسیدن به هدف کمک خواهد کرد و حتی سوالات خوب می توانند در وجه شغلی یک برنامه نویس تاثیر بسیار مثبتی نیز داشته باشند. به این صورت که مثلا در سایت stackoverflow.com سوالات نیز امتیاز دهی می شوند و در امتیازات یک کاربر تاثیر زیادی دارند.

با این مقدمه، برای پرسیدن یک سوال فوق العاده در محل کار چه مواردی نیاز است؟

سعی کنید سوال نپرسید!

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

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

عنوان سوال را دقیق انتخاب کنید

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

  • زبان برنامه نویسی یا زیرساخت مورد نظر (زمانی که در یک تیم یکنواخت کار می کنید می توانید فرض کنید طرف مقابل اطلاع از زیرساخت و زبان شما دارد)
  • متن exception یا خطای منطقی ای که به آن برخوردید به طور خلاصه. مثلا: خطای cannot enumerate all types of … را می گیرم.
  • موضوعات مربوط به شرایط خاصی که دارید، مثلا اگر پایگاه داده شما متفاوت با بقیه تیم است و حدس میزنید که خطا از این مورد است حتما ذکر کنید که پایگاه داده من متفاوت است

محدوده سوال تا حد امکان کوچک باشد

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

 برای مطالعه بیشتر در این موضوع می توانید به پست دیگری از من مراجعه کنید.

پروژه تستی ایجاد کنید

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

  • تا حد امکان داده های مورد نیاز به صورت static داخل برنامه وجود داشته باشد
  • رابط کاربری پیچیده ای نداشته باشد
  • تمام نیازمندی های نرم افزاری تا حد امکان در کنار پروژه وجود داشته باشد
  • کد ساده داشته باشد و سریع سر اصل مشکل رفته باشد

همچنین می توان گفت پروژه تستی را می توانید به عنوان یک unit test بزرگ ببینید.

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

این مطلب  در مورد پرسیدن سوالات شفاهی نوشته شده است. برخی از قوانین و اصول وبسایت هایی مانند stackoverflow با مواردی که مطرح شده متفاوت است.


 مهارت های غیر فنی یک برنامه نویس

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

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

برنامه نویس ارشد

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

نکته جالبی که مدت هاست به آن فکر می کنم عناوینی است که برنامه نویس ها معمولا با آنها شناخته می شوند.

  • Programmer
  • Senior programmer
  • Software developer
  • Senior software developer
  • Software architect
  • Software development engineer
  • Senior software development engineer

موارد دیگری نیز وجود دارد که از نظر آماری تعداد کمتری از آنها مشاهده کرده ام.

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

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

برنامه نویس خیلی خوبی است

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

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

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

بیان قوی ای دارد

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

آموزگار  و الگوی خوبی است

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

مذاکره کننده خوبی است

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

اخلاق حرفه ای دارد

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

تصمیم گیرنده خوبی است

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

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


مطالب مرتبط:

مهارت های غیر فنی یک برنامه نویس

پرکاری و بدهی فنی

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

آیا سابقه کاری در درآمد برنامه نویسی نقش مهمی دارد؟

چرا برنامه نویس ها چند شغله هستند؟

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

شاید بعضی مواردی که در این مطلب مطالعه خواهید کرد در مورد مشاغل غیر از برنامه نویسی نیز صحت داشته باشد.

چرا برنامه نویس ها چند شغله می شوند؟

۱) عدم امنیت شغلی

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

۲) پرداختی نامناسب

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

۳) یادگیری

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

۴) کسب تجربه

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

۵) پیشرفت

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

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

موارد ذکر شده از نظر اهمیت مرتب شده بودند. به طوری که موارد بالاتر از نظر بنده اهمیت بیشتری داشته اند.

پرکاری و بدهی فنی

blog.castsoftware.com
technical-debt

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

بدهی فنی نمونه ها و مصادیق فراوانی دارد. در زیر چند مورد از انها را مشاهده می کنید.

  • کلاسهای (class) بسیار بزرگ با مسئولیت های فراوان. (بیشتر سیستم توسط چند کلاس بزرگ مدیریت می شوند)
  • یک stored procedure برای بسیاری از کارها.
  • Copy paste کردن کد! (فاجعه)
  • عدم استفاده مجدد مناسب از کلاسها
  • عدم refactor کردن کدها جهدت استفاده مجدد و نوشتن تکه کدهای جدید برای حل مسائل جدید
  • عدم بروزرسانی سیستم های مشتریان و نیاز به نگهداری سیستم های قدیمی در مشتریان خاص

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

آخرین نفر مسئول است

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

پرکار هستید؟ پس دقت کنید

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

مطالب مرتبط:

آیا سابقه کاری در درآمد برنامه نویسی نقش مهمی دارد؟

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

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

نرم افزار 15 دقیقه ای

به او گفتم کار سختی نیست. امتحان میکنم. بعد از آن در حدود ۱۵ دقیقه (زمان کار را با toggl.com ثبت کردم) توانستم برنامه ساده ای بنویسم که در درایو خاصی فایل های صوتی تکراری را پیدا کرده و در یک فایل متنی گزارشی به کاربر ارائه دهد.

دوستم از نرم افزار استفاده کرد و با توجه به این که تعداد فایها صوتی موجود در آرشیو او بسیار زیاد بود، این برنامه کمک زیادی در یافتن فایل های تکراری بر اساس نام، به او کرد.

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

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

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

این درسی بود که من گرفتم از نیاز ساده یک دوست.