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

از زمانی که تصمیم گرفتم که توی دنیای آموزش پا بذارم خیلی نمیگذره، تو این زمان با افراد مختلف و ایده های جالبی روبرو بودم از آدمهای صفر کیلومتر گرفته که گاهی تو کد زدن فارغ از قوانین دست و پا گیر کارهای جالبی میکنند برای رسیدن به نتیجه تا شرکتهایی که بی اعتنا به مباحثی همچون 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

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

  1. مهدی

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

    پاسخ
    1. vahid نویسنده

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

      پاسخ
      1. مهدی

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

        پاسخ
  2. امیرمسعود ایرانی

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

    پاسخ
    1. vahid نویسنده

      اتفاقاً به نظر من بزرگترین مشکل ما اینه که فکر میکنیم مشتری باید تفاوت کد اسپاگتی و کد تمیز رو بفهمه که نقد من هم روی همین موضوع بود.
      مشتری خروجی میخواد همین و همین.
      اگر مشتری کسی بود مثل آمازون که وب سروری مثل Obidos خواست ازتون حتماً باید تمیز کد بزنید، کما اینکه این وب سرور براساس Lisp بود ولی چون یکسری مهندسان آمازون براساس اسپاگتی کد میزدن برای این وب سرور، این نرم افزار سال ۲۰۰۶ از مرحله اجرا خارج شد.
      اما اگه مشتری شما شرکت تولیدی نزدیک خونه تون هست که چیزی جز فاکتور فروش و انبارداری و … براش مهم نیست پس چرا باید پیچیده کد زد؟ فقط با این فرض که مبادا یه روزی کد من قابلیت گسترش نداشته باشه؟

      پاسخ
    1. vahid نویسنده

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

      پاسخ
          1. saeed

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

  3. vahid نویسنده

    @saeed
    چرا پیچیدگی نداره؟ پس موناد تو فانکشنال رو چطور توجیح میشه کرد؟
    البته پیچدگی شاید لازم باشه ولی نه همه جا و مخصوصاً اول کار

    پاسخ
    1. saeed

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

      پاسخ
  4. مهدی

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

    پاسخ

پاسخ دهید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

*