PDA

View Full Version : سوال: فریمورک مورد توصیه



hannanstd
دوشنبه 03 فروردین 1394, 00:39 صبح
سلام .
من تقریبا با اصول پایه ای php آشنا هستم و تا الان هر چی خواستم رو تونستم خودم بنویسم ولی جدیدا میخوام به صورت حرفه ای روی یکی از فریمورک های PHP تمرکز کنم .

اما خب مزایا و معایب هر فریمورک رو که بررسی کردم بین Yii و Codeignator شک دارم . حالا شاید بهتر از این 2 تا هم باشن .

ممنون میشم یه راهنمایی بکنید و فریمورک برتر رو معرفی کنید . میدونم که کلمه برتر کلمه غلطیه و همه چی نسبی هست .

ولی بیشتر برای کار با وب سرویس ها و پرداخت آنلاین و ... میخواستم فریمورکم رو انتخاب کنم .

Unique
دوشنبه 03 فروردین 1394, 15:03 عصر
فریم وورک ه ابه نظر من دست و پا گیر هستند و سر بار اضافه ایجاد میکنند و در کل performance را پایین میارن ! فریم وورک را فقط در شرایطی که قرار هست تیمی کار کنیم پیشنهاد میکنم اگر چه اون تیم هم با استفاده از کلاس ها و شی گرایی میتونن تدال را به حداقل برسونن.

arash691
دوشنبه 03 فروردین 1394, 16:33 عصر
اگه پروژه هات زیادی پیچیده نیستن و تنهایی کار میکنی میتونی یکسری کلاس بنویسی ( برای هر چیزی که فکر میکنی سرعت کارت رو بالاتر میبره ) بعدش از همونا استفاده بکنی اگه هم حوصله داشتی میتونی خودت روتر بنویسی و MVC کار کنی خوبیش اینه که همه چیزش دسته خودته زیاد هم زمان نمیبره میشه 1 ماهه یچی برای خودت بنویسی . اگه حوصله نداری از codeignator استفاده بکن سبک و راحت ، اموزشش هم توسط یکی از بچه های برنامه نویس تهیه شده جستجو کن پیداش میکنی ، Yii , Laravel , Zend , Phalcon اینا هم برای کارهای بزرگتر و گروهی بنظرم خوبن ... در کل همه چیز به خودت بستگی داره خیلی ها رو هم میشناسم اصلا" با فریمورک ها کار نمی کنن و خام کد میزنن

