تعدادی اشتباه مشترک بین برنامه نویس ها وجود داره که اکثرا بدون اطلاع خودشون این اشتباهات رو انجام میدن.
اینجا قراره قسمتی از این اشتباهات رو بگم که امیدوارم بتونه از تکرار این خطا ها جلوگیری کنه.
این موارد رو میشه توی چند دسته قرار داد:
? اشتباهات فاز تحلیل
? اشتباهات فاز کد نویسی
? اشتباهات فاز تست
? اشتباهات فردی یا شخصی
یکی از اشتباهات پر تکرار اینه که،همیشه نباید به مشتری اعتماد کرد، که اون چیزی که داره توضیح میده با اون چیزی که در انتهای کار میخواد، یکسان باشه.
گاهی اوقات مشتری فکر میکنه اون ایده ای که داخل ذهنش داره، اگر روی نرم افزار پیاده بشه میتونه مشکلش رو حل کنه، ولی وقتی اون تغییر توی نرم افزار اعمال میشه، متوجه میشه که درک درستی از مشکل نداشته.
شاید این سوال واستون پیش بیاد که:چرا باید برای ما مهم باشه که مشتری نیاز خودش رو درک کنه؟ چون ما در نهایت، اون چیزی رو پیاده میکنیم که مشتری از ما میخواد.
مشکل زمانی پیش میاد که یک مشتری سردرگم، همیشه برای شما دردسر ایجاد میکنه و باعث دوباره کاری در روند پروژه میشه. اون همیشه با یک لیست تغییرات جدید پیش شما میاد، که بعضی از این تغییرات، میتونه تاثیرات جانبی زیادی روی پروژه داشته باشه.
علاوه بر این: اگر به مشتری کمک کنید که نیاز و مشکل رو بهتر درک کنه. اون یه مشتری وفادار برای شما میشه.
هرزگاهی برنامه نویس بیش از حد روی تیکه های ریز پازل تمرکز میکنه، که باعث میشه تصویر اصلی (Big picture) بهم بخوره.
بیش از حد هم نباید روی دید کلی تمرکز کرد که جزئیات رو فراموش کنیم. در کل منظورم اینه که داشتن دید انتزاعی باعث میشه که راه حل بهتری برای مشکل رو انتخاب کنیم.
برای همین همیشه باید یک قدم برید عقبتر و یک دید کلی از پروژه داشته باشید که متوجه قطعه گم شده پازل بشید.
به عنوان یک برنامه نویس همیشه باید تمام راه حل های موجود رو بررسی کنید تا به بهترین راه حل برسید.
گاهی اوقات برنامه نویس برای این که احساس رضایت داشته باشه، چرخ رو دوباره اختراع میکنه. یعنی یه قسمت از سیستم (مثلا یک Extension Method) که وجود داشته رو دوباره پیاده سازی میکنه.
به عنوان یک برنامه نویس، همیشه باید چک کنید که عملیاتی که می‌خواهید انجام بدید، قبلا توی سیستم وجود نداشته باشه.شاید اون متودی که نیاز دارید داخل یک لایه دیگه، یا یک پکیج دیگه داخل پروژه اضافه شده باشه.
در نتیحه استفاده دوباره از اون ها میتونه امن تر و بهتر باشه.
گاهی اوقات، برنامه نویس مدت زمان مورد نیاز برای انجام یک تسک رو کم در نظر میگیره، علت این کار چیه؟
مهمترین دلیل این مشکل، عدم وجود درک صحیح از اون تسک هستش.
به عنوان یک برنامه نویس شما باید تسک هارو تا حدی به تسک های ریز تر تقسیم کنید که بتونید اونارو کاملا درک کنید. تو این شرایط شما میتونید یک مدت زمان منطقی برای انجام اون تسک ها در نظر بگیرید.
این زمانبندی باید شامل مدت زمان انجام تمام این مراحل باشه
▶ تحلیل و طراحی
▶ پیاده سازی
▶ ریفکتور
▶ پیاده سازی Unit Test
▶ تست کردن
▶ مستندات بروزرسانی نرم افزار
طبق عادت و علاقه برنامه نویس ها همیشه دوست دارن که زودتر کد نویسی رو شروع کنن.چون کد نوشتن و تمکیل کردن تسک ها برای بیشتر برنامه نویس ها یه محدوده امن (آرامش) محسوب میشه.
قبل از اینکه کدنویسی رو شروع کنید، باید اطلاعات مناسبی راجب اون تسک داشته باشید.
برای مثال شما باید از تاریخچه تغییرات اون قسمت از پروژه اطلاع داشته باشید.شاید چند تا سوال ساده بتونه چندین ساعت از زمان شمارو صرفه جویی کنه.
درنتیجه همیشه سعی کنید اول به خوبی تسک رو تجزیه و تحلیل کنید و از جزئیات کاری که قراره انجام بدید مطمئن بشید.
به من شش ساعت زمان بده که درختی را قطع کنم، و من چهار ساعت اول را صرف تیز کردن تبر خواهم کرد.
آبراهام لینکلن
همیشه به این فکر کنید که سیستم به چه چیزی نیازه داره. نه اون چیزی که شما دوست دارید پیاده کنید.
توی مدت زمان کاری خودم، با سیستم هایی مواجه شدم که با روش های خیلی ساده تری قابل پیاده سازی بودن. ولی چون برنامه نویس دلش میخواست که فلان دیزاین پترن یا معماری خاص رو حتما استفاده کنه، بار پیچیدگی زیادی وارد سیستم کرده.
مثلا اگر شما 10 تا پترن مختلف بلدید، مجبور نیستید حتما از یکی از اون ها استفاده کنید.(منظورم اینه که از پترن مناسب در جای مناسب استفاده کنید) شما باید روی مسئله اصلی تمرکز کنید. راجع به مسئله فکر کنید، تحلیل کنید، اشتباهات و استثنائاتی که در نظر نگرفتید رو بررسی کنید و بعد شروع به پیاده سازی کنید.
برای رسیدن به بهترین حالت، زیاد وسواس به خرج ندید. چرا؟ چون بهترین حالت توی شرایط متفاوت فرق داره، چیزی که برای شما بهترینه، میتونه برای یکی دیگه بد ترین باشه.
درنتیجه شما باید اولویت های خودتون رو مشخص کنید و بهترین راه حل رو نسبت به اولویت های خودتون انتخاب کنید.
Perfect is the enemy of good
بعضی جاها، ساده ترین راه حل، بهترین راه حل نیست و باعث میشه که اون مشکل فقط مخفی بشه یا باعث ایجاد مشکل دیگه ای توی پروژه بشه.
قبل از رفع کردن خطا، شما باید دلیل اصلی ایجاد شدن اون خطا رو پیدا کنید و مطمئن بشید که از راه درستش دارید خطارو رفع میکنید.
لاگ کردن یکی از موارد مهمه که هر برنامه نویسی باید بهش توجه کنه، زمانی اهمیت لاگ کردن رو درک میکنید که توی یک فاجعه واقعی گیر کرده باشید.
همیشه ساده ترین راه حل، بهترین راه حل نیست.بعضی وقت ها این راه حل ساده میتونه مشکلات بزرگی تو آینده بوجود بیاره.
همانطور که قبلا هم گفتم، وقتی بیش از حد روی رفع کردن یک مشکل متمرکز میشید، دید انتزاعی پروژه رو از دست میدید و باعث بوجود اومدن مشکل داخل بقیه قسمت ها میشید.
در نتیجه روی انجام تسک تمرکز داشته باشید؛ ولی معماری اصلی پروژه رو هم توی ذهنتون داشته باشید
یکی دیگر از اشتباهات برنامه نویس ها، جا دادن حجم زیادی از کد توی یک ماژول هست.(منظور رعایت نکردن اصل Single Responsibility) که باعث شکننده شدن برنامه میشه.یعنی اعمال تغییرات توی برنامه سخت میشه و هر تغییر توی یک قسمت باعث ایجاد مشکلات میشه.
هر ماژول توی سیستم باید نقش اصلی خودش رو بازی کنه، اگر شما ماژولی توی سیستم پیدا کنید که وظایف متعددی داشته باشه، یه چیزی اینجا مشکل داره.
تقسیم کردن قسمت های مختلف برای هر ماژول، یک مهارته که طی زمان توش حرفه ای تر می شوید.
کامنت هایی که هیچ ارزشی اضافه نمیکنن. اگر شما قواعد clean code رو رعایت، نباید نیازی به کامنت های زیادی باشه.
کامنت هایی که به کد اضافه میکنید باید اطلاعاتی داشته باشه که از روی کد نمیشه فهمید، پس کامنت های بی دلیل باعث سردرگمی بقیه برنامه نویس های پروژه هم میشه.
شما سورس کنترل نیستید، پس کد هایی که لازم نیست رو کامنت نکنید، حذف کنید
خیلی وقت ها وقتی که pull request هارو بررسی میکنم، پیام هایی میبینم که نه تنها کمک نمیکنن، بلکه باعث سردرگمی میشن.پیام کامیت باید توصیفی از تغییرات باشه که بقیه برنامه نویس ها هم بتونن درک کنن.
یکی از اشتباهات بزرگ برنامه نویس ها اعمال حجم تغییرات زیاد توی یک کامیت هستش. این کار باعث سخت تر شدن بررسی و کنترل تغییرات پروژه میشه.
همیشه سعی کنید، تغییرات رو توی کامیت های کوچک تر تقسیم کنید.این کار برای review کردن و بعد ها برای revert کردن کمک زیادی خواهد کرد.
این روزا سیستم ها نرم افزاری بزرگ و پیچیده شدن. به همین دلیل متکی بودن که تست دستی میتونه اشتباه بزرگی باشه و باعث سخت شدن توسعه و تغییر نرم افزار میشه.
به همین علت باید همیشه تست خودکار داشته باشید و مطمئن باشید که تست شما، همه منطق بیزینسی پروژه شما رو پوشش میده.
برای تست نویسی سناریو های زیادی وجود داره که شما باید در نظر بگیرید
کاور کردن سناریو های مثبت خوبه، ولی نمیتونه اتمام کار باشه، باید سناریو های منفی رو هم حتما در نظر بگیرید.
تست نوشتن یک تضمین و سرمایه گذاری برای آینده هستش که بتونید کیفیت و صحت کد خودتون رو نشون بدید.
هیچ وقت از اشتباه کردن نترسید چون این ترس، یادگیری و تمرین شما رو محدود میکنه. هر کسی ممکنه اشتباه بکنه ولی اصلی ترین قسمت ماجرا اینه که، از این خطا چه چیزی یاد میگیرید و از تکرار اون جلوگیری میکنید.
فکر نکنید که شما همیشه درست فکر میکنید(هیچ کس همه چیز را نمیداد)، یک دندگی نکنید و همیشه مشتاق شنیدن و یاد گرفتن باشید.
روش تصمیم گیری خودتون رو ارزیابی کنید و دوباره اون مسیر رو طراح کنید، و مطمئن باشید که این باعث رشد شما میشه.
شما ربات یا ماشین نیستید. به فکر سلامتی جسمی و فیزیکی خودتون هم باشید.
بیماری های مرتبط با چاقی ، کمر درد ، خشکی چشم ، دست درد، کبد چرب و ... در کمین شماست.
حتما ورزش کنید و رژیم مناسب داشته باشید. و حتما به فکر میز و صندلی مناسب باشید.
چه فریلنسر باشید چه برای یک شرکت کار کنید، مستقیم یا غیر مستقیم با مشتری ها در ارتباط هستید. پس باید روابط عمومی خوبی داشته باشین و بتونید از پروژه ای که کار کردید دفاع کنید، و باید بتونید اون رو ارائه بدید تا مشتری قانع بشه.
توی مدت زمان کاری خودم، خیلی از برنامه نویس هارو دیدم که بخاطر پرزنت ضعیت، مشتری رو از دست دادن.
همیشه باید برای یادگیری دانش جدید برنامه ریزی داشته باشید و مهارت خودتون رو افزایش بدید. توی دنیای نرم افزار هر روز یه چیزی اضافه میشه.
اگر شما برنامه مناسبی برای یادگیری نداشته باشید و علم شما ثابت مونده باشه، درحقیقت در حال پسرفت هستید.
برنامه ریزی کنید، زمان بندی کنید و اون رو انجام بدید، اهداف قابل اندازه گیری تعیین کنید، این میتونه بهتون کمک کنه.
بعضی از برنامه نویس ها به اشتباه، فکر میکنن که سوال پرسیدن نشونه ضعیف بودن هستش.
همناطور که قبلا هم گفتم، 'هیچ کس همه چیز را نمیداد'
اگر از کسی سوال پرسیدید یا کمک خواستید، حس بدی نداشته باشید، این یک روش کاملا عادی برای به اشتراک گذاشتن و انتقال دانش هستش.
برای کمک گرفت عجله نکنید، اول خودتون دنبال راه حل بگردید.منظورم این نیست که کمک نگیرید، ولی بخشی از وظیفه شغل شما اینه که خودتون مشکلتون رو حل کنید، این باعث پیشرفت سریعتر مهارت های حل مسئله شما میشه و از وابسته شدن شما به تخصص افراد دیگر جلوگیری میکنه.
نکته اصلی اینه که یک مدت زمان معقولی برای پیدا کردن راه حل در نظر بگیرید، و بیش از حد زمان خودتون رو هدر ندید.در کل سعی کنید منطقی رفتار کنید.
همانطور که نباید از کمک گرفتن خجالت بکشید، شما باید هر زمانی که کاری از دستتون برمیاد برای بقیه انجام بدید.
این یک موقعیت برد - برد براتون میشه. آموزش دادن به بقیه افراد باعث میشه خودتون هم بهتر یاد بگیرید
در کل همه ما اشتباه میکنیم ولی مسئله اصلی اینه که ما چه چیزی از این اشتباهات یاد میگیریم.
اینجا سعی کردم به یه سری اشتباهات مشترک اشاره کنم، شاید شما هم بهش برخورده باشید، شایدم نه.
ولی اگر این موارد رو گوشه ذهنتون داشته باشید، شاید یه جایی به دردتون بخوره.
ایده اصلی: مقاله
