In Code

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

تعداد مسیرها که آیسا می‌توانست برای رسیدن به هدفش را طی کند میزان پیچیدگی شرایط‌ش در نظر گرفتیم. در سال ۱۹۷۶ شخصی به Thomas McCabe متریکی را برای اندازه‌گیری پیچیدگی در نرم‌افزار به نام Cyclomatic complexity معرفی کرد. او نیز تعداد مسیرهای مستقلی که کل یک ماژول یا متد را پوشش بدهد به عنوان پیچیدگی آن در نظر گرفت. برای محاسبه تعداد مسیرهای مستقل در متد روشهای مختلفی وجود دارد، رسمی‌ترین روش برای این کار رسم گراف کنترل جریان آن متد می‌باشد. در تصویر زیر گراف کنترل جریان متد حستجوی باینری رسم شده است.

بعد از رسم گراف کنترل جریان با استفاده از فرمول زیر تعداد مسیرهای مستقل را محاسبه می‌کنیم.

Cyclomatic complexity = E – N + 2

تعداد یالهای گراف = E

تعداد گره‌های گراف = N

بر اساس تصویر بالا گراف کنترل جریان متد دارای ۱۲ گره و ۱۴ یال می‌با‌شد پس :

CC = 14 – ۱۲ + ۲ = ۴

پس متد جستجوی باینری دارای پیچیدگی ۴ می‌باشد، یعنی ۴ مسیر مستقل وجود دارد که کل متد را پوشش می‌دهد.

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

اگر حوصله رسم گراف و شمردن نقاط تصمیم‌گیری را ندارید، استفاده از ابزارهای که متریک‌های کد را محاسبه کرده و نمایش می‌دهند بهترین گزینه هست. یکی از بهترین گزینه‌ها برای اینکار می‌تواند XDepend باشد برای دات نت NDepend، برای جاوا JDepend و برای پی‌اچ‌پی می‌توانید از PDepend استفاده کنید.  البته اگر از ویژوال استودیو استفاد می‌کنید نیازی به نصب ابزار دیگری نیست می‌توانید از منوی ANALYAZ بر حسب نیاز خود یکی از دو گزینه مشخص شده در تصویر را انتخاب کنید و نتیجه را مشاهده کنید.

مقدار قابل قبول برای Cyclomatic Complexity یک متد چقدر هست؟

یک مقدار ایده‌ ال برای محدود کردن Cyclomatic Complexity در یک متد وجود ندارد. تا ۱۰ را یک مقدار قابل قبول برای یک متد میدانند. و با افزایش آن میزان پیچیدگی افزایش و در نتیجه آن تست پذیری و قابلیت نگهداری کاهش می‌یابد. بازه‌های زیر را SEI برای مقدار  Cyclomatic Complexity منتشر کرده است.

آیا ارتباطی بین مقدار Cyclomatic Complexity و تعداد تست‌های واحد (unit test)  وجود دارد؟

مقدار Cyclomatic Complexity برابر حداقل تعداد تست‌های هست که می‌توان نوشت تا تمام مسیر‌های برنامه را پوشش بدهد. یعنی اگر برای هر مسیری که مشخص شده هست یک تست بنویسیم می‌توانیم از پوشش تمام مسیرهای برنامه توسط تست‌هایمان مطمئن شویم. در پست بعدی سعی می‌کنم در مورد میزان پوشش تست‌ها (test coverage) بنویسم و درباره انواع پوشش تست‌ها توضیح خواهم داد.

به‌عنوان نمونه تست‌های نوشته شده برای مسیر ۱ و ۲ در متد جستجوی باینری در پایین نمایش داده شده است. سطرهای که با رنگ سبز مشخص شده است مسیر اجرای آن تست را نشان می‌دهد و سطرهای که با رنگ قرمز مشخص شده است سطرهای هست که آن مسیر پوشش نمی‌دهد.

مسیر ۱:  ۰->1->2->3->11

مسیر ۲: ۰->1->2->4->5->6->11

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

 یک از ارزش‌های XP، سادگی و یکی از تکنیک‌های آن طراحی ساده (Simple Design) هست. Kent Beck مبدع XP برای داشتن یک طراحی ساده چهار قانون تعریف کردن که عبارت‌اند از:

1. پاس شدن همه تست‌ها
2. عدم وجود تکرار
3. بیان مقصود برنامه نویس
4. کاهش تعداد کلاس‌ها و متدها

پاس شدن همه تست‌ها

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

