توی مترو نشستم، گفتم خلاصه کتاب "کد تمیز" نوشته رابرت مارتین(عمو باب) رو یه مروری کنم. اینجا هم می‌نویسمشون 😁

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

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

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

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

توی گام اول یک سری قوائد عمومی وجود داره که من اونا رو خدمتتون عرض می‌کنم:

1- یک استاندارد مناسب برای خودتون داشته باشید و همیشه و در هر شرایطی دنبالش کنید. استاندارد یعنی چی؟ مثلا یک رسم‌الخط(camelCase, Pascal‌Case, kebab_case, etc.) برای نام‌گذاری داشته باشید، کامنت‌ها رو به یک شکل بنویسید، شرط‌ها رو با یک استایل مشخص بنویسید و غیره. اگر توی یک تیم کار می‌کنید این استاندارد برای همه یکسان هستش و همه باید ازش تبعیت کنن. ولی توی پروژه‌های شخصی شما مختارید که چی استفاده می‌کنید. هر شکلی رو استفاده می‌کنید سعی کنید تا آخر همون رو نگه‌دارید تا بعدا بتونید کدهای قبلی رو بخونید.

2- هرچقدر می‌تونید ساده فکر کنید و از اون ساده‌تر بنویسید. این یک توانایی فکری هستش که به مرور زمان و نوشتن کدهای بیشتر تقویت می‌شه. یه ضرب المثل نرم‌افزاری هست که می‌گه: برای احمق‌ها کد بزنید😁. هیچ وقت نترسید از این که برگردید به کدهای قبلی‌تون و اونها رو براساس بهترین دانش خودتون اصلاح کنید. برای این مورد خوندن کدهای افراد حرفه‌ای و ریپازیتوری‌های بزرگ و مهم زبانی که کد می‌زنید می‌تونه کمک خوبی بهتون بکنه.

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



4- اگر به مشکلی برخورد کردید یا باگی پیدا کردین، از ریشه حلش کنید. شخصا سلطان ماست مالی کردن هستم اما توی نرم‌افزار هر وقت این کار رو کردم چند روز بعدش و سر یه کار خیلی حساس‌تر مجبور شدم از زمان و دقتم توی اون کار مهم بزنم و با اعصابی خراب و آبرویی رفته(که چطور تو دو روز پیش اینو حل کردی ولی هنوز این باگ وجود داره؟ مگه برنامه نویسی بلد نیستی؟) نشستم 30،40 ساعت نخوابیدم تا اون مشکل رو ریشه‌ای و درست حل کنم.


در پیام‌های بعدی درمورد کد تمیز نوشتن و تجارب دردناک و خجالت آور خودم بیشتر می‌نویسم براتون 😂🤦🏻‍♂️

#کدتمیز
#نرم_افزار
#آموزشی

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

نوکرتونم واقعا 😂🤦🏻‍♂️

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


https://www.linkedin.com/posts/tobias-zwingmann_chatgpt-ai-innovation-activity-7005151270218907648-sd99

این کانال یکی از دوستامه که کلی چیزای جذاب که اکثرا در حوزه nlp هستن رو براتون می‌ذاره هر روز.

این بشر از باحال‌ترین کساییه که می‌شناسم و کلا هم دو ساعت دیدمش، نمی‌دیدمش دق می‌کردم 😂❤️

دقیقا دانشمندا دارن چه غلطی می‌کنن که هنوز نمی‌شه همچین چیزی رو با پرینتر سه بعدی ساخت 🥺🥺

Listen to صدیق تعریف - تصنیف قدیمی by Musique Iran 4 on #SoundCloud
https://on.soundcloud.com/NymBR

#آهنگ

#file
#doc
#book
#software

Git manual
یه راهنمای خیلی خوب و ساده برای گیت.

قسمت دوم این رو من بنویسم تا وقتم خالیه و سوار مترو هستم😁

بخش دوم بیشتر اشاره به قوائد طراحی داره. طراحی اینجا یعنی طراحی کد، طراحی سطح تکنیکال. چطور یه ماژول، کلاس یا سرویس رو تمیز طراحی کنیم؟

1- متغیرها یا مقادیر قابل کانفیگ کردن رو در بالاترین سطح نگه‌ دارید. مثلا فرض کنید شما می‌خواید هر کاربر نتونه در دقیقه بیشتر از 10 بار به برنامه درخواست بفرسته. شما این عدد 10 رو می‌تونید به عنوان یک متغیر محلی داخل همون کلاس یا تابعی که این وظیفه رو داره نگه دارید. اما این شکلی تمیز نیست. چرا؟ چون این مقدار احتمالا از چندین جا نیاز به خوندنش وجود داره یا حتی می‌شه هر لحظه تغییرش داد. حالا به ازای هربار که بخواید بخونیدش مجبورید یک شی از کلاس بسازید و.... یا اگر چند جای مختلف این مقدار رو به صورت محلی تعیین کرده باشید، هر بار بخواید تغییر بدید باید همه رو تغییر بدید و ممکنه جایی رو فراموش کنید. این تیپ متغیرها بهتره توی فایل‌های سطح بالا نگه داشته بشن. مثلا توی فایل‌های .conf یا .env مثلا. حتی شاید از این هم بالاتر. مثلا توی متغیرهای pod توی k8s یا متغیرهای Container توی داکر.

