اصولی عجیب در برنامه نویسی که بدون شک از آنها بی خبر هستید!

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

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

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

اصل (Bloat) (تورم)

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

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

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

این موضوع می‌تواند در عملکرد نرم‌افزار تاثیر داشته باشد:

«نرم‌افزارها بزرگتر می‌شوند تا جایی که تمامی منابع موجود را مصرف کنند.»

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

ذهنیتِ «بدتر بهتر است»

در پاسخ به اصل تورم، ذهنیتِ «بدتر بهتر است» را داریم که برای اولین بار در مقاله‌ی کیفیت نرم‌افزار، توسط ریچارد پی گابریل مطرح شده است:

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

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

زمانی که این موضوع را در نظر نگیرید چه اتفاقی می‌افتد؟ شما درگیر اصل پیتر (نقصان) نرم‌افزاری می‌شوید:

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

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

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

هر کد شما که شش ماه یا بیشتر به آن نگاه نکرده باشید، ممکن است توسط شخص دیگری نیز نوشته شده باشد.

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

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

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

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

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

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

قانون حشره‌شناسی سایبرنتیک: همیشه یک باگ دیگر وجود دارد!

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

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

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

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

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

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

همان طور که رابرت سی مارتین توضیح می‌دهد، این مشکل تنها به باگ‌گیری بر نمی‌گردد:

«در واقع، نسبت زمان صرف شده برای خواندن به نوشتن 10 به 1 است. ما دائما کدهای قدیمی را برای نوشتن کدهای جدید می‌خوانیم و بنابراین هر چه خواندن آنها ساده‌تر باشد، نوشتن کدهای جدید ساده‌تر می‌شود.»

باگ‌گیری اردک پلاستیکی

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

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

به همین دلیل، اردک پلاستیکی می‌تواند ارمغان شگفت‌انگیزی برای برنامه‌‌نویس‌ها باشد.

قانون 90 – 90

«90 درصد اول کدهای شما 90 درصد اصلی زمان توسعه را به خود اختصاص می‌دهد. 10 درصد باقی‌مانده از کدها 90 درصد دیگر از زمان توسعه را در برمی‌گیرد.»

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

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

زمانی که فکر می‌کنید برای رسیدن به پایان کار آماده می‌شوید، می‌بینید هنوز کلی کار دارید.

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

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

قانون بروک

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

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

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

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

منبع: faradars.org