هفت عادت برنامه نویسان مؤثر

بازم این vscodeبرنامه نویسا وقت زیادی رو صرف یادگرفتن مهارت ها و کامل کردن رزومه برای مصاحبه های شغلی می کنند تا این که در آخر توی یکی از این استارتاپ ها یا شرکت های نرم افزاری استخدام شوند ولی غافل از این که این لیست بلند و بالای مهارت های درخشان در رزومه تان، در شرایط واقعی کاری، اثربخش و کافی نیست.حال ما می خواهیم با معرفی و توجه به این هفت مهارت (قانون) ، قدم های محکم تر و پرسرعت تری را در راه پیشرفت شغلی و حرفه ای برداریم (بر گرفته از ex-Google TechLead)این ها هفت عادت برنامه نویسان مؤثر است:۱- یادبگیرید که چگونه کد های دیگران را بخوانیدمن از خوندن کد های دیگران متنفرم!هر برنامه نویسی (به غیر از شما) کد های فوق العاده وحشتناکی می نویسد...No-opبه همین خاطر، مهارت خواندن کد های سایر برنامه نویسان مزیت های فراوانی دارد. مهم نیست که برنامه نویس قبلی چه قدر بد و مبتدی و افتضاح کد زده و یا این که چه قدر تمیز و حرفه ای، این وظیفه و کار شماست که بتوانید از پس این کار بر بیایید حتی اگر کد های قبلی یک سال و بیشتر قدمت داشته باشد. پس غر زدن و ترس از کد های دست دوم ممنوع!این مهارت در دو جهت به شما کمک می کند: اول این که مهارت خواندن کد های دیگران باعث یادگیری الگو های کد نویسی بد برای کار های بعدی تان خواهد شد (ادب از که آموختی...گفت از بی ادبان!)؛ دومی و از همه مهم تر، یادگرفتن نوعی کد نویسی که قابل فهم تر و خواناتر و حرفه ای تر است. (یکی از بهترین تمرینات در این زمینه، مراجعه به منابع متن باز و سعی در فهم و بهبود آن هاست)شما باید مطمئن شوید که به اندازه ی کافی کد های دیگران را خوانده اید تا به سطحی برسید که کیفیت و نوع کد نویسی برنامه نویسان دیگر را با نگاهی کلی به کد ها تشخیص دهید.از طرفی باید به نکات و قوانین تمیز کد نویسی clean code و کامنت گذاری توجه کنید. این در واقع راهی هست برای قابل فهم تر شدن کد ها و به رخ کشیدن مهارت هایتان برای سایر برنامه نویس ها (به شرطی که برنامه نویس مقابل باید مهارت کدخوانی را کسب کرده باشد)این قدر باید تمیز و آسان کد نویسی کنید که هیچ داکیومنتیشنی لازم نداشته باشد. در حقیقت اگر شما برنامه نویس خوبی باشید نباید هیچ جایی از کد هایتان را داکیومنت کنید. این صرفا باعث هدر دادن وقت و کاهش سرعت تان در کدنویسی می شود.قابلیت خواندن کد های سایر برنامه نویس ها، این توانایی را به شما می دهد که هر وقت لازم شد، بتوانید بخش هایی از کد را بدون آسیب به سایر قسمت های نرم افزار آپدیت کنید حتی اگر تجربه ی کافی در framework یا زبان برنامه نویسی مورد نظر نداشته باشید. لازمه ی این سطح از مهارت ، درک کامل کد های منبع و فهمی نسبی از زبان برنامه نویسی مورد استفاده ی آن است.توانایی خواندن کد های دیگران، شما را به شخصی کلیدی و ارزشمند تبدیل می کند، چرا که شما می توانید در هر شرایطی به سمت بهبود سیستم حرکت کنید در حالی که بقیه (کسانی که این مهارت را ندارند) این پیشرفت را کار تجربه نمی کنند.۲- حس ششم در تشخیص پروژه های بدمهارت های وقت تلف کن زیادی برای یادگرفتن وجود دارد ...یکی از این مهارت ها که احساس می کنم از همه شان مهم تر است، فهم و تشخیص پروژه های بد و طاقت فرسا از بین پروژه های خوب است.شرکت ها به اندازه ی کافی پروژه ی ناتمام و به درد نخور برای دنبال کردن دارند، چه به لحاظ مالی و کسب و کاری (به خصوص برای خودتان) و چه به لحاظ ساختار های مدیریتی غلط شرکت، به هر حال باید از این پروژه ها فرار کنید و بتوانید به خوبی و زیرکانه آن ها را تشخیص دهید. البته به این معنی نیست که راه ورود ایده های خلاقانه و جذاب رو در ذهن خودتون ببندید.۳- از جلسات متعدد پرهیز کنیدشما چه توسعه دهنده ی نرم افزار باشید و چه تحلیل گر داده، جلسات برای شما ضروریست چرا که به فهم صحیح و مشترکی از کاربر نهایی ، مدیریت پروژه و ... برسید. و البته در این بین ، یک علت و تمایل دیگری نیز برای برگزاری جلسات از طرف برنامه نویسان وجود دارد: به عقب انداختن و پر کردن برنامه. به خاطر همین، عدم شرکت در جلسات بی مورد و بی فایده اهمیت فراوانی دارد. شاید قشنگ تر و محترمانه تر بشود گفت که باید شرکت در جلسات را مدیریت کنید. هدف شما باید از شرکت در جلسات این باشد که به هم تیمی هایتان کمک کنید تا همگی یک قدم به جلو پیشرفت کنید و از رسیدن به این هدف قبل از شرکت در جلسه مطمئن شوید.ساده ترین روش این است که زمان جلسات روزانه را محدود کنید (مثلا دو ساعت) و اگر جلسه ای مفید باشد می توانید آن را در روز های بعدی نیز تکرار کنید و زمان را برای برنامه نویسی کردن روزانه باز بگذاریدیکی دیگر از راه های جلوگیری از جلسات بی مورد، تعهد به پایان تسک قبل از برگزاری جلسه است. علاوه بر آرامش و تمرکز بیشتری که در جلسه حاکم خواهد شد، کسانی که تسک های خود رو انجام داده و خودشان را ثابت کرده اند، در شرکت (یا سازمان) دوست داشتنی تر و پذیرفته تر هستند و هیچ کسی نمی تواند ایرادی از شما بگیرد.زمان برای هر کسی اهمیت زیادی دارد چرا که تنها زمانی کار کردن به نتیجه می رسد که تمرکز کافی و عدم حواس پرتی در صحبت با همکاران در محیط کار وجود داشته باشد. بله البته که بسیاری از مشکلات در زمان همکاری و هم افزایی تیمی با دیگران حل شده است ولی حل یک باگ در نهایت نیازمند دست به کیبورد شدن و کد زدن شماست بدون توقف و حواس پرتی۴- گیتهاب Githubبعضیا از موقعی که به دنیا می آیند، استفاده از گیت را شروع می کنند و بعضی دیگر اولین باری که از گیت استفاده می کنند موقعی است که در شرکتی استخدام می شوند و عمدتا نمی فهمند که با هر کامند چه می گذرد (به خاطر همین cheat sheet ها محبوب هستند)مهم نیست که در شرکت و یا تیم تان از چه سورس کنترلی استفاده می کنید،‌ این سیستم ها اگر به درستی استفاده شوند مفید و یا در صورت استفاده ی نادرست مضر هستند. (مثل چاقو هم خوبه و هم بد) زمان صرف شده برای commit و push کردن ساده کجا و زمان طولانی حل کردن confilict ها و branch های پیچیده و fork های در هم بر هم کجا! که هیچ جذابیت و چالشی هم ندارنداگر می خواهید زندگی راحت تری داشته باشید، گیت را فرا بگیرید و همواره cheat sheet آن را نزد خود داشته باشید۵- نوشتن کد های ساده ی قابل نگه دارییک برنامه نویس جوان بااستعداد همواره باید تلاش کند تا از هر آن چیزی که فراگرفته را در یک راه حل بهره گیرد. این کار مستلزم فهم عمیق و علاقه به برنامه نویسی شیء گرا، ساختمان داده، دیزاین پترن ها و سایر تکنولوژی های جدید مرتبط در هر خط کد است. زمانی پیچیدگی های غیر ضروری در کد ظهور پیدا می کنند که به یک دیزاین پترن یا اصول فنی خاصی که سابقا استفاده می کرده اید، چسبیده اید و آن را رها نمی کنید.تعادلی بین مفهموم طراحی پیچیده و کد ساده وجود دارد. دیزاین پترن ها و شیء گرایی برای ساده سازی کد ها فراهم شده اند،‌ به هر حال بار ها و بار ها استفاده ی در هم و پیچیده از این اصول بدون در نظر گرفتن best practice ها، باعث صرف زمان بیشتر برای دیباگ و خواندن کد خواهد شد.۶- نه گفتن و اولویت بندیاین مهارت در هر نقش و جاهگاهی به شدت تاثیر گذار و موثر است، چه شما تحلیل گر مالی باشید و چه برنامه نویس. اما به طور کلی نقش های فنی و مهندسی ، کسانی هستند که با همه روزه با درخواست های زیادی بیش از حد برنامه ریزی شده، مواجه می شوند. خروجی گرفتن از داده ها، داشبورد مدیریتی، برنامه ریزی جدید برای تحلیل و استخراج داده های موجود و ... از این قبیل است.همین الآن، اولویت بندی و نه گفتن را به عنوان دو مهارت جداگانه و در عین حال در هم تنیده در نظر بگیرید. اولویت بندی یعنی شما فقط زمانتان را در جایی که بیشترین بهره وری و عایدی را دارد ، صرف می کنید، در حالی که با نه گفتن ، از کار هایی که می تواند توسط دیگران انجام شود، خودداری می کنید. این دو همگام پشت سر هم باید در هر موقعیتی عادت هر روز شما باشد.این مهارت بسیار کلیدی و کسب آن دشوار است به خصوص هنگامی که با هجمه ای از درخواست ها مواجه می شوید پس سعی کنید از آن دسته از افرادی نباشید که همه کاره و هیچ کاره هستند (دو برابر کار در برابر بازده نصف افراد معمولی)۷- تفکر طراحی عملیاتی Operational Design Thinkingتفکر در نحوه ی تعامل با ماژول و کدی که می نویسید، تفکر طراحی عملیاتی، یکی از مهارت هایی است که در مصاحبه های شغلی مطرح نمی شود و دانشگاه آن را یاد نمی گیرید.در حقیقت، با گفتن عدم مهارت در تفکر طراحی عملیاتی،‌به طور محترمانه می توان گفت که مدرک کدنویسی شما ساختگی است.برای مثال، اگر تفکر طراحی عملیاتی نداشته باشید، هر گونه تغییر کوچک در برنامه که با تمامی اجزای آن در تعامل و ارتباط است غیر ممکن و بسیار طاقت فرسا خواهد بود حتی اگر تغییرtype یک فیلد دیتابیس و یا تغییر در یک object باشد.این مهارت، شامل فکر کردن و طراحی مسیر و نوع تعامل ماژول ها و اجزا قبل از شروع به کد نویسی نیز می شود.برای نمونه، هنگامی که شما در حال توسعه ی یک مایکروسرویس یا ماژول جدید هستید، صرف وقت برای فکر کردن به جنبه های عملیاتی آنچه که می خواهید بسازید اهمیت فراوانی دارد. به این فکر کنید که استفاده از آن به چه روشی صحیح و به چه روشی نادرست است و کدام پارامتر ها برای کار کردن آن لازم است و ...خیلی خلاصه...کد ها و برنامه نویسی خود جزئی از مشکل هستند. ساخت نرم افزاری که کار می کند خیلی آسان است ولی راه های متعددی برای توسعه ی همان نرم افزار وجود دارد که اشتباه هستند. اگر در شرکت ها و تیم ها، صحبت کردن در رابطه ی نحوه ی کد زدن و روش استفاده از ماژول های توسعه یافته سخت باشد، برنامه نویسان آینده با مشکلات و محدودیت های فراوانی مواجه خواهند شد...(که آه جان سوزشان گریبان ما را خواهد گرفت)پس نوشت۱: این مطلب ترجمه ای آزاد از این مقاله ی منتشر شده در مدیوم استپس نوشت۲: من خیلی وقتا اینجوری می شم! شما چطور؟؟Dev Humourمنبع عکس: ? Developer Economics @developereconomics