همه سوالهای بالا بر وجود تست در سیستم تاکید دارند. Unit Test ها کمک می‌کنند که شما بدانید چه زمانی وظیفه شما به پایان رسیده است – زمانیکه شما تمام تست‌های مرتبط با وظیفه‌ای که انجام می‌دهید را نوشته باشید و همه آن‌ها پاس شده باشند. اگر تست یا تست‌هایی پاس نشده باشد شما باید به فعالیت خودتان ادامه بدهید تا همه آن‌ها پاس بشود.

عدم وجود تکرار

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

این اصل اغلب بین توسعه دهنده‌های نرم‌افزار با نام DRY(Don’t Repeat Yourself.) یا Once And Only Once شناخته می‌شود. البته اصل DRY درباره تکرار کد نیست و درباره تکرار دانش هست، این اصل بیان می‌کند که  هر قسمت از دانش ما در سیستم باید جایگاه واحد، بدون ابهام و معتبری داشته باشد. (حسین بقایی عزیز چند ماه قبل لینک یک پست را در مورد DRY توئیت کرده بود که به صورت عالی این اصل را تشریح کرده بود خواندنش را از دست ندهید.)

بیان مقصود برنامه‌‌نویس

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

کاهش تعداد کلاس‌ها و متدها

این یکی از اصولی هست که شاید در نگاه اول با اصول بالا در تضاد باشد. وقتی برای نمونه شما برای حذف کدهای تکراری کدهای موجود را ریفکتور می‌کنید به احتمال زیاد تعداد کلاس‌ها و متدها شما افزایش می‌یابد. پس اصل چهارم به خودی‌خود نقض می‌شود؛ اما این اصل به تعداد کلاس‌ها اشاره نمی‌کند و در واقع اشاره آن به اصل YAGNI (You Aren’t gonna need it) می‌باشد.  اصل YAGNI بیان می‌کند که شما باید هر چیزی را وقتی پیاده سازی کنید که واقعاً به آن نیاز دارید و نه وقتی که می‌فهمید در آینده ممکن است به آن نیازمند شوید. این جمله یکی از جملاتی است که XP واقعاً روی آن تاکید دارد و اعلام می‌کند که شما حتی اگر اطمینان حاصل کنید که به این ویژگی در آینده نیاز خواهید داشت آنرا الان پیاده سازی نکنید. پس هدف اصل چهارم این است که نباید با پیاده‌سازی کلاس‌ها و متدهایی که احتمالاً در آینده فرضی به آن نیاز خواهیم داشت نعداد کلاس‌ها و متدها را افزایش بدهیم.

«بانک مساعدت دیگر چیست؟»

«خودت می‌دانی. هر آدم زنده‌ای این بانک را می‌شناسند.»

«ممکن است، اما هنوز منظورت را نمی‌فهم.»

«این موضوع در کتابی از یک نویسنده آمریکایی آمده. قدرتمندترین بانک دنیاست. همه‌جا شعبه دارد.»

«کشور من سابقه ادبی ندارد. نمی‌توانم به کسی کمک و لطفی بکنم.»

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

«و یک روز ….»

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

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

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

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

در آخرین سفر پدرم به دیسنی ورلد، من و او و دیلن که در آن موقع چهار سال بود، منتظر راه‌آهن تک ریلی بودیم. دیلن دلش می‌خواست در دماغه‌‌ قطار بغل دست راننده بشیند. پدرم که عاشق پارک بود، عقیده داشت که این کار خیلی کیف دارد.

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

من گفتم: “آهان، فهمیدم بابا. با توجه به اینکه من در بخش تخیلی دیسنی کار کرده‌ام، می‌دانم که برای جلو نشستن باید به دوز و کلک متوسل شد. می‌خواهی ببینی چطور؟”

او گفت: “البته.”

بنابراین به سوی متصدی خندان دیسنی رفتم و گفتم: “عذر می‌خوام، امکان دارد که ما سه نفری جلو بنشینیم؟”

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

وقتی به سرعت به سوی قلمرو سحرآمیز می‌رفتیم، گفتم: “بهت گفتم که باید کلک زد. اما نگفتم که کلک سختی است.”

گاهی تنها کار لازم تقاضا کردن است، که باعث می‌شود تمام رویاهای آدم به حقیقت بپیوندند.

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

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

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

آرزوهای ابوالفضل فتاحی برای تبریز به عنوان یک دوست خوب برای همه تبریزیها

رویای و آرزوی امیر حبیب‌زاد برای شهرمان تبریز

رویای امین ضیاء پرانرژی برای جامعه حرفه‌ای تبریز

آرزوی زهره ضیاء برای کل جامعه تبریز

رویاهای کوچک ولی بزرگ سعید چوبانی  برای جامعه حرفه‌ای ما

آرزوهای بهنام خجسته برای شهرمان

محمد فلاحت و آرزوی ایستگاه خلاقیت برای تبریز

