کد نویسی تمیز در برنامه نویسی با جاب تیم

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

کد تمیز چیست؟

احتمالاً به اندازه برنامه‌نویس‌ها تعریف وجود دارد. بنابراین از برخی از برنامه‌نویسان بسیار شناخته شده و با تجربه پرسیدم که چه فکر می‌کنند. Bjarne Stroustrup مخترع زبان C++ و نویسنده The C++ Programming Language: من دوست دارم کد من زیبا و کارآمد باشد. منطق باید سر راست باشد تا پنهان کردن باگ‌ها دشوار باشد، وابستگی‌های حداقلی برای سهولت در نگهداری، کنترل کامل خطا مطابق با یک استراتژی تکه به تکه و عملکرد نزدیک به بهینه، بگونه ای که مردم را وسوسه نکند تا کد را با بهینه‌سازی های غیر اصولی شلخته کنند. کد تمیز یک کار را به خوبی انجام می‌دهد. Bjarne از کلمه “ظریف” استفاده می‌کند. این کلمه کامل است! دیکشنری موجود در MacBook من این تعریف را برای این کلمه ارائه میدهد : از نظر ظاهری و رفتاری دلپذیر و برازنده و شیک است. کاملاً مبتکرانه و ساده. به کلمه "دلپذیر" دقت کنید. ظاهرا Bjarne فکر می‌کند که خواندن کد تمیز لذت بخش است. خواندن آن باید لبخند را به لبان شما بیاورد، هماگونه که یک جعبه موسیقی خوش ساخت و یا یک ماشین با طراحی زیبا باعث می‌شود لبخند بزنید Bjarne همچنین دو بار از واژه بازده استفاده می کند. شاید وقتی این کلمه از دهان مخترع C ++ خارج می‌شود، غافلگیر کننده نباشد. اما فکر می‌کنم چیزی فراتر از تمایل صرف برای سرعت وجود دارد. چرخه‌های تلف شده لذت بخش نیستند و ناخوشایند هستند و اکنون به کلماتی که Bjarne برای توصیف پیامد آن ناهنجاری استفاده می‌کند توجه داشته باشید. او از کلمه "وسوسه" استفاده می‌کند. در اینجا یک حقیقت عمیق وجود دارد. کد بد شلختگی را وسوسه می‌کند تا رشد کند! وقتی دیگران کد بد را تغییر می‌دهند، متمایل به بدتر کردن آن هستند. Dave Thomas عملگرا و Andy Hunt این نکته را با یک روش متفاوت می‌گویند. آنها از استعاره پنجره‌های شکسته استفاده کرده اند. وقتی ساختمانی پنجره‌های شکسته دارد اینظور به نظر می‌رسد که کسی به آن اهمیتی نمی‌دهد. بنابراین دیگران هم به آن ساختمان اهمیتی نمیدهند. آنها اجازه می‌دهند تا پنجره‌های بیشتری شکسته شود. حتی خودشان هم شروع به شکستن پنجره‌ها می‌کنند. آنها با گرافیتی نما را خراب می‌کنند و اجازه می‌دهند در آن جا زباله جمع شود.

یک پنجره شکسته روند زوال را شروع می‌کند. Bjarne همچنین خاطرنشان می‌کند که رسیدگی به خطا باید کامل باشد. این مربوط به قانون توجه به جزییات می‌شود. کنترل خطای مختصر فقط یکی از راه‌هایی است که برنامه‌نویسان با استفاده از آن به تفصیل جزئیات می‌پردازند. نشت حافظه (Memory leaks) یکی دیگر از راهها و شرایط مسابقه(race condition) راه دیگر است. راه دیگر نامگذاری متناقض(Inconsistent naming) است. نتیجه اصلی این است که کد تمیز توجه زیادی به جزئیات دارد. Bjarne با این ادعا که کد تمیز یک کار را به خوبی انجام می‌دهد، بحث را می‌بندد. تصادفی نیست که بسیاری از اصول طراحی نرم‌افزار وجود دارند که می‌توانند دلیل اصلی این توصیه ساده باشند.

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