rezakho
سه شنبه 04 فروردین 1394, 01:56 صبح
Unique (http://barnamenevis.org/member.php?11933-Unique) جان، با عرض معذرت، می خوام یکم انتقادی صحبت کنم، البته سر صحبتم با شما نیست و مطلبم کلی هست، منتها چون مطلبم خلاف نظر شماست گفتم بگم که سوءتفاهم نشه. و البته مخاطب حرفهام، در درجه اول خودم هستم و بعد دیگران

خوشبختانه! یادگیری زبان php ویژگی هایی داره که زبان هایی مثل ASP.NET و حتی JSP فاقد این ویژگی ها هستند.

چون برای این زبان فریمورک پیشفرض و IDE های ویژوال مناسب و همه گیری وجود نداره یا حداقل مرسوم نیستند، برای یادگیری این زبان باید خیلی از مبانی،اصول، پروتکل ها و ... اینترنت و وب رو ابتدا آموخت،
باید html رو خوب فهمید،
باید با روش ارسال داده ها در انواع متدهای HTTP آشنا بود،
باید با طرز کار فرم ها آشنا بود،
باید به درستی مفهوم زبان توکار و سمت سرور رو درک کرد،
باید با نحوه پیکربندی وب سرور و نحوه ارتباطش با php آشنا شد
و در کل ظرفیت این هست که با چم و خم اینترنت و وب به خوبی آشنا شد.

در بازار کار هم حتی، بخوبی میشه سطح اطلاعات زیربنایی php کارها با توسعه دهنده های سایر زبان ها رو احساس کرد.

اما!

حالا با این شرایط و سطح اطلاعات، چرا کدهای اکثر php کارها، اینقدر بی نظم و نا مفهوم و به قول دوستم، آبگوشتی! و کثیف هست؟
چرا پروژه هامون اینقدر سفت و سخت هستند و تقریبا هیچ انعطافی برای تغییر و توسعه در آینده ندارند؟!
چرا اینقدر ناپایدارند و پر از اشکال و باگ اند؟!
چرا نمیشه تیمی کار کرد و یا به سختی کار تیمی پیش میره؟!
چرا پروژه ها به پایان نمی رسند و انگار نقطه پایانی براشون نمیشه متصور شد؟!
چرا اینقدر تغییرات در حین اجرای پروژه زیاده؟!
چرا مشتری و گاها حتی خودمون از پروژه ها راضی نیستیم؟!
چرا هزینه پیش بینی شده و زمانبندی ها اغلب درست از آب در نمیاد؟!
چرا به تعداد انگشتان یک دست پروژه های اوپن سورس و عام المنفعه با سطح کیفی متوسط حتی نداریم؟؟؟ حتی پروژه های تجاری هم خیلی هاشون به همین منوالند! کافیه نگاهی به api های سرویس های sms و درگاه های پرداخت بانک ها بندازید!
و هزار چرای دیگه!

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

شاید اهم دلایل این ها باشه که:

php کارها سبک و سیاق مشخصی در کد زدن ندارند، گاهی رویه گرا، گاهی شی گرا، گاهی ترکیبی و گاهی به شکلی که حتی نمیشه بهش سبک گفت کد میزنند!
اغلب از فریمورک استفاده نمی کنند، یا اگر استفاده می کنند، باز هم سبک خودشان بر سبک فریمورک غلبه داره
اکثرا ابزارهای مرسوم کدنویسی مثل کنترل ورژن ها و روش های توسعه را اصلا نمی شناسند! و حتی اسمشون رو نشنیده اند
بروز نیستند و به نوعی با تنبلی سر و سری دارند
از کار تیمی بیزار و فراریند، که برخی دلایلش به شخصیت افراد و البته بیشترش به عذاب تیمی کار کردن بدون الزامات، بر میگرده
و ...

و اما هدف من از این مباحث!

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

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

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

Unique
سه شنبه 04 فروردین 1394, 13:36 عصر
Unique جان، با عرض معذرت، می خوام یکم انتقادی صحبت کنم، البته سر صحبتم با شما نیست و مطلبم کلی هست، منتها چون مطلبم خلاف نظر شماست گفتم بگم که سوءتفاهم نشه. و البته مخاطب حرفهام، در درجه اول خودم هستم و بعد دیگران

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


حالا با این شرایط و سطح اطلاعات، چرا کدهای اکثر php کارها، اینقدر بی نظم و نا مفهوم و به قول دوستم، آبگوشتی! و کثیف هست؟
تا حالا آبگوشتی را نشنیدم اما کد ماکارونی در مورد php کاملا صادق هست چون بالاخره باید بین html کد بزنی یا از template ها استفاده کنی که در آخر چیزی شبیه به ماکارونی داریم و خیلی سخت میشه این دو را از هم جدا کرد و دلیلش اینه که داریم html تولید میکنیم. حالا توی net. این موضوع به این شکل و سیاق وجود نداره و اگه واقعا Code Behind کار کنیم کافیه فقط بالای صفحه به کلاس مرتبط با صفحه ارجاع بدیم و بس !


چرا پروژه هامون اینقدر سفت و سخت هستند و تقریبا هیچ انعطافی برای تغییر و توسعه در آینده ندارند؟!
راستش به شخصه تا حالا نشده یک پرو‌ژه قدیمی را نتونم توسعه بدم ، برخی مواقع پیش میاد که یک پروژه به دلیل عدم اگاهی از یک سری موضوعات امنیتی یا تکنیک هایی که به تازگی یاد گرفتیم یا تکنولوژی های جدید نیاز به دوباره نویسی داشته باشه (مثلا سال ۸۴ خبری از jquery و ajax نبود). اما اینکه مثلا پروژه یکی دو سال پیش را نتونیم توسعه بدیم حرف درستی نیست.


چرا اینقدر ناپایدارند و پر از اشکال و باگ اند؟!
این به مهارت و تجربه کدنویس بر میگرده ، در این مورد framework میتونه کمک کنه. مثلا ممکنه یک framework بدون اینکه برنامه نویس متوجه باشه اون را در مقابل حملات SQL injection یا XSS محافظت کنه یا برای انجام کار های روتین مثل کار با پایگاه داده ، اعتبارسنجی داده ها و ... از روش های بهینه تری استفاده کنه. در این مورد هر چی برنامه نویس تجربه و مهارت کمتری داشته باشه framework میتونه این مشکل را رفع کنه و تاثیر مثبت داره.


چرا نمیشه تیمی کار کرد و یا به سختی کار تیمی پیش میره؟!
راستش در این زمبنه آدم بی تجربه ای هستم چون خیلی آدم تک رویی هستم و کار انفرادی را به تیمی ترجیح میدم و تجربه آنچنانی در این زمینه ندارم اما وقتی از framework ها استفاده کنیم چون داریم از یک اصول و قوائد مشخص استفاده میکنیم در نتیجه کار تیمی راحت تر میشه.


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


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


چرا به تعداد انگشتان یک دست پروژه های اوپن سورس و عام المنفعه با سطح کیفی متوسط حتی نداریم؟؟؟
توی ایران با توجه به شرابط اجتماعی و اقتصادی فرهنگش وجود نداره و کلا جایی براش نیست.


حتی پروژه های تجاری هم خیلی هاشون به همین منوالند! کافیه نگاهی به api های سرویس های sms و درگاه های پرداخت بانک ها بندازید!
نمیشه گفت همه بروژه ها بد هستند اما چون معیار انتخاب در ایران شایسته سالاری نیست و پارتی بازی و باند بازی به شدت وجود داره در نتیجه چنین مشکلاتی هست ، مثلا همین نرم افزار گلستان که توی دانشگاه ها هست را ببینید ، واقعا فکر میکنید کسی نمیتونه بهتر و کاربردی تر از این بنویسه ؟ البته که میشه اما متاسفانه به خاطر انحصار گری و باند بازی چون نتیجش معلوم نیست کسی پا پیش نمیگذاره

اما در کل من مشکل خاصی با framework ها ندارم ! از framework ها به چند دلیل استفاده نمیکنم :

۱ - خیلی از framework ها از معماری MVC استفاده میکنند که من کلا از این معماری زیاد خوشم نمیاد و ترجیح میدم از معمار یهای نرم افزاری دیگه استفاده کنم

۲ - چون این نرم افزار ها سورس باز هستند bug ها و security hole های اون ها زود رسانه ای میشه و باید همش حواست به بروزرسانی ها باشه ، این موضوع ذاتا بد نیست اما وقتی تعداد پروژه هات از ۲۰ یا ۳۰ تا گدشت و مجبور شدی برورسانی کنی و مشتری هم عموما حاضر نیست هزینه پشتیبانی بده اونوقت بی خیال میشی و سایتت در معرض حملات شناخته شده framework مورد استفاده قرار میگیره. در خیلی از این موارد شاید خصومت شخصی نباشه و یک bot بتونه سایت را آلوده کنه.

۳ - فکر کنید شما مدتی از یک framework استفاده کردین و ناگهان ادامه توسعه framework متوقف میشه یا گروه توسعه دهنده تصمیم میگیره کلا مسیر کار و روشش را عوض کنه (عموما backward compatibility هم وجود نداره) اونوقت باید پروژه هایی که شاید خیلی هم قدیمی نیستند دستخوش تغییرات زیاد بشن یا کلا بی خیالشون بشی که این هزینه و زمان میطلبه.

۴ - وقتی از یک framework خاص استفاده میکنی داری دور خودت خط قرمز میکشی ، مثلا فکر کن از zned استفاده میکنی و حالا میخوای پروژه را بفروشی یا واگذار کنی یا از افرادی برای توسعهش استفاده کنی ! شما نباید فقط دنبال برنامه نویس php بگردی ! باید دنبال برنامه نویس php مسلط به zend بگردی !

و موراد جزئی دیگه که نیاز به ابرازشون نیست ...

rezakho
سه شنبه 04 فروردین 1394, 14:49 عصر
اختیار دارین ، من خیلی هم دوست دارم که یکی نقدم کنه و اگه اشتباه میگم من را راهنمایی کنه و بتونیم با هم یک گفتگوی سازنده برای دو طرف داشته باشیم.
البته بازم می گم، سر صحبت من جامعه برنامه نویسی داخل کشور بود، نه شما!!!
ظاهرا شما خودت رو مخاطب مستقیم و واحد حرف های من گرفتی! از جواب ها که غالبا از طرف خودت جواب دادی اینطور به نظر میاد، جدا مخاطب حرفم شما نبودی!!!
نمی خواستم شما رو در مقام پاسخ قرار بدم عزیز

تا حالا آبگوشتی را نشنیدم اما کد ماکارونی در مورد php کاملا صادق هست چون بالاخره باید بین html کد بزنی یا از template ها استفاده کنی که در آخر چیزی شبیه به ماکارونی داریم و خیلی سخت میشه این دو را از هم جدا کرد و دلیلش اینه که داریم html تولید میکنیم. حالا توی net. این موضوع به این شکل و سیاق وجود نداره و اگه واقعا Code Behind کار کنیم کافیه فقط بالای صفحه به کلاس مرتبط با صفحه ارجاع بدیم و بس !
آبگوشتی اصطلاح مهندس شهرکی هست، همون اسپاگتی خودمونه :)
کدهای php هم میتونی مثل asp تمیز باشه، کمااینکه در mvc همه چیز شبیه همه و فقط زبان متفاوته! jsp هم همین قضیه براش صادقه، اونم توکار هست.
منظور من کدهای برنامه نویس(اونم برنامه نویس های غیر حرفه ای که بیشتر جمعیت برنامه نویس ها رو تشکلی میدن) هست، نه ذات php، و دلیلش رو هم برنامه نویس می دونم، می خوام بگم جامعه برنامه نویسی ما و با تجربه ها نیامدند اصولی و تمیز کد نوشتن رو رواج بدند و خود برنامه نویس ها هم علاقه ای به این کار نشون ندادند.

