وای چقدر حرفه‌ای!

۲۰ اردیبهشت ۱۳۹۴ ۶ دیدگاه

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

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

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

یادمان باشد که ما با نفی کردن دیگر دوستان و همکاران حرفه‌ای نامیده نخواهیم شد. بلکه ما با اخلاق حرفه‌ای و آگاهی به ناکامل بودن هر موجودی و احترام به داشت‎های دیگر دوستان می‌توانیم تلاش کنیم تا حرفه‌ای نامیده بشویم.

گاهی به شکستن قوانین فکر کن

افشار محبی عزیز در زیر پست قبلی کامنتی با این مضمون نوشتند: «نمی‌دانم شاید دیگر بر حسب عادت باشد. اما من هم حس می‌کنم ذهن و بدنم روی ۸ ساعت کار تنظیم شده است. اگر از این کمتر کار کنم حس تنبلی به من دست می‌دهد و اگر بیشتر از این کار کنم حس می‌کنم کارایی‌ام را از دست می‌دهم.»

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

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

می دانید چرا فاصله‌ی ریل‌های قطار ۱۴۳٫۵ است ؟ «در آغاز وقتی اولین واگن های قطار را می ساختند از همان معیارهایی استفاده کردند که در ساخت کالسکه به کار می رفت.چرا فاصله‌ی چرخ های کالسکه این قدر بود؟چون خیابان های قدیم مطابق با این فاصله ساخته شده بود وکالسکه‌ها فقط با رعایت این فاصله می‌توانستند رفت و آمد کنند. کی تعیین کرده عرض خیابان این قدر باشد؟ و ناگهان برمی‌گردیم به گذشته‌های خیلی دور: رومی‌ها، نخستین مهندسان بزرگ راهساز، این طور تصمیم گرفته بودند.دلیلش چه بود؟ ارابه‌های جنگی را دو اسب می راندند -و وقتی دو اسب را از نژادی که آن زمان به کار می رفت٬کنار هم بگداریم٬ فضایی معادل ۱۴۳.۵ سانتیمتر را اشغال می کنند. بدین ترتیب رومی های باستان فاصله‌ی ریل‌های قطار امروز را تعیین کرده‌اند٬ریل‌هایی که برای مدرن ترین قطارهای سریع السیر هم به کار می رود. وقتی مهاجران به ایلات متحده رفتند و شروع کردند به کشیدن خط آهن، فکر نکردند شاید بهتر باشد این فاصله را تغییر بدهند، و با حفظ همان نسبت کار را ادامه دادند. این موضوع بر ساخت اتوبوس‌های فضایی هم تاثیر گذاشت: نظر مهندس‌های آمریکایی این بود که باید مخازن سوخت را بزرگ‌تر بسازند، اما این مخازن در ایالت اوتاه ساخته می‌شد و باید آن‌ها را با قطار به مرکز فضایی فلوریدا می‌رساندند، و تونل‌ها گنجایش شیی با اندازه‌ی بزرگ‌تر را نداشت: در نتیجه مجبور شدند تسلیم نظر رومیان درباره فاصله‌ی مناسب بین دو ریل بشوند.» (کتاب زهیر پائولو کوئلیو)

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

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

Categories: دسته‌بندی نشده Tags:

داستان هشت ساعت قانون کار

داشتم توی دهن خودم کلنجار می‌رفتم که یک پست درباره میزان ساعت‌های کاری و سرعت توسعه پایدار در تیم‌ها بنویسم. تا رسیدم به یک تکنیک XP که تاکید می‌کند که تیم‌ها هر روز تعداد ساعت ثابتی را کار کنند و بعد از آن کار را تعطیل کنند. این تکینک میزان ساعت کاری که توصیه می‌کند ۴۰ ساعت در هفته است. همین ۴۰ ساعت برایم داستان را جالب کرد اگر شما هر هفته را ۵ روز کاری در نظر بگیرید آنوقت به همان ۸ ساعت قانون کار خودمان می‌رسید. کنجکاو شدم ببینم این ۸ ساعت قانون کار از کجا آمده؟

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

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

تام مان (Tom Mann) یک سوسیالیست دیگر در سال ۱۸۸۴ دوباره تلاش برای کاهش ساعات کاری روزانه را به ۸ ساعت از نو شروع کرد. اینبار این حرکت که از بریتانیا شروع شده بود بسیار گسترده شد و تا آمریکا رسید. و در اول مه  ۱۸۸۶ بود که کارگران آمریکای در شیگاگو برای دست یافتن به این هدف دست به راهپیمایی و اعتصاب زدن و در چهارمین روز این اعتصاب اتفاق‌های بسیار تلخ رخ داد، به همین دلیل اول مه هر سال را در دنیا به نام روز کارگر پاس می‌دارند.

با همه این اتفاقات و جنبش‌ها هنوز بسیار از صنایع تا اوایل قرن بیستم ۸ ساعت کار روزانه را به عنوان یک اصل قبول نکردند. یکی از اولین شرکت‌ها که این اصل را پذیرفت شرکت خودروسازی فورد بود که در ۱۹۱۴ ساعات کاری روزانه کارگران خود را به هشت ساعت کاهش داد و همزمان حقوق آنها را نیز افزایش داد. این تغییر در طول ۲ سال باعث شد که میزان سود فورد افزایش پیدا کند. تاثیر این اتفاق باعث شد که بسیاری از شرکتها نیز رویه مشابهی را برای کاهش ساعات کاری به هشت ساعت پیش بگیرند. و در نهایت در ۱۹۳۷، هشت ساعت کار روزانه به عنوان یک قانون در ایالت متحده تصویب شد.

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

