صفحه 2 از 2 اولاول 12
نمایش نتایج 41 تا 44 از 44

نام تاپیک: گفتگوی فنی شماره یک - اصول و قواعد کد نویسی

  1. #41

    نقل قول: گفتگوی فنی شماره یک - اصول و قواعد کد نویسی

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

    اشتباه 1 - Indentation نامناسب ممکن است شما را فریب دهد!
    قطعه کد زیر را در نظر بگیرید:

    if (condition == true)
    doSomething();

    حالا فرض کنید من می خواهم در صورت برقراری شرط متد دیگری هم فراخوانی شود:

    if (condition == true)
    doSomething();
    doSomethingElse();

    Oops! ، چی شد؟ ممکن است یک برنامه نویس یک چند دقیقه ای با این کد کلنجار برود و فکر کند که در صورت بر قراری شرط هر دو متد اجرا می شوند، اگر من این کد را با ابزار StyleCop که آقای موسوی معرفی کردند، آنالیز کنم، با این Warning مواجه خواهم شد،

    The body of the if statement must be wrapped in opening and closing curly brackets.

    خوب اگر من کد را از اول به این شکل می نوشتم، دیگر گول نمی خوردم:

    if (condition == true)
    {
    doSomething();
    }
    doSomethingElse();

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

    اشتباه 2 - جادوی Copy & Paste کار دست آدم می دهد
    "شما نباید تنها به این دلیل که یک فطعه کد بر روی اینترنت است، آن را در سیستم تولید خود Cut & Paste کنید، آیا آدامسی که در خیابان پیدا کنید را می جوید؟"
    جمله ی بالا از جناب Scott Hanselman نقل شده است که متن کامل آن را در اینجا قرار می دهم:

    Scott's Rule of Programming - Rule# 0x3eA
    Just because code is on the Internet doesn't mean you should cut and paste it into your production system. Do you chew gum you find on the street? Give code you find on the 'NET the same amount of attention you'd give advice scrawled on a public bathroom wall.
    بارها در همین انجمن برنامه نویس مشاهده کردیم که شخصی کدی را از یک سایت معتبر دریافت کرده و به دلیل اینکه نتیجه ی دلخواه خود را از آن کد نگرفته است، اقدام به طرح سوال می کند، کمی که موضوع را بررسی می کنید، متوجه می شوید که این شخص اصلا" دقتی در کد مربوطه نداشته و فقط زحمت Copy & Paste را کشیده است، هر قطعه کدی هر چقدر هم که به نیازمندی های شما نزدیک باشد، باز هم باید برای قرار گرفتن در محیط تولید و پروژه ی شما مورد بازبینی قرار گیرد و در صورت لزوم، برای تطابق آن با شرایط موجود، اصلاح گردد، قبلا" هم گفته شد که برنامه نویسی یک فعالیت "مستمر" است، قطعه کدی که الان و فقط در زمان حاضر نیاز شما را برطرف کند، لزوما" فطعه کد خوبی نیست و ممکن است در آینده شما را با مشکلاتی روبرو کند، پس باید همیشه پیش از قرار دادن یک قطعه کد در پروژه خود، به دقت آن را بررسی کرده و با اطمینان کامل از آن استفاده کنید،
    گاهی اوقات هم به دلیل رعایت نکردن Code Reusability، برنامه نویس، یک قطعه کدی را که در جایی از برنامه نوشته بوده، به محل جدیدی کپی کرده و قصد دارد که با تغییر دادن مقدار تنها چند متغیر، همان عملکرد را پیاده سازی کند، خوب این کار را انجام می دهد و می بیند که کد در محل جدید و با مقادیر جدید نتیجه دلخواه را نمی دهد، بعد از مدت زیادی بالا پایین کردن کد، متوجه می شود که مقدار یکی از متغیرها را تغییر نداده است و اینجاست که برنامه نویس "خطا" کرده است، تنها به خاطر اینکه تصور می کرد با کمی زرنگی می تواند در وقت صرفه جویی کند، اما با اینکار هم وقت و انرژی که می شد صرف انجام فعالیت مفیدتری شود به هدر رفت و هم اینکه یکی از اصول اساسی در کد نویسی که به آن اشاره کردم را نقض کرده است که مشکلاتی را به همراه دارد، پس یکی از جاهایی که نیاز مبرم به Code Refactoring احساس می شود، همین جاست،

    اشتباه 3 - Overuse نکنید
    یکی از مزایای قوائد و اصولی که در برنامه نویسی وجود دارد که ما به بخشی از آن ها اشاره کردیم، برای نظم بخشیدن بیشتر می باشد، گاهی اوقات اصل پروژه و الگوریتم به کل از یادمان می رود، از بس که غرق در این اصول می شویم و فقط بیشتر به "پیچیدگی" کار اضافه می کنیم تا اینکه بخواهیم آن را سازماندهی نماییم، این الگوها زمانی مفید خواهند بود که "در جای خود و متناسب با نیاز" از آن ها استفاده کنیم،

    راستش را بخواهید، از این اشتباهات، زیاد وجود دارد، حتما" سعی خواهم کرد که در آینده بیشتر به آن ها بپردازم،

    خوب، منتظر شنیدن صحبت های پایانی آقای موسوی هستیم،

    اوقات خوشی را برای شما آرزو می کنم و منتظر شنیدن نظرات شما هستم،

    امیدوارم که دوستان از این گفتگو لذت برده باشند، از آقای موسوی و آقای عسگری هم تشکر و قدردانی می کنم،

    ،/
    آخرین ویرایش به وسیله علیرضا مداح : جمعه 25 تیر 1389 در 17:55 عصر
    I've just started tweeting!
    @Alireza_Maddah

  2. #42

    نقل قول: گفتگوی فنی شماره یک - اصول و قواعد کد نویسی

    ممنون آقای مداح. آقای موسوی شما آخرین پست این بحث رو هم بنویسید تا گفتگوی فنی شمارۀ یک تموم بشه.
    از هر دو مهمان عزیز ممنونم.
    We work in the dark, we do what we can, we give what we have.
    Our doubt is our passion and our passion is our task.
    The rest is the madness of art

  3. #43

    نقل قول: گفتگوی فنی شماره یک - اصول و قواعد کد نویسی

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

    نقل قول نوشته شده توسط Saeed_m_Farid مشاهده تاپیک
    2) Divergent Change (تغییر واگرا) و Shotgun Surgery رو میشه بیشتر توضیح بدین؟ من نوعی تو برخی کدهام، فکر میکنم که درست تر از این دیگه نمیشه و از زمان و وقتم هم هزینه میکنم و دنبال کدهای تمیز مشابه و قابل استفاده برای نمونه می گردم و ... ولی باز هم - علیرغم دقت اولیه- طی زمان همچین مشکلاتی شبیه اون چیزی که آقای موسوی فرمودن برام پیش میاد. اینا دیگه Refactoring نیستند که تو توسعه نهایی سیستم تاثیری نداشته باشند؛ باید هزاران خط کد از اول بهینه سازی بشه یا دید توسعه دهندگان سیستم عوض بشه و بردارن تمام اجداد کلاسها رو بهینه نویسی کنند که اونهم معلوم نیست بازم Refused Bequest بشن یا نه! اینا واقعاً تو پروژه هایی که پرونده شون مثلاً بسته شده و تغییرات جزئی میخوان هزینه بر و اعصاب خوردکن هست؛ چه راه حلی پیشنهاد می کنید؟ یا بنظرتون از این به بعد چی کار کنیم بهتره؟
    ببینید، ما کدمون رو همواره طوری می نویسیم (یا باید بنویسیم) که بشه براحتی تغییرات رو روش اعمال کرد. وقتی می خواهیم تغییری در سیستم بدیم، حالت بهینه اینه که به سرعت بتونیم نقطه ای در برنامه رو نشون بدیم که نیاز به تغییر داره. منظورم تنها یک نقطه هستش. وقتی قادر نباشیم اینکارو کنیم، باید نگران طرح پیاده سازی شده باشیم. Divergent Change شرایطی هستش که شما برای اعمال یک تغییر باید تو چندین نقطه از برنامه دست ببرید (و این خطرناکه، چرا که ممکنه یکی از نقاط مورد نظر که نیاز به تغییر داشته رو از قلم بندازیم). در واقع چنین کدی کد Error-Prone ای هستش (یعنی کد به نحوی نوشته شده که بالقوه خطر آفرین هستش). در این شرایط بهترین کار این هستش که اون کلاس رو به کلاسهای دیگه تقسیم کنیم به نوعی که هر کلاس فقط و فقط یک کار رو انجام بده و هر تغییر فقط در یک نقطه انعکاس پیدا کنه.

    در مقابل، تصور کنید شرایطی رو که تغییر در یک کلاس منجر به تغییر در چندین کلاس متعدد بشه (Shotgun Surgery). خوب، این وضعیت نشون میده قانون SRP در نوشتن برنامه نادیده گرفته شده و کلاسها به همدیگه وابسته هستن. در ادامه در مورد SRP صحبت خواهم کرد. اینکه چطور می تونیم از این شرایط دوری کنیم، بخشیش به داشتن این اطلاعات بر میگرده و بخشیش به تجربه. در طول فرآیند توسعه نرم افزار، کدها باید مدام Refactor بشن تا در نهایت به نقطه Stable ای برسن. چون توسعه در طی زمان رخ میده، طی این زمان (و اضافه شدن قابلیتهای جدید) هستش که برنامه نویس متوجه میشه کدوم بخش از کد رو باید چگونه Refactor کنه. اگر عمل Refactoring زود زود انجام بشه، دیگه با انبوهی کد مواجه نخواهیم بود که یک تغییر ساده، نیاز به زیر و رو کردن کل سیستم داشته باشه.

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

    بطور کلی، نوشتن یک کد خوب هرگز محدود به رعایت قوانین نام گذاری، سپردن هر Functionality به بک تابع خاص یا خوب نوشتن Comment ها در برنامه نمیشه. برای اینکه یک کد خوب بنویسیم، باید به اصول شیء گرایی، بهترین الگوها و ... اشراف داشته باشیم. این اشراف بعلاوه مطالبی که تا به حال ذکر شد، می تونه تواما ما رو به نوشتن یک کد خوب رهنمون بشه.

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

    احتمالا تا به حال با برخی از این واژه ها در دوران کاری خودتون، روبرو شده اید: SRP، OCP، LSP، ISP و DIP. اینها بخشی از قوانینی هستن که شما رو در نوشتن یک کد خوب، یاری میکنن. اجازه بدید تا اندکی در مورد هر یک از این مفاهیم توضیح بدم.

    • واژه SRP یا Single Responsibility Principle به این معناست که فقط و فقط باید یک وظیفه رو دوش کلاس گذاشته بشه. وقتی شما کلاسی به اسم Car ایجاد می کنید، طبیعتا باید کلیه متودها، Property ها و Member Field های کلاس مزبور همگی در یک راستا نوشته بشن و نباید آهنگ نوشتن یک کلاس رو با معرفی متودی نامتناسب در کلاس مزبور بهم بزنید. به بیان دیگه، هر کلاس باید تنها و تنها به یک دلیل تغییر کنه. نیاز به تغییر یک کلاس به دو دلیل مجزا در دو برهه زمانی متفاوت، بیانگر این مساله هستش که این کد نیاز به Refactoring داره و در واقع باید در دو ماژول یا دو کلاس جداگانه تعریف بشه.
    • واژه OCP، یا Open Closed Principle به این معناست که شما باید بدون دست بردن در یک کلاس، توان توسعه اون کلاس رو داشته باشید. در واقع کدی خوبه که توسعه پذیر باشه. به بیان دیگه، یک کلاس (یا یک ماژول) باید برای توسعه پذیر بودن دست برنامه نویس رو باز بذاره، در عین حال در برابر تغییرات بیرونی کاملا بسته و محدود باشه.
    • LSP یا Liskov Substitution Principle به این معناست که شما باید کلاسهای Derived رو طوری بنویسید که در صورت نیاز بتونید اونها رو با Base Class خودتون عوض کنید، بدون اینکه تغییری در کلاسهای دیگه بوجود بیارید! فهم عمیق این مساله، مستلزم دونستن مفاهیم Contravariance، Covariance، Invariant و ... هستش، که در حال حاضر از حوصله این گفتگو خارجه.
    • ISP یا Interface Segregation Principle به این معناست که وقتی Interface شما در طول فرآیند توسعه نرم افزار فربه شدش، باید اون Interface رو به Interface های دیگه تقسیم کنید تا Client هایی که از اون Interface اولیه استفاده می کردن، اما نیازی به بسیاری از متودهاش ندارن، مجبور به پیاده سازی اجباری اونها نباشن. اگر دقت کنید، یکی از دلائل بوجود اومدن Interface های نسخه 2 در Windows SDK همین بوده. اگر متودهای جدید، روی اینترفیس قبلی قرار میگرفتن، اونوقت (علاوه بر بوجود اومدن مشکلات عدیده مهمتری که بی ارتباط با این موضوع هستش) Client های قدیمی مجبور بودن تا متودهای جدید Interface جدید رو نیز پیاده سازی کنن، در صورتیکه به اونها نیازی ندارن.
    • DIP یا Dependency Inversion Principle عنوان میکنه که اولا ماژولهای سطح بالا نباید به ماژولهای سطح پایین گره بخورن، بلکه هر دو باید بر اساس لایه Abstraction ای بنا بشن (مثل HAL در ویندوز). ثانیا، این Abstraction ها نباید به جزییات گره بخورن، بلکه جزییات نیز باید بر اساس abstraction ها پایه ریزی بشن. دونستن این مفاهیم و بکار بردن اونها هنگام طراحی کلاسها، بدون شک به شما کمک میکنه تا کدتون در آینده کمتر نیاز به Refactoring داشته باشه و در نتیجه، خواناتر و بهتر باشه.

    مسائلی که مطرح کردم، یک کد خوب رو از دید طراحی کلاسها مد نظر قرار میده. اما کد خوب، از دید Package Cohesion (پیوستگی در سطح Package) نیز باید مورد توجه قرار بگیره.
    RREP، CCP و CRP سه تا از مهمترین قوانین درگیر با شکستن کد در سطح Package هستن:

    • CCP به این معناست که کلاسهایی که با یکدیگر تغییر می کنن، باید در یک Module قرار بگیرن. به این ترتیب هنگامیکه نیاز به اعمال تغییر در یک کلاس باشه، دیگه نیازی نیست تا Module های دیگه به روز بشن و با بهنگام سازی همون ماژولی که حاوی Class مورد نظر هستش، سیستم نرم افزاری ارتقاء پیدا خواهد کرد. به این مساله Common Closure Principal یا CCP میگن.
    • منظور از CRP یا Common Reuse Principle، بسته بندی کلاسها در یک Module هستش هنگامیکه اون کلاسها در کنار یکدیگر استفاده بشن. فرض کنید در حال نوشتن برنامه ای همانند Paint هستیم. این قانون ما رو ملزم میکنه تا کلاسهای Circle، Line، Polygon و ... رو که همگی در کنار یکدیگر استفاده خواهند شد رو در یک Package قرار بدیم.
    • RREP یا Release Reuse Equivalency Principle به ما میگه که اگر قراره یک کد بطور مناسبی مورد استفاده مجدد قرار بگیره، این کد باید بصورت یه Black Box عرضه بشه تا بشه بدون درگیر شدن با جزییات پیاده سازیش، از اون استفاده کرد. نه اینکه دل و روده کد ما در اختیار استفاده کننده باشه و اون نیز به نوبه خودش بتونه در کد دست ببره و تغییرات مورد نظرش رو ایجاد کنه. در واقع Component مورد نظر باید بصورت یک Library در اختیار استفاده کننده قرار بگیره و تغییرات درونی این Library از دید استفاده کننده کاملا پنهان باشه.

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

    قانون KISS، یا Keep it simple, stupid به این معناست که هر چه کد رو ساده تر نگه دارید، کدتون خواناتر و بهتره. در برابر، این قانون شما رو ترغیب به استفاده مجدد از کلاسها و کدهای موجود میکنه. بر این اساس، شما هر چه "داده های کمتری" رو در برنامه خودتون لمس کنید، Performance برنامه شما بالاتر خواهد رفت. این مساله فقط محدود به کد نویسی نمیشه! بطور مثال هنگامیکه دارید جدولی رو برای بانک RDBMS خودتون طراحی می کنید، این سوال رو از خودتون بپرسید که "آیا میتونم مساله رو خیلی متناسب بدون طراحی این جدول، حل کنم؟" و اگر پاسخ مثبت بود، حتما اینکارو کنید. جدول جدید، یعنی نیروی کار اضافی. یعنی پیچیدگی در لایه های دیگه نرم افزار و ... بنابراین KISS!

    یکی دیگه از مسائلی که اینجا باید بهش اشاره کرد، تحلیل و یافتن منشاء اصلی مشکل هنگامی هستش که با یک خطا مواجه میشیم. همونطور که مستحضرید، در سایت برنامه نویس عموما سوالاتی مطرح میشه که فرسنگها از سوال اصلی فاصله گرفته. من وقتی تو برنامه خودم بواسطه دسترسی غیر مجاز از یک Thread به UI Control ای که در Thread دیگه ای ایجاد شده، خطای InvalidOperationException رو میگیرم، باید ببینم این خطا به چه معناست و چرا بوجود اومده نه اینکه با Set کردن یه Flag در کلاسم روی این خطا در پوش بذارم. وقتی شما این بدنبال منشاء خطا نمیرید، اون خطا جای دیگه و به طریق دیگه یقه شما رو میگیره. اینها رو گفتم تا با Root Cause Analysis آشنا بشید و در ادامه صحبتهام، مسیری به Exception ها باز کرده باشم.

    در ابتدای صحبتهام در این گفتگو، خدمتتون عرض کردم که تعامل با خطاها بخشی از نگارش یک کد خوب رو تشکیل میده. بعنوان یک قانون کلی، شما باید Exception های خاص رو بگیرید. علاوه بر اینکه نوشتن catch(Exception) بدلیل Corrupted State Exceptions بیشتر از اونی که تصور کنید خطرناکه، بلکه اینکار نیز گذاشتن در پوش روی خطایی هستش که رخ داده و همونطور که گفتم بعدا تو یه بازه زمانی دیگه (در runtime) به سراغتون میاد و شما رو به زانو در میاره.

    شما از Exception ها نباید برای کنترل جریان برنامه استفاده کنید. به عنوان نمونه جای اینکه از DateTime.TryParse برای Parse کردن یک رشته استفاده کنید، بیایید و رشته مورد نظر خودتون رو Parse کنید، بعد یه catch بذارید که اگر throw کردش متوجه بشید که رشته مزبور، تاریخ نبوده! این کار بر اساس الگوها، نه تنها اشتباه هستش، بلکه لطمه شدیدی به Performance برنامه میزنه.

    بسیار خوب. با در دست داشتن این اطلاعات، اجازه بدید تا بصورت خیلی گذرا نیز نگاهی به Unit Testing و تاثیر اون روی نوشتن یک کد خوب داشته باشیم. چون هیچ گفتاری در مورد نوشتن یک کد خوب، بدون صحبت کردن در مورد Unit Test کامل نیست.

    Unit Test چیه و هدف از نوشتن این Unit ها چی هستش؟ Unit Test به مجموعه توابعی گفته میشه که صحت اجرای بخش کوچکی از سیستم نرم افزاری در حال توسعه رو مورد آزمایش قرار میده. این توابع ممکنه توسط خود برنامه نویس نوشته بشه و میتونه در شرکتهای بزرگتر، به Tester ها سپرده بشه. اما چرا بی جهت وقت بذاریم همچین Unit هایی بنویسیم؟ چرا وقتی رو که میتونم صرف نوشتن یک Unit Test کنیم، صرف Production Code نکنیم؟

    سیستم نرم افزاری ای رو در نظر بگیرید که به مرور زمان تغییراتی در این سیستم رخ میده. کدی در Base Class ای تغییر میکنه، مقدار یک Constant کم و زیاد میشه و ... تا به سمت بهینه شدن پیش بره. هر کدوم از این تغییرات، ممکنه بخش مربوطه، یا بخشهایی دیگه از این سیستم رو از کار بندازه و مستلزم صرف ساعتها وقت برای آزمایش و بررسی کد، پس از اعمال هر تغییر کوچک در برنامه هستش. برای جلوگیری از چنین شرایطی و عدم مواجه با شرایط از پیش تعیین نشده، بهتره تا Unit Test هامون رو یک گام جلوتر از Production Code بنویسیم. بله! درست شنیدید. Test Code دقیقا به همون اندازه Production Code اهمیت داره، و باید در موردش فکر بشه و با برنامه انجام بشه.

    توسعه Unit Test ها خودش به شیوه های متفاوتی انجام میگیره: TDD، DDT، POUTing و ... توضیح هر یک از این روشها از حوصله این گفتگو خارجه. فعلا در این حد به خاطر بسپارید که کد خوب، کدی هستش که آزمون پذیر باشه و از قانون FIRST طبعیت کنه. FIRST حروف اولیه این عبارات هستن:

    • Fast: آزمایش باید سریع انجام بگیره. اگر آزمایش زمان بر باشه، احتمالا علاقه به اجرای اون کم و کمتر میشه و این خودش نوشتن Unit Test ها رو در هاله ای از ابهام فرو میبره.
    • Independent: آزمایشها نباید به یکدیگر وابسته باشن و هر آزمایشی باید بطور مجزا قابل انجام باشه.
    • Repeatable: آزمایشات باید در محیطهای اجرایی متفاوت، قابل تکرار باشن تا بشه اونها رو دائما در فواصل مختلف و در شرایط اجرایی متفاوت، اجرا کرد.
    • Self-Validating: آزمایشات باید یه مقدار Boolean برگردونن، True یا False، اولی به این معنا که آزمایش با موفقیت انجام شد و دومی یعنی اینکه آزمایش پاس نشده.
    • Timely: آزمایشات باید از نظر زمانی، حتما جلوتر از Production Code نوشته بشن، چرا که اگر این اتفاق نیفته ممکنه شما قادر به نوشتن Unit Test (بدلیل پیچیدگی Production Code) نباشید.

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

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



    (اگر منبعی رو فراموش کرده باشم، بعدا به این پست اضافه خواهم کرد).

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

    موفق باشید.

  4. #44

    نقل قول: گفتگوی فنی شماره یک - اصول و قواعد کد نویسی

    خب ، ممنون از آقایان موسوی و مداح و همینطور عزیزانی که این بحث رو دنبال کردند و سوال پرسیدند و پیشنهاداتشون رو ارائه دادن. گفتگوی فنی شمارۀ یک به اتمام رسید. منتظر گفتگوهای فنی بعدی باشید
    We work in the dark, we do what we can, we give what we have.
    Our doubt is our passion and our passion is our task.
    The rest is the madness of art

صفحه 2 از 2 اولاول 12

برچسب های این تاپیک

قوانین ایجاد تاپیک در تالار

  • شما نمی توانید تاپیک جدید ایجاد کنید
  • شما نمی توانید به تاپیک ها پاسخ دهید
  • شما نمی توانید ضمیمه ارسال کنید
  • شما نمی توانید پاسخ هایتان را ویرایش کنید
  •