راستش به شخصه تا حالا نشده یک پرو‌ژه قدیمی را نتونم توسعه بدم ، برخی مواقع پیش میاد که یک پروژه به دلیل عدم اگاهی از یک سری موضوعات امنیتی یا تکنیک هایی که به تازگی یاد گرفتیم یا تکنولوژی های جدید نیاز به دوباره نویسی داشته باشه (مثلا سال ۸۴ خبری از jquery و ajax نبود). اما اینکه مثلا پروژه یکی دو سال پیش را نتونیم توسعه بدیم حرف درستی نیست.
باز هم منظورم شما نبودید و اشاره ام به اغلب برنامه های برنامه نویس های معمول بود، ضمن اینکه من منظورم از توسعه، تغییرات بزرگ توی برنامه هست، نه چند خط کد! مثلا یک سیستم فروشگاهی رو فرض کن که بعد از اجرا، قابلیت فیلتر و مقایسه فیلد به فیلد می خواد و از قضا، برنامه اصلا فیلد نداره و با json و serial اومده فیلد ها رو داخل یک سلول نگه داری کرده!

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

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

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

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

rezakho
سه شنبه 04 فروردین 1394, 15:03 عصر
و اما درباره این بند، که اینبار اتفاقا مخاطب اصلی خود شما هستی


