عجیب‌ترین اصول برنامه‌نویسی که تا به حال نشنیده‌اید!‌
1398/01/20 14:19 , میلاد صاحب نظر

عجیب‌ترین اصول برنامه‌نویسی که تا به حال نشنیده‌اید!‌

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

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

  1. اصل bloat (نفخ)

این اصل انواع مختلفی دارد که انتخاب یکی از آن‌ها به عنوان نوع اصلی کار مشکلی است. شاید رسمی‌ترین ورژن آن قانون احاطه نرم‌افزار (Software Envelopment) که بیشتر به عنوان قانون زاوینسکی معروف است. نام این قانون از اسم جیمی زاوینسکی الهام گرفته شده و در هنر برنامه‌نویسی UNIX به آن اشاره شده است:

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

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

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

این امر همچنین می‌تواند برای عملکرد نرم‌افزار نیز صدق کند:

"نرم‌افزار توسعه می‌یابد تا جایی که همه منابع موجود را مصرف کند"

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

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

اصل bloat

  1. ذهنیت " هرچه بدتر، بهتر"

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

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

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

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

  1. قانون ایگلسان

"اگر به کدی که خودتان نوشته‌اید به مدت ۶ ماه یا بیشتر سر نزده‌اید، مثل این است که شخص دیگری آن کد را نوشته باشد".

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

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

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

  1. اصل حداقل شگفتی

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

این اصل اولین بار در مجله سیستم‌های IBM در سال ۱۹۸۴ منتشر شد و هنوز که هنوزه قدیمی نشده است – حتی شاید امروزه بیش از پیش صدق کند.

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

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

اصل حداقل شگفتی

  1. قانون حشره شناسی سایبری

"همیشه پای یک حشره (باگ در انگلیسی به معنای حشره است) در میان است"

این اصل گاهی با نام قانون حشره شناسی سایبری لوبارسکی شناخته می‌شود. مشخص نیست لوبارسکی دقیقا کیست.

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

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

  1. قانون کرنیگان

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

برایان کرنیگان، همان شخصی که یکی از ناشران کتاب the C programming language bible است، به خاطر این قانون مهم و با بصیرتش معروف شد. چکیده قانون او این‌چنین است: کد خوب بنویسید، کد خوانا بنویسید، کد ساده بنویسید، کدی بنویسید که برای نوشتن آن از حداکثر هوش خود استفاده نکنید.

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

و همان‌طور که رابرت سی مارتین توضیح می‌دهد، موضوع فقط دیباگ کردن نیست:

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

اصل اردک پلاستیکی

اصل اردک پلاستیکی

  1. روش دیباگ اردک پلاستیکی

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

روش دیباگ اردک پلاستیکی زمانی است که شما نرم‌افزار خراب را با توضیح دادن کد خود به یک شیء بی‌جان (مثلا یک اردک پلاستیکی) توضیح می‌دهید، هر دفعه یک خط کد.

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

به همین دلیل، روش اردک پلاستیکی می‌تواند یک هدیه عالی برای برنامه‌نویسان باشد.

  1. قانون نود – نود

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

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

این اصل کاملا با قانون هافستادتر برابری می‌کند:

"همیشه بیش از آنچه انتظارش را دارید طول می‌کشد. حتی وقتی قانون هافستادتر را نیز در نظر بگیرید".

اصل نود - نود

اصل نود - نود

  1. قانون پارکینسون

"کار به اندازه‌ای گسترش می‌یابد و طول می‌کشد که به تمام زمان موجود برای تکمیل آن نیاز پیدا خواهید کرد."

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

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

  1. قانون بروک

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

دفعه بعد که در تحویل یک پروژه تاخیر کردید (که اکثر پروژه‌های برنامه‌نویسی به زمانی بیش از آنچه از اول مشخص شد نیاز خواهند داشت)، به یاد داشته باشید که اضافه کردن کد نویسان بیشتر به تیم خود، باعث حل شدن سریع مشکل نمی‌شد.

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

پیشرفت و بهبود به عنوان یک برنامه‌نویس

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

منبع: makeuseof

 مطالب مرتبط

 ۴ برنامه‌نویس معروف که کدهای موفقیت زندگیشان را نوشتند
7 دلیل منطقی برای آموختن #C
 طبقه بندی زبان های برنامه نویسی
با یادگیری چگونگی تمرکز بر کارها، می‌توانید بهتر کد بنویسید
 LINQ(زبان جستجوی یکپارچه)
برنامه نویسی شیءگرا چیست؟

از آخرین دوره های آموزشی و تخفیف ها مطلع شوید

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

آخرین مطالب

آموزش جامع SQL Server (جلسه ۱۲)
آموزش جامع SQL Server (جلسه ۱۲)

دستور UPDATE در SQL Server برای تغییر داده‌های موجود در یک جدول، از دستور UPDATE به شکل زیر استفاده ...

آموزش جامع SQL Server (جلسه ۱۵)
آموزش جامع SQL Server (جلسه ۱۵)

دستور DROP TABLE در SQL Server گاهی، لازم است یک جدول که دیگر استفاده‌ای ندارد را حذف کنید. برای ...

آموزش جامع SQL Server (جلسه ۳۵: Window Functionها – بخش ۲)
آموزش جامع SQL Server (جلسه ۳۵: Window Functionها – بخش ۲)

بخش اول از آخرین مبحث دوره جامع آموزش SQL Server در جلسه قبلی بررسی شد. این مبحث که ...

آخرین دیدگاه ها

دیدگاه خود را درباره این پست بنویسید

فرم ارسال نظرات