2- داخل هر فایل فقط و فقط یک کلاس بنویسید. یعنی اصل تک وظیفگی رو حتی برای فایل هم رعایت کنید. اگر مجبور شدین تحت هر شرایطی چند کلاس رو توی یک فایل بگذارید، سعی کنید کلاس‌های فرعی‌ای که می‌دارید توی فایل صرفا کلاس‌های دیتا مدل باشن. یعنی کلاس‌هایی که صرفا ویژگی‌ها رو نگه می‌دارن و متد ندارن یا اگه دارن متدهاشون عملکرد آنچنانی ندارن.

3- هر کلاس باید صرفا، فقط و فقط وابستگی‌های خودش رو بدونه و اگر قراره داخل یک کلاس از یک کلاس دیگه استفاده کنید و برای استفاده از کلاس دوم نیاز دارید داده یا کلاس‌های دیگه‌ای رو استفاده کنید، این داده‌ها و کلاس‌ها باید توی همون کلاس بیان نه کلاس بالاتر. چرا؟ اولا کدتون کثیف نمی‌شه. دوما کلاس بالایی سبک می‌شه. سوما به مشکلات طراحی مثل وابستگی حلقه‌ای(Circular Dependency) برنمی‌خورید. چهارما اگه بخواید از کلاس بالایی جایی استفاده کنید نیاز ندارید که وابستگی‌های کلاس‌های داخلی رو هم فراهم کنید. پنجما اسکوپینگ پروژه به واسطه اون همه وابستگی توده مانند به هم نمی‌خوره.


4- کدهایی که قراره به صورت چند نخی(Multi Thread) اجرا کنید رو از سایر کدها تا حد ممکن ایزوله کنید تا مشکلاتی مثل مشکلات نقاط مشترک(بن‌بست، قحطی، رقابت، مشکلات خواندن و نوشتن همزمان و..) تا حد امکان کاهش پیدا کنن.


5- از over-configurability جلوگيری کنید. یعنی یه کلاس یا سرویس یا هرچیزی که می‌خواید توسعه بدید رو هی نیاید براش آپشن قابل کانفیگ کردن در نظر بگیرید! برنامه‌نویسی که بخواد از کلاس شما استفاده کنه خیلی اذیت می‌شه و این باعث می‌شه رفتار سرویس یا کلاستون خیلی متغییر و غیرقابل پیش‌بینی بشه.

6- از تزریق وابستگی استفاده کنید. این مورد شیشم خیییلی چیز مهم و بزرگیه و خودم هم حتی بعد از 4 سال یک درک کاملا صحیح، درست و روشن ازش ندارم. می‌تونم ازش استفاده کنم و 90% سوراخ سنبه‌هاش رو هم گشتم و بلدم ولی هنوز احساس می‌کنم خودم نمی‌تونم یه سیستم DI دیزاین کنم. برای همین توصیه می‌کنم خودتون برید بخونید و روی سواد ناقص من حساب باز نکنید.

این بخش توی کتاب در همین حد اشاره شده ولی مبسوط. اما حتی اگه کل کتاب‌های دنیا درمورد طراحی و ذهن طراح نوشته بشن، باز هم نمی‌تونن همه چیز رو پوشش بدن.

#software
#نرم_افزار
#یادگیری

یه جزوه برای الگوهای طراحی مهم

#software
#book
#learning

Listen to تصنیف آتش دل / خواننده: مهدیه محمدخانی by Mahdieh Mohammadkhani on #SoundCloud
https://on.soundcloud.com/7NGKs


آتشی در سینه دارم جاودانی
عمر من مرگیست نامش زندگانی...

عزیزانی اومدن و ادعای نزول و افول PHP رو کردن! باید بگم:

لذت ببرید واقعا ❤️
ارباب حلقه‌ها

امروز شرکت رو پیچوندم نشستم یه کار باحال کردم. از اون جایی که می‌دونم خیلی مشتاقید بدونید چکار کردم، نشستم براتون نوشتم ولی خیلی طولانی شد بردمش توی Draftهام🤦‍♂️
احتمالا براتون مطلبش رو بنویسم. ای کاش می‌تونستم وویس بدم بهتون. وویس بدم؟😂

چشم من اینو امشب براتون می‌نویسم. بعد از مدتی هم که اجازه انتشار گرفتم کدش رو براتون می‌ذارم رو گیت‌هاب که ببینید

"It will make artists obsolete!"

@backendlife

در موردش اینو می‌گن. اما من بررسی نکردم حقیقتش