علی اسدی آرزوها و حرفهای خوبش برای جامعه ما

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

ندا ضیاء و آرزوهایش برای جامعه حرفه‌ای و کل شهرمان

شهرام اشراف‌نیا آرزیلاری

امید زمانی و آرزوی رفع یک مشکل شهرمان

وحید کشی‌پور و کمی حرف حساب

ابراهیم جباری و آرزوهایش برای شهر آرزوها

فرید دهقان و یک عالمه حرف‌ها و آرزوهای خوب برای شهرمان

مژگان و آرزوش برای تبریزمان و خودش

 نسرین و آرزوهایش برای ساختن یک دنیا بهتر

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

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

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

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

علی‌محمد ایزدی در کتاب چرا «عقب» مانده‌ایم؟ می‌نویسد: «وقتی درباره موضوعی بحث به میان می‌آید، به شرطی که ترسی در بین نباشد، به ندرت کسی را می‌توان دید که اظهارفضل و ابزار عقیده نکند. موضوع آن هرچه می‎خواهد باشد، سیاسی باشد، اقتصادی باشد، اجتماعی باشد، زمین باشد، آسمان و یا ریسمان باشد، هیچ فرقی نمی‌کند. در این زمینه‌ها همه کس در ایران علامه دهر است و خوشمزه اینجا که در ته قلبش دیگران، ولو متخصصان در آن رشته‌ها را قبول ندارد مگر از راه تقلید. یعنی اینکه چون دیگران فلان کس را قبول دارند، ممکن است این هم به ظاهر تعریف کند، و اگر دیگران گفتند فلان کس اطلاعاتش ضعیف است، او هم می‌گوید مطلقا چیزی بارش نیست.»

بیاید به همدیگر قول بدهیم قبل از اینکه به هر سوالی پاسخ بدهیم یک کمی فکر کنیم، شاید «نمی‌دانم» جواب اصلی سوال باشد.

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

یاد بگیریم وقتی در جایی کمپ می‌زنیم آنجا را تمیزتر از قبل‌اش ترک کنیم. این جمله به عنوان قانون بوی اسکات شناخته می‌شود و می‌تواند به عنوان راه حل ما برای حفظ کیفیت کد در طول زمان به‌کار برود. قانون بوی اسکات در شکل نرم‌افزاری آن تاکید می‌کند که با هر commit کیفیت کد را نسبت به قبل بهبود ببخشیم. در پست تئوری پنجره شکسته، سوال «در برابر پنجره‌های شکسته باید چگونه عمل کرد؟»  مطرح شد که، شکل دیگر پاسخی که برای آن ارائه شد همان قانون بوی اسکات هست. و باز در آخر توصیه می‌کنم که برای حفظ کیفیت کد در طول زمان هیچ فرصتی را از دست ندهید و به صورت پیوسته و در فواصل زمانی بسیار کوتاه Refactoring را بر روی کدهای خود انجام دهید.

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

به‌صورت اتفاقی در جای مطلبی را می‌خواندم که در آن اشاره به تئوری پنجره شکسته داشت. تئوری پنجره شکسته محصول فکری دو جرم شناس آمریکائی (Criminologist) بود به اسامی جمس ویلسون (James Wilson) و جورج کلینگ(George Kelling).  این دو استدلال می کردند که جرم نتیجه یک نابسامانی است. اگر پنجره ای شکسته باشد و مرمت نشود آنکس که تمایل به شکستن قانون و هنجارهای اجتماعی را دارد با مشاهده بی تفاوتی جامعه به این امر دست به شکستن شیشه دیگری می زند. دیری نمی پاید که شیشه های بیشتری شکسته می شود و این احساس آنارشی و هرج و مرج از خیابان به خیابان و از محله ای به محله دیگر می رود و با خود سیگنالی را به همراه دارد از این قرار که هر کاری را که بخواهید مجازید انجام دهید بدون آنکه کسی مزاحم شما شود.

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

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

