پرهیز از کمال‌گرایی غیر ضروری در توسعه نرم‌افزار

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

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

البته یکی از اصول توسعه نرم‌افزار خصوصاً در سال‌های اخیر که روش‌های «چابک» رواج بیشتری پیدا کرده‌اند این است که تا به چیزی به طور کامل نیاز پیدا نکرده‌اید، آن را انجام ندهید. از طرفی درست است که یک code base خوب به شما کمک می‌کند که امکان توسعه‌های آتی راحت‌تر فراهم شود و حتی خطایابی و پشتیبانی هم راحت‌تر و سریع‌تر شود، اما چیزی که واقعاً برای مشتری مهم است کارآیی برنامه و از طرفی پایین بودن زمان و هزینه توسعه است. اگر قرار باشد همه چیز به روش اصولی و صد در صد درست انجام شود، حتی موارد ساده و کم استفاده، آن وقت هزینه‌های تولید و پشتیبانی نرم‌افزار بیشتر از آنی خواهد بود که باید باشد. باور کنیم که تیم‌های تولید نرم‌افزار هم در استفاده از روش‌های برنامه‌نویسی باید «مقیاس‌پذیر» باشند. اگر مشتری کارش را در نصف زمان و با نصف هزینه خواست، تیم هم باید بتواند با به کارگیری روش‌های ساده‌تر و معمولی‌تر هزینه‌ها را کاهش دهد. نه این که با اصرار بر ایده‌آل گرایی هزینه‌ها را افزایش دهد.

به عنوان مثالی که اخیراً به آن برخورد کردم باید به ذخیره و خواندن تنظیمات سیستم از app.config اشاره کرد. مورد استفاده من نگهداری چندین value به ازای یک key یکسان بود. هر چند که دات‌نت اجازه چنین کاری را می‌دهد و خطا اعلام نمی‌کند. اما استفاده معمولی از ConfigurationManager.AppSetting فقط آخرین value را بر می‌گرداند. راه اصولی برای حل این مشکل استفاده از Config Sectionهای سفارشی بود. حتی می‌شد از راه‌حل‌های پیچیده‌تر مبتنی بر reflection برای حل مسئله استفاده کرد. اما یک راه فوق‌العاده ساده‌تر و کم هزینه‌تر هم وجود داشت. اضافه کردن یک عدد چند رقمی (بی‌استفاده) به انتهای keyها (تا از یکسان بودن در بیایند) و استفاده از یک foreach و عملیات استرینگی ساده برای به دست آوردن valueها! راه حل آخر را از یک برنامه‌نویس VB.NET یاد گرفتم.

‫روش برنامه‌نویسی Forum Driven Development

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

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

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

An open letter to oDesk from an Iranian software developer

Dear oDesk managers,

I’m an Iranian software developer living and working in Tehran/Iran. Recently I opened an account in oDesk and started to bid on oDesk projects as a contractor. But unfortunately oDesk has suspended my account just because I’m an Iranian.

I can’t realize why I can’t work in oDesk like many other people all around the world including Pakistan, Latin America, Egypt, Ukraine, India, etc? What is difference between them and us? I know about Iran Sanctions Act (ISA), but we, the people of Iran not the government, do not deserve it. In Iran, a very few software developers work directly for government or government organizations. While American and Iranian politicians hate each other, why we, the people of Iran must be sacrificed? Why we must pay for it?

Please watch software developers of Iran more carefully, we don’t program for nuclear weapons, mass destruction weapons or anything else dangerous for people of world. Main stream of software development in Iran is LOB applications deployed in boring offices manipulating personal data, banking data, accounting data and any none military data. Why you are think these poor and peaceful software developers are dangerous to other people?

I beg you think twice…

Best Regards,
A peaceful Iranian software developer,
Afshar Mohebbi

تویتر: راه ارتباطی راحت‌تر از وبلاگ‌نویسی

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

۱- کیوان نیری
۲- اسکات هنزلمن
۳- علی اقدم
۴- مهدی تقی‌زاده
۵- ناصر حاجلو
۶- مسعود رمضانی
۷- جف اتوود
۸- ریک استرال
۹- افشار محبی (اینجانب)
۱۰- اسکات کان
۱۱- مارتین فولر
۱۲- سپهر لاجوردی
۱۳- اشکان روشنایی
۱۴- هادی اسکندری
۱۵- سهیل رشیدی
۱۶- سروش ایوبی
۱۷- حامد سعیدی فرد
۱۸- مجید آواژ (بهساد)
۱۹- جو استنگر
۲۰- صالح سوزنچی
۲۱- سلمان عرب عامری
۲۲- بهنام بهمنی

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

تولید نرم‌افزار یا تحقیق و توسعه؟

خیلی وقت‌ها (نه بعضی وقت‌ها) حس می‌کنم کارم به عنوان یک مهندس نرم‌افزار به جای تولید نرم‌افزار (software development) تبدیل شده به تحقیق و توسعه (R and D). البته فکر می‌کنم این فقط مشکل من نباشد. فقط کافی است به بعضی شرکت‌ها سر زده و نگاهی به مانیتور افراد بیندازید. خیلی‌ها را پیدا می‌کنید که از صبح تا شب یا در حال PDF خوانی هستند یا همیشه در حال کار روی پروژه‌های تستی و آزمایشی هستند.

تحقیق و توسعه (R and D) لزوماً چیز بدی نیست. اما اولاً که برنامه‌نویس‌ها معمولاً برای درست برنامه‌نویسی آموزش دیده‌اند نه R and D و ثانیاً این که تاکید زیاد به R and D می‌تواند نشانه‌ای از آموزش غلط برنامه‌نویسان یا کم سوادی تصمیم‌گیرندگان شرکت باشد.