اگر مشغول خواندن یک رمان پلیسی باشید، اتفاق خوشایندی است که مجبور شوید تمام فکر و حواس‌تان را روی بخشی از کتاب متمرکز کنید تا بفهمید چه اتفاقی دارد می‌افتد. اما موقعی که مشغول خواندن کدی هستید، چنین اتفاقی اصلا خوشایند نیست. ممکن است در مورد خودتان تصور کنید که شما هم یکی از اعضای «مردان اسرار آمیز بین‌المللی» (International Men of Mystery) هستید که کسی سر از کارتان در نمی‌آورد. قبول! با این‌حال وقتی نوبت به کدتان می‌رسد، کدتان باید «رو زمینی» و «روشن و شفاف» باشد (به راحتی قابل درک و فاقد پیچیدگی غیرضروری و عناصر گیج‌کننده باشد).
یکی از مهم‌ترین بخش‌های یک کد روشن و شفاف، نام‌های مناسبی است که در کد وجود دارد. و به همین دلیل است که ما در انتخاب اسامی توابع، ماژول‌ها، متغیرها و کلاس‌ها، دقت زیادی به خرج می‌دهیم. و به همین دلیل است که اسامی آنها به خوبی بیان می‌کنند چه کاری انجام می‌دهند و ما چگونه می‌توانیم از آنها استفاده کنیم.
متاسفانه نام‌گذاری یکی از دو کار دشوار در برنامه‌نویسی است. و به همین دلیل است که پرکاربردترین تکنیک بازسازی کد (refactoring)، تغییر نام است.
افراد از این که نام‌ها را در برنامه تغییر بدهند می‌ترسند و فکر می‌کنند که این کار ارزش دردسرهای بعدی‌اش را ندارد. در حالی که نامگذاری درست و مناسب می‌تواند جلوی ساعت‌ها گیجی و نفهمیدن کد را در آینده بگیرد.
نام‌گذاری فقط مهارت تغییر نام‌ها نیست. معمولا ناتوانی شما در انتخاب نام مناسب برای یک عنصر نشان‌ می‌دهد که مشکل عمیق‌تر و جدی‌تری در طراحی وجود دارد. نفهمیدن یک نام دشوار و نامفهوم در کد معمولا منجر به ساده‌سازی‌های چشم‌گیر و قابل‌ملاحظه‌ای در آن می‌شود.

مرجع: Refactoring, 2nd Edition, by Martin Fowler.

گزیده:
[با وجود پیشرفت ابزار و تکنولوژی]، فرایند توسعه‌ی نرم‌افزار نسبت به گذشته لزوما بهتر (راحت‌تر و خوشایندتر) نشده است.
راب پایک (یکی از خالقان زبان Go)

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

قدم بعدی استفاده از پروفایلری (profiler) بود که کنت بک نوشته بود تا بتوانیم کارایی و سرعت سیستم را بررسی کنیم. بعد از اجرای پروفایلر، با کمال تعجب فهمیدیم که هیچ یک از حدس‌های ما دلیل کندی سیستم نبود. جالب‌تر این که متوجه شدیم که نصف زمان اجرای سیستم صرف ایجاد متغیری از نوع تاریخ می‌شود. موضوع عجیب‌تر این بود که تمام این متغیرها مقدار ثابت و یکسانی داشتند. … وقتی این مشکل را به کمک یک متغیر استاتیک حل کردیم سرعت سیستم دو برابر شد.

من به همراه اعضای تیم (غیر از کنت بک و مارتین فاولر ) که کد سیستم را به خوبی می‌شناختیم، در مورد ریشه‌ی کندی سیستم حدس‌هایی زده بودیم و تقریبا مطمئن بودیم که مشکل از آنهاست. ما حتی برای مواردی که حدس زده بودیم راهکارهایی هم آماده کرده بودیم؛ بدون آن بررسی کنیم واقعا چه اتفاقی در سیستم رخ می‌دهد.

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

درسی که باید بیاموزیم این است:‌حتی اگر می‌دانید واقعا در سیستم شما چه اتفاقی می‌افتد، کارایی و سرعت سیستم را اندازه بگیرد و از حدس و گمانه‌زنی پرهیز کنید. با این کار، شما چیزهای جدیدی از سیستم می‌فهمید و ۹۰ درصد مواقع چیزی که می‌فهمید این است که حدس شما اشتباه بوده.

نویسنده: ران جفری (Ron Jeffries)

مرجع: Refactoring, 2nd Edition, by Martin Fowler.

گزیده:
سادگی شرط لازم برای اعتمادپذیری است. (Simplicity is prerequisite for reliability.)
ادگر دایکسترا

