(پارت اول)
به مناسبت نوروز: کمی بیشتر مهندسی نرم‌افزار رو بیاریم توی زندگی! 🪻

توی مهندسی نرم‌افزار یه اصل خیلی مهم داریم به اسم Encapsulation. 🛠 توی OOP، پراپرتی‌ها رو ایزوله نگه می‌داریم که بقیه کلاس‌ها نتونن مستقیماً تغییرشون بدن. چون اگه این اتفاق بیفته، کل سیستم ناپایدار می‌شه، پترن‌های دیگه‌ای رو هم نمی‌تونیم درست پیاده کنیم، و در نهایت، کنترل روی رفتار آبجکت رو از دست می‌دیم.

حالا بیا انسان رو یه کلاس در نظر بگیریم.

تصمیم‌هایی که می‌گیریم، یه پراپرتی‌ از این کلاسن.

حسی که نسبت به اون تصمیم داریم، یه پراپرتی دیگه.


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

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

@azibom
@azibomChannel

Azibom.com

(پارت دوم)
برای مثال

🔹 State Management؟

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

🔹 Single Responsibility Principle؟

نابود شد. یه بخشی از زندگی‌مون که باید فقط توسط خودمون مدیریت می‌شد، حالا یه پروژه‌ی اوپن سورس شده که هر کسی می‌تونه روش کامیت بزنه!
📝 وظیفه‌ی تغییر حس و تصمیم با ما بود، اما حالا بقیه هم روی این مسئولیت دخالت می‌کنن.

🔹 Dependency Inversion Principle؟

❌ نقض شد! وقتی ما تصمیم و احساساتمون رو طوری طراحی کنیم که به ورودی‌های خارجی وابسته باشن، دیگه اختیار دست خودمون نیست.
🔄 به جای اینکه یه interface برای ورودی‌ها داشته باشیم که خودمون کنترل کنیم چه چیزی رو قبول کنیم، مستقیم به تغییرات بیرونی وابسته می‌شیم.
📌 این یعنی هر بار یکی چیزی بگه، رفتارمون تغییر می‌کنه.

پس، امسال موقع دید و بازدیدهای عید، حواسمون باشه که چی رو Private نگه داریم و چی رو واقعاً لازمه Public کنیم.
چون بعضی پراپرتی‌ها فقط برای خودمونن، و اگه همه بهشون دسترسی داشته باشن، دیگه اون سیستم، اون آدم، اون زندگی، یه طراحی درست نداره.

🛡از پراپرتی های زندگیتون مراقبت کنید و اگه دلیلی برای پابلیک کردنشون ندارید حتما پرایوت نگهشون دارید.

@azibom
@azibomChannel

Azibom.com

فراخوان ثبت‌نام منتورینگ

لینک توضیحات کامل:
azibom.com/mentorship

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

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

@MrAmirSalehi

ظرفیت خیلی محدوده و اولویت با افرادیه که زودتر اقدام کنن.

توصیه:
قبل از ثبت‌نام، حتما نظرات بچه‌هایی که قبلاً شرکت کردن رو بخونید.
داخل سایت توی صفحه منتورشیپ هست و توی پیامی که ریپلای شده هم گذاشتیم.

مراقبت کنید.

@azibom
@azibomChannel

Azibom.com

اینم آدرس لینکدین بنده برای آشنایی بیشتر دوستانی که تازه به کانال اضافه شدن🙏
https://www.linkedin.com/in/azibom

دوره جدید از سری دوره های Mindset با رویکرد حل مسئله با حمایت دیجیکالا این اردیبهشت 🔥🔥🔥

دوره اول درباره پترن ها و اوپن سورس صحبت کردیم و این بار قراره درباره حل مسئله و الگوریتم صحبت کنیم ...

اطلاعات بیشتر رو کم کم داخل کانال میذارم

مراقبت کنید

@azibom
@azibomChannel

Azibom.com

(پارت اول)
جورج پولیا
فهمیدن مسئله

شاید باید شکلی رسم کنی!

@azibom
@azibomChannel

Azibom.com

(پارت دوم)
مسئله فهمیدن مسئله

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

در خاطرات دانشجوهاش اومده که پولیا، حتی بیرون از کلاس در راهرو، کافه‌تریا یا موقع قدم زدن اگه می‌دید کسی با مسئله‌ای درگیر شده، به‌جای دادن جواب، فقط یه سوال می‌پرسید:
«مطمئنی مسئله رو درست فهمیدی؟»

همین جمله ساده، بعدها شد هستهٔ مرکزی کتابی که نوشت:

How to Solve It – «چطور مسئله را حل کنیم».

کتابی که سال ۱۹۴۵ منتشر شد و حالا، نزدیک به هشت دهه بعد، هنوز در دانشگاه‌ها به‌خاطر نگاهی که به تفکر و یادگیری ارائه می‌ده تدریس می‌شه.

پولیا باور داشت خیلی از ما، وقتی با یه مسئله مواجه می‌شیم، ناخودآگاه سریع می‌ریم سراغ پیدا کردن جواب.
بدون اینکه لحظه‌ای صبر کنیم و از خودمون بپرسیم:

مسئله دقیقاً چی می‌خواد؟
چه چیزهایی در اختیارم هست؟
چه شرط‌هایی توی این سؤال پنهانه؟

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


@azibom
@azibomChannel

Azibom.com

(پارت سوم)
وقتی نوکیا داشت مسئلهٔ اشتباهی رو حل می‌کرد

اواخر دههٔ ۲۰۰۰، نوکیا هنوز سلطان بازار موبایل بود.
سهم بازارش در سال ۲۰۰7 نزدیک به ۴۰٪ بود. میلیون‌ها گوشی در ماه فروخته می‌شد.
اما همون زمان، آیفون تازه معرفی شده بود و اندروید هم داشت از راه می‌رسید.

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

اما مسئله‌ای که داشتن حل می‌کردن این بود:
«چطور سیمبین رو بهتر کنیم؟»

در حالی که مسئلهٔ واقعی، چیز دیگه‌ای بود:
«آیا سیمبین اصلاً پلتفرم درستی برای آیندهٔ موبایل هست؟»

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

نوکیا بهترین تیم‌ها رو داشت، دقیق‌ترین مهندسا رو، و سخت‌کوش‌ترین نیروها رو…
فقط داشت برای سؤال اشتباه جواب پیدا می‌کرد.


---

پولیا می‌گه:

"Before you rush to fix, step back and ask: are we solving the right problem?"


و این احتمالا همون چیزی بود که نوکیا دیر پرسید!

@azibom
@azibomChannel

Azibom.com