گردی بوچ Grady Booch، نویسنده “Object Oriented analysis and Design with Applications” :کد تمیز ساده و سر راست است. کد تمیز مثل یک نثر خوب نوشته شده است. کد تمیز هرگز هدف طراح را مبهم نمی‌کند بلکه پر از انتزاعات واضح و خطوط کنترل سر راست است. Grady برخی از نکاتی را که Bjarne بیان می‌کند، عنوان می‌کند، اما او یک جنبه خوانایی را در نظر می‌گیرد. من خصوصاً این نظر او را که كد تمیز باید مانند نثر خوب نوشته شده باشد دوست دارم. دوباره به کتاب خوبی که مطالعه کرده اید فکر کنید. به یاد آورید که چگونه کلمات ناپدید شدند تا تصاویر جایگزین شوند! مثل تماشای فیلم. اینطور نیست؟ بهتر! شخصیت‌ها را دیدید، صداها را شنیدید، ترحم و طنز را تجربه کردید. خواندن کد تمیز هرگز شبیه به خواندن کتاب ارباب حلقه‌ها نخواهد بود. با این وجود استعاره ادبی بد نیست. مانند یک رمان خوب، کد تمیز باید به وضوح تنش‌های موجود در مشکل را حل کند. باید آن تنش‌ها را به اوج خود برساند و سپس به خواننده بگوید که: "آها! اینه!" زیرا مشکلات و تنش‌ها در ظهور یک راه حل واضح برطرف می‌شود.به نظر من استفاده grady از عبارت "انتزاع خشک(crisp abstraction)" به عنوان یک کلمه ضد و نقیض جذاب است! در نهایت، کلمه "خشک" تقریباً مترادف "واقع" است. فرهنگ لغت مک بوک من تعریف زیر از "خشک" را دارد: قاطعانه و سرنوشت ساز، بدون تردید و جزئیات غیر ضروری. علیرغم این کنار هم گذاشتن معانی، کلمات دارای پیام قدرتمندی هستند. کد ما باید برخلاف حدس و گمان‌ها و واقعی باشد. کد باید فقط شامل چیزهای مهم و ضروری باشد. خوانندگان ما باید قاطعیت ما را درک کنند.

آقای Dave Thomas، موسس OTI، پدرخوانده استراتژی Eclipse : کد تمیز میتواند بجز نویسنده اصلی آن، توسط یک توسعه‌دهنده دیگر نیز خوانده شود و بهبود یابد. این کد Unit test و Acceptance test دارد. این کد اسامی معنی دار دارد. کد تمیز به جای اینکه راههای زیادی برای انجام یک کار ارائه کند، یک راه برای انجام یک کار دارد. کد تمیز حداقل وابستگی‌ها، که به طور واضح تعریف شده اند، و یک API واضح و حداقلی را ارائه می‌دهد. کد باید دانا باشد زیرا بسته به زبان، تمام اطلاعات لازم را نمی توان به طور مشخص و به تنهایی با کد بیان کرد. Dave بزرگ، تمایل Grady برای خوانایی را با پیچیدگی مهمی به اشتراک می‌گذارد. Dave ادعا می‌کند که کد تمیز باعث می‌شود بهبود آن برای سایر افراد آسان باشد. این ممکن است واضح به نظر برسد، اما نمی‌تواند بیش از حد مورد تأکید قرار بگیرد. از این گذشته، میان کدی که خواندن آن آسان است و کدی که تغییر آن آسان است تفاوت وجود دارد. Dave تمیز بودن کد را با تست‌ها پیوند می‌زند! ده سال پیش این امر باعث تعجب بسیار می‌شد. اما قوانین توسعه مبتنی بر تست(Test Driven Development) تأثیر عمیقی بر صنعت ما گذاشته و به یکی از اساسی‌ترین قوانین ما تبدیل شده است. حق با Dave است. کد، بدون تست، تمیز نیست. مهم نیست که چقدر زیبا باشد، هر چقدر هم که قابل خواندن و در دسترس باشد، اگر آزمایش نشده باشد، کثیف است. Dave دو بار از کلمه حداقل استفاده می‌کند. ظاهراً منظور او در این تعریف کدهای کوچک است. در واقع، از زمان پیدایش ادبیات نرم‌افزار تا کنون، این یک ترجمه رایج بوده است. کوچکتر بهتر است. Dave همچنین می‌گوید که کد باید دانا(Liteate) باشد. این یک اشاره ریز به ادبیات برنامه‌نویسی Knuth دارد. نتیجه کلی این است که کد باید به شکلی تهیه شود که برای انسانها خوانا باشد

