۱۲ اشتباه برنامه نویسی که باید اجتناب کنید

دوجین کثیف از مشکلات توسعه نرم افزار – و نحوه جلوگیری از این اشتباهات برنامه نویسی بسیار رایج.

• پخش سریع و آزاد
• وسواس در مورد جزئیات
• پیچیدگی نظری بسیار زیاد
• پیچیدگی نظری کافی نیست
• ایمان بیش از حد به هوش مصنوعی
• داده‌های آموزشی کافی نیست
• اعتماد به امنیت خود به جعبه‌های جادویی
• رمزنگاری خودتان را رشد دهید
• اعتماد بیش از حد به مشتری
• اعتماد کافی به مشتری وجود ندارد

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

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

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

پخش سریع و آزاد

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

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

وسواس در مورد جزئیات

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

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

پیچیدگی نظری بسیار زیاد

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

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

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

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

پیچیدگی نظری کافی نیست

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

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

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

ایمان بیش از حد به هوش مصنوعی

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

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

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

داده های آموزشی کافی نیست

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

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

یک “قوی سیاه” سناریویی است که توسط داده های آموزشی پوشش داده نشده است. آنها نادر هستند اما می توانند هوش مصنوعی را کاملاً مخدوش کنند. وقتی رویدادها در داده‌های آموزشی یافت نمی‌شوند، هوش مصنوعی ممکن است یک پاسخ تصادفی ایجاد کند.

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

اعتماد به امنیت خود به جعبه‌های جادویی

نگران امنیت هستید؟ فقط مقداری رمزنگاری اضافه کنید. نگران نباشید، فروشنده گفت: این فقط کار می کند.

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

جهان تازه شروع به درک مشکل اشتراک گذاری بیش از حد کد در بسیاری از کتابخانه ها کرده است. وقتی اشکال Log4j ظاهر شد، بسیاری از مدیران از اینکه آن را عمیقاً در کدشان جاسازی کرده بودند، شوکه شدند. افراد زیادی به این ابزار تکیه کرده اند که می توان آن را در داخل کتابخانه هایی یافت که در داخل کتابخانه های دیگری هستند که در کدهای در حال اجرا به عنوان یک سرویس مستقل گنجانده شده اند.

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

مؤسسه ملی استاندارد و فناوری، برای مثال، به تازگی اعلام کرد که بازنشستگی SHA-1، استاندارد اولیه برای ساخت هش پیام. نقاط ضعف کافی پیدا شد تا زمان ادامه کار فرا رسیده است.

واقعیت این است که بسیاری از این الگوریتم‌های جادویی نقاط ضعف ظریفی دارند. اجتناب از آنها مستلزم یادگیری بیشتر از آنچه در بخش “شروع سریع” کتابچه راهنمای کاربر است.

رمزنگاری خودتان را رشد دهید

شاید نتوانید به دیگران اعتماد کنید، اما آیا واقعاً می توانید به خودتان اعتماد کنید؟ توسعه دهندگان دوست دارند رویای نوشتن کتابخانه های خود را ببینند. اما فکر کردن به اینکه روش بهتری برای کدنویسی می‌دانید، می‌تواند دوباره شما را آزار دهد.

جان ویگا می‌گوید: «رمزنگاری خود را رشد دهید برای مهاجمان یک منظره خوشایند است»، و اشاره می‌کند که حتی متخصصان نیز هنگام تلاش برای جلوگیری از یافتن و سوء استفاده دیگران از نقاط ضعف در سیستم‌های خود اشتباه می‌کنند.

خب، به چه کسی اعتماد دارید؟ خودتون یا به اصطلاح متخصصین که اشتباه هم میکنن؟

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

اعتماد بیش از حد به مشتری

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

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

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

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

اعتماد کافی به مشتری وجود ندارد

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

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

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

کتاب من، پایگاه‌های داده شفاف، روش‌هایی را توضیح می‌دهد که پایگاه‌های داده می‌توانند اطلاعات کمتری را در حین ذخیره کنند. ارائه خدمات مشابه.

بستن منبع

یکی از چالش‌برانگیزترین چالش‌های هر شرکتی، تعیین میزان اشتراک‌گذاری با کاربران نرم‌افزار است.

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

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

باز بودن به عنوان راه درمان

میلیون‌ها پروژه منبع باز راه‌اندازی شده‌اند، و تنها بخش کوچکی از آنها تاکنون بیش از چند نفر را برای کمک به حفظ، اصلاح یا گسترش کد جذب کرده‌اند. به عبارت دیگر، W.P. “اگر آن را بسازید، آنها خواهند آمد” کینسلا همیشه نتایج عملی به همراه ندارد.

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

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

خیلی اوقات، کدهایی که بعضی اوقات کار می کنند در GitHub پرتاب می شوند با این امید که الف های جادویی از ساختن کفش ها دست بردارند و برای راه اندازی کامپایلر عجله کنند – تصمیمی که می تواند شتاب پروژه را قبل از شروع واقعی از مسیر خارج کند. .

اشکال Goto Fail اپل و آسیب‌پذیری Log4j تنها دو نمونه خوب از مواردی است که خطاها برای سال‌ها در معرض دید پنهان بودند. خبر خوب این است که بالاخره یک نفر آنها را پیدا کرد. خبر بد این است که هیچ یک از ما نمی دانیم چه چیزی هنوز پیدا نشده است.

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