شیوه‌های مهندسی خوب،‌ در هنگامی که به صورت انفرادی کار می‌کنید - بخش دوم

وقتی که مجبورید کاری را به صورت انفرادی انجام دهید، چگونه بیشترین بهره را از آن می‌برید؟

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

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

در بخش دوم این مقاله با ما همراه باشید...

ارتباط برقرار کنید

برقراری ارتباط اکثرا در هنگام کار با یک تیم کوچک، یا برای یک مشتری صدق می‌کند.

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

یک علت دیگر این است که اغلب یک عضو از گروه به مشکلی بر می‌خورد، که این مشکل می‌تواند با برقراری ارتباط با مشتری یا یک عضو دیگر تیم برطرف شود. من شمار دفعاتی که از روی ناامیدی داد زده‌ام: «تغییرات من ظاهر نمی‌شوند.»، و یکی از اعضای دیگر تیم به من گفته است: «فکر کنم من برخی تغییرات را اعمال کرده‌ام که تغییرات تو را لغو کرده‌اند.» را از دست داده‌ام.

کاری که می‌توانید انجام دهید:

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

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

نظارت کنید

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

کاری که می‌توانید انجام دهید:

• لاگ‌ها و متریک‌ها را بگیرید. از console.log() کردن در هنگام ضرورت نترسید. این که اطلاعات بیش از حدی را لاگ کنید، بهتر از این است که خیلی اطلاعات کمی را لاگ کنید. گرچه، مطمئن شوید که لاگ‌ها را با جزئیات غیر ضروری پر نمی‌کنید، تا اَلَک کردن لاگ‌ها آسان‌تر باشد.
• بدانید که لاگ‌های شما به کجا می‌روند و سیستمی برای دیدن آن‌ها راه‌اندازی کنید. این سیستم می‌تواند چیزی به سادگی SSH کردن در سرور خود برای ساخت یک فایل باگ، یا چیزی به پیشرفتگی ارسال لاگ‌های خود به ELK Stack باشد. اما مهم است که وقتی console.log() را می‌نویسید، بدانید که در کجا به دنبال آن لاگ‌ها بگردید.
• خطاها را قورت ندهید. با این که برنامه شما بهتر است ارتجاعی باشد (بتواند در هنگام وقوع یک خطا بهبود یابد)، خوب است که خطاهایی که انتظارشان را ندارید، لاگ کنید. برای مثال، اگر یک API‌ را فراخوانی می‌کنید تا محتویات ساخته شده توسط کاربر را بگیرید، باید آماده باشید که پاسخ 404 Not Found را مدیریت کنید. اما اگر یک خطای متفاوت و غیر منتظره از API دریافت کردید، این خطا بهتر است که لاگ شود. من در موقعیت‌های این چنینی بوده‌ام، و از آنجایی که خطاها را لاگ نمی‌کردم، نمی‌دانستم که از محدودیت نرخ خود سبقت گرفته بودم، و در نتیجه برنامه در لیست سیاه API مورد نظر قرار گرفته بود.
• لاگ‌ها و متریک‌هایی که گرفته‌اید را بررسی کنید. این کار می‌تواند یا به صورت دستی، و یا به روش‌های خودکار انجام گیرد. من در موقعیت‌هایی بوده‌ام که یک بر طرف‌سازی ساده را پیاده‌سازی کرده‌ام، آن را گسترش داده‌ام و راه خود را ادامه داده‌ام، و در نهایت پی برده‌ام که این بر طرف‌سازی کار نمی‌کند. از آن موقع، من روش نظارت بر روی لاگ‌های برنامه برای مدتی پس از گسترش برنامه را در پیش گرفتم، تا مطمئن شوم که همه چیز طبق انتظار کار می‌کند.

استراتژی‌های نظارت می‌توانند اشکال مختلفی از لاگ‌های کنسول ساده و فایل‌های متنی گرفته، تا providerهای خارجی مانند Sentry، Bugsnag و Elastic AMO داشته باشند. یک stack که برای شما مناسب است را انتخاب کرده، و با آن پیش بروید.

مشاهده کرده، و تکرار کنید

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

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

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

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

من تصمیم گرفتم که «UTC» را به صفحه نمایش اضافه کنم (تا برای مثال عبارت «5:30 pm UTC» را نشان دهد). این حرکت کار می‌کند، و حال گیجی کمتری برای کاربران وجود دارد. اما در نهایت من پی می‌برم که چرا کاربر را مجبور نکنم که کار تبدیل (convert) ناحیه زمانی خود را انجام دهد؟ پس من برنامه خود را به گونه‌ای تغییر می‌دهم که زمان نمایش داده شده در ناحیه زمانی کاربر را تبدیل کند. حال برنامه من بسیار بهتر است.

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

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

نتیجه گیری

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

بابت وقتی که بر روی این مقاله گذاشتید ممنونم و امیدوارم از خواندن آن لذت برده باشید.

منبع