برای طرح سوال و دسترسی به آموزش ها  کانال ما در تلگرام بپویندید  

۹۷ نکته که باید هر برنامه نویس بداند- بخش دوم – پارسی – ترجمه

نکته ۴

.Automate Your Coding Standard

۴- گوینده : Filip van Laenen به طور خودکار برنامه خورد را استاندارد کد بزنید .
بدون شک شما کد های زیادی تا کنون زده اید .  در ابتدای پروژه همه معمولا نیت های خوبی دارند در “پذیریش قرارداد” ها اغلب این قرارداد ها در اسناد به صورت نوشته شده است .یکی از اصول این است که در آخر کد های پروژه شما استاندارد باشد.  در طول جلسه سعی بر این است که همه اسناد به بهترین و نحو و مطابق با میل همه تنظیم شود ، اما زمانی که پروژه به جریان میافتد خیلی از این نیات خوب فراموش میشود  ، در آن واحد ، اما زمان تحویل که میرسید کد مثل آش شعله قلم کار شده و هیچ کس نمیداند که چگونه و از چه راهی به این شکل در آمده است.
چه زمانی همه چیز رو به خطا نهاد؟ احتمالا در همان پایان نشست .به برخی از قسمت های پروژه توجه نکرده اید ، دیگران متوجه این نکته نیستند، اما بدتر این است که شما در پی برنامه ریزی یک کد استاندارد بودید اما اختلال در کد ایجاد میشود ،  در نهایت برخی از نقاط را با آنها کنار می آیید ، اما زمانی فشار پروژه بیش از حد بالا میرود ، آنها مجبور میشوند کارهای بکنند ، زمانی که کد پروژه فرمت بندی میشود مشتری از شما کد با قابلیت بیشتری می خواهد. بنابراین رعایت کردن یک کد استاندارد به طور خودکار در پروژه خسته کننده میشود. فقط سعی کنید در غرق شدن در کلاس آشفته پروژه ، خود در آن پیدا کنید.

wallpaper-3ac52
اما اگر مشکل این چنین است ، چرا می خواهیم کد های استانداردی در خانه اول داشته باشیم ؟ یک دلیل این است که فرمت یک نواخت کد راهی است که هیچ کسی نمیتواند یک قطع از کد ما را فرمت بندی کند و راهش خصوصی است .ممکن است ما بخواهیم برای جلوگیری از بروز برخی از اشکالات رایج از الگو ها ( pattern   ) استفاده کنیم ، کد استاندراد می بایستی ساده تر باشد و سرعت ما رو از آغاز تا پایان توسعه پروژه حفظ کند . اگر همگان استارندارد ها قبول کنند دیگر توسعه دهندگان مدام به کمک نیاز پیدا نمی کنند ، مثلا فروفتگی کد ها در ۳ خط فاصله و دیگری۴ فاصله .
وجود مستندات و نماها ( چارت ها ) چگونگی استفاده با کیفیت و استارندارد سازی کد ها یک ثروت در است و اما همه راه حل نیست ، این که باید علاوه بر امکان پذیر بودن ، قابل اجرا و خودکار باشد به عنوان مثال :
مطمئن شوید فرمت بندی بخشی از فرآیند ساخت است ، به طوری که هر کسی این کد را اجرا میکند خودکار سر همبندی ( کامپایل ) شود .
از ابراز های ایستا ( استاتیک) برای بررسی کدهای بدون قالب نا خواسته استفاده کنید ، اگر چیزی یافتید فوراً ساخت پروژه را متوقف کنید.
پیکربندی این ابزار ها را بیاموزید ، به این صورت است که شما میتوانید برای پروژه خود تحلیل را ارائه دهید .
آیا شما به تنهایی پروژه خود رو میسنجید؟ ولی خودکار این کار نتایج بیشتری را در بر دارد ، دوباره می گویم ، پروژه رو متوقف کنید اگر نتیجه آزمودن ضعیف است.

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

نکته ۵.

Beauty Is in Simplicity

