در مجموعه مقالات برنامه‌نویسی وبلاگ سکان آکادمی، ترفندهای و آموزش‌های بسیاری در رابطه با استراتژی‌های بهتر و خواناتر کد زدن پیدا خواهید کرد؛ اما در این پست قصد داریم راه‌کار‌هایی آزموده شده برای تبدیل کردن سورس‌کد به یک فاجعهٔ تمام‌عیار را به اشتراک بگذاریم.
پروسهٔ معماری نرم‌افزار را نادیده بگیرید!
مرحلهٔ طراحی اِسکما (Schema) یا معماری نرم‌افزار، صرفاً وقت تلف کردن است و بلافاصله پس از آمدن ایده به ذهن، باید دست به کد شد و در حین کدنویسی ساختار‌ها و الگو‌های مناسب به مرور به ذهن‌تان سرازیر می‌شوند. قواعد نام‌گذاری، انتخاب زبان مورد نیاز و دیزاین پترن‌ها بیهوده هستند، بلکه هرچه سریع‌تر باید شروع به کدنویسی کرد (لازم به ذکر است که هرچه زودتر شروع به کد نوشتن کنید، سورس‌کدتان افتضاح‌تر خواهد بود.)
از فریمورک‌ها و لایبرری‌های موجود استفاده نکنید!
استفاده کردن از فریمورک‌ها، لایبرری‌ها، کلاس‌ها و ماژول‌های آماده را فراموش کنید چرا که خودتان خواهید توانست دوباره آن‌ها را از صفر بنویسید؛ به‌خصوص فانکشن‌های پیچیدهٔ رمزنگاری (در همین راستا، می‌توانید به مقالات مزایا و معایب استفاده از یک Framework در توسعهٔ نرم‌افزار و استفاده از فریمورک یا کدنویسی از پایه: مسئله این است! مراجعه نمایید.)
انتخاب نام‌های تصادفی برای متغیرها
مهم این است که کامپایلر مفهوم متغیرهایی همچون c_One$ و یا xx$ را متوجه می‌شود؛ لذا زمان گذاشتن برای انتخاب نام‌هایی بامسمی که دیگر دولوپرها -و یا خودتان در آینده- از آن‌ها سر در بیاورید، کاری بس بیهوده است.
خیلی در نوشتن کامنت‌های دقیق وسواس به خرج ندهید!
وقتی صحبت از کد افتضاح به میان می‌آید، تنها یک چیز بهتر از کامنت نگذاشتن است و آن هم چیزی نیست جز نوشتن کامنت‌های بی‌دقت. در همین راستا، می‌توانید مدل‌های مختلفی را امتحان کنید؛ از توضیحات مَن‌‌درآوردی گرفته تا اصرار برای اثبات اینکه چیزی که نوشته‌اید به خوبی کار می‌کند و چنانچه به هر دلیلی کار نکرد، مسلماً اشکال از سیستم دیگران است (البته حواستان باشد کمی واقعیت هم در کامنت‌ها بگنجانید تا باورپذیرتر شوند که در غیر این صورت، سایر دولوپرها کم‌کم شروع به نادیده گرفتن آن‌ها می‌کنند.)
دیتای ورودی فرم‌ها را اعتبارسنجی نکنید!
کاربران سایت یا اپلیکیشن دوستان‌تان هستند و می‌توانید به آن‌ها اعتماد کامل کنید. اعتبارسنجی داده‌ها و ورودی‌های کاربران -از طریق فرم‌ها و غیره- کاری بس وقت‌گیر است و صرفاً زمان لانچ پروژه را به تعویق می‌اندازد.
هر طور که شده، از اصول شیئ‌گرایی دوری کنید!
برای سهولت کار سایر دولوپرها، طوری کد بزنید که هر وقت در سورس‌کد گشت‌زنی می‌کردند، بدون اینکه نیاز داشته باشند فایل‌های مختلف را زیر و رو کنند، در همان فایل به تمام کدها دسترسی داشته باشند. به عبارت دیگر، هر وقت به فانکشنی احتیاج داشتید، دوباره در همان فایل تعریف‌اش کنید و کلاً مفاهیم OOP را نادیده بگیرید.
اِکسپشن هَندلینگ را فراموش کنید!
اِکسپشن (استثناء)، اِکسپشن است و همان‌طور که از نامشان برمی‌آید، خیلی کم پیش می‌آید و بسیار نادر است. پس نگران نوشتن چیزهایی همچون Try ... Catch برای بررسی و هَندل کردن آن‌ها نباشید. رُک و پوست‌کنده بگوییم، اگر بسته به رفتار کاربر با اپلیکیشن اِکسپشنی رخ داد، خود وی مقصر اصلی است نَه شما.
وقت خود را با تست نرم‌افزار تلف نکنید!
هرگاه در حال نوشتن کدهای افتضاحی هستید، نگران تست کردن آن‌ها نباشید. چه یونیت تست و چه تست‌های دیگر، همه را به دیگران محول کنید. در یک کلام، این وظیفهٔ تیم QA (کنترل کیفیت) است نَه شما تا از درست کار کردن اپلیکیشن اطمینان حاصل کند.
به یاد داشته باشید که هرچه بزرگ‌تر بهتر!
در یک سورس‌کد افتضاح، اندازهٔ چیز‌ها خیلی مهم است. به طور مثال، هرچه فانکشنی طویل‌تر، کد هم افتضاح‌تر. در واقع، اگر می‌خواهید سورس‌کدی به معنای واقعی کلمه افتضاح بنویسید، همیشه به دنبال راه‌های برای طولانی‌تر کردن و افزایش تعداد خطوط آن باشید. اگر چیزی را می‌توانید در ۱۰ خط بنویسید، سعی کنید آن را در ۱۰۰ خط بنویسید.