سماموس: نوشته‌های یوسف مهرداد بی‌بالان

بوی جوی مولیان آید همی!


با تشکر از خانم مانا عزیزی




 https://www.bibalan.com/?p=4222
https://t.me/bibalan_com

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

گفتار:
عنوان نامه: آشغال ها را دوست داشته باش

۵ سال قبل بود که شروع کردم به نوشتن مقاله در Codeproject, بار اول که مقاله را فرستادم, یک جواب ناراحت‌کننده گرفتم: “این مقاله یک آشغال کد است”.

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

امروز سال ها از آن روز که کار تحقیقاتی کوچولویم با عنوان “آشغال” نام برده شده می‌گذرد. اگرچه روزی خبر از Codeproject می‌دادم و شما به من با تشویق‌هایتان دلگرمی می‌دادید, حالا اما خبر بزرگتری دارم.

نتایج تحقیقات ۳ سال گذشته را در قالب ۲ مقاله در زمینه استفاده از الگوریتم‌های یادگیری ماشین به کنفرانس کاربرد مهندسی در پزشکی و بیولوژی (EMBC) با قدمت ۳۸ ساله فرستادم. این کنفرانس که مهمترین کنفرانس در زمینه مهندسی در پزشکی در جهان است, هر ساله در کشور آمریکا برگزار می‌شود و پذیرای قشر متنوعی از محققان و پزشکان از دانشگاه‌های و مراکز تحقیقاتی از سراسر دنیاست.

ترسیدم که بگویند این ۲ تا آشغالت را بردار و برو پی کارت. اما می‌دانستم که آشغال ها را باید دوست داشت. گفتم اگر هم شکست خوردم, بر می‌گردم و تدارک میبینم و دوباره می‌فرستم. اما امشب نتایج بررسی ۳ ماهه مقالات آمد و هر ۲ مقاله در کمال ناباوری‌ام پذیرفته شد.

می‌گویم می‌خواهم یک راز مهمی با شما در میان بگذارم. فقط هیس!! بیایید جلوتر. بیشتر…. بیشتر… ” آشغال ها بهترین دوستان ما هستند.. آشغال ها را دوست داشته باش! “.

۱۹ اردیبهشت ۱۳۹۴

گزیده:
«موفقیت یک نتیجه است نه یک هدف» گوستاو فلوبر

 https://www.bibalan.com/?p=1125
https://t.me/bibalan_com

