چالش صد روز کد که خیلی ها احتمالا اسمشو شنیدن ، یه چالش محبوب هست که کمک تون می‌کنه عادت برنامه نویسی و یادگیری رو همراه با بقیه ایجاد کنید. میتونید از وبسایت رسمی اش دیدن کنید و همین الان به این چالش بپیوندین . ممنونم از مهدی آخی عزیز که این چالش رو شروع کرد ، راهنمایی مون کرد و تجربیاتش در این مسیر رو در اختیار مون قرار داد و ممنونم از همه عزیزانی که باعث انگیزه و ادامه مسیر شدن. اگه خواستین به این چالش بپیوندین اینجا رو چک کنید .
ali mir ferdos, majidTaherkhani, Dutchman , Mohammadmahdi Mirzaei and other genius and inspiring people.
بریم سر اصل مطلب ! میخوام باهاتون درمورد مطلبی که تو دومین روز چالش مطالعه کردم صحبت کنم درمورد کلمه ای چهار حرفی و اونقدر مهم که تا ابد باید یادتون بمونه و اگه قرار باشه به عنوان برنامه نویس ، برنامه های flexible و user-friendly بنویسید یکی از مهم ترین مفاهیمی که باید یادبگیرین Object Oriented Analysis and Desgin هست .
پس مطالعه رو با کتاب Head first OOA&D شروع کردم ، روش کتاب اینطوری هست که ذهن خسته نمیشه ، با شکل و فونت های مختلف به ذهن سپردن مطالب رو راحت تر می‌کنه و مطالعه رو تبدیل به یه تجربه لذت بخش می‌کنه.
خیلی خلاصه در حدی که با فصل اول این کتاب آشنا بشین و علاقمند بشین برای مطالعه و یه سرنخ اولیه بدست بیارین درمورد موضوعاتی که امروز خوندم اینجا توضیح میدم امیدوارم برای حتی یه نفر بتونه مفید باشه ❤
کتاب از اسم Rick استفاده کرده من میگم اصغر :) خب بگذریم ، فکر کنید که اصغر صاحب یه سوپری خیلی خوب توی محله اس ، اصغر موفق شده با تخفیف های روزانه ای که به مشتریاش میده و تنوع بالای محصولاتش مشتریای قدیمی و محلی خودشو حفظ کنه، حتی باوجود سوپرمارکت های زنجیره ای که اون اطراف وجود داره !
اما اصغر تصمیم گرفته حالا که کارش رونق گرفته و مشتریاش زیاد شدن و خیلی از این مشتریا هم خریداشون رو با تلفن زدن سفارش میدن ، همه اجناس توی مغازه اش رو تو یه سیستم کامپیوتری نگهداری کنه و هر وقت که یه مشتری زنگ میزنه تا سفارش بده سریع توی سیستم چک کنه که ببینه محصول مورد نظر رو داره یا نه و حتی یه لیست از کالاهای محبوب مشتریاش داشته باشه .
سعی کنین خودتون خیلی ساده با هر مفهومی که تا الان از OO یادگرفتین یه کلاس دیاگرام ساده (فقط برای قسمت اول برنامه یعنی کالا ها و نه سرچ کردن ) طراحی کنید بعد به شکل پایین نگاه کنید :
سعی کردیم تو ساده ترین حالت ممکن فقط یه کلاس درست کنیم با سه تا field و سه تا متد access modifier برای فیلد ها . خیلی از جزئیات رو اینجا نیاوردیم و اگه بخوایم برنامه واقعی اش رو بنویسیم نیاز به جزئیات بیشتری داریم مثلا constructor داشته باشه یا نه ؟ خروجی متد ها چی باشه ؟ و خیلی چیزای دیگه . ولی از کجا بدونیم که چطور برنامه رو طراحی کنیم ؟ اصلا از کجا شروع کنیم ؟ نرم افزار عالی به چه معناست و چطور مطمئن بشم نرم افزار دقیقا همون کاری رو انجام میده که اصغر انتظارش رو داره ؟
حالا که قدم اول رو انجام دادیم ، یه مرحله نزدیک تر شدیم به اولین سوالی که این کتاب مطرح کرده :
How do you write great software, every time ?
موضوع اینه که هر کس به این سوال جواب متفاوتی میده یه نفر میگه اصول کد تمیز و OOP رعایت شده باشه ، یه نفر دیگه اهمیتی به کد نمیده وفقط کارکرد براش مهمه و اینکه مشتری راضی باشه.
نکته اینجاست همه اون ها میتونه درست باشه چون نرم افزار چیزی بیشتر از یه دیدگاه هست .
ولی به طور کلی کتاب سه تا اصل مهم مطرح کرده که باید برای رسیدن به نرم افزار خوب انجام بدین :
1. Make sure your software does what the customer wants it to do.
اول باید با توجه به نیازمندی ها و پرسش و پاسخ ها مطمئن بشیم که چیزی که اصغر میخواد رو فهمیدیم . Make sure the app does what it’s supposed to do FIRST
این اولین قدم و مهم ترین قدم هست ، تا زمانی که ندونیم مشتری دقیقا چه نیاز هایی داره نمیتونیم نرم افزاری بسازیم که نیازمندی هاش رو رفع کنه و وسط راه ممکنه دچار کلی خطا بشیم و باید از اول desgin رو شروع کنیم .
ولی قدم بعدی چیه ؟
2. Apply basic OO principles to add flexibility
قبل از اینکه مفهومی به اسم OO بوجود بیاد برنامه هامون رو با روش رویه ای میساختیم تصور کنید به جای اینکه مسئله بزرگ به کلاس های مختلف تقسیم بشن و هر ویژگی متمایز یک شئ براش ایجاد بشه ، ما برنامه نویسی رویه ای رو داشتیم که کل برنامه به شکل فراخوانی تعداد خیلی زیادی از رویه های پشت سر هم اجرا میشد به اصطلاح کد اسپاگتی تولید میشد و اشکال زدایی برنامه خیلی سخت میشد ، هیچ کپسوله سازی ای وجود نداشت و در نتیجه اطلاعات حیاتی به صورت مستقیم قابل دسترس بودن . اما با شئ گرایی خیلی از مشکلاتی که روش های قبلی وجود داشت رو حل کردیم و تونستیم نرم افزارهای پیچیده طراحی کنیم .
به همین دلیل هست که دومین قدم مهم اطمینان از اینه که برنامه شما از قوانین شئ گرایی پیروی کنه .
3. Strive for a maintainable, reusable design
ما درمورد این صحبت کردیم که در مرحله اول ، کد باید خوب کار کنه طوری که نیاز مشتری تامین بشه ولی سومین بخش مربوط به ما میشه، برنامه نویس ها . ما نیاز داریم کدی که نوشتیم علاوه بر اینکه functionality مناسب رو داره برای برنامه نویس ها هم قابلیت نگهداشت پذیری و طراحی خوبی داشته باشه. ممکنه بخوایم تو برنامه های دیگه هم از این کد استفاده کنیم پس بایدمطمئن بشیم قابلیت های بالا رو داره .
حالا چند قدم به نوشتن بهترین نرم افزار نزدیک شدیم .
در ادامه بخشی از لغات خیلی مهمی که تو پروسه نرم افزار زیاد بهش اشاره شده رو میارم :
Flexibility
بدون من، شما هرگز مشتری رو راضی نخواهید دید. مهم نیست چقدر برنامه شما به خوبی طراحی شده است، من چیزی هستم که لبخند را بر لبان مشتری می نشانم : )
Encapsulation
من تماماً در مورد استفاده مجدد هستم و مطمئن شوم که شما در حال تلاش برای حل مشکلی که شخص دیگری قبلاً آن را کشف کرده است نیستید .
Functionality
شما از من برای نگهداری کردن بخش هایی از کد خود استفاده می کنید که بدون تغیر میمانند میمانند جدا کردن آن ها از کد هایی که تغییر میکنند، آنگاه ایجاد تغییرات در کد شما بسیار آسان است بدون اینکه نیاز به شکستن همه چیز باشد.
Design Pattern
از من استفاده کنید تا نرم افزار شما تغییر کند و رشد کند. بدون دوباره کاری مداوم من نرم افزار شما را از شکننده بودن حفظ میکنم . ( به طراحی ای که شکننده نیست میگیم robust design یعنی عدم حساسیت محصول یا فرآیند به تغییرات)
این اولین خلاصه مطالعه من از این کتاب بود و در روز های بعدی حتما پروسه نوشتن از این چالش رو ادامه میدم . امیدوارم که لذت برده باشین هر انتقادی دارین با کمال میل میپذیرم تا بتونم مطالب بهتر و تخصصی تری بنویسم .
