سلام دوستان. بالاخره بعد مدت ها تونستم یه زمانی گیر بیارم که دوباره یک مقاله در ویرگول بنویسم و از این بابت خیلی خوشحالم. توی این پست می خوام راجع به مهارت هایی حرف بزنم که به نظر من یک برنامه نویس باید اون ها رو هم در کنار مهارت های کد نویسی اش پرورش بده.
دانش فنی یک برنامه نویس راجع به یک framework بسیار مهم است اما کافی نیست. مهارت های دیگه ای هم هست که به برنامه نویس در کارش کمک می کنند. در ادامه، من لیستی از مهارت هایی که فکر می کنم خیلی کمک کننده و بعضا حیاتی هست رو ارائه خواهم کرد. خوشحال میشم اگر شما هم چیزی به ذهنتون رسید، در بخش کامنت ها به من بگید.
اگر خیلی با کار های front-end سر و کار دارید (چه web و چه پلتفرم های native مثل android و ios)، یادگیری اپلیکیشن های app interface design می تونه خیلی در ساخت نمونه اولیه بهتون کمک کنه. مثلا اگر شما به صورت فریلنسری و تنها کار می کنید، می تونید از prototype (نمونه اولیه) هایی که ساختید برای سنجیدن نظر و نیاز های مشتری هاتون استفاده کنید. اینطوری می تونید مطمئن باشید که طرح front سایتی که دارید براش کلی زحمت می کشید و کد میزنید، مورد پسند مشتری هست و احتمال اینکه نیاز به تغییر اساسی در طرح های سایت باشه کمه.
در ضمن اگر با framework های component based مثل react، vue و ... کار می کنید، دیدن نمونه اولیه اپلیکیشن به صورت بصری خیلی بهتون کمک می کنه که ساختار component های اپلیکیشن رو از قبل پیش‌بینی کنید و به عبارت دیگه، در ذهنتون یک plan کد نویسی برای interface اپلیکیشن داشته باشید.
البته اگر در یک شرکت کار می کنید و یا در تیمتون یک designer دارید، به عنوان یک برنامه نویس front-end زیاد این مهارت براتون حیاتی نیست اما مزیت های زیادی داره که مطمئنا یه زمانی به دردتون می خوره.
ابزاری که من ازش استفاده می کنم، نرم افزار figma هست که کار باهاش خیلی آسونه و اگر قبلا با ابزار های ویرایش عکس و ... کار کرده باشید، خیلی سریع یاد میگیرید که چطور از این ابزار استفاده کنید. البته شما آزاد هستید که از هر ابزاری که باهاش راحت هستید استفاده کنید. مهم اینه که بتونه براتون کار های prototyping رو انجام بده.
این مورد از نون شب هم برای یک برنامه نویس واجب تره، اگر بتونید در تایپ ده انگشتی ماهر بشید، می تونید در زمان پیاده سازی کد هاتون کلی صرفه جویی کنید و سریع تر کد بزنید. از همه مهم تر، خیلی سریع تر می تونید کار document نویسی پروژه (که خیلی هامون، از جمله خودم، از این کار بدمون میاد) رو انجام بدید.
برنامه نویس های خفنی رو دیده ام که سرعت تایپشون 170 WPM (یعنی 170 کلمه در دقیقه) هست. واقعا نمی دونم این طور آدم ها چطوری تایپ می کنند، چون خودم تا حالا سرعت تایپم از 70 تا بیشتر نشده ?. اینم مدرکش:
آخر هفته ها همیشه تمرین می کنم. سرگرمی خوبی هست اما پیشرفت کندی دارم خخخ.
گرفتن کلید های میان‌بر keyboard می تونه در طولانی مدت، ساعت ها زمان براتون صرفه جویی کنه. هرچند یادگیری کلید های میان‌بر کمی سخت هست و کمی طول میکشه که بهشون عادت کنید، اما وقتی که با اون ها خو بگیرید، دیگه نمی تونید بدون اونها زندگی کنید.
البته لازم نیست همه میان‌بر های همه اپلیکیشن های کامپیوترتون رو یاد بگیرید، بیشتر روی این ها تمرکز کنید:
اگر توی یک شرکت کار می کنید که بالاخره یه جایی رئیستون گیر میده و به خودتون میاید ...
اما اگر دارید به صورت فریلنسری کار می کنید، این مورد رو حتما جدی بگیرید. یکی از خوبی های فریلنسری ساعت های کاری آزاد و منعطف هست اما اگر این آزادی بیش از اندازه باشه براتون مشکل زا میشه. پس حتما برای کارهاتون برنامه ریزی کنید و زمان بندی داشته باشید.
البته در انجام این کار هم میانه روی کنید و بیش از حد برنامه ریزی نکنید. برنامه ریزی بیش از حد فقط وقت تون رو میگیره و اکثر مواقع اون چیز هایی که براشون کلی برنامه ریزی کردید، طبق انتظارات شما پیش نمیره. پس اصلا ارزشش رو نداره که ساعت ها روی این وقت بزارید. برنامه شما باید انعطاف پذیری لازم جهت مهار اتفاقات پیش‌بینی نشده رو داشته باشه اما وقتی که بیش از حد طبق فرضیات خودتون پیش برید، به هم خوردن یکی از فرضیات شما باعث به هم ریختن کل برنامه تون میشه.
این که شما چطور برای انجام کار هاتون برنامه ریزی و اون ها رو اولویت‌بندی می کنید به خودتون و سلیقه تون بستگی داره. یکی ممکنه کاغذ و خودکار رو ترجیح بده، در حالی که دیگری ممکنه از نرم افزار های digital استفاده کنه. اما هدف یکی هست.
خیلی وقت ها پیش میاد که بقیه برنامه نویس های تیم در کار با چیزی که ساخته اید مشکل داشته باشن، مثل زمانی که برنامه نویس های front می خوان کلاینت رو به API های سرور وصل کنند.
شاید رفتار بعضی از end-point های API به راحتی قابل پیش‌بینی نباشه یا شاید نکاتی راجع به پارامتر های API وجود داره که باید توسط خود توسعه دهنده API به برنامه نویس های front توضیح داده بشه. در این مواقع، شما باید بتونید قسمت های پیچیده API رو به خوبی به بقیه توضیح بدید و دانش مورد نیاز رو انتقال بدید.
خیلی هامون از این بدمون میاد اما document های پروژه خیلی مهم هستند. مثلا اگر بخواهید یک نفر جدید رو در تیم استخدام بکنید، داشتن document های پروژه، پروسه یاد دادن عملکرد قسمت های مختلف پروژه رو به عضو جدید تیم خیلی تسهیل می کنه. البته لازم نیست تمام جزئیات پروژه رو پوشش بدید. مثلا اگر به عنوان یک برنامه نویس back-end دارید document های API رو برای برنامه نویس های front-end می نویسید، ارائه یه سری اطلاعات کلی راجع به API و پارامتر هاش + چند تا نکته مهم + چند مثال کاربردی می تونه کار تیم front رو راه بندازه.
این document ها رو لازم نیست دستی بنویسید چون ابزار های خوبی برای auto-generate کردنشون وجود داره. مثلا من برای ساخت document برای API هایی که با Django Rest Framework ساخته ام از swagger و پکیج django spectacular استفاده می کنم.
مطمئنا معادل همین ها رو در framework های back-end دیگه هم پیدا می کنید.
اما اگر دارید document برای برنامه نویس های back-end ای که قراره در آینده به تیم اضافه بشن می نویسید، بهتره اصلا ننویسید ? چون واقعا به زمانی که باید برای آپدیت نگه داشتن شون بزارید نمی ارزه. فقط بین کد هاتون هرجایی که واقعا لازم بود، کامنت بزارید. یا اگر خیلی به document نویسی اعتقاد دارید، حداقل document هاتون رو لا به لای کد ها بنویسید. (مثلا اگر با python کار می کنید، از docstring ها استفاده کنید، یا مثلا اگر با js کار می کنید از jsdoc استفاده کنید و ...) اینطوری حداقل update نگه داشتن شون راحت تره.
باز هم تاکید می کنم که نیازی به شرح تمام جزئیات در document نیست! نزارید کسی فوت و فن های خفن تون و HACK هایی که به کار بردید رو درک کنه ?? (خودتون منظورم رو بهتر می فهمید ...)
خیلی ممنون که تا انتهای مطلب رو خوندید (یا scroll کردید). اگر چیز دیگه ای به ذهن تون رسید، در کامنت ها بهم بگید. تا پست بعدی فعلا خدانگهدار!