اما در کل من مشکل خاصی با framework ها ندارم ! از framework ها به چند دلیل استفاده نمیکنم :

۱ - خیلی از framework ها از معماری MVC استفاده میکنند که من کلا از این معماری زیاد خوشم نمیاد و ترجیح میدم از معمار یهای نرم افزاری دیگه استفاده کنم

۲ - چون این نرم افزار ها سورس باز هستند bug ها و security hole های اون ها زود رسانه ای میشه و باید همش حواست به بروزرسانی ها باشه ، این موضوع ذاتا بد نیست اما وقتی تعداد پروژه هات از ۲۰ یا ۳۰ تا گدشت و مجبور شدی برورسانی کنی و مشتری هم عموما حاضر نیست هزینه پشتیبانی بده اونوقت بی خیال میشی و سایتت در معرض حملات شناخته شده framework مورد استفاده قرار میگیره. در خیلی از این موارد شاید خصومت شخصی نباشه و یک bot بتونه سایت را آلوده کنه.

۳ - فکر کنید شما مدتی از یک framework استفاده کردین و ناگهان ادامه توسعه framework متوقف میشه یا گروه توسعه دهنده تصمیم میگیره کلا مسیر کار و روشش را عوض کنه (عموما backward compatibility هم وجود نداره) اونوقت باید پروژه هایی که شاید خیلی هم قدیمی نیستند دستخوش تغییرات زیاد بشن یا کلا بی خیالشون بشی که این هزینه و زمان میطلبه.

۴ - وقتی از یک framework خاص استفاده میکنی داری دور خودت خط قرمز میکشی ، مثلا فکر کن از zned استفاده میکنی و حالا میخوای پروژه را بفروشی یا واگذار کنی یا از افرادی برای توسعهش استفاده کنی ! شما نباید فقط دنبال برنامه نویس php بگردی ! باید دنبال برنامه نویس php مسلط به zend بگردی !

و موراد جزئی دیگه که نیاز به ابرازشون نیست ...
1- کاملا سلیقه ای هست و حق دارید
2- همین اتفاق برای کلوز سورس ها و حتی خود php هم میافته! خوب اگر اوپن سورس باشه که زودتر patch اصلاح میاد تا کلوز سورس! حالا بحث مخفی کردن اطلاعات فریمورک از دید کاربران بمونه!
3- قرار هم نیست تا آخر روی یک فریمورک بمانیم، بالاخره هر کدوم طول عمری دارند مثل خود php، این جزو ذات پیشرفت هست، ضمن اینکه اکثر فریمورک ها طول زمان پشتیبانی دارند و وقتی مثلا نسخه جدید و متفاوت بیاد، قرار نیست نسخه قبلی بلافاصله از دور حذف بشه، میشه بر اساس اونها برنامه ریزی کرد، و همچنین، پروژه ای که مثلا با یی 1 نوشته شد، نیازی نیست به نسخه 2 بروز بشه؟! مگر در موارد خیلی خیلی خاص که نحوه upgrade رو قطعا ارائه خواهند داد.
4- هر مزییتی هزینه ای هم خواهد داشت، مثلا اگر شما از جوملا بخوای استفاده کنی، خوب طبیعتا باید جوملا کار داشته باشی، میشه ماهیت جوملا رو عوض کرد و ما همون php خام کار بمونیم؟!

Unique
سه شنبه 04 فروردین 1394, 17:41 عصر
البته بازم می گم، سر صحبت من جامعه برنامه نویسی داخل کشور بود، نه شما!!!
ظاهرا شما خودت رو مخاطب مستقیم و واحد حرف های من گرفتی! از جواب ها که غالبا از طرف خودت جواب دادی اینطور به نظر میاد، جدا مخاطب حرفم شما نبودی!!!
نمی خواستم شما رو در مقام پاسخ قرار بدم عزیز

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


