۱۰ عادت بد برنامه نویسی که مخفیانه دوستشان داریم

برخی از عادات بد خیلی خوب هستند که نمی‌توان آنها را ترک کرد، به خصوص اگر بتوانید آنها را برای شما مفید کنید. در اینجا ۱۰ عادت بد برنامه نویسی که توسعه دهندگان آنها را از دست نمی دهند، آورده شده است.

همه ما هیجان خم کردن قوانین یا حتی زیر پا گذاشتن آنها را می دانیم. شاید در یک منطقه با سرعت ۵۵ مایل در ساعت به ۵۶ می رسد یا اجازه می دهد که پارکومتر منقضی شود. شاید بدون آزمایش دو عدد را تقسیم می‌کند تا ببیند مخرج صفر است یا نه.

برنامه نویسان رابطه عجیبی با قوانین دارند. از یک طرف، کد فقط انبوهی از قوانین است – قوانینی که بی‌پایان توسط دروازه‌های سیلیکونی وظیفه‌شناس، بدون ترس یا لطف، تقریباً همیشه بدون خطای ناشی از ذرات آلفا اعمال می‌شوند. ما می خواهیم ترانزیستورها این قوانین را به خوبی رعایت کنند.

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

بحث واقعی این است که آیا این ایده خوبی است که انسان ها قوانین خود را زیر پا بگذارند. آیا ما حق نداریم آنها را در حال تعبیر مجدد کنیم؟ شاید به این دلیل است که برخی از قوانین مربوط به دوره ای متفاوت است. شاید برخی از آنها از ابتدا تصورات نیمه کاره ای بودند. شاید برخی در آن زمان ایده هوشمندانه ای به نظر می رسید. شاید بهتر باشد برخی را «عادات» نامید.

چند سال پیش، فهرستی از عادات بد برنامه نویسی که مخفیانه دوستشان داریم گردآوری کردم. به منظور پیشرفت هنر برنامه نویسی، در اینجا ۱۰ عادت برنامه نویسی دیگر وجود دارد که بسیار بد هستند که ممکن است خوب باشند.

۱۰ عادت بد برنامه نویسی که توسعه دهندگان دوست دارند

1. کدنویسی بدون نظر
2. کد آهسته
3. کد رامبلی
4. کد قدیمی
5. کد خود را بنویسید
6. بهینه سازی خیلی زود
7. بی دقتی
8. ناسازگاری
9. تعقیب زنگ ها و سوت ها
10. نقض قوانین

کدنویسی بدون نظر

این یک واقعیت شناخته شده است که کدهای غیرمستند برای درک و اشکال زدایی کابوس هستند. کلاس های برنامه نویسی ما به ما می آموزند که نوشتن نظرات خوب ضروری است. برنامه نویسی با سواد، سبک برنامه نویسی که ترکیبی از زبان طبیعی و کد است، توسط دان کنوت ابداع شد—شاید بزرگترین برنامه نویسی که تا به حال زندگی کرده است. ما کی هستیم که بحث کنیم؟

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

مشکلات دیگری نیز وجود دارد. شاید نظر به زبان طبیعی نوشته شده باشد که شما نمی دانید. شاید این مفهوم را نتوان به راحتی در چیزی کمتر از هفت پاراگراف خلاصه کرد و کدنویس در یک سرعت چابک بود. شاید شخصی که نظر می دهد اشتباه کرده است.

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

کد آهسته

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

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

کد رامبلی

یکی از همکاران من دوست دارد از همه عملگرهای هوشمند جدید در جاوا اسکریپت استفاده کند، مانند بیضی. کد به دست آمده مختصرتر است، که در ذهن آنها به معنای ساده تر و بهتر است. همه بررسی‌های کد آن‌ها با پیشنهادهایی در مورد جایی که می‌توانیم کد را برای استفاده از نحو جدید بازنویسی کنیم، بازمی‌گردند.

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

دلایل تاریخی وجود دارد که چرا مردم کدهای بسیار فشرده را دوست ندارند. زبان‌هایی مانند APL که به لطف نمادهای سفارشی‌شان به‌طور باورنکردنی فشرده و کارآمد طراحی شده‌اند، اساساً ناپدید شده‌اند. زبان‌های دیگر مانند Python که از براکت‌های فرفری اجتناب می‌کنند، همچنان محبوبیت خود را افزایش می‌دهند.