۵-گوینده : Jørn Ølmheim زیبایی در سادگی است .
در اینجا یک نقل و قول از افلاطون وجود دارد ، که فکر می کنم همه توسعه دهنده ها آن را بدانند و آویزه گوش خود کنند :
زیبایی در سَبک ، هماهنگی ، موهبت و ریتم خوب به سادگی بستگی دارد.
در یک جمله آنچه که ما توسعه دهنده در سر داریم را در یک جمله ارشمند خلاصه کرده است .
چند نمونه از آنچه که ما باید تلاش کنیم در کد هایمان وجود داشته باشد :
خوانا بودن
قابل نگهداری بودن
سرعت در توسعه
کیفیتی دست نیافتنی در توسعه
افلاطون در گفته خود به ما می آموزد فراهم آمدن همه این ویژگی ها و کیفیت در سادگی است ، کد زیبا چیست ؟ این سوال بسیاری مرسومی است .ادراک زیبایی بستگی به شدت فهم هر فرد از یک زمینه میسر است ، فقط به میزان درک ما از آن زمینه بستگی دارد. افراد تحصیل کرده در رشته های هنری درک متفاوتی ( حداقل در روشی ) زیبایی به نسبت آنها که در علوم فنی مطالعه داشته اند دارند . کسانی که در زمره هنرمندان هستند زیبایی یک نرم افزار را با یک آثار هنری مقایسه می کنند در حالی که فنی ها زیبایی یک نرم افزار را در تقارن و نسبت ساده کردن فرمول های تلاش نرم افزار می دانند.من طبق تجربه فردی پایه و اساس هر دو طرف را درک کرده ام .
درمورد سورس کد هایی که تا به حال خوانده اید بیاندیشید ، اگر هم تا به حال سورس مردم را مطالعه نکرده اید ،همینک خواندن این مقاله را متوقف کنید و چند پروژه متن باز رو مطالعه نماید .واقعا منظورم همین است ! بروید و در فضای وب دنبال سرور های افراد سر شناس و حرفه ای از زبان برنامه نویس خود بگردید و آن را مطالعه کنید .
شما برگشتید؟ ( پس خوندید و برگشتید ) کجا بودیم ؟ اوه بله …. من این کد را پیدا کردم و طنین اندازی زیبایی بود به نظر من ( زیاد جدی نگیرید این کلمه زیبایی را این جماعت کم دارند تو حرف زدن) ، دارای شماری از ویژگی های رایج است ، رئیس اصلی در این میان سادگی است ، من این را پیدا کردن مهم نیست که کار نرم افزار یا سیستم چقدر پیچیده باشد مهم این است که من در تک تک بخش ها سادگی را یافتم : اشیای ساده ، با یک کار واحد ، نام ها و روند ( توابع ) با نام های متمرکز و مرتبط . برخی مردم بر این اعتقاد هستند که ایده هایی که دارای روندی با ۵-۱۰ خط کد هستند فوق العاده هستند ، و برخی از زبان ها بسیار سخت آن کار را انجام می دهند ، اما من بر این باور نیستم که چنین انتظاری یک توقع مطلوب باشد.
خط پایینی این است که کد زیبا کد ساده است ، هر بخش با مسئولیت ساده ، روابط ساده و ساده نگه داشتن سیستم می تواند کمک به حفظ سیستم ما کند و قادر است در طول زمان با کد های بی آلایش و ساده تمیز ، قابل سنجش و اطمنیان حاصل کردن از این که کد با سرعت بالا قابل توسعه در تمام عمر سیستم است .
زیبایی در سادگی متولد و یا یافت میشود.

نکته ۶.

Before You Refactor