کدهای php هم میتونی مثل asp تمیز باشه، کمااینکه در mvc همه چیز شبیه همه و فقط زبان متفاوته! jsp هم همین قضیه براش صادقه، اونم توکار هست.
در این مورد net. خیلی فرق داره ! من توی net. یک فایل dll داشتم و بس. حتی یک خط کد asp غیر از سطر اول که کلاس صفحه را مشخص میکرد توی فایل هام نبود ! یعنی یک طراح فقط نباید به id های تگ های سمت سرور من دست میزد. اما توی php دقیقا به این شکل نیست و بالاخره ماکارونی ، اسپاگتی یا ابگوشتی در حد خیلی خیلی خیلی کم بسته به تجربه و پیاده سازی خواهید داشت.


مثلا یک سیستم فروشگاهی رو فرض کن که بعد از اجرا، قابلیت فیلتر و مقایسه فیلد به فیلد می خواد و از قضا، برنامه اصلا فیلد نداره و با json و serial اومده فیلد ها رو داخل یک سلول نگه داری کرده!

به نظرم این موضوع مربوط به framework و کدنویسی نمیشه. مربوط به همون هدف گذاری و مهندسی نرم افزار میشه. serial کردن فیلد ها (که البته یک مثال هست) مثل چشم بند زدن هست و خیلی مشکلات به وجود میتونه بیاره و از اول اشتباه کار شده. من میگم اگه فقط جلوی پامون را نبینیم و موقع طراحی سیستم اصولی عمل کنیم نه سلیقه ای و راحت طلبی بعدا کار خودمون را برای گسترش سیستم راحت میکنیم. اما همین مشکل فیلد ها هم با یک برنامه search و replace قابل حله اما خوب زمان بیشتری میبره. در کل میخوام بگم مشکلات طراحی و مهندسی نرم افزار را گردن خام نویسی نندازیم.


خوب حالا چاره چیه؟!
مجری باید بعد از اینکه هدف گزاری کرد و نیازمندی های مشتری را بررسی و مستند سازی کرد و غیره ... بشیه کامل با کارفرما مسیر را چک کنه و حتی با پرسیدن مسخره ترین و ساده ترین سوالات مطمئن بشه که کارفرما همینو میخواد و لا غیر ! اگه هم میبینه توانش را نداره بگذاره یک همکار دیگه کار کنه و سوادش را بیشتر کنه.


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

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

درمورد پروژه های تجاری هم پروژه هایی که آدمهای کار بلد کار کردند و کارفرما ارزش کار خوب را میدونسته و هزینه کرده یا کلا گروه یا شخصی که کار خودش برنامه نویس هست کار آفرینی کرده موفق هستند. نمونه موفق کم نداریم. مگه سایت های کلوب یا آپارات یا جیب یا تخت گاز یا کافه بازار را نداریم !؟ خیلی از این ها هست. فقط digikala که نیست در کنارش بامیلو ، فینال ، زنبیل و غیره هم واقعا دارن کار میکنن ، حتی سایت های بازی ایرانی مثل mr90 هم خوب تونسته کار کنه.


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

کلا وقتی شما سورس بسته کار میکنید یعین سورس CMS مال خودتونه حتی اگه bug هم داشته باشین تا زمانی که ارزش کشف باگ نباشه برای شما اتفاقی نمیفته (منظورم باگهایی هست که نیاز به بررسی و کار داره نه مثلا sql injection) اما در مورد framework های سورس باز واقعا ارزش داره و چون عمومی منتشر میشه هم bot ها و هم افرادی که چشم دیدن شما را ندارن خیلی راحت تر میتونند سوء استفاده کنند ! در مورد PHP صادق نیست چون داریم در مورد framework حرف میرنیم و php را مدیر سیستم باید به روز نگه داره نه ما به عنوان برنامه نویس


قرار هم نیست تا آخر روی یک فریمورک بمانیم، بالاخره هر کدوم طول عمری دارند مثل خود php، این جزو ذات پیشرفت هست، ضمن اینکه اکثر فریمورک ها طول زمان پشتیبانی دارند و وقتی مثلا نسخه جدید و متفاوت بیاد، قرار نیست نسخه قبلی بلافاصله از دور حذف بشه، میشه بر اساس اونها برنامه ریزی کرد، و همچنین، پروژه ای که مثلا با یی 1 نوشته شد، نیازی نیست به نسخه 2 بروز بشه؟! مگر در موارد خیلی خیلی خاص که نحوه upgrade رو قطعا ارائه خواهند داد.

