سری مهندسی نرم افزار: پست 4
از لینکدین Saeed Shahrivari Joghan
لینک

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

اول دو تا نکته ریز بگم خدمتتون:
۱- معمولاً اگه در کتاب‌ها یا وب بگردید به دو مفهوم بر می‌خورید یکی «نرم‌افزار خوب» (Good Software) و یکی هم «نرم‌افزار باکیفیت» (High Quality Software) که به نظر من تقریباً یه مفهوم دارند.
۲- کیفیت از دو دید قابل بحثه یکی کیفیت داخلی مثلاً معماری خوب و یکی هم کیفیت خارجی مثلا واسط کاربری خوب. معمولاً کاربر بیشتر کیفیت خارجی رو درک میکنه و مهندس نرم‌افزار هم ناخودآگاه بیشتر به کیفیت داخلی توجه میکنه. حالا کدوم باید اولویت داشته باشه؟ به نظر من هیچکدوم برتری نداره که الآن نمیخوام راجع بهش بحث کنیم.

حالا ویژگی‌های یه نرم‌افزار خوب چیه؟ معیارها خیلی متنوعه و پراکنده ولی اجازه بدید در این مورد اقتدا بکنیم به آقای سامرویل! از دید سامرویل ویژگی‌های یه نرم‌افزار خوب موارد زیره:
- کاربردی (Functional): یعنی عملکرد لازم رو به کاربر بده یا به عبارتی درست کار کنه و به درد بخور باشه.
- کارا (High Performance): یعنی کارایی لازم رو هم ارائه بده مثلاً کند نباشه.
- قابل استفاده (Usable): یعنی سهولت استفاده داشته باشه یا به عبارتی کاربرپسند باشه.
- قابل اعتماد (Reliable): یعنی بدون خطا و خرابی کار کنه به عبارتی باگ نداشته باشه و بشه روش حساب کرد.
- قابل نگهداشت (Maintainable): یعنی به راحتی بشه تغییر، ارتقا و بهبودش داد.
- امن (Secure): یعنی امنیت لازم رو برای کاربر فراهم کنه.
البته ویژگی‌های بیشتری هم هست مثل: Scalability یا Testablity‌ یا Compatibility و ... ولی به نظرم ۶ موردی که بالا مرور کردیم تقریباً تو هر نرم‌افزاری دیده میشه ولی موارد دیگه ممکنه تو بعضی نرم‌افزارها خیلی دغدغه نباشه مثلاً مقیاس‌پذیری. لطفاً این ۶ مورد و تعاریفش رو همیشه به خاطر داشته باشیم.

چند تا نکته کنکوری و پایانی:
۱- اینا ویژگی‌های نرم‌افزار خوبه یعنی: کد، داده و مستندات. پس صرفاً شامل کد نمیشه.
۲- نرم‌افزار شامل استهلاک نمیشه یعنی با گذشت زمان خرابی توش بوجود نمیاد برای مثال مقایسه بکنید با ماشین که به مرور زمان استهلاک پیدا میکنه و بیشتر خراب میشه.
۳- یه مهندس نرم‌افزار صرفاً نباید توجهش معطوف به ویژگی‌های کیفی داخلی باشه و باید به ویژگی‌های کیفی خارجی هم توجه کنه مثل قابل استفاده بودن.
۴- این ویژگی‌ها معمولاً مثل یه تار عنکبوت به هم تنیده شدند. یعنی اگه بخوایم یکی رو افزایش بدیم ممکنه به احتمال زیاد ویژگی‌های دیگه که در تعارض هستند کاهش پیدا کنند. برای مثال معمولاً تلاش برای افزایش کارایی سیستم باعث کاهش اتکاپذیری میشه. احتمالاً در آینده راجع این موضوع بیشتر صحبت می‌کنم اما فعلاً پیشنهاد میکنم برای این بحث مقاله بسیار عالی «The web of system performance» رو مطالعه بکنید:
https://lnkd.in/d9s998jA

حالا چه کنیم که نرم‌افزار خوب تولید کنیم؟ ایشالا به شرط حیات در پست‌های بعدی بهش می‌پردازیم😉

دیزاین notification system قسمت دوم

تا اینجای کار ما فرضمون رو از سیستم نوتیفی که میخوایم طراحی کنیم گفتیم

