مکالمه‌ی کوتاهم با 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) را بر اساس موضوعاتی مانند «کد تمیز» (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) (با بازی مورگان فریمن) است.

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

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

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