من بیشتر از ۱۵ سال است که مشغول برنامه‌نویسی هستم. در این مدت با زبان‌ها، فریمورک‌ها، پارادایم‌ها و... مختلفی کار کرده‌ام. اما امروز در این مطلب قصد دارم که تمام این تجربیات را در ۱۳ قاعده ساده بگنجانم که به شما کمک بسیار زیادی برای نوشتن کدهای بهتری می‌کنند.
۱- بهینه‌سازی یا خوانایی
همواره سعی کنید کدهایی بنویسید که برای خواندن ساده باشند و قابلیت درک پذیری‌شان برای توسعه‌دهندگان مختلف در سطح متفاوت بالا باشد. اما این موضوع لازم نیست که برای همیشه به این شکل باشد. زمانی که شما کدهایی را برای اجرا دارید و یا یک پروسه دیباگ فایل dll را در اختیار دارید آن زمان بهینه‌سازی بسیار مهمتر خواهد بود. ترجیحا سعی کنید برای یک برنامه دو کد را نگه داری کنید. یک کدی که قابلیت توسعه/خوانایی داشته باشد و کدی که برای سریع کردن روند اجرا بهینه‌سازی شده است.
۲. معماری
من با افراد زیادی ملاقات کردم که می‌گویند: ما نیاز داریم این کار را سریع انجام دهیم و وقتی برای معماری ساختن نداریم.
بگذارید راستش را به شما بگویم، حدود ۹۹ درصد این افراد بخاطر داشتن چنین تفکری با مشکلات بسیار بزرگی همراه خواهند بود.
نوشتن کد بدون فکر کردن راجع به معماری آن درست مانند رفتن به جایی بدون داشتن نقشه است. شما در بیشتر حالات به مقصد نخواهید رسید، پس در نتیجه شانس بسیار کمی برای موفقیت دارید.
قبل از اینکه سراغ کدنویسی بروید، بهتر است تصمیم بگیرید که می‌خواهید چکاری را انجام دهید، این کار به چه شیوه‌ای انجام می‌شود، از چه فریمورک ها و سرویس‌هایی قرار است استفاده بکنید و... . پس در نهایت بهتر است قبل از انجام کاری برای آن به خوبی پلن داشته باشید.
۳. تستینگ
نوشتن تست برای برنامه‌ها رویکرد بسیار خوبی است اما همیشه قرار نیست که این موضوع تاثیر زیادی روی برنامه شما داشته باشد. در واقع شما تنها در یکسری از حالات به تست احتیاج دارید:
- زمانی که می‌خواهید یک ماژول یا میکروسرویس بنویسید که خروجی آن حداقل یک ماه دیگر مشاهده خواهد شد.
- زمانی که کدهای متن باز بنویسید.
- زمانی که کدهای بسیار حیاتی برای کانال‌های مالی بنویسید.
- زمانی که منابع اضافی را برای بروزرسانی و ایجاد تست‌ها داشته باشید..
چه زمان‌هایی به تست نیاز ندارید:
- زمانی که شما یک استارتاپ کوچک هستید.
- زمانی که منابع مالی و انسانی محدود است و کدهای شما مدام تغییر می‌کند.
- زمانی که اسکریپت‌های شما توسط خروجی‌های‌شان قابلیت فهم رویکردی (منظور درک تمام عکس‌العمل‌های آن اسکریپت است) را داشته باشند.
۴. ساده بودن
نیازی به نوشتن کدهای پیچیده ندارید. اگر کدی ساده نوشته شده باشد در زمان رفع عیب می‌تواند بسیار کاربردی و عالی باشد چرا که شما نیازی به درک دوباره کدها ندارید، همه چیز به صورتی واضح نوشته شده است. سعی کنید کدهای‌تان را به دور از مفاهیم پیچیده و عجیب و غریبی مانند abstraction و... تولید کنید. ما از شئ‌گرایی استفاده می‌کنیم که مدیریت و اداره کدها ساده‌تر شود، اما ویژگی‌های بسیار پیچیده‌ای که در شئ‌گرایی وجود دارد مخصوصا در زبان‌هایی مانند جاوا و سی‌پلاس‌پلاس همه چیز را پیچیده و پیچیده‌تر می‌کنند.
۵. کامنت
کامنت‌ها برای نمایش کدهای بد نوشته شده استفاده می‌شود. کدهایی که قابلیت درک بالایی دارند نیازی به حتی یک خط کامنت ندارند. اما اگر توسعه‌دهنده تازه کاری بخواهد از کدها استفاده بکند چه؟ در این حالت قبول دارم که نوشتن چند خط ساده به عنوان مستندات می‌تواند کاربردی و کمک کننده باشد. این حالت به افراد شانس بیشتری را برای درک و پیاده‌سازی کدهای خودشان میدهد. همچنین عادت برای نوشتن کامنت به شما نقطه شروع بسیار خوبی را برای نوشتن مستندات بزرگ میدهد.
۶. میکروسرویس
سعی کنید ساختار کدنویسی به صورت میکروسرویس را یاد بگیرید. درست است که یک نرم افزار توسعه داده شده به صورت یکپارچه می‌تواند سریع‌تر از نرم افزاری با معماری میکروسرویس اجرا شود اما این سرعت از طرفی آنقدرها هم ملموس نخواهد بود. استفاده از معماری میکروسرویس به شما توانایی بسیار بالایی برای مدیریت و هندل پروژه‌تان را میدهد.
۷. بازبینی کد
بازبینی کدها می‌تواند هم خوب و هم بد باشد. بازبینی کردن کد بسیار وقت گیر است، اگر شما توسعه‌دهندگانی برای این کار داشته باشید، برای کنترل کیفیت محصول، بازبینی کدها بسیار تاثیرگذار و مثبت است. اما اگر افراد مخصوصی را برای اینکار نداشته باشید، می‌تواند کار بسیار وقت‌گیری باشد.
افرادی از بازبینی کدها برای آموزش استفاده می‌کنند، بحث این موضوع جداست، چرا که ما در این بخش منظورمان از بازبینی کد همان کنترل کیفیت پروژه است که شما آن را ایجاد کرده‌اید.
۸. بازسازی
در حوزه کاری من گاهی اوقات می‌شنیدم که افرادی می‌گفتند: «نگران نباشید ما فلان قسمت را در آینده بازسازی می‌کنیم». این آینده با مشکلات بسیار بزرگی همراه بود که در نهایت باعث می‌شد تا همه چیز را حذف کنیم و از ابتدا روند کدنویسی را شروع نمایم.
بنابراین برای بازسازی کردن هیچوقت منتظر آینده نمانید چون در آینده به مشکلات بزرگی برمی‌خورید.
۹. زمان خستگی و یا خواب آلودگی کد ننویسید
وقتی که توسعه‌دهنده‌ای خسته و یا خواب آلود باشد معمولا ۲ الی ۵ بار بیشتر از حالت معمول باگ و خطا تولید می‌کند. برخی از کشورها برای برنامه‌نویسان قانون کاری ۶ ساعته دارند، چرا که فکر می‌کنند زمانی بیشتر از این می‌تواند آسیب‌پذیری بالا همراه با اشتباهات بزرگ را به ارمغان بیاورد.
۱۰. همه چیز را یکجا ننویسید
قبل از آنکه به صورت مستقیم وارد روند کدنویسی شوید، سعی کنید به خوبی نیازهای مشتری‌تان را درک کنید. بعد از آن تلاش کنید تا با ارزش‌ترین ویژگی‌های ممکن را انتخاب کرده و همراه با یک کیفیت خوب در یک مدت زمان کوتاه ارائه دهید. برای بروزرسانی‌ها و کارهایی از این دست نیز بهتر است چنین روندی را تکرار کنید. زمان و منابع‌تان را برای انجام کارهای بدون دلیل مصرف ننمایید.
۱۱. خودکارسازی در مقابل دستی
خودکارسازی به معنای موفقیت در بلند مدت است. پس اگر منبع لازم را دارید حتما به فکر خودکارسازی باشید. شاید فکر کنید که کار شما تنها ۵ دقیقه طول می‌کشد پس نیازی به خودکارسازی نیست، اما این ۵ دقیقه در مدت ۲۱ روز برای ۵ توسعه‌دهنده خود می‌تواند زمان بسیار زیادی باشد.
۵ دقیقه * ۵ توسعه‌دهنده * ۲۱ روز * ۱۲ ماه = ۶۳۰۰ دقیقه که به عبارتی ۱۰۵ ساعت و در نهایت حدود ۵۲۵۰ دلار هزینه!
برای یک تیم با ۴هزار توسعه‌دهنده این هزینه بسیار بالاتر خواهد رفت.
۱۲. تفریح کنید
انجام کارهای متفاوت می‌تواند سلامت شما را ارتقا داده و به شما ایده‌های جدیدی برای شروع یک کار را بدهد. بنابراین کارتان را متوقف کنید و کمی سراغ دوستان، یک ساز موسیقی و... بروید.
۱۳. زمان آزاد‌تان را با یادگیری چیزهای جدید پر کنید
وقتی که مردم دست از یادگیری برمی‌دارند، شروع به سقوط کردن می‌کنند.
امیدوارم این نکات و تجربیات بتواند به خوبی برای شما کار بکند و شما را در ادامه دادن به مسیرتان یاری دهد.
دیدگاه و پرسش
در حال دریافت نظرات از سرور، لطفا منتظر بمانید
در حال دریافت نظرات از سرور، لطفا منتظر بمانید