الان نوبت میرسه به یه طراحی سطح بالا از سیستم.

مثال اول : گوشی های Apple

ممکنه بدونید که شرکت اپل برای ارسال نوتیف از APN استفاده میکنه یا همون Apple push notification service هست. به بیان دیگه یه پیام توسط provider تولید میشه و توسط APN به گوشی ها فرستاده میشه.
سه بخش مهم داریم الان:
۱ - بخش provider
2 - بخش APN
۳ - گوشی iOS

بخش provider، با دو نوع داده کلیدی سر و کار داره:

۱ - قسمت device token که شامل یک توکن منحصر به فرد برای ارسال نوتیفیکیشن هست
۲ - بخش payload که یک داده JSON شامل محتوای ارسالی نوتیفیکیشن هست

بخش APN رو هم که توضیح دادیم و کلاینت ما هم که گوشی هست.
یه دیزاین سطح بالا هم ببینیم ازش بد نیست

✅در مسیر تبدیل شدن به یک مهندس نرم‌افزار یکی از راه هایی که خیلی میتونه شمارو کمک کنه و مسیر رو براتون شفاف تر کنه، شنیدن پادکست هایی از جنس تجربس.

از لینکدین Reza Amini
لینک

من این پایین لیستی از چندین پادکست خوب در زمینه مهندسی‌ نرم افزار رو اوردم که میتونید بررسی کنید.

- Software Engineering Daily

توی این پادکست خفن میزبان میاد و درخصوص چالش ها توی پروژه های بزرگ با مهندسین نرم افزار شرکت های بزرگ صحبت میکنه و تجربیات خوبی شیر میشه.
https://lnkd.in/evyWJjQT

- Software Engineering Radio

‏پادکست رادیوی مهندسی نرم افزار، یکی از اون پادکست های پرمحتواییه که آدم های خفن هر هفته درخصوص چالش های طراحی نرم افزار صحبت میکنند.
‏⁦ se-radio.net⁩

- CaSE

پادکست Conversations about Software Engineering سعی کرده هر سه هفته یک اپیزود برای افرادی که علاقه مند به معماری و مهندسی نرم افزار هستند رو منتشر کنه.

پادکست های رلیز شده مصاحبه طور هستند و بنظرم
جذابن.
https://lnkd.in/emXbqqNi

- Changelog

پادکست Changelog هم واقعا باحاله، خیلی از زمینه های اپن سورس، توسعه وب و برنامه نویسی و.. رو توی اپیزود هاش ساپورت میکنه و تا الان نزدیک ۵۷۰ اپیزود ضبط شده رو قرار داده روی سایتش.
https://changelog.com/

- The Cloudcast

اگه شماهم علاقه مند به Cloud, Serverless architecture, aws ,.. هستید احتمالا این پادکست از بقیه براتون جذاب تره و هر هفته داره اپیزود های جدیدی در زمینه کلاود به اشتراک میزاره.
https://lnkd.in/ejjFdwJk

- CodeNewbie

این پادکست هم با هدف باحالی اومده، آدمای مختلف داستان رسیدنشون به از صفر به پوزیشن های بالایی که الان دارن رو توی هر اپیزود میگن و میگن که چطوری از یک کورس ساده به شرکت های بزرگ نرم افزاری رسیدن.
codenewbie.org/podcast

- System Design

یکی از جذاب ترین پادکست ها برای افرادی که به سیستم دیزاین علاقه دارن، اینجا مصاحبه های سیستم دیزاین بصورت پادکست ضبط میشن و آدمای با تجربه چالش های سیستم دیزاین مختلف رو حل میکنند.
https://lnkd.in/eGsH5ufj

- Soft Skills Engineering

این بار دیگه قرار نیست محتوای فنی و کد بشنوید، با این پادکست شما قراره مهم ترین سافت اسکیل هارو تقویت کنید، بنظرم از دستش ندید.
https://softskills.audio/

- CoRecursive

این پادکست هم عناوین باحالی داره، آدم های بزرگی راجع به مسائل جذابی صحبت کردن، میتونید چک کنید.
https://corecursive.com

✅آشنایی با کلاس TemplateResponse در جنگو

