تالار گفتمان nCIS.ir

با احتیاط عمل کنید

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

مهم نیست که چقدر با جدول زمانبندی کارها راحتین یا بهش عادت دارین و اینکه جدول زمانبندی شما در ابتدای شروع به کار، چقدر راحت بنظر برسه. بهرحال گاهی اوقات خودتون رو ازنظر زمانی تحت فشار احساس میکنید. اگر خودتون رو توی دوراهی انتخاب بین «انجام دادن درست» و «انجام دادن سریع» دیدین، اغلب «انجام دادن سریع» انتخاب میشه و به خودتون میگین: «بعداً برمیگردم درستش میکنم». وقتی که دارین این قول رو به خودتون، تیمتون و مشتریتون میدین، واقعاً قصد دارین بهش عمل کنین. اما اغلب مواقع، قدم بعدی توی جدول زمانبندی کارها و بخش بعدی پروژه که درگیرش میشین، مشکلات جدیدی ایجاد میکنه که روی اونها متمرکز میشین. این مدل به تأخیر انداختن کارها رو بهش میگن «بدهی فنی» که میتونم بهتون قول بدم دوست شما نیست! مارتین فاولر توی کتاب واژه شناسی خودش، اون رو «بدهی فنی عمدی» نامگذاری کرده و نباید اون رو با «بدهی فنی غیرعمدی» اشتباه بگیرین.

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

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

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

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

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

همه ما تمایل داریم فرض کنیم که بقیه مردم مثل ما فکر میکنن. اما واقعاً اینطور نیست. روانشناسان این موضوع رو «تمایل آگاهانه اشتباه» نامگذاری کردن. وقتی مردم مثل ما فکر یا رفتار نمیکنن، دلمون میخواد اونها رو آگاهانه یا سهواً با القابی مثل ناقص العقل یا معلول نامگذاری کنیم.

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

بهترین راه برای اینکه بفهمین یه مشتری چطور فکر میکنه اینه که به یکیشون نگاه کنید. از یه کاربر بخواین تا یه کاری رو با بخشی از برنامه ای که شما میخواین بسازین انجام بده. مطمئن بشین که همون چیزی رو خواستین که میخواین انجام بدین. «یه ستون از اعداد رو جمع بزن» خوبه؛ ولی «مخارج ماه گذشته خودتو حساب کن» بهتره. از درخواست کردن کارهایی که خیلی تخصصی و جزئی هستن خودداری کنید. مثلاً به مشتری نگین «میتونی این خونه های جدول رو انتخاب کنی و فرمول SUM رو روی اونها اجرا کنی و جواب رو این پایین بگذاری؟». خوب شما یه سرنخ خیلی خوب به مشتری توی این سؤال دادین و نگذاشتین کار رو اون جوری که همیشه خودش انجام میداده، اجرا کنه. درواقع مجبورش کردین مثل شما فکر کنه. از مشتری بخواین درمورد روند کارش صحبت کنه. بین حرفهاش وقفه ایجاد نکنید. سعی نکنید بهش کمک کنین. مدام از خودتون بپرسین «چرا اینکار رو انجام داد؟» و «چرا اونکار رو انجام نداد؟».

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

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

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

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

یه جمله از پلاتو هست که فکر میکنم لازمه همه برنامه نویسان اون رو بدونن و نزدیک قلبشون نگه دارن:

نقل قول:زیبایی سبک و سیاق و هارمونی و ظرافت و ریتم مناسب، بستگی به سادگی داره.

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

پلاتو بهمون میگه که عامل فعالسازی تمام این نیازها، سادگیه.

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

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

خوب برگشتین؟ خوبه. کجا بودیم؟ آه، بله... من فهمیدم کدی که باهام همخوانی داره و بنظرم زیبا میاد، چندتا خصوصیات مشترک داره. رئیس همه اینها سادگیه. فهمیدم که مهم نیست چقدر کل برنامه یا سیستم پیچیده باشه، اجزای اون باید ساده نگه داشته بشن: اشیاء ساده با یک مسئولیت ساده که حاوی متدهایی با اسامی خوانا و بامعنا هستن. بعضی از افراد فکر میکنن داشتن متدهای 5 تا 10 خطی سخته و بعضی زبانها هم ساخت چنین متدهایی رو خیلی سخت میکنن، ولی من فکر میکنم چنین اختصاری درنهایت باید یک هدف برای شما باشه.

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

زیبایی متولد و توی سادگی پیدا شد.