PDA

View Full Version : جلوگیری از تداخل نامها



freeman99
سه شنبه 12 اسفند 1393, 19:59 عصر
فکر کنم بالاخره تصمیم گرفتم و دارم شروع میکنم که پروژهء سیستم رجستر و لاگین (http://barnamenevis.org/showthread.php?335895-%DB%8C%DA%A9-%D9%BE%D8%B1%D9%88%DA%98%D9%87%D8%A1-%D8%B3%DB%8C%D8%B3%D8%AA%D9%85-%D8%B1%D8%AC%DB%8C%D8%B3%D8%AA%D8%B1-%D9%88-%D9%84%D8%A7%DA%AF%DB%8C%D9%86-%D8%A8%D8%A7%D8%B2%D9%85%D8%AA%D9%86&highlight=%D8%B1%D8%AC%DB%8C%D8%B3%D8%AA%D8%B1) خودم رو کامل تر کنم.
یکی از نیازهایی که در همین نگاه اول بنظرم رسید اینه که چون این پروژه میخواد در پروژه های مستقل دیگری استفاده بشه و به اصطلاح با اونا Integrate بشه، باید یه کاری بکنم که یوقت نام Identifier های برنامهء من با نام Identifier های برنامه های دیگر یکسان نباشه و خطا یا باگ پنهان بوجود نیاد. مثلا نام متغییرهای کانفیگ زیادی که دارم، نام توابع، کلاسها، متغییرهای عادی و غیره.
اولین راه حلی که بنظر من رسید اینه که به ابتدای نام تمام Identifier برنامم یک پیشوند reg8log اضافه کنم. این راه ساده و موثری بنظر میرسه و ضمنا چیزی هست که ظاهرا در بقیهء پروژه های نرم افزاری هم بصورت گسترده تاحالا استفاده شده. مثلا در خیلی از کتابخانه های برنامه نویسی شما میبینید که ابتدای نام کلاسها و خیلی دیگر از Identifier های اونا رو با پیشوند مخصوص خودشون Prefix کردن. مثلا اولین چیزی در این مورد که یاد من اومد کتابخانهء Qt است که ابتدای نام تمام کلاسهاش Qt داره. خیلی از کتابخانه های دیگر هم به همین شکل هستن. تاجاییکه میدونم، اگر نگیم تنها دلیل، ولی حداقل یکی از دلایل اصلی این امر، همون جلوگیری از تداخل نامهاست.

خب بنظر شما این روش درستیه و مشکلی نداره؟
گفتم شاید روشهای دیگری رو دیده باشید و پیشنهاد کنید.
البته اگر ما همه چیز را تا میتونیم به شکل کلاس و شیء دربیاریم، طبیعتا خیلی از متغییرهایی که قبلا در حوزهء گلوبال یا حوزهء بزرگتری بودن داخل کلاسها میرن و تعداد این Identifier هایی که دارای حوزهء قابل تداخل با کدهای دیگر هستن کاهش پیدا میکنه، ولی هیچوقت به صفر نمیرسه (مثلا اسم کلاس خودش یک Identifier است)، و ضمنا من نمیخوام فقط به این خاطر کلاس و شیء تعریف و استفاده کنم و نمیخوام از همین ابتدا خودم رو به پیروی از یک روش خاص مجبور کنم. فعلا میخوام به مرور پروژه رو کاملتر و بهتر کنم و از موارد ضروری و مهمترین ها شروع کنم.

H:Shojaei
سه شنبه 12 اسفند 1393, 20:50 عصر
به نظر من شی گراش کنید بعد این کارها رو انجام بدین...
من یه بار اومدم پروژه رو زیرو رو کنم ببینم میتونم که استفادش کنم (منظور از زیرو رو کردن بفهمم چکار میکنه) ولی اینقدر گیج شدم که گذاشتمش کنار!! و همیشه میگم سر یه تایم خواص که 1 یا 2 روز کامل بیکار بودم میرم سراغش ازش سر در بیارم که هنوز وقت نشده...
توانایی های شما در زمینه امنیت به کسایی که میشناسنتون پوشیده نیست ولی کاری که میکنید اگر کسی نتونه استفاده کنه یا بفهمه چکار کردین فکر نکنم فایده ای باشه...
یکی از روش شما خبر نداشته باشه و پروژه رو ببینه فکر میکنه عمدا پیچیده برنامه نوشتین که کسی نتونه به شیوه و روشش دست پیدا کنه... در صورتی که این رو همونطور که گفتید واسه استفاده همه و متن باز نوشتید...

freeman99
سه شنبه 12 اسفند 1393, 21:17 عصر
تاجاییکه میدونم و خودم هم در عمل تاجاییکه دیدم و به نظرم میرسه، درسته شیء گرایی در خیلی موارد میتونه پیچیدگی کد رو کاهش بده و خوانایی رو زیاد کنه، ولی این مطلب بصورت دقیق درمورد تمام برنامه ها و همهء شرایط و ساختارها در یک حد خاص و لزوما زیاد نیست (و معیار و فرمول روشن و دقیقی هم برای اثبات و محاسبهء اون ندیدم تاحالا). گاهی حتی از جهاتی شیء گرایی میتونه بعضی موارد رو پیچیده تر هم بکنه - اینو از خودم نمیگم و در منابعی خوندم ولی بعضی موارد هم خودم دیدم.

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

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

یک بخش از پیچیدگی برنامهء بنده و غیرقابل فهم بودنش بخاطر اینه که کلا منطق و الگوریتم ها و جزییاتش زیاد و پیچیده هستن و اینو به این راحتی نمیشه کاریش کرد. این بخاطر جزییات و انعطاف زیاد و الگوریتم های دقیق درونی و بخشی هم بخاطر استفاده از متدهای امنیتی و رمزنگاری پیشرفته است (شما مثلا یک کتابخانهء رمزنگاری پیشرفته مثل crypto++ رو بررسی کنید باوجود اینکه با شکل شیء گرایی کامل و قشنگی طراحی شده اما بهرحال نمیتونه پیچیدگی و جزییات و ظرافت های رمزنگاری رو از یک حداقلی که بازم نیاز به دانش و احاطه در این زمینه داره کم کنه). البته شیء گرایی روش کار کنم شاید بتونم بهترش کنم، ولی مطمئن باشید هنوزم بطور قابل توجهی پیچیده خواهد بود، چون منطق و الگوریتم ها پیچیده و مفصل و دقیق هستن (مثلا تعداد و ساختار جدول های این برنامه رو بررسی کنید و فکر کنید تعداد زیاد جدول ها و فیلدها و پیچیدگی اونا بخاطر چیه! فکر نمیکنم بخاطر عدم استفاده از شیء گرایی باشه!!). البته اگر منظور این باشه که تمام کدها و الگوریتمش رو کسی بخواد بررسی کنه و بفهمه، وگرنه اگر در حد API و صرفا این باشه که کسی در پروژش بخواد اون رو Integrate کنه که اونقدرها هم سخت نیست و اگر مقدار کافی روی این بخش کار بشه و مستندات بیشتری هم براش درست بشه در این زمینه فکر کنم این مشکل تا حد زیادی برطرف میشه؛ حالا زیاد مهم نیست کدهای پشت پرده شیء گرا باشن یا MVC و یا غیره، همونطور که شما نگاه کنید مثلا وردپرس ساختار کاملا شیء گرا نداره ولی با این حال فهم و استفاده از API های اون اصلا سخت نیست (من خودم قبلا رفرنسش رو خوندم و کار هم کردم باهاش) و تازه تاجاییکه من دیدم و شنیدم، یادگیری اولیه سیستمهایی که شیء گرا هستن مقداری دشوارتر هم هست (چون اصول و جزییات و استانداردهای بیشتری دارن)، ولی بعدش برای توسعه و سفارشی سازی شاید راحتتر باشه (اما پروژهء بنده هم که هدف اولش توسعه و تغییر توسط دیگران نیست چون هنوز به اون سطح از استفاده و محک خوردن و شهرت نرسیده).

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

H:Shojaei
سه شنبه 12 اسفند 1393, 21:59 عصر
باید همین روزا یه نگاه دیگه بندازم شاید نگاهم نسبت به یک سال پیش فرق کرده باشه...!
حرفاتون درسته و متین ولی فرض کنید پروژه که متن بازه یک نفر بخواد تغییرات تو یه بخش ایجاد کنه باید به روش شما اول تو طراحی برنامه پی ببره بعد ببینه کجا ها رو باید تغییرات بده!
ولی اگر شی گرا باشه هر تابع عمل خواصی رو انجام میده یه نگاه به مستندات میندازه تابع یا توابع مربوطه رو پیدا میکنه تغییر میده...
تو یه پروژه عمومی شی گرایی مزایاش نسبت به معایبش بیشتره (البته استثنا هم هست ولی این مورد فکر نکنم جزء استثنا ها باشه...)

freeman99
سه شنبه 12 اسفند 1393, 22:46 عصر
پروژه که متن بازه یک نفر بخواد تغییر
ات تو یه بخش ایجاد کنه باید به روش شما اول تو طراحی برنامه پی ببره بعد ببینه کجا ها رو باید تغییرات بده!
زیادم سخت نیست. یعنی بنظر من با شیء گرایی خیلی اختلاف نداره. ولی بازم اونقدر سخته که درحال حاضر اهمیتی نداره!!
هر برنامه نویسی که بتونه شیء گرایی رو بفهمه قاعدتا ساختارهای ساده تر و قدیمی تر رو هم میتونه کشف کنه و بفهمه.
ولی فعلا من خودم یکی فقط از پس منطق و الگوریتم های برنامم برمیام! کسی سوادش رو هم داشته باشه باز انگیزه و شرایط دیگر هم میخواد که احتمال زیادی نمیدم همچین شخصی پیدا بشه بخواد روی پروژهء من کار کنه. ولی اگر به مرحلهء قابل استفاده برسونمش و در عمل شناخته بشه اونوقت ممکنه کسانی به فکر توسعه دادنش هم بیفتن.


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

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

MMSHFE
چهارشنبه 13 اسفند 1393, 09:44 صبح
شئ گرایی فقط 4 تا کلاس نیست. امتیازات خیلی خوبی در اختیارتون میگذاره که میشه از اونها استفاده کنید. یکی از این امتیازات namespace هست که اجازه میده کلاسها و متدهای همنام (ولی توی فضاهای نام مختلف) ایجاد کرد. برای مثال:
این یک فایل:

namespace Ahmad;
class Hello { ... }
اینم یک فایل دیگه:

namespace Ali;
class Hello { ... }
اینم نحوه استفاده:

require_once ahmad.php;
require_once ali.php;
$hello1 = new Ahmad\Hello;
$hello2 = new Ali\Hello;
یا اینطوری:

use Ahmad\Hello as HelloAhmad;
use Ali\Hello as HelloAli;
$hello1 = new HelloAhmad;
$hello2 = new HelloAli;
به این ویژگیها، ارث بری (قراردادن کدهای مشترک در کلاس والد و مشتق شدن کلاسهای فرزند از اونها و صرفاً قراردادن تفاوتها در کلاسهای فرزند) و رابطها (ایجاد استاندارد برای کلاسها) و موارد متعدد دیگه مثل Lazy Load (بارگذاری فایل در اولین استفاده بطور خودکار) رو هم اضافه کنید.

انصافاً انجام کار بزرگ با برنامه نویسی به روش رویه گرا چیزی بجز عذاب نیست. تازه میتونین با کمک ابزارهایی مثل PHPDoc بیاین و برای اسکریپتتون مستندات HTML بسازین (از روی همون کامنتهایی که ننوشتین!) و خودش براساس namespaceها پوشه بندی میکنه و حتی براساس وراثت کلاسها، گراف ارتباط بین کلاسها رو هم براتون میسازه. بد نیست نگاهتون رو نسبت به شئ گرایی کمی اصلاح کنید.

freeman99
چهارشنبه 13 اسفند 1393, 11:48 صبح
ارث بری (قراردادن کدهای مشترک در کلاس والد و مشتق شدن کلاسهای فرزند از اونها و صرفاً قراردادن تفاوتها در کلاسهای فرزند) و رابطها (ایجاد استاندارد برای کلاسها)
اینا رو همه زیادتر از چیزی که واقعا کاربرد داره تبلیغ میکنن! همش میگن ارث بری، ولی مثال واقعی و عملیش که ضرورت و فواید بزرگ اونو عملا و به وضوح ثابت کنه کسی ارائه نمیکنه.
البته در بعضی جاها ارث بری دیدم بد نیست خوبه، ولی توی خیلی برنامه ها هم ندیدم به اون صورت و بنظر هم نمیاد اصولا نیاز و فایدهء زیادی درش باشه. شاید در برنامه های خاصی اینطور باشه.
مثلا در DVD آموزشی خودتون من ندیدم به اون صورت از ارث بری استفادهء ضروری و خیلی مفیدی بکنید در نمونه پروژه هایی که انجامشون دادید. شاید چون اصولا ساختار سلسله مراتبی اونقدر گسترده و پیچیده درشون وجود نداره. اصولا فکر نمیکنم زیاد در PHP و برنامه نویسی وب عادی کاربرد داشته باشه. با توجه به چیزایی که تاحالا دیدم فکر میکنم ارث بری بیشتر در زبانها و کتابخانه هایی مثل سی++ و سطح پایین تر کاربرد مفید داره. تازه اونم خیلی وقتا ارث بری چندگانه است و در اینکه ارث بری غیرچندگانه چقدر میتونه با ارث بری چندگانه برابری بکنه و کاربرد و فایده داشته باشه شک دارم.
اینترفیس هم باز به همین شکل. مثلا شما خودتون در مثال و پروژه ای که انجام دادید درسته استفاده کردید ولی در عمل بیشتر نمایشی یا آموزشی سینتاکس بود و من شخصا ضرورت و فایدء بزرگی درش متوجه نشدم جز اینکه مجبور بودید مدام کد اضافه تر بنویسید و کلاسها رو با اینترفیس مربوطه تطبیق بدید، و فکر کنم یه جاهایی هم بیشتر وصله و پینه کردید واسه این کار که صرفا طبق یه اینترفیس خاصی باشه فلان کلاسها که بنظر من بدون اینترفیس بهتر بود و دلیل و فایدهء روشنی برای تعریف و تقید به اینترفیس خاصی ندیدم.
مگر اینکه پروژه واقعا بزرگ و پیچیده باشه که اونوقت این مزایا برجسته تر بشن و استفاده عملی ازشون در عمل خیلی مفید باشه. ولی پروژهء من فکر نمیکنم باوجود حجمش ساختاری داشته باشه که بتونه از این جنبه ها و مزایا استفادهء زیادی بکنه.

MMSHFE
چهارشنبه 13 اسفند 1393, 12:09 عصر
نه این طرز فکر بنظرم اشتباهه. ببینید توی پروژه های کوچکی که توی پکیج مقدماتی مطرح میشه شاید کاربردش به چشم نیاد و اصلاً نیازی نباشه ولی توی پروژه های بزرگ قطعاً بهش احتیاج پیدا میکنید. توی پکیج پیشرفته خیلی جاها از وراثت استفاده شده. خیلی جاها با کمک رابطها میایم کار میکنیم. توی کارهای تیمی قطعاً وجود استاندارد برای طراحی و کدنویسی لازمه و چی بهتر از رابط میتونه این استاندارد رو فراهم کنه؟ کافیه با instanceof چک کنید ببینید کلاس مربوطه، رابط رو پیاده سازی کرده یا نه و بعد با خیال راحت میتونید از متدهایی که توی رابط معرفی کردین، روی اشیاء اون کلاس به همون شکلی که ساختارش رو توی رابط مشخص کردین استفاده کنید چون مطمئنید که کلاس مربوطه اونها رو پیاده سازی کرده (وگرنه خطای Runtime میگیرین). خود همین پروژه لاگین شما وقتی قراره با بخشهای دیگه همکاری کنه، یکی از مشکلاتش که بهش برخوردین، مسئله تداخل نامها بوده که با کمک فضاهای نام قابل حله. مشکل دیگه اینه که کلاس شما باید با استانداردهای موجود در پروژه دیگه همخوانی داشته باشه. بخصوص وقتی دارین تیمی کار میکنید. برای مثال مدیر پروژه میگه که همه کلاسها باید یک متد داشته باشن که شئ مربوطه رو بصورت JSON برمیگردونه. خوب اینجا میشه یه رابط طراحی کرد و همه کلاسها رو ملزم کرد که اون رو implement کنن و اگه کلاسی اون رو پیاده سازی نکرده باشه (چک کردن با instanceof) اصلاً توی پروژه بارگذاری نشه (فرضاً ماژولش Load نشه) یا هر کار دیگه.
مطمئنم توی پروژه خودتون هم اگه به عناصر اون به دید شئ نگاه کنید، منطق کار خیلی راحتتر خواهد شد. مثلاً یک کلاس برای دریافت اطلاعات از دیتابیس بگذارین و یک کلاس برای اعتبارسنجی و یا هر کار دیگه که خودتون بهتر میدونید چون بیشتر در جریان جزئیات هستین. فقط کافیه دیدتون رو به مسئله، شئ گرا کنید چون این الگو اومده که زندگی رو برای برنامه نویسها راحتتر کنه و قطعاً یک موضوع بلا استفاده و تفریحی نبوده. امتیاز ویژه شئ گرایی هم قابلیت استفاده مجدد هست (مثلاً یکی از کلاسهای برنامه رو بردارین ببرین توی یک پروژه دیگه استفاده کنید یا یک کلاس دیگه ازش مشتق کنید و متدهای خاصی رو بازنویسی کنید و اونوقت اشیاء ایجادشده از کلاس والد با صدازدن اون متدها به شکل متفاوتی نسبت به اشیاء ایجاد شده از کلاس فرزند کار میکنن - مفهوم Polymorphism در شئ گرایی).

همیشه کد کوتاه تر به معنای کد بهینه تر نیست. بخصوص با کمک قابلیتهایی مثل OPCache توی PHP که میشه اسکریپتهای بزرگ رو یکبار پردازش و کش کرد و از اون به بعد، فقط بهینگی و قابلیت استفاده مجدد از کدها و خوانایی و سهولت در تغییر و پشتیبانی و... اهمیت پیدا میکنن. اگه اینطور باشه، لابد باید بگیم چه نیازی به Test Driven Development داریم؟ چرا دردسر بکشیم و کلی Unit Test و Functional Test بنویسیم؟ ما که میدونیم کدمون داره کار میکنه. اما مشکل از اونجایی شروع میشه که بخواین توی فاز پشتیبانی کدها رو عوض کنید و فرضاً بجای MySQL با Oracle یا Apache Cassandra کار کنید. اینجاست که Test Unit ها بدرد میخورن. کافیه تست رو اجرا کنید و ببینید روی کد جدید هم همون نتیجه قبلی رو میده یا نه. توی پروژه ای که میلیونها رکورد داده داره و توی مرحله Production هست، دیگه نمیشه تست رو روی داده های واقعی انجام داد. Backup گرفتن از میلیونها رکورد هم خیلی جاها مقرون به صرفه نیست. اگه کد جدید درست کار نکنه ممکنه رکوردها رو خراب کنه و این مسائل قابل جبران نیستن.

بهرصورت هدف پکیج مقدماتی هم همین آموزش Syntax بوده و توی پکیج پیشرفته با 40 پروژه کوچک و بزرگ، کاربردهای اون Syntaxهایی که توی پکیج مقدماتی توضیح دادم در عمل توی محیط Production نشون داده میشه.