توی ویوهای فانکشن بیس جنگو معمولا متد render رو return می کنیم که توی مسیر django.shortcuts هست.

✔️گاهی اوقات لازم میشه response ایی که بر میگردونیم یکم مخلفات داشته باشه. مثلا به http header ش یه چیزی (به هر دلیلی) اضافه کنیم. در این مواقع میتونیم TemplateResponse رو return کنیم.
✔️وقتی هم که Middleware سفارشی ایی داشته باشیم که تغییراتی رو توی response اعمال میکنه (ریسپانسی که template داره) ، استفاده از TemplateResponse خوبه.

اگه داکیومنت جنگو و بخش میدلورهارو خونده باشی متدی به اسم process_template_response هست.
✔️متد process_template_response در Middleware ها فقط بر روی پاسخ‌هایی از نوع TemplateResponse اجرا می‌شه.

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

بد نیست به نکته‌ای اشاره بکنم. سوال یک اگر بخواهیم دقیق صحبت کنیم، مبنای ۳۲ به کار رفته در geohash شامل حروف a و i و l و o نمی‌شود که برای راحتی چنین فرضی در امتحان نداشتیم.

@golemcourse

اینم موتور Django 🥸

لینک

✅بیزینس لاجیک رو کجای مدل در جنگو میشه گذاشت؟
من از این چهار مورد در معماری فریمورک جنگو استفاده کردم که در ویدئو توضیحاتش رو میدم:
1. Field Constraints
2. Custom Constraints
3. Validators
4. Model Clean Method

از لینکدین Hamze Qaempanah

✅کارهایی که با QuerySet در جنگو میتونیم انجام بدیم
از لینکدین Hamze Qaempanah
✔️کوئری ست توی جنگو یک ابسترکشن از عملیات‌های دیتابیسه که کلی متد کمکی در اختیارمون می‌ذاره که خیلی‌هاش کارمون رو آسون می‌کنن و خوبه گوشه ذهنمون باشن تا ازشون استفاده کنیم.
یکسری‌ها که شاید فراموش کنیم ازشون استفاده کنیم رو مرور می‌کنم و لیست کاملش رو از سایت جنگو می‌تونین چک کنین.
البته توی ویدئو هم این‌ها رو توضیح دادم:
aggregate, annotate, dates, defer, only, diffrence, exists, field lookups, get_or_create, update_or_create, intersection, Q, select_for_update, select_related

سری مهندسی نرم‌افزار: پست 5
از لینکدین Saeed Shahrivari Joghan
لینک

تو پست‌ قبلی راجع به مفهوم «نرم‌افزار خوب و با کیفیت» صحبت کردم و اشاره کردم که هر نرم‌افزار معمولاً حداقل ۶ محور کیفی داره که در این پست می‌خوام به «قابلیت نگهداشت» یا همون Maintainability بپردازم که معمولاً یکی از جذاب‌ترین فاکتورها برای مهندسین نرم‌افزار هست.
من خیلی از مواقع طی گپ و گفت با دوستان توسعه‌دهنده این سوال رو مطرح می‌کنم که «به نظرت یه کد با کیفیت چه ویژگی‌هایی باید داشته باشه؟». یه جواب کلیشه‌ای که من خیلی دوستش ندارم اینه که «اگه اصول سالید رو رعایت کنیم، کد خوبی تولید کردیم». ایشالا اگه عمری باشه در آینده راجع به سالید مفصل صحبت می‌کنم و سعی می‌کنم نشون بدم که رعایت سالید برای تولید کد باکیفیت کافی نیست ولی خب فعلاً بگذریم.

