روز معلم را به همه‌ی معلمان و استادان عزیزم و همه‌ی بزرگوارانی که برای من معلم بودند تبریک عرض می‌کنم و صمیمانه از آنها برای تک‌تک نکاتی که به من آموختند قدردانی می‌کنم. امیدوارم که شاگرد خوبی برای آموزه‌های شما بوده باشم.

«می‌توانید اسم یک پرنده را در تمام زبانهای دنیا یادبگیرید اما وقتی این کار به پایان رسید، شما دقیقاً هیچ چیز در مورد آن نمی‌دانید… پس بیایید به پرنده نگاه کنیم و ببینیم که چه می‌کند. این مسئله است که مهم است. من خیلی زود تفاوت میان دانستن نام یک چیز و شناختن آن چیز را آموختم.» ریچارد فاینمن

منبع: ویکی گفتار

قسمت اول را اینجا و قسمت دوم را اینجا بخوانید.

به جای بهانه، گزینه‌ها و راه‌کارهای جدیدی پیشنهاد کنید. نگویید که این کار شدنی نیست؛ توضیح دهید که چه کاری می‌توان برای نجات از شرایط کنونی انجام داد. آیا بهتر است کد را حذف کنیم (delete)؟ اگر به این نتیجه رسیدید،‌ این موضوع را با آنها در میان بگذارید و اهمیت و فایده‌های بازسازی کد (refactoring) را توضیح دهید.
آیا برای انتخاب بهترین راهکار به نمونه‌سازی اولیه (prototype) نیاز دارید؟ آیا برای جلوگیری از تکرار چنین شرایطی نیاز به تعریف و پیاده‌سازی آزمون‌های بهتر یا خودکارسازی آنها دارید؟ شاید برای انجام کار به منابع بیشتری نیاز داشته باشید. یا شاید لازم باشد زمان بیشتری را با کاربران بگذرانید و روش کار آنها را از نزدیک ببینید. شاید هم نیاز باشد تکنیک یا فناوری جدیدی را عمیق‌تر و دقیق‌تر یاد بگیرید. شاید یک کتاب یا یک دوره‌ی آموزشی بتواند به شما کمک کند. از درخواست کردن یا پذیرش و اعتراف به اینکه به کمک نیاز دارید نترسید.
قبل از اینکه بهانه‌های غیرمنطقی و ناموجه را با صدای بلند جار بزنید سعی کنید آنها را از ذهن خود بیرون بریزید. اگر فکر می‌کنید باید بهانه‌‌ی ناموجهی را با صدای بلند اعلام کنید، بهتر است ابتدا آن را با گربه‌تان در میان بگذارید. خدا را چه دیدی، شاید این گربه‌ی کوچک و ملوس شما، مسئولیت اشتباهات را قبول کند.

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

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

منبع عکس:
gettyimages.ca

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

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

قسمت اول را اینجا بخوانید.

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

اگر با این ریسک رو به رو هستید که احتمالا فروشنده سخت‌افزار هنگام بروز مشکل مطابق میل و خواسته شما عمل نمی‌کند، باید از قبل، یک طرح اضطراری (contingency plan) داشته باشید. اگر دستگاه ذخیره انبوه (mass storage) شما که تمام کدها روی آن است خراب شده و شما نسخه‌ی پشتیبانی (backup) از آن ندارید، این تقصیر فروشنده نیست بلکه تقصیر خود شماست. این که بروید و به رییس‌تان بگویید «گربه کد من رو خورده»، مشکل شما را حل نخواهد کرد و بدیهی است که بهانه‌جویی گره‌ای از مشکل شما باز نمی‌کند.

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

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

منبع: کتاب برنامه‌نویس عملگرا (The Pragmatic Programmer)

گزیده:
بزرگترین نقطه ضعف، ترس از ضعیف به نظر رسیدن است.
جی.بی. باسوئیت

و برف می‌بارد در بهار
آن هم چه برفی

۲ اردیبهشت ۱۴۰۲
۲۲ اپریل ۲۰۲۲

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

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

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

منبع: کتاب برنامه‌نویس عملگرا (The Pragmatic Programmer)

گزیده:
بزرگترین نقطه ضعف، ترس از ضعیف به نظر رسیدن است.
جی.بی. باسوئیت

عامل ۲: وابستگی ها (Dependencies)
وابستگی ها را به صورت شفاف و صریح بیان کنید و آن ها را ایزوله کنید (Explicitly declare and isolate dependencies)

