باد همایون به تو سال نو و روز نو
عمر تو زان بر مزید عز تو زین بر دوام

در سال نو برای‌تان دل خوش، لب خندان، تن سالم و پیروزی‌های پی‌درپی آرزومندم.
به امید روزهای بهتر

فروردین ۱۴۰۲

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

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