این سوال در سال‌های خیلی دور همیشه ذهن منو به خودش درگیر می‌کرد. شاید بتونم بگم که در اوایل برای من سریع بودن و بدون باگ بودن کدهایی که می‌نوشتم خیلی مهم بود (چون حس می‌کردم این مدلی کار خفنی کردم)، ولی آیا میشه گفت یه کد (یا به صورت کلی‌تر یه نرم‌افزار) اگه سریع و قابل اتکا باشه، چیز خوبیه؟
همون‌طوری که توی پست قبلی مفصل صحبت کردم کارایی و قابلیت اتکا خیلی فاکتورهای مهمی در مبحث کیفیت نرم‌افزار هستند ولی من به تجربه به این رسیدم که برای یه مهندس نرم‌افزار نگهداری، تغییر و توسعه بی‌دردسر خیلی فاکتور مهم‌تری هست یا حداقل اینجوری بگم که شایع‌ترین چیزی که گریبان من به عنوان مهندس نرم‌افزار رو می‌گیره کندی یا باگی بودن محصول نیست بلکه آشفتگی و عذاب‌آور بودن تغییر و توسعه نرم‌افزار موجود هست. پس الان که یه مقداری پخته‌تر شدم، اگه از من سوال بالا رو بپرسید میگم کد با کیفیت کدیه که به راحتی تغییرپذیر باشه یا به صورت عمومی‌تر ببینیم maintainable باشه. چرا؟ چون معمولاً یه نرم‌افزار یه-بار-نوشت نیست که یه بار تولیدش کنی و دیگه دست بهش نزنی در طول حیات یه نرم‌افزار قبل از بازنشستگی، هم تغییرات و توسعه زیادی خواهیم داشت و هم برای رفع باگ معمولاً باید نرم‌افزار رو تغییر و توسعه بدیم. مثال دم‌دستی بخوام بزنم از دید من برای یه تعمیرکار بهترین نوع ماشین، ماشینی هست که راحت بشه تعمیرش کرد و حتی در مواردی تغییرش داد و یا تقویتش کرد. به صورت طبیعی من مشتری هم از این قضیه خیلی خوشحال‌تر میشم چون با هزینه و زمان خیلی کمتری ماشینم رو نگهداری می‌کنم.

حالا چه کنیم که نرم‌افزاری داشته باشیم که توسعه، تغییر و نگهداریش راحت باشه؟ از دید من کافیه که حین فرآیند تحلیل، طراحی و توسعه نرم‌افزار دو تا اصل رو رعایت کنیم:
۱- سادگی: همه چیز باید تا حد ممکن ساده نگه داشته باشه یا همون قاعده KISS
۲- رعایت اصل تفکیک دغدغه‌ها (Separation of Concerns): یعنی نرم‌افزار رو طوری به بخش‌های متمایز تفکیک کنیم که هر بخش به دغدغه متمایز بپردازه. حرف راجع به این موضوع مفصله.
اصل اول که بر همه عیانه اما معمولاً من در بین دوستان خیلی اصل تفکیک دغدغه‌ها رو نمی‌شنوم. خب این اصل رو برای اولین بار آقای دایکسترای بزرگ که یه دانشمند هلندیه در سال ۱۹۷۴ مطرح کرده و چون مثل آدمهایی مثل عمو باب معروف اهل شومن بودن نیست شاید خیلی شناخته‌شده نباشه. فعلاً تا اینجای کار داشته باشیم و برای اینکه پست طولانی نشه ایشالا در پست‌های بعد بیشتر به این دو اصل می‌پردازم.

پانوشت: بد نیست به کارهایی که آقای دایکسترا کرده یه نگاهی بندازید.

https://lnkd.in/didwSMYU

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

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

#حریم_خصوصی
#رمز_نگاری
#پسورد
#hash
#salt
#password
#privacypolicy

@easymicroservice
@easymicroservices
@csharptips

سریال this is us درباره یه خواهر و دو تا برادر همسن هست که یکی شون به فرزند خواندگی گرفته شده و سر همین از اون دو تا خیلی باهوش تر و برای درامای سریال حتی سیاه پوست هم هست. (دو تا سفید و مو بلوند)
یه جای سریال پدر خوانده از رندال (برادر سیاه پوست) سوال های ریاضی طور می‌پرسه و پسر با اینکه جواب ها رو میدونه اما نمیگه
پدر عصبانی میشه و پسر رو دعوا می‌کنه که تو که باهوشی چرا انقدر نمره هات بده و چرا تلاش نمیکنی؟
پسر در دفاع از خودش میگه که دوس نداره جواب درست بده چون باعث میشه فقط خودش جایزه بستنی بگیره و خواهر برادرش جایزه نگیرن و این جوری خواهر برادرش از رندال بدشون میاد و نمیخواد که متفاوت باشه

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

تاپیک #موقعیت_سخت

