بازسازی کد: ارزش کد خودآزما (Self-testing code)

  • یوسف مهرداد بی‌بالان

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

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

معمولا هر برنامه‌نویسی خاطره‌ای دارد از این که کل روزش را برای پیدا کردن یک خطا مشغول بوده است [شما بخوانید سر کار بوده! مترجم]. رفع خطا معمولاً بسیار سریع انجام می‌شود، اما پیدا کردن خطا واقعا کابوس است.

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

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

وقتی تست‌ها دستی باشند به شدت خسته‌کننده‌اند. اما وقتی خودکار باشند، نوشتن تست‌ها واقعا بسیار سرگرم‌کننده و جذاب است.

گزیده: (عجب گزیده‌ای)
کیفیت واقعی به این معنی است که مطمئن باشید افراد به کدی که می‌نویسند افتخار می‌کنند، فعالانه مشارکت می‌کنند و آن را از خود می‌دانند (نسبت به آن حس غرور، مالکیت و مسئولیت‌پذیری دارند).
لینوس توروالد، سپتامبر ۲۰۰۸

Real quality means making sure that people are proud of the code they write, that they’re involved and taking it personally. Linus Torvalds

 

برای یک روز تعطیل عالی!

  • یوسف مهرداد بی‌بالان

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

«چند روز پیش یک نفر به من گفت دو تا بچه دارم که گشنه موندن یه غذایی بگیر من ببرم خونه بهشون بدم بخورن. من رفتم همون سوپری نزدیک گفتم چی بخرم گفت تخم مرغ و نون. ۱۵ تا تخم مرغ و دو بسته چهار تایی نون لواش و دو تا روغن کوچیک گرفتم شد ۲۴۰ هزار تومن! یک لحظه با خودم گفتم یعنی یک خانوار سه نفره در طول روز برای سه وعده نون و تخم مرغ باید ۳۰۰ هزار تومن هزینه کنه و در ماه ۹ میلیون تومن فقط پول غذای حداقلی؟! میانگین دریافتی کارمندای دولت و بازنشسته ها و نظامی ها چقدره؟»

به برادرها و خواهرها و همسایه‌ها و دوستانم فکر می‌کنم. به دوست تازه‌دامادی که دیروز از فشار فکری راهی بیمارستان شده فکر می‌کنم. کاری از دست‌ام بر نمی‌آد جز امید به روزهای خوش، آن هم اگر امیدی باقی مانده باشد!

توصیه‌های ChatGPT به توسعه‌دهندگان نرم‌افزار

  • یوسف مهرداد بی‌بالان

مکالمه‌ی کوتاهم با ChatGPT را در اینجا آورده‌‌ام با این هدف که برای خوانندگان عزیزم مفید باشد.


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

شما چه توصیه‌ای به توسعه‌دهندگان نرم‌افزار دارید؟
مهم‌ترین توصیه من به توسعه‌دهندگان نرم افزار این است که به یادگیری (learning)، رشد و پیشرفت (growth) خود ادامه دهند. دنیای توسعه‌ی نرم‌افزار پیوسته در حال تحول است و از این رو مهم است که در زمینه‌ی آخرین فناوری‌ها، ابزارها و تکنیک‌ها به‌روز باشید.
در اینجا به چند توصیه‌ی ویژه‌ی دیگر هم اشاره می‌کنم:
۱- به یادگیری ادامه دهید:‌ حوزه‌ی توسعه‌ی نرم‌افزار پیوسته در حال تغییر است و در نتیجه آشنایی با آخرین پیشرفت‌ها در آن بسیار حائز اهمیت است. روش‌های بسیاری از جمله شرکت در کنفرانس‌ها و دوره‌ها یا روش‌های ساده‌تری مانند خواندن بلاگ‌ها و سایت‌های خبری برای یادگیری و رشد و پیشرفت وجود دارد.

۲- همکاری کنید و ارتباط داشته باشید: توسعه‌ی نرم‌افزار به ندرت به صورت تک‌نفره انجام می‌شود و بنابراین همکاری و ارتباط اثربخش با دیگر اعضای تیم بسیار مهم است. این همکاری و ارتباط شامل مواردی از جمله برگزاری و شرکت جلسات دوره‌ای، مستندسازی شفاف و استفاده از ابزارهای همکاری مانند ابزارهای کنترل نسخه‌ها (version control) و ثبت و ردیابی مسایل و مشکلات ( issue tracking ) است.

۳- کد تمیز و خوانا بنویسید: یکی از مهم‌ترین مهارت‌های توسعه‌دهندگان نرم‌افزار، توانایی نوشتن کد تمیز و خوانا است. نه تنها پشتیبانی و خطایابی کد خوب راحت است بلکه فهمیدن و کارکردن با آن برای سایر توسعه‌دهندگان نیز راحت است.

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

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

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

با احترام
ChatGPT
۳۰ بهمن ۱۴۰۱، ۱۸ فوریه ۲۰۲۳

بازسازی کد: نام‌های اسرارآمیز

  • یوسف مهرداد بی‌بالان

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

  • یوسف مهرداد بی‌بالان

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

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

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

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

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

برای خروج از جستجو کلید ESC را بفشارید