۶- میگوید : Rajith Attapattu قبل از دوباره عمل کردن (دوباره کاری ) .
برخی موارد هر برنامه نیاز به این دارد که دوباره کاری کند با وجود کد ها ، قبل از این که این کار را انجام دهید بهتر است به موارد زیر فکر کنید :
بهترین روش برای شروع مجدد پروژه در نظر گرفتن کد های موجود و آزمودن عملکرد آنها می باشد . این به شما کمک می کند در مکانی که هستید نقاط قوت و ضعف خود را بیابید . بنابراین شما میتواند نقاط قدرت خود رو تقویت و از نقص های خود دوری گزنید. همه می فکر می کنیم میتوانیم کار بهتر انجام دهیم ، اما در پایان میبینیم که وضعیت بدتر از گذشته است چرا که از ضعف های موجود عبرت نگرفته ایم .
از وسوسه بازنویسی همه چیز دوری کنید .بهترین راه استفاده مجدد از کدهایی هستند که مصرف آنها امکان پذیر است .  مهم نیست کد چقدر زشت به نظر برسد مهم این است که اکنون کار می کند ، آزموده و بازینی شده است. دور انداختن کد اصلا خوب نیست بدین معنا که کد هایی که شما ماها و یا سالها آزموده اید دور بیاندازید . درسته ممکن است جنگ سختی با کد داشته باشید اما ممکن است راه حلی در آن باشد که از دید شما پنهان است. اگر شما این کار را نمی کنید ممکن است یک کد نویس جدید بیاید و این مشکل را برای شما حل کند .این کار صرفه جویی در مقدار زیادی سرمایه وقت شما است که مصرف کرده اید.
بسیاری از تغییرات جزئی و کارآمد خیلی بهتر ا تغییرات عظیم و کلی است . تغییرات مفید به شما این امکان را میدهد که پس از تغییر به راحتی عملکرد آن را بر روی سیستم مشاهده و بازخورد آن را بدست آورید. این که ۱۰۰ باز خطا را ببیند زمانی آزمودن کد ها سرگرم کننده نیست ، این ممکن است باعث ایجاد فشار ، سر خوردگی شما و یا عامل تصمیم گیری بد شود. دعوا های یک زن و شوهر خیلی ساده تر از حل روند یک رویکرد یک کد قابل کنترل است .
بعد از تکرار هر توسعه ، مهم است از آزمون پس دادن عملکرد پروژه اطمینان حاصل شود. اضافه کردن آزمون های جدید اگر کد های شما تغییرات چندانی داشته ضروری به نظر می رسد تا آزمون را به طور کامل پوشش دهد. اما اگر دور انداختن کد ها مد نظر نباشد زیاد این موضوع مطرح نیست . و قابل استفاده در پروزه جدید خود می باشد چرا که دلایل محکمی وجود دارد که این کد ها آزمون های خاص خود را پس داده اند.
ویژگی های شخصی و خود خواهانه در این راه وجود ندارد ، اگر چیزی به شکست  نیانجامیده چرا باید تعمیر شود ؟ چون که سَبک و سیاق کد با ویژگی های شخصی شما سازگار نیست دلیل موجهی برای این بازسازی نیست.  شما فکر می کنید که بهتر از برنامه نویس قبل می توانید کد بزنید این نیز دلیل موجهی برای این کار نیست.
فناوری های جدید دلیل کافی برای دوباره کاری نیستند ، یکی از بدترین دلیل ها برای دوباره کاری است چرا که کد شما پیش از فناوری روز عرضه شده است و و ما نیز معتقد هستیم فناوری های جدید و فریم ورک های جدید میتواند به کد زیبایی ببخشد. مگر در صورتی که تجزیه و تحلیل کد فعلی هزینه ی گزافی به همراه دارد دست آخر شما مجبور به مهاجرت به فناوری جدید می کند.
به خاطر داشته باشید که انسان ها اشتباه می کنند ، تجدید ساختار همواره تضمین کننده بهتر بودن و بدون اشتباه بودن ساختار نیست ،  من بارها دیده ام بعد از باسازی ساختار کد ها زیبا نبوده و پروژه شکست خورده ولی این انسان ( جایز الخطا ) است.

صحبت آخر:

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


انتشار

در

توسط

برچسب‌ها:

نظرات

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

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *