کد پاک. اصول برای برنامه نویسان

من برخی از ضروری ترین قوانینی را که هر مهندس نرم افزار باید بداند فهرست کرده ام. این اصول از کتاب برنامه نویس عملی گرفته شده است.

سرعت الگوریتم 🚀

اگرچه این چیز جدیدی برای مهندسان باتجربه نیست، اما همیشه باید در برخورد با حلقه های متعدد محتاط و محتاط باشید.
این پیچیدگی یک حلقه ساده است O(n). حال، اگر یک تابع/روش را در داخل آن معرفی کنیم که چیزی را نیز حلقه کند، بلافاصله پیچیدگی تبدیل می شود O(m x n). همیشه عواقب جانبی هر نوع تغییر در کد خود را ببینید تا مطمئن شوید که در دراز مدت تأثیری بر مقیاس‌بندی برنامه شما نخواهد داشت.

بهترین همیشه بهترین نیست💡

توجه داشته باشید که بهینه سازی زودرس همیشه تصمیم مناسب در شروع هر پروژه یا اثبات مفهوم (POC) نیست. در آن مرحله خاص، اطلاع از ترافیک و تکرار/جهت نهایی برنامه شما غیرممکن است. در عوض، همیشه عاقلانه تر است که ما را ساده و کوچک نگه دارید.

یک برنامه نویس عملگرا باشید نه تصادفی برنامه نویس “CodeMonkey” 💥

کدنویسی یک کار مکانیکی نیست.
به عنوان یک برنامه نویس عملگرا، باید تصمیمات درستی بگیرید. شما باید به طور انتقادی در مورد همه کدها و تأثیری که می تواند داشته باشد و همچنین میزان مقیاس کد و معماری نرم افزار شما در آینده فکر کنید.

از سوی دیگر، یک برنامه نویس تصادفی/کد پول بدون اینکه به تصویر بزرگ نگاه کند، کد می نویسد. آنها تمایل دارند کدهای مکانیکی را به روشی ناکارآمد اضافه کنند.

اتوماسیون 🤖

خودکار کردن چیزها یک مفهوم مهم در چرخه عمر یک برنامه کاربردی است. با این حال، مانند بهینه‌سازی، اگر خیلی زود کارها را در مواردی که ممکن است تکراری نباشند خودکار کنید، فقط ساعت‌های اضافی غیرضروری به کار اضافه می‌کند.

آنچه را که نیاز دارید بیاموزید 📝

یادگیری خوب ابزارهای مناسب (ممکن است جنکینز، داکر، چارچوب، میانبرها، IDE مورد علاقه شما، ابزار محک و …) بهترین نقطه قوت شما در حرفه شما خواهد بود.

Dodo-Code ننویسید 🦤

نوشتن کد dodo به این معنی است که کد شما در طول زمان به خوبی سازگار نخواهد شد. دودو با حضور انسان سازگار نبود. آنها قبل از انقراض در جزیره موریس دامپروری می کنند. آینده مشابهی را به کد خود ندهید. با الگوهای طراحی خوب که تغییرات جدید و پیاده سازی ویژگی ها را آسان می کند، پایگاه کد خود را چابک و به خوبی حفظ کنید.

تست قبل از تولید🍳

اگرچه این می تواند منطقی به نظر برسد، اما اغلب من “تغییرات مهم لحظه آخری” را می بینم که باید در اسرع وقت برای تولید ارسال شوند. و سپس، از آنجایی که مهندس (های) نرم افزار زمان و منابع لازم را ندارند، با ارسال تغییرات فوراً اقدام می کنند تا مدیران خود را خوشحال کنند.
با این حال، این می تواند بسیار بد تمام شود. دست کم گرفتن همیشه بسیار آسان است که همه چیز به خوبی پیش خواهد رفت، تا زمانی که یک روز صبح از خواب بیدار شوید و کل سرویس آنلاین به دلیل گم شدن اپراتور تخصیص یا یک نقطه ویرگول/کاما در یک فایل که رفتار نادرستی را نشان می دهد، قطع شود. مهم نیست که چقدر به انتشار اعتماد دارید، هرگز از عواقب هر تغییر در کد خود 100٪ مطمئن نیستید. داشتن آزمون های ادغام و پذیرش می تواند بسیار مفید باشد.
یک تمرین خوب همچنین می‌تواند استفاده از تکنیک “میمون‌های آشوب” در برنامه شما باشد تا مطمئن شوید که هیچ مشکل آشکاری در آن وجود ندارد.

طرز فکر اشکال زدایی 🧠

قبل از شروع اشکال زدایی، مهم است که طرز فکر درستی را در مورد اشکال زدایی اتخاذ کنید. اشکال زدایی می تواند مشکل و زمان بر باشد.

با این حال، برای خوشایندتر کردن این «کاوش ذهنی» یک قانون کلی است:
1. فوراً فکر کنید که مشکل از کدام لایه/لایه کد شما می تواند باشد.
2. خرابی زودهنگام به طور مستقیم و فوری به شما می گوید که در کجا چیزی کار نمی کند. همیشه باید زود شکست بخورید به جای اینکه بی سر و صدا به سراغ بعدی بروید function وقتی قرار نیست اتفاقی بیفتد
3. از نقاط شکست و ردیابی استثنا استفاده کنید.
4. با “اردک لاستیکی” خود (یا هر حیوان لاستیکی دیگری) صحبت کنید به شما کمک می کند واضح تر بفهمید و تصویر بزرگی از کار پسر را ببینید. خیلی اوقات، وقتی به یک اردک لاستیکی یا همکارتان توضیح می‌دهید که چه چیزی کار نمی‌کند، چه چیزی تغییر کرده است و کجای کد را طی کرده‌اید، یک لحظه «آها» خواهید داشت و متوجه می‌شوید که چه چیزی در کدتان اشتباه است.
5. تصویر بزرگ کل معماری/زیرساخت را ببینید تا مشکل را با سهولت بیشتری پیدا کنید.

قانون پیشاهنگی پسر 🧹

قانون پیشاهنگی می گوید: “همیشه محل کمپ را تمیزتر از چیزی که پیدا کردید ترک کنید.”
یعنی وقتی دیگران چیزهای کثیف را رها کردند، بدون توجه به اینکه چه بهانه ای دارند، باید آن را تمیز کنید. فرقی نمی کند که این کار را انجام نداده باشید. هدف این قانون این است که هر بار که قسمت قدیمی کد را لمس می‌کنید، پایه کد را به‌طور دانه‌بندی بهتر کند، قدم به قدم کودک.
بنابراین، هر بار که نیاز به اضافه کردن/تغییر چیزی در یک تابع/کلاس موجود دارید، چیز کوچکی را شناسایی کنید که می توانید آن را نیز بهبود ببخشید. یک بهبود کوچک مشکلات جدیدی اضافه نمی‌کند یا بازبینی کد را سخت‌تر نمی‌کند، اما همین بهبود کوچک برای هر به‌روزرسانی، کل پایگاه کد را در دراز مدت بسیار زیباتر می‌کند.

کد نویسی مبارک! 🤠