میشل فیدرز Micheal Feathers، نویسنده Working Effectively with Legacy Code :من می‌توانم تمام خصوصیاتی را که در کد تمیز به آن توجه می‌کنم ذکر کنم، اما کیفیت فرا معماری وجود دارد که بر تمام آنان ارجح است. همیشه به نظر می‌رسد که کد تمیز توسط کسی نوشته شده است که به آن اهمیت داده است. هیچ چیز واضحی وجود ندارد که بتوانید انجام دهید تا کد بهتر شود. به همه این موارد توسط نویسنده کد فکر شده است و اگر سعی دارید پیشرفت‌ها را تصور کنید، به جایی که هستید برمیگردید، جایی که از کد شخصی که برای شما باقی گذاشته تشکر میکنید - کدی که توسط کسی که عمیقاً به این مهارت اهمیت می‌دهد به جا گذاشته شده است. یک کلمه: اهمیت دادن. این کلمه واقعاً موضوع این کتاب است. شاید یک عنوان مناسب این باشد که چگونه به کد اهمیت دهیم. Micheal به مهمترین نکته اشاره کرد. کد تمیز کدی است که از آن مراقبت شده است. شخصی وقت خود را برای ساده و منظم نگه داشتن آن صرف کرده است. آنها توجه کافی به جزئیات داشته اند. آنها مراقبت کرده اند.

رون جفری.Ron Jeffries، نویسنده Extreme Programming Installed و Extreme Programming Adventures in C# : رون حرفه برنامه‌نویسی خود را در Fortran در فرماندهی هوایی استراتژیک آغاز کرد و تقریباً به هر زبان و تقریباً بر روی هر دستگاهی، کدی را نوشت. این امر باعث شد که در مورد صحبت کردنش بسیار مراقب باشد: در سال‌های اخیر من قوانین کد ساده Beck را شروع و تقریباً به پایان رساندم. به ترتیب اولویت، کد ساده:

• تمام تست‌ها را اجرا می‌کند؛

• بدون (کد اضافه)Duplicate است.

• تمام ایده‌های طراحی موجود در سیستم را بیان می‌کند.

• تعداد موجودیت‌هایی چون کلاسها، متدها، توابع و موارد مشابه را به حداقل می‌رساند.