بازسازی کد: ارزش کد خودآزما (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


 https://www.bibalan.com/?p=4211
https://t.me/bibalan_com

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

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

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

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

 https://www.bibalan.com/?p=4208
https://t.me/bibalan_com

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


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

https://bit.ly/3lRryeo

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

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

در اینجا به چند توصیه‌ی ویژه‌ی دیگر هم اشاره می‌کنم:

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

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

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

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

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

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

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

https://www.bibalan.com/?p=4200
https://t.me/bibalan_com

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

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

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

متاسفانه نام‌گذاری یکی از دو کار دشوار در برنامه‌نویسی است. و به همین دلیل است که پرکاربردترین تکنیک بازسازی کد (refactoring)، تغییر نام است.

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

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

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

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

https://www.bibalan.com/?p=4195
https://t.me/bibalan_com

حدس نزنید، اندازه بگیرید

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

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

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

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

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

نویسنده: ران جفری (Ron Jeffries)
مرجع: Refactoring, 2nd Edition, by Martin Fowler.

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


https://www.bibalan.com/?p=4183
https://t.me/bibalan_com

بازسازی کد، کد خودآزما، یکپارچه‌سازی پیوسته


اگر بخش قبلی در مورد مشکلات بازسازی‌کد (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.

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


https://www.bibalan.com/?p=4177
https://t.me/bibalan_com

دام توجیه بازسازی کد (Refactoring)


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

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

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

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

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

به یاد آرش

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

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


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

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

۲۴ دی ماه ۱۳۹۸

bit.ly/3QwLTBc

https://www.bibalan.com/?p=2711
https://t.me/bibalan_com

بهترین روش بازنگری کد

چگونگی انجام بازسازی کد (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

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

https://www.bibalan.com/?p=4157
https://t.me/bibalan_com

رستگاری شائوشنگ

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

bit.ly/3jxpirL

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

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

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

اندی: «یادت باشه رد، امید چیز خوبیه، شاید بشه گفت بهترین چیز دنیاست و چیزهای خوب هیچ وقت نمی‌میرند.»

گزیده: (دیالوگ مورد علاقه‌ام)
اندی: می‌دونی مکزیکی‌ها درباره‌ی اقیانوس‌ آرام چی می‌گند؟

رد:‌ نه.

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


https://www.bibalan.com/?p=4153
https://t.me/bibalan_com

برای تعلیمات اجتماعی

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

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

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

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

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

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

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


https://www.bibalan.com/?p=4130
https://t.me/bibalan_com

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

لطفا اگر پیامی از طرف من دریافت کردید آن را فراموش کنید.

کو خاک بر سر ماره اولاده

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

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

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

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

حالا این روزها به یاد مادر، بارها این جمله‌ی او را با خود زمزمه کرده‌ام که «کو خاک بر سر ماره اولاده»

https://www.bibalan.com/?p=4105
https://t.me/bibalan_com

تا نفس باقى است غلط بنویسیم

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

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

۱. ضمیر ابتداى جمله زائد است. پیدا است که من و شما ضمیر فعل جمله نیستیم.
۲. چون لحن کتاب متمایل به‌سادگى لحن محاوره است «جلو» کافى و «در» زائد است.
۳. سر نرم پایان کلماتى چون جلو و چلو و دو و پالتو برخلاف ر و س در حالت اضافه به مصوت ِ«ىِ» نیاز ندارد زیرا در این حالت سىِ نیمه ملفوظِ انتهائى به حسىِ کامل تبدیل مى‌شود: «جلوِ کتابخانه» «دوِ صدمتر» وگرنه: «جلوى» (=پیشین) و «چلوى» (=آن‌که چلوپزد یا فروشد).
۴. جامه ابتدا نیمدار (=کارکرده) است پس از آن کهنه. نه اول کهنه و بعد نیمدار. تازه گیریم که این دو به یک معنى باشد، جمله را چرا باید بى‌جهت سنگین کرد؟
۵. نقطه اول و هرسه ویرگول میان جمله زائد است.
۶. اگر جمله به این شکل نوشته مى‌شد عیبى داشت؟: «تو پالتوِ نیمدارش دست به جیب جلوِ کتابخانه به دیوار تکیه مى‌داد و منتظر مى‌شد.»

گزیده:
شب‌های تارِ نم‌نمِ باران ــ که نیست کار ــ
اکنون کدامیک ز شما
بیدار می‌مانید
در بسترِ خشونتِ نومیدی
در بسترِ فشرده‌ی دلتنگی
در بسترِ تفکرِ پُردردِ رازِتان

https://www.bibalan.com/?p=4102
https://t.me/bibalan_com

کدام دسته از توسعه‌دهنگان هستید؟

به نظر شما، بر اساس روز کاری ایده‌آل‌تان، شما در کدام دسته‌ از توسعه‌دهندگان زیر قرار می‌گیرید؟ ویژگی‌های کاری و شخصی شما به کدام گروه از توسعه‌دهندگان شامل توسعه‌دهندگان اجتماعی (Social)، تنها (Lone)، متمرکز(Focused)، متعادل (Balanced)، هدف‌گرا (Goal-oriented) یا رهبر (Leading) شباهت دارد؟


گزیده:
۲۰۱۱: نرم‌افزار داره دنیا رو می‌خوره. مارک اندریسون (Marc Andreessen)
۲۰۲۲: نرم‌افزار داره نرم‌افزاری رو که در حال خوردن دنیاست می‌خوره. جان اکارد (Jon Eckhardt)

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


https://www.bibalan.com/?p=4094
https://t.me/bibalan_com

گپ و گفت‌های هوش مصنوعی (۳)
https://bit.ly/3DnWCJw

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

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

این ادعا نشانگر شرط‌بندی بی‌پروایی علیه نبوغ انسانی است. ما قبلا این شرط را بسته‌ایم و باخته‌ایم.

در ۱۱ سپتامبر ۱۹۳۳، ارنست راترفورد، فیزیکدان پرآوازه، با اطمینان کامل گفت «هر کس از تبدیل این اتم‌ها انتظار منبع توان داشته باشد، حرف پوچ و چرندی می‌زند.» در ۱۲ سپتامبر ۱۹۳۳، لئوسیلارد واکنش زنجیره‌ای هسته‌ای با القای نوترون را اختراع کرد و چند سال بعد چنین واکنشی را در آزمایشگاهش در دانشگاه کلمبیا نشان داد. او نشان داد که شکافت هسته‌ای به واکنشی زنجیره‌ای می‌انجامد. سیلارد در خاطراتش نوشته است: «ما همه چیز را خاموش کردیم و به خانه رفتیم. آن شب، هیچ شکی در ذهن من وجود نداشت که دنیا به سوی غم و اندوه روان شده است.»

استوارت راسل (Stuart Russell)، استاد دانشگاه برکلی، نویسنده معروف کتاب‌‌های هوش مصنوعی

منبع: کتاب تراوش‌های ذهنی، ۲۵ شیوه نگرش به هوش مصنوعی، فصل ۳
نوشته جان بروکمن، ترجمه استاد گرامی ابراهیم نقیب‌زاده مشایخ



آدرس کتاب:‌
https://bit.ly/3o46tv9

https://www.bibalan.com/?p=4090
https://t.me/bibalan_com

نخست مرتب‌ کنید (tidy first) (۴ و پایانی )
سخن پایانی
روش “نخست مرتب کنید” به بررسی تغییرات طراحی در ابعاد بسیار کوچک می‌پردازد و رابطه‌ی برنامه‌نویس با خودش را بررسی می‌کند. این روش چیزهای زیادی برای اندیشیدن و آموختن دارد اگر به دنبال یافتن راه‌هایی هستید تا به کمک آنها بتوانید پروژه‌ها و تیم‌های خود را بهتر مدیریت کنید.
به همین دلیل است که ما در Beetroot به دنبال ایجاد فرهنگی انسان‌محور هستیم تا تیم‌ها در کنار رشد و پیشرفت، با همدلی روی راه‌کارهای تاثیرگذار کار کنند. اگر شما یکی از این تیم‌ها را انتخاب کنید و به آن بپیوندید، ما می‌توانیم با هم کارهای فوق‌العاده‌ای انجام دهیم.

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



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

https://www.bibalan.com/?p=4081
https://t.me/bibalan_com

نخست مرتب‌ کنید (tidy first) (۳ )
خُب، مرتب‌سازی (tidying) چیست؟
بک با شوخ طبعی همیشگی‌اش توضیح می‌دهد: «هر مرتب‌سازی (tidying) یک بازسازی (refactoring) کوچولو موچولوی نازنازی نادقیق است. هر مرتب‌سازی یک تغییر در ساختار سیستم است که تغییر در رفتار سیستم را آسان‌تر می‌کند. هر کار از نوع «نخست‌ مرتب‌‌ کنید» (tidy-first) تلاش می‌کند ساختارِ کد را بدون ایجاد ترس و وحشت تغییر دهد.”


اجازه دهید مثالی را با هم مرور کنیم. فرض کنید با یک تابع (function) بزرگ که تعداد خط‌های آن زیاد است رو به رو هستید. قبل از تغییر آن، کد تابع را می‌خوانید تا بفهمید چه کار می‌کند و ببینید چطور می‌توانید آن‌را به طور منطقی به بخش‌های (chunk) کوچکتر تقسیم کنید.
https://bit.ly/3eEKlX4


توجه کنید که تقسیم کد به بخش‌های کوچک‌تر، یک «مرتب‌سازی»(tidying) ساده است. ما صمیمانه به شما پیشنهاد می‌کنیم به کانال YouTube ما بروید (https://youtu.be/VrkRAVX1h4I) و کل سخنرانی را تماشا کنید تا مثال‌های بیشتری از مرتب‌سازی با استفاده از عبارت‌های نگهبان (guard clause)، توضیح‌ کد (comment) یا توابع کمکی (helping function) را ببینید.

(مترجم؛ عبارت نگهبان (guard clause) یکی از روش های بازسازی کد است که در آن، با استفاده از چندین شرط، ساختار درختی کدی که دارای شرط‌های تو در تو(Nested Conditional) است، حذف و به یک ساختار مسطح تبدیل می‌شود. یک نمونه از آن را در کد زیر می‌توانید ببینید.
https://bit.ly/3quIZkk
منبع کد: refactoring.guru

(مترجم؛ تابع کمکی (helping functions) تابعی است که بخشی از وظیفه‌ی تابع دیگری را انجام می دهد. توابع کمکی برای خوانایی بیشتر کد استفاده می‌شوند چون بخشی از کد تابع اصلی را جدا می‌کنند و نام جداگانه‌ و خوانایی به آن اختصاص می‌دهند. این توابع به شما اجازه می دهند از کد جداشده در تابع‌های دیگر نیز دوباره استفاده کنید.)

چرا تغییر نرم افزار پرهزینه است؟
برداشت دیگری که می‌توانید از این مفهوم طراحی نرم افزار داشته باشید این است که هزینه نرم افزار تقریباً با هزینه تغییر آن برابر است و توسعه اولیه تاثیر چندانی بر آن ندارد. با این حال، همه تغییرات یکسان و شبیه به هم نیستند: گاهی اوقات هزینه کل ایجاد یک تغییرِ “ارزان” تحت تاثیر هزینه‌‌های چند تغییر بسیار گران قرار می‌گیرد. از نظر فنی، توزیع هزینه ویژگی‌ها (features) از توزیع توانی (power law distribution) پیروی می‌کند. چرا برخی از تغییرات بسیار پرهزینه‌تر از بقیه تغییرات هستند؟

(مترجم؛ توزیع توانی در علم آمار، نوعی رابطه بین دو کمیت است که یک کمیت به صورت توانی از دیگری تغییر می‌کند. مثلاً مساحت یک مربع از دیدگاه طول ضلع آن را در نظر بگیرید، اگر طول دو برابر شود، مساحت آن چهار برابر (دو به توان دو برابر) می‌شود [ویکی‌پدیا])

ما همان اثر بهمن (avalanche effect) را در این رفتار مشاهده می‌کنیم، جایی که تغییر پارامترِ یک تابع باعث ایجاد تغییرات متعدد در سیستم می‌شود. رابطه‌ی بین اجزای نرم‌افزاری که باعث بروز و پخش تغییرات متعدد در سیستم می‌شود همان جفت‌شدگی (coupling) است. اما در کنار این وابستگی‌ها و جفت‌شدگی‌های اجزا، ما مشغول جداسازی‌ (decoupling) آنها هم هستیم. اگر به عقب برگردیم و با دقت نگاه کنیم به این نتیجه می‌رسیم که نقش طراحی نرم افزار، مدیریت تصمیم‌های بینابینی (tradeoff) جفت‌شدگی(coupling) /جداسازی(decoupling) است زیرا افزایش هر یک از آنها باعث افزایش هزینه می‌شود.

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

https://bit.ly/3L10OAV

“بنابراین بین این دو یعنی جفت‌شدگی (coupling) یا جداسازی (decoupling) باید نقطه‌ی کمینه‌ی (minimum) هزینه را پیدا کنید. برای این تصمیم‌گیری باید توجه کنید که اگر جفت‌شدگی (coupling) وجود دارد ما باید برای کاهش آن سرمایه‌گذاری کنیم و در نتیجه لازم است هزینه جداسازی (decoupling) را افزایش دهیم تا بتوانیم به آن نقطه‌ی کمینه برسیم. و این توضیحات پاسخ به این سؤال است که «چرا باید نخست مرتب کنیم؟» و کنت بک با این جمله صبحت‌هایش را به پایان می‌رساند در حالی که ما نیز با صحبت‌هایش کاملا موافقیم.