اگر بخش قبلی در مورد مشکلات بازسازی‌کد (refactoring) را خوانده باشید، احتمالاً یکی از درس‌هایی که یاد گرفته‌اید این است که اثربخشی بازسازی کد با سایر تکنیک‌ها و روش‌هایی که یک تیم استفاده می‌کند، ارتباط تنگاتنگی دارد.
اکس‌پی (XP) یکی از اولین متدهای چابک بود و برای سالها رهبر تکنیک‌های جدید و نوظهور چابک بود. امروزه پروژه‌های زیادی از روش‌های چابک که جریان فکری اصلی آنها همان تفکر چابکی (agile thinking) است استفاده می‌کنند، هر چند در واقعیت، اکثر پروژه‌های «چابک» تنها بهره‌ای که از چابکی می‌برند فقط نام آن است.
برای اینکه تیمی واقعاً به روشی چابک رفتار کند باید اعضای آن در بازسازی کد، توانمند و مشتاق باشند و برای تحقق چنین شرایطی ضروری است بسیاری از جنبه‌های فرایند آنها، هم‌سو و هم‌جهت با تبدیل بازسازی‌ کد به بخشی منظم و عادی از کار توسعه باشد.
۱) اولین ستون و پای‌بست بازسازی کد، کد خودآزما (self-testing code) است. منظورم از کد خودآزما این است که مجموعه‌ای از آزمون‌های خودکار وجود دارد که با اجرای آنها، مطمئن می‌شوم در صورت ایجاد خطا توسط کد من، برخی از آزمون‌ها ناموفق خواهند شد و آزمون نیز با شکست همراه خواهد شد.
۲) برای بازسازی کد در یک تیم، این نکته مهم است که هر یک از اعضا بتوانند بدون خراب‌ کردن کار دیگران، کدها را تغییر بدهند و اصلاح کنند. به همین دلیل است که من یکپارچه‌سازی پیوسته (Continuous Integration) را توصیه می‌کنم.

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

پانوشت: YAGNI مخفف “You Aren’t Gonna Need It” است و تکنیکی است برگرفته از XP که بیان می‌کند برنامه‌نویس نباید کارکردی را به سیستم اضافه کند مگر آن که تشخیص داده شود ضروری است.

مرجع: Refactoring, 2nd Edition, by Martin Fowler.

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

“Baseball thinking is midevil. They are asking all the wrong questions. And if I say anything I get ostrisized. I’m a lepper.”
“Ok, think in terms of buying players. Your goal shouldn’t be to buy players it should be to buy wins. And in order to buy wins you have to buy runs.”
— Peter Brand, Moneyball

اما من فکر می‌کنم خطرناک‌ترین روشی که افراد به دام می‌افتند زمانی است که سعی می‌کنند بازسازی کد (refactoring) را بر اساس موضوعاتی مانند «کد تمیز» (Clean Code)، «تجربه‌ی خوب و شناخته‌شده‌ی مهندسی» (Good Engineering Practice) یا دلایل اخلاقی مشابه توجیه کنند.

هدف از بازسازی کد این نیست که نشان دهیم یک مخزن کد (code base) چقدر عالی و فوق‌العاده است. هدف از بازسازی کد صرفاً اقتصادی است. ما کد را بازسازی می‌کنیم زیرا چنین کاری سرعت انجام کارها را سریع‌تر می‌کند: افزایش سرعت افزودن ویژگی‌ها (features)، افزایش سرعت رفع اشکال‌ها و خطاها.

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

مرجع: Refactoring, 2nd Edition, by Martin Fowler.

گزیده:
تمیز نگه داشتن کد بسیار شبیه تمیز نگه داشتن یک اتاق است. هنگامی که اتاق به هم ریخته است، تمیز کردن آن سخت تر است. هر چه اتاق بیشتر به هم ریخته باشد، کمتر تمایل دارید سراغ تمیز کردن آن بروید.
Refactoring to Patterns By Joshua Kerievsky

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

تجربه‌‌ام نشان می‌دهد که بهترین روش بازنگری کد این است که در کنار برنامه‌نویس اصلی بنشینید، کد را با هم مرور کنید و همزمان با مرور کد، کد را بازسازی و تغییر دهید.

نهایت و غایت چنین سبکی به برنامه‌نویسی دونفره (pair programming) ختم می‌شود یعنی قرارگرفتن بازنگری پیوسته‌ی کد (continuous code review) به عنوان یکی از فعالیت‌های داخلی فرایند برنامه‌نویسی و نه فعالیتی بعد از اتمام آن.

مرجع: Refactoring, 2nd Edition, by Martin Fowler

