چطوری تمیز کد میزنید

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

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

رابرت مارتین کتاب خیلی خوبی در این زمینه نوشته که پیشنهاد میدم حتما بخونید:
Clean Architecture: A Craftsman’s Guide to Software Structure and Design

متن زیر از قسمت مقدمه این کتابه:

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