از این میان، بیشتر روی Duplication تمرکز می‌کنم. وقتی همین کار بارها و بارها انجام شد، این نشانگر این است که ایده ای در ذهن ما وجود دارد که به خوبی در کد نمایش داده نشده است. سعی می‌کنم بفهمم که چیست. سپس سعی می‌کنم این ایده را با وضوح بیشتری بیان کنم. برای من، بیانگر بودن شامل اسامی معنادار است، و من احتمالاً چندین بار اسامی چیزها را قبل از تثبیت آنها، تغییر می‌دهم. با ابزار مدرن کدنویسی مانند Eclipse، تغییر نام کاملا بدون هزینه است، بنابراین تغییر دادن برای من مشکل ساز نخواهد بود. با این وجود بیان کد فراتر از نامها است. من همچنین به این موضوع نگاه می‌کنم که آیا یک شی یا متد بیش از یک کار را انجام می‌دهد یا نه. اگر یک شیء باشد، احتمالاً باید به دو یا چند شیء تقسیم شود. اگر یک متد باشد، من همیشه از refactoring Extract Method روی آن استفاده می‌کنم، نتیجه اجرای این روش بر روی یک متد این است که چیزی که متد انجام میدهد را واضح تر بیان می‌کند، و برخی از زیرمتدها چگونگی انجام این کار را بیان میکنند. Duplication و صراحت، برای رسیدن به چیزی که من آن را کد تمیز تلقی کنم، راه بسیار طولانی ای را طی می‌کنند و بهبود کد کثیف فقط با توجه به این دو مورد می‌تواند تفاوت بزرگی ایجاد کند. با این حال، یک چیز دیگر وجود دارد که من از انجام آن آگاه هستم، که توضیح آن کمی سخت‌تر است. بعد از سالها انجام این کار، به نظر من همه برنامه‌ها با عناصر بسیار مشابهی ساخته شده اند. یک مثال "یافتن چیزها در یک مجموعه" است. چه بانک اطلاعاتی از سوابق کارمندان، یا نقشه درهم ساز(Hash map)کلیدها و مقادیر، و یا آرایه ای از بعضی از اقلام داشته باشیم، ما اغلب خودمان را خواهان مورد خاصی از آن مجموعه میبینیم. در پی آگاهی از وقوع این اتفاق، من اغلب پیاده‌سازی خاصی را در یک متد یا کلاس انتزاعی تر می‌پیچم. این به من چند مزیت جالب می‌دهد. من اکنون می‌توانم آن عملکرد را با چیزی ساده پیاده‌سازی کنم، مثلا با یک هش مپ، اما از آنجایی که اکنون همه ارجاعات مربوط به آن جستجو را توسط انتزاع کوچکم تحت پوشش قرار دادم، می‌توانم هر زمان که بخواهم، پیاده‌سازی را تغییر دهم. من بعدا می‌توانم با حفظ توانایی خود برای تغییر، به سرعت پیش بروم. علاوه بر این، وقتی با چند روش نسبتا ساده می‌توانم همه چیزی که می‌خواهم را بیابم، مجموعه انتزاع اغلب توجه مرا به آنچه که "واقعاً" در جریان است، جلب می‌کند و مرا از مسیر پیاده‌سازی مجموعه رفتارهای دلخواه منصرف می‌کند. Duplication کاهش یافته، بیان واضح و ساخت انتزاعات ساده از ابتدا. این چیزی است که برای من کد تمیز می‌سازد.

در اینجا، در چند پاراگراف کوتاه،  خلاصه مقاله را می بینید

بدون Duplication، یک چیز، بیان، تجریدهای کوچک. همه چیز آنجاست.

و **Ward Cunningham مخترع ویکی، مخترع Fit، هم اختراع کننده eXtreme Programming. نیروی انگیزشی در پشت Design Pattern. رهبر فکری شی گرایی و Smalltalk. پدرخوانده همه کسانی که به کد اهمیت میدهند:**وقتی هر روالی(Routine) که میخوانید دقیقا همان چیزی است که انتظار دارید، شما می‌دانید که دارید روی کد تمیز کار می‌کنید. همچنین هنگامی که کد شبیه به زبانی که برای مشکل درست شده است، می‌توانید آن را یک کد زیبا بنامید.

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

تفکر Ward در مورد زیبایی چطور؟ همه ما در برابر این واقعیت که زبانهای ما برای مشکلات ما طراحی نشده اند جبهه می‌گیریم. اما جمله Ward باری را بر دوش ما می‌گذارد. او می‌گوید که کد زیبا باعث می‌شود اینطور به نظر برسد که زبان برای این مشکل ایجاد شده است! بنابراین این مسئولیت ماست که زبان را ساده جلوه دهیم! طرفداران زبانها در همه جا هستند، هشیار باشید این زبان نیست که برنامه‌ها را ساده جلوه دهد. این برنامه‌نویس است که باعث می‌شود زبان ساده به نظر برسد!

مکتب فکری!

