تو دنیای رقابتی توسعه نرمافزار، گاهی اوقات همگامی با جدیدترین ابزارها، روندها و بهترین شیوه ها (best practices) میتونه چالش برانگیز باشه. موفقیت همراه با تلاش، فداکاری و تمرکز زیاده. که با اتخاذ ذهنیت و عادات مناسب شروع میشه. عادات مناسب میتونه برای موفقیت در هرچیزی کمک حال باشه، مهم نیست چقدر اون چیز چقدر سخت یا چالش برانگیزه.
پس بیا یه نگاهی به پنج عادت مهندسان نرمافزار موفق بندازیم.
ابزارهات بشناس
قبل از اینکه بتونی به ذهنیت ِ بهترین شیوه ها و بهره وری وارد بشی، باید با ابزارهایی که استفاده خواهی کرد، آشنا بشی. با ابزارهای سادهی ردیابی کارها (Task-Tracking Tools) مثل “ساخت لیست وظایف” یا “ثبت ساعات کاری” شروع کن.
استفاده از ابزارهایی مثل Asana، Trello یا بقیه نرم افزارهای to-do list بهت کمک می کنه تا با سازماندهی وظایفت به دسته بندی های مختلف، بهره وری بیشتری داشته باشی و همچنین این امکان میده تا پیشرفت هر آیتم از لیستت رو تو یه نگاه مشاهده کنی.
برای تبدیل شدن به یه مهندس ماهرتر، باید نکات زیر و بم ابزارهات یاد بگیری. نمیتونی توی همه چیز متخصص و خبره بشی، اما میتونی در زمینه های مهم تمرکزی که کردی متخصص بشی. این تمرکز بهت این امکان میده از زمانت به نحو احسنت استفاده کنی و با همکارات بهتر مشارکت و همکاری داشته باشی.
برای کمال تلاش نکن
کمال دشمن خیره. جستجوی کمال اغلب ما رو نه تنها به صورت فردی بلکه به عنوان یه جامعه هم عقب نگه میداره. کمال هدفیه که همهی ما میخوایم بهش برسیم، اما هدفیه که به ندرت در هر صنعت یا حرفه ای به دست میاد.
به جاش برتری رو هدف قرار بده. برتری چیزیه که می تونی به دستش بیاری نه کمال. تو مهندسی نرمافزار چیزی به اسم راه حل کامل وجود نداره، اما راه حل های عالی وجود داره.
چیزی که داری میسازی رو درک کن
هر مهندسی بخش قابل توجهی از زمانش رو صرف رویاپردازی امکانات جدیدی می کنه که دوست داره به نقشهی راه محصولِ شرکتش اضافه کنه. اما بیشتر مواقع نمیدونه که چی داره می سازه.
به عنوان یه مهندس وظیفه شما اینه که مطمئن بشی محصولی که میسازی در دنیای واقعی کار میکنه. ولی اغلب مهندس ها این واقیعت مهم رو فراموش میکنن. اونها هدف مورد نظر محصول رو از دست میدن.
هرچقدر محصول محورتر بشی، به عنوان یه مهندس کارآمدتر خواهی بود. در این صورت درک واضح تری از کاری که محصولت قرار انجام بده خواهی داشت و میتونی با صرف زمان کمتر بفهمی که چطور یه کاری کنی که محصولت یه کار متفاوتی انجام بده.
انتزاع، اما نه خیلی زود
خیلی اوقات مهندس ها تو این فکر گیر می افتن که اولین راه حلی که به ذهن شون میرسه، راه حال عالیه. اغلب این طرز فکر اونها رو تو مسیر مهندسی بیش از حد میندازه.
راه حل های مهندسی اغلب به تعادلی بین انتزاع خیلی زود و انتزاع خیلی دیر نیاز دارن. خیلی زود، راه حل هایی ایجاد میکنی که ارزشی به محصول اضافه نمیکنه و کاربرانت رو هم سردرگم میکنه. خیلی دیر، متوجه میشی که پایگاه کد بیس خودت رو شکوندی. در هر حال چندین بار طول میکشه که در نهایت به تعادل مناسب برسی.
بیش از حد مهندسی نکن
به عنوان یه مهندس ممکنه فکر کنی باید یه نرم افزار پیچیده ایجاد کنی.
نه ممکنه یه وقتی در مورد اصل KISS شنیده باشی!
اصل KISS میگه اکثر فریم ورک ها در شرایطی که به جای پیچیدگی ساده نگه داشته بشن، بهترین عملکرد رو دارن. به همین دلیل راحتی باید یه هدف حیاتی تو برنامه باشه و پیچیدگی های اضافی باید از اون دور بمونه.
بسیاری از مهندس ها در تلاشن تا با حل مسائل بی اهمیتی که ارزش حل کردن ندارن به بزرگی برسن.
گاهی اوقات اونها چیزای زیادی رو برای یه سیستم واحد به عهده میگیرن، اشتباهی کلاسیک دیگه ای که همه ما تو اون گرفتار میشیم!