چند ساعت بالای کوه دارد بحث را مدیریت می‎‌کند که به نتیجه دلخواه خودش برسد و آن اتفاقی که در زندگیش افتاده را توجیه کند. می‌خواهد به نقطه‌ای برسیم که هم خودش و هم ما قبول کنیم که آن اتفاق قسمتش بود و او نمی‌توانسته نقشی در نتیجه آن اتفاق داشته باشد. می‌خواهد چشم‌هایش را بر حقیقت ببندد و فقط با جمله “قسمت‌م این بود” به آرامشی هر چند کوتاه‌مدت، دست بیابد.
امیر شاید به اندازه آن دوست پارگراف بالا قفسه‌های پر کتاب جامعه‌شناسی، روانشناسی، فلسفه و … نداشته باشد. اما امیر در صفحه فیس‎‌بوک خود نوشته «میدونستید اگه ایرانیها میخواستن کولر رو اختراع کنن هیچ وقت اختراع نمیشد! چون هی‌هی مثل خیلی از ماها میگفتن خدا حتمن یه چیزی میدونه که تابستونو گرم کرده اگه خودش بخواد سردش میکنه. خدا میدونه چی واسه ما خوبه :|میدونید از چی متنفرم؟ از اینکه بگن این حکمت خدا بوده که اینطوری شده یا این قسمت نبوده که اینطوری شده. » از نظر من امیر این جامعه، مردمش و تفکرش را می‌شناسد و نمی‌خواهد بخاطر آرامش چشمانش را بر حقیقت ببندد.
من از توجیه کردن، کتمان حقیقت و هر چیزی که کم‌کارهای خودمان را پنهان کند نفرت دارم. اما حقیقت‌گریزی و پنهانکاری در ذات اغلب آدم‌های این جامعه هست. این حرف من نیست، فقط کافی هست که چشم‌هایم را ببندم و صفحات چند کتاب را به یاد بیاورم. جامعه‌شناسی خودمانی نوشته حسن نراقی مثل همیشه گزینه اول هست که در ذهنم خودنمایی می‌کند.
«در مجموع ما ایرانی‌ها علاقه چندانی به روبرو شدن با حقایقی که به هر دلیلی مطابق میل و سلیقه‌مان نباشد نداریم.
از بیماری صعب‌العلاجی که خدای ناکرده گریبان خود و یا عزیزی از اطرافیانمان را گرفته تا معظلات و مشکلات اجتماع ترجیح می‌دهیم در بهترین حالت با سکوت به آسانی از کنار آن بگذریم و به این منظور در حادترین شرایط حاکم با «انشاءا…» . به امید خدا و در اوج بی‌علاجی «هر چی خداوند مقدر کرده باشند»، صورت مسئله را پاک می کنیم. غافل از این‌که به استناد ده‌ها توصیه مسلم انجام این گونه امور را خداوند به عهده خود ما قرار داده و قرار هم نیست اگر کوشش در رفع معضل نکنیم خود بخود حل شود.»
اما این درد، یک درد کهنه هست و مانند یک میراث خانوادگی از نسلی به نسل دیگر منتقل می‌شود. قبل از حسن نراقی، فریدون آدمیت در کتاب اندیشه‌های میرزا آقاخان کرمانی همین جملات را تکرار می کند. «از اینرو در دماغ ایرانیان عقیده غریبی رخنه یافته که همه چیز را به بخت و طالع نسبت می‌دهند، و زحمت و کوشش را در تحصیل ثروت و آبرو شرط نمی‌دانند. این اعتقاد درهای علم و معرفت را چنان به‌روی اهالی این مملکت بست که پیدایش اشیاء را بی‌سبب دانسته‌اند و «عقب پژوهش علل اشیاء که ریشه درخت علم است برنیامده‌اند». رفته‌رفته این مرض شوم کار مردم این مرز و بوم را به جایی کشانیده که هر تقصیر در تدبیر را حواله به تقدیر می‌کنند و هر خرابی را محول به مشیت پروردگار می‌نمایید.»
اما این مشکل فقط مربوط به جامعه ما نیست و تقریبا تمام کشورهای خاورمیانه را در برمی‌گیرد. استفین پی. رابینر در کتاب مبانی رفتار سازمانی بیان می کند «در کشورهای خاورمیانه، مردم از این دیدگاه به زندگی نگاه می‌کنند که از قبل تعیین شده است. هنگامی که رویدادی رخ می‌دهد آنها آن را خواست خدا می‌دانند. در جامعه‌ای که خود را تابع محیط می‌داند، تعیین هدف اهمیت چندان زیادی ندارد. اگر قرار باشد انسان بر این باور باشد که نمی‌تواند در امر رسیدن به هدف کار چندان زیادی انجام دهد، دیگر تعیین هدف چه فایده‌ای دارد.»
سالها هست که این کتابها هست، سالها هست که هزاران نفر این کتابها را می‌خوانند، سالها هست کسانیکه این کتابها را نه خواندن و نه نوشتن این درد را می‌بینند. اما دیدن، نوشتن و خواندن داروی این درد نیست چون اگر دارویش بود تا بحال باید ریشه این بیماری از بین رفته بود. داروی این درد فقط پذیرفتن حقیقت هست با تمام دردهای نهانش، داروی این درد اینست که ما میراث‌دار خوبی نباشیم و کوری را بخاطر آرامش تحمل نکنیم.