در مورد من(عمو Bob) چی؟ من در مورد کد تمیز چه فکر میکنم؟ این کتاب با جزییات زیاد آنچه من و همفکرانم درباره کد تمیز فکر می‌کنیم را به شما خواهد گفت. ما آنچه که فکر میکنیم یک نام متغیر تمیز، یک تابع تمیز، یک کلاس تمیز و غیره را ایجاد می‌کند به شما خواهیم گفت. ما این عقاید را مطلق ارائه خواهیم کرد و از سختگیری خود عذرخواهی نمی‌کنیم. برای ما، در این مرحله از حرفه مان، آنها مطلق هستند. آنها مکتب فکری ما در مورد کد تمیز هستند. هنرمندان رزمی همه با بهترین هنر رزمی یا بهترین تکنیک در یک هنر رزمی موافق نیستند. اغلب استادان هنرهای رزمی مکتب خود را تشکیل می‌دهند و دانش آموزان را برای یادگیری دور خود جمع می‌کنند. بنابراین ما Gracie Jiu Jistu را می‌بینیم، که توسط خانواده Gracie در برزیل تأسیس و تدریس شده است. ما Hakkoryu Jiu Jistu را می‌بینیم که توسط Okuyama Ryuho در توکیو تاسیس و تدریس شده است. ما Jeet Kune Do را می‌بینیم، که توسط بروس لی در ایالات متحده تاسیس و تدریس شده است. هنرجویان این رویکردها، خود را در آموزه‌های بنیانگذار غرق می‌کنند. آنها خود را وقف این می كنند كه آنچه آن استاد خاص تدریس می‌کند را فارغ از چیزی که استاد دیگر تدریس می‌کند، بیاموزند. بعداً با رشد هنرجویان در هنر خود، ممکن است دانش آموز استاد دیگری شوند تا بتوانند دانش و تمرین خود را گسترش دهند. عده ای سرانجام برای کشف مهارت‌های خود، به کشف تکنیک‌های جدید و تأسیس مکتب خود می‌روند. هیچ یک از این مکاتب مختلف کاملاً درست نیستند. با وجود این، در درون یک مکتب خاص به نظر می‌رسد که آموزه‌ها و فنون صحیح هستند.

از این گذشته، یک روش درست برای تمرین Hakkoryu Jiu Jitsu یا Jeet Kune Do وجود دارد. اما این حق در یک مکتب، آموزه‌های یک مکتب متفاوت را باطل نمی‌کند. این کتاب را در مورد توصیفات مکتب اشیا آموزشی در کد تمیز در نظر بگیرید. تکنیک‌ها و آموزه‌های موجود روشی است که ما هنر خود را تمرین می‌کنیم. ما مایل هستیم ادعا کنیم که اگر این آموزه‌ها را رعایت کنید، از مزایایی که ما از آنها لذت بردیم لذت خواهید برد و یاد می‌گیرید که کدی بنویسید که تمیز و حرفه ای باشد. اما این اشتباه را نکنید که فکر کنید که "حق" به طور مطلق با ما است.

