وقتی که مجبورید کاری را به صورت انفرادی انجام دهید، چگونه بیشترین بهره را از آن می‌برید؟
اکثر توسعه دهندگان به عنوان بخشی از یک تیم کار می‌کنند. گرچه، بالاخره در جایی در حرفه‌های ما، ما مجبوری بوده‌ایم (و مجبور خواهیم بود) که به صورت انفرادی کار کنیم. و با این که بخشی زیادی از توسعه‌دهی محصول، شامل داشتن توانایی مدیریت یا کار کردن با باقی تیم است، توسعه دادن روش‌های خوب در هنگام انفرادی کار کردن هم درست به همان اندازه مهم است.
در بخش اول این مقاله با ما همراه باشید...
کلامی کوتاه درباره « به صورت انفرادی کار کردن»
«انفرادی»، معمولا یعنی کاری را تنها انجام دادن. اما در این زمینه ما از آن برای توصیف چیزی استفاده می‌کنیم که توسط تعداد کمی از افراد، و در یک محیط غیر رسمی و بدون ساختار انجام می‌شود. این مجموعه افراد می‌تواند فقط شما، یا شما و گروهی از افراد دیگر باشد. برای مثال:
- یک پروژه متن باز، مانند یک پکیج یا کتابخانه.
- یک محصول شخصی، که می‌تواند تبلیغاتی یا رایگان باشد.
- یک کار آزاد برای یک مشتری.
موضوع مشترک در اینجا، این است که هیچ قوانین مقرری مانند قوانینی که معمولا در یک شرکت دارید، وجود ندارند.
چرا باید نگران شیوه‌های مهندسی خود باشم؟
یک علت مبتنی بر اهمیت داشتن شیوه‌های مهندسی، این است که شما یک دارایی برای تیم خود خواهید بود.
بیایید سناریوهای احتمالی که ممکن است وقتی به یک تیم ملحق می‌شوید به وجود بیایند را در نظر بگیریم:
- شما به یک تیم ملحق می‌شوید که از شیوه‌هایی که شما به آن‌ها عادت دارید، پیروی می‌کند. عالی است؛ این یعنی شما آماده شراکت از روز اول خواهید بود.
- شما به یک تیم ملحق می‌شوید که از مجموعه شیوه‌های متفاوتی پیروی می‌کند. اگر مفهوم عمومی شیوه مهندسی خوب را درک کرده باشید، عادت کردن به آن خیلی برای شما وقت نخواهد برد، و شما هم به زودی بارور خواهید بود.
- شما به یک تیم ملحق می‌شوید که از هیچ شیوه خوبی پیروی نمی‌کند. در این مورد، شما بسته به تیم خود ممکن است بتوانید دانش خود را به کار بگیرید و روندهای آن‌ها را بهبود ببخشید. در غیر این صورت... شاید فقط آن تیم را ترک کنید.
به هر حال، نتیجه این مسئله یک برد برد است. شما یک توسعه دهنده بهتر خواهید بود.
مهندسی نرم‌افزار، چیزی بیش از فقط کدنویسی است. بخش‌های محرک بسیار زیادی در رساندن یک محصول از تصور به اجرا، و سپس آن را در حین اجرا نگه داشتن وجود دارند. جایگیر ساختن بهترین شیوه‌ها، به شما کمک خواهد کرد تا به مسیر خود ادامه دهید و از ناامیدی جلوگیری کنید.
اگر عاشق کدنویسی هستید، همیشه در هنگام کار بر روی یک چیز جدید، وسوسه این که مستقیما به سراغ اصل مطلب بروید و شروع به کدنویسی کنید وجود دارد. اما من در طی گذر زمان دیده‌ام که داشتن نوعی ساختار در جای خود، درحالیکه همچنان انعطافی که با کار کردن به صورت انفرادی می‌آید را نگه می‌دارم، به من کمک می‌کند تا از بسیاری از موانع موجود در راه بگذرم.
بیایید برخی از این شیوه‌های خوب را در نظر بگیریم.
به یک جریان کاری بچسبید
یک جریان کاری، مجموعه‌ای از قدم‌ها است که در تغییر شکل یک ایده در ذهن شما به یک محصول به اتمام رسیده، نقش دارند. برخی از مواردی که جریان کاری شما باید پوشش دهد:
- وقتی برای یک تغییر تصمیم گرفته‌ام، از چه روندهایی برای پیاده‌سازی آن پیروی کنم؟
- چگونه نسخه‌های جدیدی از این محصول را به کاربر نهایی تحویل دهم؟
- چگونه رد تغییرات اعمال شده به این محصول را بگیرم؟
- چگونه رد عیب‌ها، مشکلات و برنامه‌های آینده این محصول را بگیرم؟
چرا؟ به نظر می‌رسد که انجام کارها بدون یک جریان کاری مشخص، بسیار سریع‌تر است، اما شما همینطور که پیچیدگی یک پروژه بیشتر می‌شود، پی خواهید برد که داشتن تعریفات واضح، تعیین این که چه چیزی باید انجام شود و بر رویش تمرکز شود را آسان‌تر می‌کند. وقتی که در یک تیم کار می‌کنید، جریان کاری تبدیل به یک لوله می‌شود که به هر عضو کمک می‌کند تا بارورتر باشد.
کاری که می‌توانید انجام دهید:
- از نشریه‌ها (GitHub، Gitlab، BitBucket یا هر جایی که کد شما در آن میزبانی شده است) استفاده کنید. نشریه‌ها به شما کمک می‌کنند تا رد عیب‌ها، درخواست‌های امکانات و تغییرات بزرگ در محصول خود را بگیرید. همچنین نوشتن عنوان و توصیفات مشکل، شما را مجبور می‌کند تا افکار موجود در ذهن خود را شکل دهید و تعریف کنید که دقیقا مشکل چیست و راه حل آن باید چه باشد. شما همچنین می‌توانید با اضافه کردن ابزار مدیریت پروژه مانند Trello و GitHub Project، این مسئله را یک قدم جلوتر ببرید.
- از درخواست‌های pull استفاده کنید. بسیاری از توسعه دهندگان ترجیح می‌دهند که وقتی به صورت انفرادی کار می‌کنند، مستقیما به سراغ استاد کار بروند. گرچه، منفعت‌هایی هم در ایجاد تغییرات از طریق درخواست‌های pull وجود دارند. دیدن تمام تغییرات دخیل در آن ویژگی یا رفع عیب، و نحوه تاثیرگذاری آن وقتی که با سورس کد ترکیب شده است، ساده‌تر است. همچنین وقتی که درخواست‌های pull با نشریه‌ها جفت شوند، مشاهده نحوه تکامل یک پروژه بدون این که نیاز به خواندن کد و درک آن باشد، ساده‌تر است.
- کد خود را بازبینی کنید. ممکن است عجیب به نظر برسد، اما بهتر است که کد خود را به گونه‌ای بررسی کنید که انگار توسط شخص دیگری نوشته شده است. برخی افراد پیشنهاد می‌دهند که برای چند دقیقه یا ساعت از آن دور شوید، و سپس قبل از ادغام یا بروزرسانی کد، آن را بازبینی کنید. بازبینی کد به دور از IDE که در آن یک پادشاه هستید، شما را قادر می‌سازد تا کد خود را با چشمان باز ببینید، که این مسئله به شما کمک می‌کند تا عیب‌ها را بیابید و چیزهایی که فراموش می‌کنید را تشخیص دهید. بازبینی کد همچنین شما را مجبور می‌کند تا خودتان به سوالات خود پاسخ دهید. چرا من آن را به این صورت پیاده‌سازی کردم؟ چه چیزی می‌تواند اشتباه باشد؟ آیا راه بهتری وجود دارد؟
- یک تاریخچه Git با معنی را نگهداری کنید. سعی کنید به گونه‌ای تغییرات را دائمی کنید که انگار در یک تیم کار می‌کنید. از اعمال تغییرات بزرگ خودداری کنید، آن‌ها را متمرکز و با معنی نگه دارید. نوشن یک پیغام تغییر توصیفی، درست به مانند بازبینی کد شما را مجبور می‌کند تا کندتر حرکت کنید. من در تلاش بودم که در این تغییر به چه چیزی برسم؟ چگونه تلاش کردم که به آن برسم؟
موقعیتی وجود خواهد داشت که شما می‌توانید به خود اجازه دهید تا قوانین را بکشنید. برای مثال، شاید تصمیم بگیرید که برای برطرف کردن‌های جزئی، اشکالی ندارد که مستقیما به سراغ استاد کار بروید و در نتیجه از کند شدن روند کار جلوگیری کنید.
با صرف نظر از چیزی که در جریان کاری خود ترکیب می‌کنید، باید این چیز عمدی باشد. محصولات موفق همینطور خودشان به وجود نمی‌آیند؛ این محصولات با عشق و علاقه ساخته می‌شوند. عمدی بودن یعنی به عقب برگشتن، نگاه کردن به نقاط دردی که با آن‌ها مواجه می‌شوید و فکر کردن به راه‌هایی برای بهبود آن‌ها.
کامپوننت‌ها و ماژول‌هایی با قابلیت استفاده مجدد بسازید
نرم‌افزار خود را از کامپوننت‌های کوچک‌تر، کپسوله‌سازی شده و اتمی با قابلیت استفاده مجدد تشکیل دهید.
سندنگاری‌هایی را برای پروژه خود بنویسید
سندنگاری! بسیاری از افراد درباره آن می‌دانند، تعداد کمی از افراد آن را انجام می‌دهند و تعداد کمتری آن را دوست دارند. پس از هجوم هیجان انگیز کدنویسی، سندنگاری آن اغلب یک کار طاقت فرسا است. چگونه تمام پیچیدگی‌های کد خود را در پروسه کار بیابم؟
چرا؟ انسان‌ها جایز الخطا هستند. ما چیزهایی را فراموش خواهیم کرد، روزهایی خواهیم داشت که مریضیم، یا از یک پروژه می‌گذریم. سندنگاری تضمین می‌کند که دانش مربوط به یک پروژه، به یک انسان وابسته نیست. سندنگاری همچنین به توسعه دهندگان کمک می‌کند تا تصویر کلی را ببینند و متمرکز بمانند.
کاری که می‌توانید انجام دهید:
- درک کنید که شما در حال نوشتن یک کتاب نیستید. سندنگاری حتما نباید یک شاهکار ادبی باشد. هیچ کسی به شما نمره نمی‌دهد. سعی نکنید همه چیز را توضیح دهید. آن را مختصر و مرتب نگه دارید. گاهی اوقات فقط چند نکته ریز، تمام چیزی است که نیاز دارید.
- قبل از کدنویسی، سندنگاری کنید. رابط محصول خود (نحوه کار آن از بیرون) را سندنگاری کنید. این کار به عنوان یک مشخصه عمل می‌کند و شما را در هنگام ساخت برنامه راهنمایی خواهد کرد.
- پس از کدنویسی، سندنگاری کنید. باز هم به گونه‌ای بنویسید که انگار از بیرون به آن نگاه می‌کنید. چه چیزی مهم است، برای استفاده از آن، چه چیزی را باید بدانید؟ مشخصه مورد نظر در هنگام ساخت، ممکن است تغییر کند؛ پس مهم است مطمئن شوید که پس از اتمام کار شما، تمام سندنگاری‌های قبل از کدنویسی همچنان صحیح هستند.
- در هنگام کدنویسی، سندنگاری کنید. این مورد اکثرا به نوشتن سندنگاری در کد صدق می‌کند. مقاله‌های زیادی درباره سندنگاری کد وجود دارند، پس من به جزئیات آن وارد نخواهم شد.
- به صورت واحدی کار کنید. تمام اصول بالا، به واحدها صدق می‌کنند. برای مثال، یک واحد می‌تواند یک تابع، یک کلاس، یک ویژگی جدید، یک تغییر در رفتار، یک ماژول و یا یک محصول کامل باشد. اگر سندنگاری یک تکه کار به شدت سخت به نظر می‌آید، سعی کنید آن را به واحدهای کوچک‌تر تقسیم کنید.
بخش دوم این مقاله هم با تمرکز بر روی موضوعات برقراری ارتباط، نظارت و مشاهده و تکرار به زودی بر روی راکت قرار خواهد گرفت. با ما همراه باشید...
دیدگاه و پرسش
در حال دریافت نظرات از سرور، لطفا منتظر بمانید
در حال دریافت نظرات از سرور، لطفا منتظر بمانید