✅ پارامتر on_delete که توی تعریف یک رابطه (relationship) در مدل ها استفاده میشه، نحوه رفتار سیستم در مواقع حذف یک شی مرتبط با شی دیگه رو مشخص می‌کنه.

⚠️قرارداد: توی این متن به جدول اصلی میگم پدر. به جدول خارجی میگم فرزند.

احتمالا با مقدار on_delete=models.CASCADE آشنا هستید. وقتی که CASCADE باشه. اگر پدر رو حذف کنیم همه فرزندانش هم حذف میشن.

✔️اما مقدار on_delete = protected (توی جنگو) به معنای اینه: در صورتی که پدر بخواد حذف بشه و فرزندی داشته باشه، یک خطای ProtectedError ایجاد میشه. در واقع این حالت اجازه نمیده پدری که فرزند حذف نشده داره، حذف بشه.

کمی حرف حساب..

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

مهندس نرم افزار حالا واقعا کیه؟
به طور کلی اون شخصی که یک نرم افزار از صفر تا صد رو تحویل مشتری میده میشه مهندس نرم افزار‌.
مهندسی نرم افزار خیلیییییی فراتر از کد زنی هست
اصولا دید کد زنی و برنامه نویسی با دید مهندسی تفاوت زیادی داره ( اینو اگر تو ایران بگین احتمالا کتک بخورین ولی حقیقته) چون اکثرا ( حدود ۹۹ درصد) اسیر پدیده golden hammer هستن.
یه زبان بلدن و فکر میکنن ختم عالمن :)

یه مهندس نرم افزار بسته به این که تو چه زمینه ای فعالیت میکنه باید بتونه سیستم رو تحلیل و طراحی کنه، ریسک ها رو بسنجه، پروژه رو مدیریت کنه و هر مرحله ای که لازمه برای ساخت یه نرم افزار رو در نظر بگیره که داستانش خیلی خیلی مفصله و تقریبا خیلی از این مسائل به کد مربوط نیست!
حرف حساب من بیشتر روی شرکتای معتبره که رو پروژه های خاص دارن کار میکنن وگرنه متاسفانه تو ایران دید مناسبی از مهندسی نرم افزار وجود نداره.
برای مثال شرکتای بزرگ مهندس متدلوژی دارن! که البته فیلد تحقیقاتی خودم هم همین مهندسی متد هست.
و کارش چیه؟ میان بسته به یه پروژه که تعریف میشه یه متدلوژی رو مهندسی میکنه
در واقع میاد یه process line برای ایجاد نرم افزار تعریف میکنه و این کاملا سفارشی شدست و بسته به پروژه و ریسک هاش میتونه متفاوت باشه
تو این زمینه مقالاتی هم هست که میتونید بخونید.
و این در حالیه که تو ایران فقط مدیران پروژه اسکرام رو بلدن و برای هر پروژه ای از اسکرام استفاده میکنن و طبعا نتیجش رو هم میبینن.
حتی خود سازندگان اسکرام اون رو برای هر پروژه ای توصیه نمیکنن!
این مشکلات متاسفانه ناشی از نبود سواد کافی و البته پدیده golden hammer هست که خیلی خیلی زیاده این روزا
حرف آخر من به هر کسی که به شکل حرفه ای میخواد مهندسی نرم افزار رو ادامه بده اینه که inertie رو تا حد امکان کاهش بدن. دنبال یادگیری چیزای جدید باشن. فک نکنن یه چیز بلد باشن دیگه ختم عالمن و یاد بگیرن چیزای بد و اشتباه رو با دونستن پاد الگو ها تغییر بدن

✅ یک ویدئوی خیلی مفید از @BenDevelop
✔️ توی این ویدئو امیربهادر سه تا نکته در مورد مرتبه زمانی (پیچیدگی زمانی) میگه که من خودم تا امروز برداشتم اشتباه بود.
✔️ یه مثال پادشاه و شطرنج هم اشاره کرد، که بهراد قبلا توی لینک های زیر توضیح داده:
رشد نمایی:
https://t.me/TadavomnisT_channel/92
داستان تا کردن کاغذ:
https://t.me/TadavomnisT_channel/93
داستان شطرنج:
https://t.me/TadavomnisT_channel/95


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

https://www.youtube.com/watch?v=2L-9QV0Nqgo&t=1295s

@BenDevelop