مکاتب و اساتید دیگری نیز وجود دارند که به همان اندازه که ما ادعا داریم، حرفه ای هستند. شایسته است که شما از آنها نیز بیاموزید. در واقع، بسیاری از توصیه‌های این کتاب جنجال برانگیز است. احتمالاً با همه آنها موافق نخواهید بود. ممکن است با بعضی از آنها به شدت مخالف باشید. خوب است. ما نمی‌توانیم ادعای کمال اعتبار کنیم. از طرف دیگر، توصیه‌های موجود در این کتاب مواردی است که ما طولانی و سخت در مورد آنها فکر کرده ایم. ما آنها را طی چندین دهه تجربه و آزمایش و خطای مکرر آموخته ایم. بنابراین چه موافق باشید یا مخالف باشید، اگر به نقطه نظر ما احترام نگذارید و آن را نبینید شرم آور خواهد بود. ما نویسنده ایم فیلد @author در یک Javadoc به ما می‌گوید که ما کی هستیم. ما نویسنده هستیم و یک چیز در مورد نویسندگان وجود دارد و آن این است که آنها خواننده دارند. در واقع، نویسندگان مسئول برقراری ارتباط خوب با خوانندگان خود هستند. دفعه بعد که شما یک خط از یک کد را نوشتید، به یاد داشته باشید که شما نویسنده ای هستید که برای خوانندگانی که تلاش شما را قضاوت می‌کنند، می‌نویسید. ممکن است بپرسید : یک کد واقعا چه مقدار خوانده می‌شود؟ تمام تلاش ما صرف نوشتن آن نمی‌شود؟ آیا تاکنون به یک جلسه ویرایش دوباره باز گشته اید؟ در دهه 80 و 90 ویرایشگرانی مانند Emacs داشتیم که هرگونه فشار به صفحه کلید را ردیابی می‌کردند. می‌توانید یک ساعت کار کنید و بعد از آن کلیه ویرایش‌های خود را مانند یک فیلم پر سرعت پخش کنید. وقتی این کار را کردم، نتایج جالب توجه بود. هیچ یک از این مکاتب مختلف کاملاً درست نیستند. با وجود این، در درون یک مکتب خاص به نظر می‌رسد که آموزه‌ها و فنون صحیح هستند.

