بایگانی ماهیانه: تیر ۱۳۹۲

هنر تنبلی یا چطور یاد بگیریم اول کار رو انجام بدیم!

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

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

اما تو همه این رفت و آمدها و تعامل با انسانهای متفاوت تجربه خیلی متفاوتی رو همین هفته گذشته شاهد بودم، تو دوره فشرده آموزشی که برای یک شرکت تولید نرم افزار داشتم، شاهد این بودم که پروژه های متوسط رو به بزرگی را با رویکرد بزن در رو به جلو سوق داده بودن و بدون اینکه فکر کنن میتونن یک شالوده(framework) مشترک بین چند ده پروژه خودشون داشته باشن و دقیقاً از کانسپتهایی استفاده میکنند که Robert C. Martin در کتاب Clean Code خودش بعضاً اونها رو به توسعه گرها توصیه میکنه مثل استفاده از امکانات IDE (به دلیل رعایت اخلاق حرفه ایی قصد شرح تکنیکهاشون رو ندارم).

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

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

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

نتیجه اخلاقی

با توجه به تعداد شرکتهایی که از نرم افزار شرکت مذکور در حال استفاده هستند به جدّ میتونم به این نتیجه برسم که OOP یا FP فاکتورهای مناسبی برای استاندارد کد زدن نیستن، اگر به فاکتور رضایت مشتری توجه بیشتری بکنیم شاید به این نتیجه برسیم که مشتری راضی به اسپاگتی کدی هست که کار کنه و نه کلاسهای پیچیده ایی که هر روز یک باگ جدید در اونها کشف بشه!

من به انجام اولیه کار به هر روشی، میگم تنبلی و باهوش بازی درنیاوردن بابت انجام کار، که این خودش یه هنره!

سوالات بی جواب

آیا میتوان آینده ایی ورای OOP ،FP و یا MDA برای صنعت نرم افزار متصور بود که در اون مسائل حول محور دامنه بیزنس حل بشوند و نه حول محور مهندسی نرم افزار؟(DDD هم براساس OOP هست آیا رویکرد جدیدتری وجود داره؟)

آیا ۴GL مبحثی نبود که صنعت نرم افزار میبایست طی میکرد و آنرا به حد اعلای خود میرساند؟

آبا فریم ورکهایی مانند RoR مسکنهای موضعی برای درد مشتری مداری هستند؟ و وقت آنها هم به سر خواهد آمد؟

————————– آپدیت————————–

آفتاب آمد دلیل آفتاب، همین الان مصاحبه STLPORT با A. Stepanov مخترع STL رو خوندم که اتفاقاً ایشون با اینکه خودش STL رو برروی C plus plus پیاده کرده خودش مخالف OOP هست و از نظر درستی اون رو رد کرده.

http://www.stlport.org/resources/StepanovUSA.html