اکثر زبان‌های برنامه‌نویسی دارای سیستم بسته‌بندی (packaging system) یا مدیریت بسته‌ها (package manager) برای توزیع و پخش کتابخانه‌ها هستند، مانند npm برای جاوا اسکریپت، pip برای پایتون و NuGet برای دات‌نت. کتابخانه‌هایی که با ابزار مدیریت بسته‌ها نصب می‌شوند می‌توانند در سطح کل سیستم (system-wide) نصب ‌شوند که با نام site packages نیز معروف‌ هستند یا می‌توانند فقط محدود به یک دایرکتوری شوند که برنامه در آن قرار دارد که با نام vendoring یا bundling نیز معروف هستند.

یک برنامه دوازده عاملی هیچ گاه اعتماد نمی‌کند که بسته‌ها از قبل در سیستم نصب شده‌اند و به صورت پیش‌فرض وجود دارند. این گونه برنامه‌ها همه‌ وابستگی‌ها را به صورت کامل و دقیق و به کمک یک «بیانیه اعلان وابستگی‌» (dependency declaration manifest) اعلام می‌کنند. به علاوه از یک «ابزار ایزوله‌سازی وابستگی» (dependency isolation tool) در طول اجرای برنامه استفاده می‌کنند تا مطمئن شوند که هیچ‌گونه وابستگی بیان‌نشده‌ای از محیط اطراف به داخل سیستم “نشت نمی‌کند” (leak in). وابستگی‌ها به صورت کامل و صریح و به شکل یکسان هم برای محیط عملیاتی و هم برای محیط توسعه اعمال می‌شوند.

برای مثال در پایتون دو ابزار جداگانه برای این کارها وجود دارد. ابزار Pip برای اعلان وابستگی‌ها و Virtualenv برای ایزوله‌سازی استفاده می‌شود. صرف نظر از ابزارهای استفاده‌شده، اعلان وابستگی‌ها و ایزوله‌سازی وابستگی‌ها باید همواره با هم استفاده گردند و هیچ یک از آنها به تنهایی شرط‌های برنامه‌های ۱۲ عاملی را محقق نمی‌کنند.

یکی از مزایای اعلان صریح وابستگی‌ها (explicit dependency declaration) این است که راه اندازی (setup) را برای توسعه‌دهندگان تازه‌وارد ساده می‌کند. توسعه‌دهنده جدید کافی است نسخه‌ای ازکد (codebase) برنامه را روی دستگاه خود داشته باشد و آن وقت برای اجرا تنها به ابزارهای خود زبان (مانند پایتون) و ابزار مدیر وابستگی (مانند pip) ‌نیاز خواهد داشت. پس از این مراحل، آنها می‌توانند به کمک یک سری دستورات ساخت (build command) معین کارهای لازم برای اجرای برنامه را انجام دهند.

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

نوشته‌های قبلی:
– قسمت دوم: پایگاه کد (۲)

مترجم: حمید آقای خاتمی

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

عامل ۱:‌ پایگاه کد (code base)

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

یک برنامه‌ی دوازده عاملی همیشه به کمک سیستم‌های کنترل نسخه (version control) مانند Git، Mercurial یا Subversion کنترل و ردیابی (track) می‌شود. به یک کپی از پایگاه داده‌ای که حاوی اطلاعات نسخه‌ها است مخزن کد (code repository) گفته می‌شود که معمولا به صورت مختصر به نام مخرن، code repo یا repo خوانده می‌شود.

معمولا ارتباط یک به یکی بین پایگاه کد و برنامه وجود دارد:

• وجود چندین پایگاه کد برای یک برنامه نشان می‌دهد که آن برنامه تنها یک برنامه جدا نیست، بلکه احتمالا یک سیستم توزیع‌شده است. هر مؤلفه (component) از این سیستم توزیع‌شده، خود یک برنامه‌ی جداست و هر یک از این برنامه‌ها به تنهایی می‌تواند عوامل دوازده‌گانه را رعایت کنند.
• اگر چند برنامه دارای یک کد یکسان و مشترک باشند، عوامل دوازده‌گانه را نقض کرده‌اند. راه حل این است که کد مشترک بین آنها جدا شود و در کتابخانه‌هایی قرار گیرد که بتوان به کمک مدیر وابستگی(dependency manager) در جاهای مختلف استفاده شوند.

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

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

نوشته‌های قبلی:
– قسمت اول: برنامه ۱۲ عاملی (۱)

مترجم: حمید آقای خاتمی

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