فراموش نکنیم تغییرات php همون framework ها را هم تحت تاثیر قرار میده و یادمون باشه هنوز خیلی جاها داره php 4 مورد استفاده قرار میگیره و تغییرات و باگ های php به اندازه خود framework ها نیست یا در اون حد critical نیست. اما در مورد framework ها این ریسک ها خییل خیلی زیاده. حتما خیلی ها قبول دارن Codeigniter یکی از محبوب ترین framework ها هست ولی آیا میدونین EllisLab (https://ellislab.com/blog/entry/ellislab-seeking-new-owner-for-codeigniter) میخواست واگذارش کنه ؟ و گویا این کار را انجام داده و حالا دست یک موسسه IT در British Columbia (https://ellislab.com/blog/entry/your-favorite-php-framework-codeigniter-has-a-new-home) هستش ! خوب این اتفاقات ممکنه مسیر درستی پیدا نکنند و کلی پروژه که بر پایه یک framework بوده بی صاحب بمونه ! البته ممکنه شما بگی خیلی بدبین هستم اما خوب از این چیزا زیاد دیدم.


هر مزییتی هزینه ای هم خواهد داشت، مثلا اگر شما از جوملا بخوای استفاده کنی، خوب طبیعتا باید جوملا کار داشته باشی، میشه ماهیت جوملا رو عوض کرد و ما همون php خام کار بمونیم
برای شخص بنده و خیلی های دیگه ممکنه اصلا استفاده از جوملا یا wordprtess یک مزیت نباشه و تازه کلی دردسر درست کنه ! مخصوصا برای جذب نیرو.

MMSHFE
سه شنبه 04 فروردین 1394, 19:49 عصر
فکر کنید شما مدتی از یک framework استفاده کردین و ناگهان ادامه توسعه framework متوقف میشه یا گروه توسعه دهنده تصمیم میگیره کلا مسیر کار و روشش را عوض کنه (عموما backward compatibility هم وجود نداره) اونوقت باید پروژه هایی که شاید خیلی هم قدیمی نیستند دستخوش تغییرات زیاد بشن یا کلا بی خیالشون بشی که این هزینه و زمان میطلبه.

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

Unique
سه شنبه 04 فروردین 1394, 21:02 عصر
شما وقتی یک فریمورک رو برای کارهاتون انتخاب میکنید، بر اساس نسخه فعلی اون کار میکنید نه امکاناتی که قراره در آینده بهش اضافه بشه (و شما ازشون حتی خبر هم ندارین).

این کاملا واضح و درسته !


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

تنها ضربه ای که میزنه باگ هایی هستند که پس از قطع توسعه پیدا میشن و طبیعیه وقتی توسعه متوقف یا کند بشه و از تکنولوژی روز فاصله بگیره یا تغییراتی که با بروز شدن PHP پیش میاد عموما حداقل من دیدم توسعه دهندگان سراغ framework های دیگه میرن.

MMSHFE
سه شنبه 04 فروردین 1394, 22:04 عصر
درسته که این مسئله محتمل هست ولی اگه قرار باشه با این احتمالات کار کنیم، توی تمام پروژه ها باید با همون کدنویسی PurePHP خودمون کار کنیم و طبیعتاً در مواردی مثل کار تیمی یا جاهایی که نیاز به توسعه مطابق با استانداردهای به روز هست، به مشکلات جدی تری برخورد میکنیم که احتمال بروز این مشکلات، خیلی بیشتر از قطع توسعه فریمورکی هست که چندین میلیون نفر در جهان دارن ازش استفاده میکنن. عمر یک نرم افزار هم در حالت متوسط بین 3 تا 5 ساله که توی این مدت میشه باگها رو به یه نحوی مدیریت کرد و این مسئله، با توجه به بازمتن بودن فریمورکها، حقیقتاً کار خیلی سختی نخواهد بود.

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

m.esmaeilzadeh
چهارشنبه 05 فروردین 1394, 12:42 عصر
استفاده از فریم ورک های شخصی که خودتون می نویسید و یا فریم ورکهایی که به اصطلاح پابلیک و متن باز هستن هر کدوم به نحوی مزایا و معایب خاص خودش رو داره و هیچکس نمیتونه این قضیه رو کتمان کنه !
من خودم برای یکسری پروژه ها اومدم فریم ورک شخصی نوشتم و خیلی بهتر از سیستم های دیگه که mvc و oop هستن کارم رو راه میندازه و اونقدر معماری کار خوب از آب در اومده که هم مشتری و هم خودم برای گسترش و کد نویسی راضی هستم !!!
ولی برای یکسری پروژه ها لازمه که از سیستم های پابلیک مثلا Yii , codeigniter و بقیه استفاده کنی ....
و یا حتی از cms های خوبی مثل wordpress که واقعا خیلی حرف برای گفتن داره تو کار استفاه بشه !!!
کل مطلب اینکه سلیقه ای هست و استفاده از فریم ورک ها با نام و نشون و مثلا معروف ملاک حرفه ای بودن و کار بلدی برنامه نویس نیست !

rezakho
چهارشنبه 05 فروردین 1394, 15:33 عصر
کل مطلب اینکه سلیقه ای هست و استفاده از فریم ورک ها با نام و نشون و مثلا معروف ملاک حرفه ای بودن و کار بلدی برنامه نویس نیست !
اگر مطلب اول من رو خوب خونده باشید، من توسعه صحیح و اصولی رو مد نظر داشتم، نه فقط فریمورک!

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

بله، فریمورک اختصاصی هم روش خوب و در شرایطی حتی بهتر از فریمورک های عمومی هست

من به شخصه حتی کد خام php رو هم برخلاف Unique، اسپاگیتی و نامنظم نمی دونم! کمااینکه توی پست های قبلی اشاره کردم، موضوع خود برنامه نویس و روش توسعه هست.

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

حرفه ای بودن در برنامه نویسی، به نبوغ برنامه نویس در حل مسئله بر میگرده، نه به ابزار مورد استفاده اش، اگر چه این هم عیب بزرگی هست که برنامه نویس حرفه ای از ابزار و سبک غیر حرفه ای استفاده کنه!

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

behnamy01
چهارشنبه 05 فروردین 1394, 22:03 عصر
سلام .
من تقریبا با اصول پایه ای php آشنا هستم و تا الان هر چی خواستم رو تونستم خودم بنویسم ولی جدیدا میخوام به صورت حرفه ای روی یکی از فریمورک های PHP تمرکز کنم .

اما خب مزایا و معایب هر فریمورک رو که بررسی کردم بین Yii و Codeignator شک دارم . حالا شاید بهتر از این 2 تا هم باشن .

ممنون میشم یه راهنمایی بکنید و فریمورک برتر رو معرفی کنید . میدونم که کلمه برتر کلمه غلطیه و همه چی نسبی هست .

ولی بیشتر برای کار با وب سرویس ها و پرداخت آنلاین و ... میخواستم فریمورکم رو انتخاب کنم .

پیشنهاد میکنم هر دو رو یاد بگیرید! اول ci و بعدش Yii یا فریمورک های دیگه.
CI فریمورکی هستش که یادگیریش خیلی راحته و میشه اسمش رو گذاشت فریمورکی برای شروع کار با فریمورک ها! یک هفته ای میتونید تقریبا از همه چیش سر در بیارید. واسه همین اول با CI شروع کنید و اگر دیدید از فریمورک ها خوشتون میاد و کارتون رو راحت میکنه، یک فریمورک حرفه ای دیگه رو در ادامه یاد بگیرید.

under22
چهارشنبه 05 فروردین 1394, 22:42 عصر
این کاملا واضح و درسته !



تنها ضربه ای که میزنه باگ هایی هستند که پس از قطع توسعه پیدا میشن و طبیعیه وقتی توسعه متوقف یا کند بشه و از تکنولوژی روز فاصله بگیره یا تغییراتی که با بروز شدن PHP پیش میاد عموما حداقل من دیدم توسعه دهندگان سراغ framework های دیگه میرن.
این باگ هایی که میگید چند تا نکته هست
1. والا من ندیدم تو فریمورک های بزرگ مثل yii و zend و laravel باگ امنیتی شدیدی پیدا نشده و اگر باگی بوده خیلی جزیی بوده برای مثال اگه گیتاپ yii فریمورک رو ببینید متوجه میشد مثلا ولیدیتور string تو زبان چینی سر یه حرفی مشکل داره اونا هم تو گیتاپ برچسب باگ زدن
2.توسعه یه فریمورک بین 5 تا 7 سال هست حدودا و این خودش زمان خیلی زیادیه
3.اگرم زمان توسعه تمام بشه کی از کجا میخاد بفهمه شما از چه فریمورکی تو پروژتون استفاده کرده
4.اگه به فریمورک های قدیمی نگاه کنید و سرچی در مورده باگ هاشون بزنید چون توسعه داده نمیشن چیزی پیدا نمیکنید
5.به ریلیز های فریمورک ها نگاه کنید چند تا باگ امنیتی دارن اونایی هم که دارن بالا اشاره کردم جزیی هستن . اکثرا قابلیت جدیدا یا عملکردو بهتر کردن
6.فریمورک درسته سر بار میاره اما اگه شما مثلا بخواهید هی پروژه تقریب ابزرگ بزنید با قابلیت کشی که دارن مثل فایل کش یا مم کش یا apc کش و انواع و اقسام کشی که دارند سرعت شما رو خیلی بیشتر از کد خام میکنند .
7.وقتی از فریمورک استفاده میکنید از قابلیت های جدید هم استفاده میکنید برای مثال شما نمیتونید ORM بنویسید ولی از فریمورک استفاده میکنید در مواقع داری دازش استفاده میکنید orm یه مثاله ولی خیلی چیزا هست داخل فریمورک ها

freeman99
پنج شنبه 06 فروردین 1394, 15:06 عصر
php کارها سبک و سیاق مشخصی در کد زدن ندارند، گاهی رویه گرا، گاهی شی گرا، گاهی ترکیبی و گاهی به شکلی که حتی نمیشه بهش سبک گفت کد میزنند!
خب PHP خودش هم اینطوریه.
مثلا من اخیرا که دارم بیشتر از امکانات شیء گراییش استفاده میکنم متوجه این موارد میشم که مثلا برای گرفتن اسم کلاس باید از یک تابع ساده بنام get_called_class استفاده کنم! یعنی منظورم اینه حتی امکانات شیء گرایی PHP خودشون ساختار کاملا شیء گرا ندارن و رویه گرا و تابع معمولی رو با شیء گرا و کلاس و آبجکت کاملا قاطی داره.
البته من لزوما اینا رو بد نمیدونم و برای یک زبان ترکیبی و به تدریج تکامل یافته و یابنده، فکر میکنم قابل قبول باشه و احتمالا راه بهینه برای تکامل و گسترش اینطوری بهتر بوده.
اصلا بطور کلی بنظر من امکان کد ترکیبی و مخلوط شیء گرایی و پراسیجرال و اینا هم چیز بدی نیست بلکه خوبه چون دست رو باز میذاره و انعطاف رو در کدنویسی زیاد میکنه. واقعا هر پروژه ای و هرجایی و هر بخشی از کد هر چیز کوچکی آیا ارزش داره وقت میشه در هر شرایطی فقط به شکل شیء گرا کار بشه؟ اون وقت و انرژی که میره ممکنه اون موقع توجیه نداشته باشه، یا اون کار کوچک، موردی، کم اهمیت باشه که ارزشش رو نداشته باشه. مثلا من الان پروژهء خودم رو به مرور دارم بهبود میدم الان ترکیبی از کلاس و تابع شده و بنظر ناهمگون میاد، ولی این برای من از نظر راحتی و سرعتی که بتونم با این وقت محدودم برنامم رو هرچه سریعتر به یک پله بالاتر ارتقا بدم و برای استفاده حداقل خودم به موقع آماده کنمش خوب بوده. اگر مثلا مجبور بودم همه رو بطور وسیع و عمیق دستخوش تغییرات ساختاری کنم خیلی بیشتر طول میکشید کار و زحمت زیادتری میبرد که الان من شاید وقتش رو نداشتم و تا مدتها هم نمیرسیدم که اون رو به جایی برسونم، درحالیکه الان برنامم درسته خیلی ساختار استاندارد و تمیز و بدون مشکلی نداره اما بعنوان یک سیستم مفید دم دست آماده استفاده است حداقل واسه خودم و به موقع میتونم تحت شرایط نیاز و عجله و محدودیت وقت کارم رو باهاش راه بندازم، چون بهرحال کار میکنه، بقدر کافی خوب کار میکنه و از نظر کارکردی تقریبا کامله، حالا کدهاش پشت پرده میخواد هرچی باشه حتی کد اسپاگتی هم باشه! بهرصورت درست کار میکنه و بنظر میاد تاحد کافی پایداری و دقت و اطمینان و قابلیت استفاده رو داره.


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


چرا که اگر پروژتون خیلی وابسته به سرعت و پرفورمنس باشه کلا باید برید سراغ زبان ها و ابزارهای دیگه رفت و یک زبان و یک تکنولوژی به تنهایی کافی نخواهد بود
اینم دقیقا از استدلال های بنده هست که خیلی وقتا میارم و کسی جواب معقولی هم بهش نمیده! حالا ما که میگیم اکثرا برخورد خوبی نمیکنن :ناراحت:


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

freeman99
پنج شنبه 06 فروردین 1394, 15:16 عصر
آبگوشتی اصطلاح مهندس شهرکی هست، همون اسپاگتی خودمونه :)

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

