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

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

اصل (Bloat) تورم

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

قانون 90 – 90

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

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

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

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

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

قانون بروک

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

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

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