گزیده:
Brevity is the soul of wit, but clarity is the soul of evolvable software.
Martin Fowler
برداشت شخصی: هر چند خلاصه، مختصر و مفید بیان کردن موضوعات نشانه‌ی هوشمندی و ذکاوت است [از نمایش‌نامه‌ی هملت اثر شکسپیر]، اما بر خلاف آن برای نرم‌افزار در حال تکامل، خوانایی و شفافیتِ کد رکن اصلی است و بهتر است کد به جای آن‌که کوتاه و دشوارفهم باشد طولانی‌تر ولی خواناتر باشد.

تعطیلات پایان سال فرصت خوبی است برای دیدن دوباره‌ی فیلم‌های خوب و آموزنده. یکی از این فیلم‌ها، فیلم رستگاری شائوشنگ یا The Shawshank Redemption است که دوباره دیدم. این فیلم یکی از بهترین‌ و محبوب‌ترین فیلم‌های تاریخ سینما است که کمتر کسی پیدا می‌شود که آن را تماشا نکرده باشد.
کلمه‌ی redemption که در عنوان فیلم آمده است به ویژه در آیین مسیحیت به معنای نجات انسانی از شر یا درد و عذاب یا همان رستگاری و رهایی است. تا به امروز بر این باور بودم که داستان فیلم درباره‌ی رستگاری اندی دوفرن (با بازی تیم رابینز) و رهایی‌اش از شر زندان شائوشنگ و به ویژه رییس زندان، واردی نورتن، است. اما نقدی درباره‌ی فیلم خواندم که با استدلال‌های قابل قبول مدعی شده بود که موضوع اصلی رستگاری و نجات در این فیلم به جای اندی دوفرن، الیس ردینگ معروف به رد (Red) (با بازی مورگان فریمن) است.

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

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

گزیده: (دیالوگ مورد علاقه‌ام)
اندی: می‌دونی مکزیکی‌ها درباره‌ی اقیانوس‌ آرام چی می‌گند؟
رد:‌ نه.
اندی: می‌گند اقیانوس آرام هیچ خاطره‌ای نداره [هیچی از گذشته یادش نیست]. می‌خوام بقیه عمرم رو همچین جایی زندگی کنم. جایی گرم و بدون خاطره‌ای از گذشته.

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

گفتار:
– مایکل، تمرین درس علوم اجتماعی‌‌ت چیه؟
مایکل: باید در مورد انقلاب فرانسه یک روزنامه درست کنیم.
– انقلاب فرانسه!
مایکل: آره
– بگو ببینم انقلاب فرانسه چه سالی اتفاق افتاد؟
مایکل: نمی‌دونم.
به کمک پروفسور گوگل پاسخ سوالم را پیدا می‌کند.

– خوب این روزنامه چه شکلی باید باشه؟
– مایکل:‌ باید بریم تحقیق کنیم و ۳ تا از عوامل مهمی رو که باعث بروز انقلاب شد پیدا کنیم.
– خب!
– در مورد عامل اول باید از قول نویسنده‌ی روزنامه، مطلبی در تایید وجود آن عامل بنویسم (مثلا نان گران است) و بعد در ادامه باید نظر مخالفان این نظر رو هم بنویسیم (مثلا نان خیلی ارزان است).
– (من با قیافه‌ای متعجب) خب!
مایکل: در مورد عامل دوم هم باید یک گزارش خبری کوتاه بنویسیم که اون عامل که باعث بروز انقلاب شده توی اون گزارش باشه (مثلا دیروز بین نانوا و مشتری در فلان جا بگومگو شد)
– (من با تعجب دو چندان) خوب! چه جالب!
مایکل:‌ درباره‌ی عامل سوم هم باید یک کاریکاتور سیاسی (political cartoon ) بکشیم.
– (من که از تعجب شاخ‌ در آورده بودم) خب!
– حالا شما چرا باید در مورد انقلاب فرانسه روزنامه درست کنید؟‌ اصلا چرا انقلاب فرانسه این قدر مهمه که توی درس‌تون باشه؟
مایکل:‌ برای این مهمه که توی انقلاب فرانسه پادشاهی بود که به حرف و اعتراض مردمش گوش نمی‌کرد و به اون‌ها ظلم و ستم می‌کرد، مردم هم اول اعتراض کردند و بعد دیدند چیزی تغییر نمی‌کنه انقلاب کردند و شاه رو برکنار کردند.
– (من که دیگه کارم از شاخ درآوردن گذشته بود) اوه! اوه! چقدر عالی.

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

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

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

گزیده:
شما، که قوانین را برمی‌سازید؛ فضایل و رذایلِ مردم نتیجه کارتان خواهد بود.
لوئی آنتوان دو سن-ژوست