درست نمیگم مهندس؟ :لبخند:

rezakho
شنبه 08 فروردین 1394, 23:17 عصر
خب PHP خودش هم اینطوریه.
مثلا من اخیرا که دارم بیشتر از امکانات شیء گراییش استفاده میکنم متوجه این موارد میشم که مثلا برای گرفتن اسم کلاس باید از یک تابع ساده بنام get_called_class استفاده کنم! یعنی منظورم اینه حتی امکانات شیء گرایی PHP خودشون ساختار کاملا شیء گرا ندارن و رویه گرا و تابع معمولی رو با شیء گرا و کلاس و آبجکت کاملا قاطی داره.

متاسفانه این نکته درسته و یکی از اشکالات فعلی PHP هست و توسعه دهنده های PHP ظاهرا قرار نبوده یک زبان برنامه نویسی خلق کنند و دنبال یک اسکریپت روان برای کارهای ساده بودند که به مرور به این زبان تبدیل شده.
البته در نسخه 7 که در حال توسعه هست و یا HHVM، این اشکالا احساس شده و PHP داره به سمت یک زبان با قاعده تر پیش میره.
حتی تقریبا تمام کلاس ها و اکستنشن های جدید داخلی PHP، از نسخه 5 به بعد به صورت شی گرا داره ارائه میشه، نمونه اش
DateTime
SoapClient
PDO
Mysqli
Directory
FileInfo
Filter
Memcached
MongoDB
Rar
Zip
Phar
...