عاشقان جدیدترین و بهترین انتزاع‌ها به ارائه ویژگی‌های مختصر جدید ادامه می‌دهند و در مورد کوتاهی سخن می‌گویند. آنها ادعای خود را مبنی بر مدرن بودن و باسن بودن دارند. با این حال، برخی دیگر همچنان به کدهای طولانی تر و خواناتر وارد پشته می شوند. آنها می دانند که در نهایت، خواندن آن ساده تر است.

کد قدیمی

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

برخی افراد معتقدند که استفاده از این ویژگی‌ها بهترین است. به هر حال، آنها می‌گویند، اولین قانون قدرت این است که «از آن استفاده کن یا از دست بده». آیا نباید از تک تک قطره قند نحوی که در آن کتابچه راهنمای هزار صفحه ای توضیح داده شده است استفاده کنیم؟

هر چند این همیشه قانون خوبی نیست. ویژگی های بیش از حد می تواند باعث سردرگمی شود. اکنون ترفندهای نحوی بسیار زیرکانه ای وجود دارد که هیچ برنامه نویسی نمی تواند به همه آنها مسلط باشد. و چرا باید؟ به چند روش نیاز داریم که مثلاً باطل بودن را آزمایش کنیم یا وراثت را در ابعاد چندگانه انجام دهیم؟ آیا یکی از آنها درست است یا بهتر از بقیه؟ مطمئناً، برخی از برنامه نویسان تیم با بحث کردن در مورد آنها و خراب کردن ناهار یا جلسه استندآپ راهی برای خلق نمایشنامه پیدا می کنند.

حداقل یک مجموعه از طراحان زبان محدودیت مجموعه ویژگی را تعیین کردند. سازندگان Go language گفتند که می‌خواهند چیزی بسازند که بتوان آن را خیلی سریع، حتی در یک روز، یاد گرفت. این بدان معناست که همه کدنویسان تیم می توانند همه کدها را بخوانند. ویژگی های کمتر منجر به سردرگمی کمتر می شود.

کد خود را بنویسید

متخصصان بهره وری دوست دارند بگویند، “چرخ را دوباره اختراع نکنید.” از کتابخانه های سهام که به خوبی تست شده و آماده اجرا هستند استفاده کنید. از کد قدیمی که قبلاً اثبات شده است استفاده کنید.

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

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

بهینه سازی خیلی زود

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

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

بی دقتی

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

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

ناسازگاری

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

از سوی دیگر، سازگاری از نظر زمان و گاهی اوقات در پیچیدگی هزینه دارد. رفع تفاوت ها به معنای بازگشت به عقب و بازنویسی همه کدهایی است که مسیر اشتباه را دنبال کرده اند. این به تنهایی می تواند بودجه را تحت فشار قرار دهد.

مشکل عمیق‌تری در رابطه بین بخش‌های مختلف ایجاد می‌شود. برخی از پروژه ها به کدهای قدیمی متکی هستند. بقیه به کتابخانه ها وابسته اند. بسیاری نمی توانند بدون APIهای نوشته شده توسط افراد کاملاً متفاوت در شرکت های جداگانه کار کنند.

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

تعقیب زنگ ها و سوت ها

مسئله دیگر با ثبات بیش از حد این است که از نوآوری جلوگیری می کند. همچنین نوعی پایبندی سفت و سخت به روش قدیمی انجام کارها را تشویق می کند.

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

شکن کردن قوانین

برای پوزخند، از جمینی گوگل پرسیدم که آیا برنامه نویسان قوانینی را در فرآیند ایجاد آن زیر پا گذاشته اند یا خیر. جمینی پاسخ داد، “به جای اینکه برنامه نویسان قوانین خاصی را زیر پا بگذارند، دقیق تر است که بگوییم آنها ممکن است در هنگام ایجاد مدل های زبان بزرگ مانند من، مرزهای برخی از بهترین شیوه ها را جابجا کرده باشند.”

«مدل‌های زبان بزرگ مانند من بر روی مقادیر انبوه داده آموزش می‌بینند، و عنصری از «ناشناخته‌ها» در نحوه یادگیری مدل از آن داده‌ها وجود دارد.» گفت جوزا “برخی از تکنیک های مورد استفاده برای ایجاد مدل های زبان بزرگ می توانند بسیار کارآمد باشند، اما درک اینکه مدل دقیقا چگونه به پاسخ های خود می رسد دشوار است.”

بفرمایید. LLM ها بهتر از ما می دانند که قوانین قدیمی در حال تغییر هستند. وقتی می‌توانید مجموعه‌های آموزشی عظیم را در جعبه قرار دهید، ممکن است نیازی به صرف زمان زیادی برای درک الگوریتم نداشته باشید. پس برو جلو و انسان باش! اجازه دهید LLMها به قوانین توجه کنند.