اکثریت قریب به اتفاق تجدید نظرها در مورد بخش پیمایش و هدایت به سایر ماژول‌ها بود! باب وارد ماژول می‌شود. او به تابعی که نیاز به تغییر دارد می‌رود او با توجه به گزینه‌های خود مکث می‌کند. اوه، او در حال برگشتن به بالای ماژول برای بررسی مقدار اولیه داده شده به یک متغیر است. اکنون او دوباره به پایین برمیگردد و شروع به تایپ می‌کند. اوه، او دارد آنچه را که تایپ کرده است پاک می‌کند! او دوباره آن را تایپ می‌کند. او دوباره آن را پاک می‌کند! او نیمی از چیز دیگری را تایپ می‌کند اما بعد آن را پاک می‌کند! او به تابع دیگری می‌رود که تابعی را که دارد تغییر می‌دهد را صدا میزند تا ببیند چگونه آن تابع صدا زده شده است. او دوباره به بالا برمیگردد و همان کدی را که تازه پاک کرده است تایپ می‌کند. مکث می‌کند. او دوباره آن کد را پاک می‌کند! وی پنجره دیگری را باز می‌کند و به یک زیر کلاس نگاه می‌کند. آیا این تابع دوبار نوشته شده است؟ . . . شما بی اراده کار می‌کنید. در واقع، نسبت زمانی که صرف خواندن میکنید در مقابل زمانی که صرف نوشتن میکنید بیش از 10: 1 است. همیشه بخشی از تلاشمان برای نوشتن کد جدید، برای خواندن کد قدیمی صرف می‌شود. از آنجا که این نسبت بسیار زیاد است، می‌خواهیم خواندن کد آسان باشد، حتی اگر این کار نوشتن را سخت‌تر کند. البته هیچ راهی برای نوشتن کد بدون خواندن آن وجود ندارد، بنابراین آسان تر کردن خواندن در واقع نوشتن آن را آسان تر می‌کند. از این منطق گریزی وجود ندارد. اگر نمی‌توانید کدهای اطراف را بخوانید، نمی‌توانید کد بنویسید. نوشتن کدی که می‌خواهید امروز بنویسید بسته به اینکه چقدر خواندن کد اطراف آن سخت یا آسان باشد، دشوار یا آسان خواهد بود. بنابراین اگر می‌خواهید سریع کار کنید، اگر می‌خواهید به سرعت کار خود را به اتمام برسانید، اگر می‌خواهید کد شما به راحتی نوشته شود، خواندن آن را آسان کنید قانون پیشاهنگان پسر اینکه کد به خوبی نوشته شود کافی نیست. کد باید در طول زمان تمیز نگه داشته شود. با گذشت زمان، همه ما شاهد پوسیدن و کاهش درجه ارزش کد هستیم. بنابراین ما باید نقش فعالی در جلوگیری از این تخریب داشته باشیم. پیشاهنگان پسر امریکا یک قانون ساده دارند که ما می‌توانیم از آن در حرفه خود استفاده کنیم. محل اردوگاه را تمیزتر از آنچه که به آن وارد شدید، ترک کنید اگر همه ما هنگام ورود به کد، كد خود را كمي تميزتر از زماني كه آن را رها کرده بوديم کنیم، كد به سادگي نمي تواند پوسيده شود. پاکسازی لازم نیست چیز بزرگی باشد. بهتر کردن نام یک متغیر، شکستن یک تابع نسبتا بزرگ به توابع کوچکتر، از بین بردن یک تکثیر، پاک کردن یک عبارت شرطی ترکیبی باعث تمیزتر شدن کد می‌شود. آیا می‌توانید کار کردن روی پروژه ای که کدش با گذشت زمان به آسانی بهتر شده است را تصور کنید؟آیا معتقدید که گزینه ای غیر از این حرفه ای است؟ در واقع، آیا پیشرفت مداوم جز ذاتی حرفه ای بودن نیست؟ مقدمه و اصول از بسیاری جهات، این کتاب "مقدمه" کتابی است که من در سال 2002 با عنوان توسعه نرم‌افزار چابک: اصول، الگوهای و عملکردها نوشتم. کتاب PPP خود با اصول طراحی شی گرا و بسیاری از شیوه‌هایی که توسط توسعه دهندگان حرفه ای استفاده می‌شود درگیر است. اگر PPP را نخوانده اید، ممکن است در آینده متوجه شوید که آن کتاب، داستانی که توسط این کتاب گفته شده را ادامه می‌دهد. اگر قبلاً آن را خوانده اید، می‌توانید تکرار بسیاری از تفکرات آن کتاب در سطح کد را در این کتاب ببینید. در این کتاب اشاراتی پراکنده به اصول مختلف طراحی خواهید یافت. در میان این اصول اصل تک مسئولیت4، اصل بسته باز5 و اصل وارونگی وابستگی6 وجود دارد. این اصول به تفصیل در PPP شرح داده شده است نتیجه گیری کتابهای مربوط به هنر قول نمی دهند شما را به یک هنرمند تبدیل کنند. تمام کاری که آنها می‌توانند انجام دهند این است که برخی از ابزارها، تکنیک‌ها و فرآیندهای فکری که سایر هنرمندان استفاده کرده اند را به شما ارائه می‌دهند. بنابراین این کتاب نیز نمی‌تواند قول دهد شما را به یک برنامه‌نویس خوب تبدیل کند. نمی‌تواند قول بدهد که به شما "درک کد" را بدهد. تمام کاری که می‌تواند انجام دهد این است که فرآیندهای فکری برنامه‌نویسان خوب و ترفندها، تکنیکها و ابزارهایی را که از آنها استفاده می‌کنند به شما نشان دهد. درست مانند یک کتاب در زمینه هنر، این کتاب پر از جزئیات خواهد بود. تعداد زیادی کد وجود دارد. هم کد خوب خواهید دید و هم کد بد. میبینید که کد بد را به کد خوب تبدیل می‌کنید. لیست‌های از اکتشاف، قوانین و تکنیک‌ها را مشاهده خواهید کرد. مثال پشت مثال خواهید دید. پس از آن، به شما بستگی دارد. شوخی قدیمی درباره ویولنیست کنسرت را که در راه رسیدن به یک اجرا گم شده بود را به یاد می‌آورید؟ او پیرمردی را در گوشه ای متوقف کرد و از او پرسید که چگونه به Carnegie Hall برسد. پیرمرد به ویولنیست و ویولون زیر بازویش نگاه کرد و گفت: "تمرین کن پسرم. تمرین کن!"

یه کد نویسی خوب تو آموزش لاراول هم هست که پیشنهاد میکنم بررسی کنید مخصوصا سرفصلهای آماده شده که واقعا حرفه ای هستند

https://jobteam.ir/Course/178-Laravel-course-building-online-store