عمق وراثت (Depth of Inheritance)

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

وراثت در برایر Decorator

وراثت در برایر Decorator

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

عمق وراثت یکی از متریک‌های طراحی شی‌گرا می‌باشد که به این شکل تعریف می شود: “حداکثر فاصله یک گره از گره پدر درخت”. برای نمونه من درخت وراثت را برای کلاس Hidden از فریم‌ورک Asp.NET MVC رسم کردم و همانطوریکه در تصویر مشخص هست عمق این درخت ۴ هست. به یک نکته توجه کنید که در بسیاری از زبانها همه کلاس‌ها از یک کلاس پایه ارث می‌برند حتی اگر به طور صریح در کد شما به آن اشاره نشده باشد. برای نمونه در سی شارپ همه کلاسها از کلاس Object ارث می‌برند پس هر کلاسی که شما ایجاد کنید حداقل دارای عمق یک خواهد بود.

 

عمق وراثت کلاس Hidden

عمق وراثت کلاس Hidden

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

 

حداکثر مقدار قابل قبول برای عمق وراثت چقدر است؟ هیچ مقدار استانداردی برای حداکثر مقدار بهینه عمق وراثت تا بحال اعلام نشده است. مقادیر توصیه شده از ۵ تا ۸ متغییر است. برای نمونه مستندات مایکروسافت ویژوال استودیو مقدار ۵ را پیشنهاد می‌کند در حالیکه برای نمونه در سورس Asp.net MVC که مربوط به خود این شرکت هست عمقی تا هفت را می‌توان مشاهده کرد. شاید دلیلی که نمی‌توان یک حداکثر مقدار بهینه برای این متریک تعیین کرده در متفاوت بودن ماهیت سیستم‌های نرم‌افزاری باشد. برای مثال شاید برای یک فریم‌ورک توسعه وب مقدار ۵، ۶ قابل قبول است در حالیکه برای یک سیستم اتوماسیون اداری این اعداد یک مقدار بزرگ است.

حداکثر عمق کلاس در فریم‌ورک ASP.NET MVC

حداکثر عمق کلاس در فریم‌ورک ASP.NET MVC

من و ابهاماتم از کار حرفه‌ای

اپیزود اول

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

اپیزود دوم

  • من کم‌کاری نمی‌کنم، دقیقا به اندازه پولی که به هم می‌دهند کار می‌کنم. پس کار چند روز را تا چند هفته کش می‌دهم.

اپیزود سوم

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

جلسات باز نرم‌افزاری تبریز

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

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

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

Episode

 خودمختاری! . آدمی حتی از شنیدن کلمه اختیار و آزادی حس خوب پیدا می‌کند چه برسد به داشتنش. این موارد امروزه از محرک‌های اصلی برای انگیزش تیم‌ها و افراد هست. گوگل، فیس‌بوک، تیم‌های چابک، سازمانهای افقی و … یکی از عناصر اصلی که به کارمندان و تیم‍‌های می‌دهند خودمختاری هست. حتی ما سیستمی به نام “محیط کاری نتیجه‌گرا” (ROWE) را داریم که خودمختاری افراطی را توصیه می‌کند. در این سیستم مردم زمانبندی ندارند، هر وقت بخواهند سرکار می‌روند. موظف نیستند سر ساعت خاصی در دفترشان باشند، یا اصلا بروند. اونا فقط باید کارشان را انجام بدهند. چطور این کار را انجام می‌دهند، کجا انجام می‌دهند، کاملن بستگی به خودشان داره. جلسات در این نوع محیط‌ها اختیاری است. و در نهایت بازدهی در همه زمینه‌ها بالا می‌رود.

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

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

اندازه‌گیری پیچیدگی نرم‌افزار

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

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

گراف کنترل جریان

گراف کنترل جریان متد جستجوی باینری

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

Cyclomatic complexity = E – N + 2

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

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

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

CC = 14 – ۱۲ + ۲ = ۴

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

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

if | while | for | for each | case | default | continue | goto | && | || | catch | ?: | ??

 

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

منوی اندازه گیری متریک‌های کد

منوی اندازه گیری متریک‌های کد

صفحه خروجی متریک‌های کد نرم‌افزار

صفحه خروجی متریک‌های کد

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

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

Cyclomatic Complexity سطح پیچدگی ریسک
۱-۱۰ ساده کم
۱۱-۲۰ نسبتا پیچیده متوسط
۲۱-۵۰ پیچیده زیاد
بزرگتر از ۵۰ غیرقابل تست خیلی زیاد

 

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

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

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

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

تست مسیر 1

تست مسیر ۱ در متد جستجوی باینری

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

 

تست مسیر 2

تست مسیر ۲ در متد جستجوی باینری

قوانین طراحی ساده

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

 یک از ارزش‌های 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 واقعاً روی آن تاکید دارد و اعلام می‌کند که شما حتی اگر اطمینان حاصل کنید که به این ویژگی در آینده نیاز خواهید داشت آنرا الان پیاده سازی نکنید. پس هدف اصل چهارم این است که نباید با پیاده‌سازی کلاس‌ها و متدهایی که احتمالاً در آینده فرضی به آن نیاز خواهیم داشت نعداد کلاس‌ها و متدها را افزایش بدهیم.

سپرده‌گذاری در بانک مساعدت

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

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

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

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

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

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

«و یک روز ….»

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

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

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

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

Categories: دسته‌بندی نشده Tags:

رویاهای ما برای جامعه حرفه‌ای ما

۱۵ شهریور ۱۳۹۳ ۱۹ دیدگاه

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

گاهی «نمی‌دانم» جواب سوال هست.

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

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

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

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

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

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