بله | کانال کوشش
ک

کوشش

۶۸عضو
سلام.گیت‌نامه (۱)
توی این سری پست میخوایم در مورد نحوه «کامیت»، «برنچینگ»، «بازبینی کد»، «مرج کردن پول ریکوئست‌ها» و «نحوه انتشار و استقرار» صحبت کنیم.
نحوه کامیت ۱:زود زود کامیت کنین و تند تند پوش. با این پیش فرض که شما برای هر کاری که انجام میدین یک برنچ در اختیار دارین، توی مرحله نوشتن کد تا میتونین سریع کامیت و پوش کنین لازم نیست که کد کامپایل بشه یا یک فیچر کامل تموم بشه undefined ، این برنچ مال خودتونه پس توش راحت باشین undefined . صد البته که اگه کامیت‌ها تمیز و مرتب نوشته بشه توی مراحل بعد راحت‌تر هستین. undefined
نحوه کامیت ۲:توی برنچ مستر ما، فقط و فقط کامیت‌های تمیز وجود دارن بعد از اینکه کارتون تموم شد و خواستین کد رویو بدین اولین کاری که باید بکنین تمیز کردن کامیت‌ها هستش. کامیت تمیز چیه؟ undefined کامیت تمیز چند ویژگی داره۱. به طور مستقل معنا دار هستش. ینی وقتی من دیف یک کامیت رو میخونم فارغ از اینکه کامیت قبل و بعدش چی هستش متوجه میشم که یه کار انجام شده. مثل نوشتن یک api جدید یا اضافه کردن دکمه ارسال پیام توی پروفایل کاربرا. میشه برای اینکه مطمئن بشیم یه کامیت معنا دار هست یا نه از خودمون بپرسیم آیا با اضافه شدن این کامیت به مستر چیزی به مستر اضافه میشه؟ جواب باید بله باشه.۲. باعث کامپایل نشدن مستر نمیشه. در نتیجه توی مستر ما می‌تونیم از روی هر کامیتی برنچ بسازیم و یه کاری رو شروع کنیم.۳. توضیح کامل توی کاری که انجام شده توی کامیت وجود داره.۴. مستند کد‌ها وجود داره.برای هر کامیت با توجه به جنس کاری که انجام شده از یکی از کلید واژه‌های زیر استفاده می‌کنیم.feat => اضافه شدن یک فیچر جدید به کدfix => اصلاح مشکلی در کدrelease => انجام کارهای مربوط به ریلیز. توجه داشته باشین که توی برنچ ریلیز هیچ کدی زده نمیشه!! اگه نیاز به کد باشه میشه خیلی راحت یه برنچ دیگه زد و بعد از مرج شدن اون برنچ کامیت‌های لازم رو به برنچ ریلیز منتقل کرد.chore => انجام کارهایی که تاثیری در عملکرد و منطق کد نمیذارهref => انجام اصلاحات ساختاری توی کد
برای مشخص کردن تیم مالک کد هم از یکی از کلیدهای زیر استفاده می‌کنیم.botmoneymessagingbank
و برای مشخص کردن تسک مربوط به کامیت هم از الگو زیر استفاده می‌کنیم.related #MES-23
نمونه‌ای از یک کامیت خوب
feat(money): Implements save recent card (title)
This implementation dose not have encryption. (body)
related #MON-123 (footer)
خب حالا چه جوری میشه که یه برنچ شلوغ پلوغ و راحت داشت و اونو تبدیل به یه برنچ تمیز کرد؟ خوبه در مورد ۲ کامند گیت سرچ کنین undefined git rebase --interactive
git merge --squash

توی لینک زیر هم می‌تونین گیت‌نامه رو کامل توی داکستان بخونین.http://doc.voroodi.ir:8080/pages/viewpage.action?pageId=46203253

۱۹:۴۸

سلامگیت‌نامه (۲)
توی پست اول در مورد نحوه کامیت کردن صحبت کردیم. حالا که با کامیت کردن و کامیت تمیز آشنا شدیم، می‌خوایم در مورد برنچینگ صحبت کنیم.
برنچینگ:ما توی همه پروژه ها یه برنچ به اسم مستر داریم. هیچ برنچی ساخته نمیشه مگر از روی برنچ مستر و هیچ برنچی مرج نمیشه مگر با مستر. undefined برنچ‌هایی که ساخته میشن حداکثر ۲ روز عمر می‌کنن ولی ما خیلی دوست داریم که هر برنچ یه روز بیشتر عمر نکنه و سریع پاک بشه. اسم این مدل رو میذاریم مدل کاکتوسی ، از اینا که دیگه روی میز من نیستش!هر برنچی که ساخته میشه یه دلیلی داره، اسم هر برنچ رو با توجه به کاربرد اون برنچ از روی یکی از مدل‌های زیر می‌سازیم.
feature/*این برنچ‌ها برای اضافه کردن ویژگی‌های جدید به کد استفاده می شن. این ویژگی جدید می‌تونه معماری جدیدی باشه که به خاطرش داریم کد رو ریفکتور میکنیم.
hotfix/*این برنچ‌ها مربوط به رفع مشکلات جدی هستش که توی کد به وجود اومده و باید سریع یه فکری براش بکنیم وگرنه منجر به فاجعه‌ای بزرگ میشه.
release/*این برنچ‌ها مربوط به انجام کارهایی هستش که همیشه قبل نسخه دادن باید انجام بشه. نسخه فقط و فقط از روی این برنچ‌ها داده میشه
bugfix/*این برنچ‌ها مربوط به رفع مشکلات و باگ‌های موجود در کد هستش.
توی لینک زیر هم می‌تونین گیت‌نامه رو کامل توی داکستان بخونین.http://doc.voroodi.ir:8080/pages/viewpage.action?pageId=46203253

۱۹:۴۸

سلامگیت‌نامه (۳)
توی دو پست قبلی در مورد کامیت و برنچینگ صحبت کردیم. حالا وقتش رسیده که ببینیم بعدش چه بلایی سر کد میاد! undefined
بازبینی کد:قبل از کد ریویو دادن برای هر برنچی طبق ریویو نامه به تعداد کافی باید اعضای جوخه باید کد رو بازبینی کرده و تایید کنن. برنچی که برای بازبینی میاد باید طبق تعریفی که از تمیزی توی نحوه کامیت ۲ داشتیم تمیز باشه. هر جوخه می‌تونه خودش در مورد نحوه اجرای بازبینی کد، طبق ریویو نامه، تصمیم بگیره و روش خودش رو داشته باشه ولی نباید فراموش کنیم که بازبینی کد نباید طولانی بشه. قرارمون این بوده که هیچ برنجی بیش از دو روز عمر نکنه.
مرج کردن پول ریکوئست‌ها:مرج پول ریکوئست توسط سرجوخه انجام میشه. قبل از مرج حتما باید بازبینی کد انجام شده و شرایطی که در بخش بازبینی کد گفته شد ارضا شده باشن.
نحوه انتشار و استقرار:برای انتشار حتما باید تست‌ها پاس شده باشه و مطمئن باشیم مشکلی وجود نداشته. بعد از اون با مدیر محصولمون هماهنگ می‌کنیم تا نسخه ما رو تایید کنه و در اسرع وقت نسخه ما عملیاتی بشه.اینجوری هر مرج ما می‌تونه نسخه‌ای باشه که با صلاحدید مدیر محصول منتشر میشه.
توی لینک زیر هم می‌تونین گیت‌نامه رو توی داکستان بخونین.http://doc.voroodi.ir:8080/pages/viewpage.action?pageId=46203253

۱۹:۴۸

سلامریویونامه (۱)
توی این سری پست می‌خوایم در مورد کد ریویو صحبت کنیم از چرایی تا چگونگی.
چرا کد ریویو؟ در زمان‌های دور وقتی تیم کوچیکی بودیم، هر کسی تسکی داشت و سعی می‌کرد به بهترین شکل ممکن تسکش رو انجام بده. اما از یه جایی به بعد، به کدمون که نگاه کردیم، دیدیم عهههه undefined یه کد داریم با کلی دست خط مختلف! که شاید بعضیاش هم بد خط بودن! undefinedundefined این موقع بود که مغزهای متفکر بله به کار افتادن! undefinedundefinedاولین پیشنهادی که مطرح شد این بودش که خب معلومه یه نفر قبل از مرج شدن کد، همه کدها رو نگاه کنه اگه خوش خط و خوانا بودن باگ نداشتن و ... مرج بشن اون یه نفر رو بعدها، مراج (زیاد مرج کننده) نامیدیم undefinedخیلی زود دیدیم که مراج نشسته لب پنجره، با دلی شکسته میخونه
"با هجوم پول ریکوئست فراوان چه کنم؟با غم انگیزترین نغمه توسعه دهنده چه کنم؟در غمش، چشمه‌ی خوناب ز چشمم جاریستبی تو با جوشش این پول ریکوئستا چه کنم؟"
دوباره مغزهای متفکر دست به کار شدن و ضمن یادآوری این نکته به مراج، که دیگه شعر نگو، شروع کردن به فکر کردن در مورد مشکل. نتیجه‌ای که از تفکرات عمیقشون حاصل شد این بود که خب به جای زیاد مرج کننده، مرج کننده زیاد داشته باشیم. undefinedundefined
و این شروعی بود بر داستان کد ریویو در بله undefined
توی لینک زیر هم می‌تونین ریویونامه رو توی داکستان بخونین.http://doc.voroodi.ir:8080/pages/viewpage.action?pageId=56820022

۱۶:۲۷

thumbnail
سلامریویونامه (۲)
توی پست قبل در مورد چرایی کد ریویو صحبت کردیم. اما الان میخوایم ببینیم مزایای کد ریویو چیه؟
توی تصویر بالا از ۱۱۰۰ توسعه دهنده نظرشون رو در مورد مزایای استفاده از کد ریویو در سال ۲۰۱۸ پرسیدن و گزینه‌های بالا حاصل شده.
مزایای کد ریویو:۱. تقویت انگیزه: وقتی که قرار باشه کد من و کار من رو چند نفری ببینن ناخودآگاه می‌رم به سمت تمیز و با دقت انجام دادن کارم. اینکه کار و ایده‌های من توسط بقیه دیده بشه جذاب هستش. نظرات بقیه چیزایی که می‌تونم به بقیه یاد بدم و از بقیه یاد بگیرم.۲. انتشار دانش: کد ریویو یکی از ارزشمند‌ترین روش‌ها برای مشارکت توی یه پروژه محسوب میشه - کد ریویو کننده می‌تونه با پیشنهادات و تغییراتی که توی کد ریویو می‌ده دانشی که داره رو در اختیار بقیه بذاره. - کد ریویو دهنده می‌تونه ایده‌ها و الگوریتم‌هاش رو توی کد ریویو با بقیه شرکت به اشتراک بذاره - دانش مربوط به یک ویژگی یا کاری که کد ریویو دهنده داره انجام میده دیگه مختص خود فرد نمی‌مونه و بقیه هم ازش خبر دارن و می‌تونن در صورت لزوم بهش کمک کنن. - با کد ریویو می‌شه ارتباط سازنده‌ای بین افراد شرکت در تیم‌ها و بخش‌های مختلف ایجاد کرد.۳. یکپارچگی رسم الخط: با استفاده از کد ریویو می‌تونیم رسم الخط کد بیس رو یکپارچه نگه داریم. این یکپارچگی همکاری بین افراد درگیر کد رو راحت‌تر می‌کنه و در خیلی از موارد از به وجود اومدن خطاها جلوگیری می‌کنه.۴. افزایش خوانایی و راحتی نگه‌داری: زمانی که قرار هستش کد من توسط فرد دیگه‌ای بازبینی بشه سعی می‌کنم کد رو طوری بنویسم که نیازی به توضیح برای کس دیگه‌ای نداشته باشه این عدم نیاز به توضیح باعث می‌شه در آینده نگه‌داری کد با هزینه کمتری انجام بشه، چون دیگه لازم نیست که توسعه دهنده همراه کدش باشه تا بشه کد رو فهمید.۵. کاهش خطاها: وقتی کد توسط فرد ثالثی بازبینی میشه از فضایی خارج از فضای توسعه دهنده اصلی بهش نگاه می‌شه این نوع نگاه متفاوت در خیلی از موارد می‌تونه راه گشا باشه و مشکلات ریز و درشتی رو حل کنه مشکلاتی از جنس معماری، منطق، ساختار، امنیت و ...طبق بررسی‌ها حل مشکل پیدا شده توسط تیم موفقیت مشتری یا کنترل کیفیت بیش از ۲ برابر هزینه داره تا زمانی که اون مشکل توی تیم توسعه پیدا بشه.
توی لینک زیر هم می‌تونین ریویونامه رو توی داکستان بخونین.http://doc.voroodi.ir:8080/pages/viewpage.action?pageId=56820022

۱۲:۲۰

سلامریویونامه (۳)
چه چیزی رو باید ریویو کرد؟ همه چی! چرا؟ به دلایل بالا! undefined طول می‌کشه! بلی کد ریویو کار زمان‌بری هستش ولی بخش مهمی از کار محسوب میشه.می‌شه حالا این دفه رو از دلایل بالا گذشت؟ معلومه که نه! دلایل بالا خیلی مهم هستن undefined یکی می‌گفت کد ریویوها مثل یه غول بی شاخ و دم می‌مونن اگه رهاشون کنین بر می‌گردن و می‌خورنمون پس مراقب خودمون باشیم! undefinedundefined
چه زمانی باید ریویو کنیم؟کد ریویو کار زمان‌بری هستش با تمام خوبی‌هایی که داره باید حواسمون باشه که توش وقت تلف نکنیم. بعضیا میگن بهترین زمان کد ریویو دقیقا بعد از اجرا شدن تست‌های CI هستش یا بعد از هر چک اتوماتی که داریم!پس تا می‌تونیم تست بنویسیم و هر چیزی رو که می‌تونیم اتومات کنیم ، دقت کنیم که وقت طلاست پس بهترین استفاده رو ازش بکنیم.
چه جوری آماده کد ریویو بشیم؟کد ریویو مثل یه مجلس اشتراک دانش می‌مونه! برای رفتن به مجلس هم خب باید آماده بود. برای دادن کد ریویو لازم هستش که کدمون یه سری ویژگی داشته باشه:۱. توی مرحله اول باید یه دور خودمون به قد و بالای کاری که کردیم ر یه نگاه بکنیم! یه دور کامپایل رو چک کنیم، تستا رو چک کنیم و ... تا یه وقت خدایی نکرده دسته گل مون توی کد ریویو پر پر نشه و با غروری شکسته برگردیم سر جامون!۲. توی مرحله بعد یه کد ریویو باید خودش گویای حالش و کارش باشه. پس لازم هستش هر کد ریویو یه توضیحی داشته باشه مفید و مختصر در مورد کاری که می‌کنه و اتفاقاتی که افتاده. این توضیح می‌تونه بسته به کامیت و حجم و اهمیت کار متفاوت باشه. اولین چیزی که ریویو کننده بهش نگاه می‌کنه تغییرات و توضیحات مربوط به کد ریویو هستش. چرا این کد نوشته شده و با چه هدفی؟
نکته: بعضی وقتا پیش میاد که ما یه کد رو بنا به هزار و یک دلیل ریفکتور می‌کنیم. ریفکتورها معمولا خییییلی بزرگ هستن و کد ریویو کردنشون خیییییییلی کار سختی هستش! راه حل چیه؟ خیلی ساده است. تا می‌تونیم ریفکتورها رو بشکنیم همچنین توی ریفکتور به منطق برنامه و ویژگی‌های برنامه کاری نداشته باشیم تا کسی که قرار هستش کد رو بازبینی کنه با خیال راحت فقط بره سراغ ساختار و پترن و ... . تازه اونا رو هم اتومات کردیم قبلا! پس کار خیلی ساده میشه!
توی لینک زیر هم می‌تونین ریویونامه رو توی داکستان بخونین.http://doc.voroodi.ir:8080/pages/viewpage.action?pageId=56820022

۲۰:۲۳

سلامریویونامه (۴)
توی پست‌های قبلی در مورد چرایی کد ریویو، مزایا و آداب و رسوم اولیه اون خوندیم. توی این پست می‌خوایم در مورد اینکه چه طور کد ریویو بهتری داشته باشیم بخونیم.
چه جوری کد ریویو کنیم؟کد ریویو میدون جنگ نیست! در نهایت قراره مجلس بزمی باشه. در طول کد ریویو لبخند بزنین undefinedundefined و تا می‌تونین از هم یاد بگیرین.به ریویو دهنده احترام بذارین اگه نمی‌تونین توی چند ساعت ریویو کنین بهش خبر بدین.اون اپرو و تایید حرمت داره! ما مسئول حفظ کیفیت کد هستیم! پس اگه چیزی واضح نیست سوال بپرسین ولی یادتون باشه که هنوز توی مجلس بزمیم پس لبخند فراموش نشه. undefined نظر بقیه رو بپرسین.سعی کنین دانشتون رو به اشتراک بذارین و از بقیه یاد بگیرین. دلیل سوال یا درخواست‌هاتون رو توضیح بدین از جملاتی مثل "برو این کار رو انجام بده؟" یا "این آشغال چیه نوشتی؟" استفاده نکنین. هیچ چیزی بدون توضیح ارزش نداره. سعی کنین reference بدین ، به clean code یا هر جای دیگه‌ای که لازمه.همه ما آدمیم حواستون باشه. توی کد ریویو در مورد کد صحبت کنین، نه توسعه دهنده کد!
- هدف این کد چیه؟ قرار چیکار کنه؟- آیا گیت نامه رعایت شده؟ کامیت‌ها تمیز هستن؟- آیا کد همون کاری رو می‌کنه که میگه؟- آیا تست‌های لازم برای کد نوشته شده؟- آیا همه چی درست کار می‌کنه؟- اگه این کد مرج بشه برای کاربرای قبلی و نسخه‌های قبلی چه اتفاقی میافته؟- اگه من بودم همینجوری مساله رو حل می‌کردم؟- کد خواناست؟ نیاز به کامنت و توضیح نداره؟- معماری و رسم الخط یکپارچگی لازم رو داره؟- دیپندسی‌های پروژه تغییر کرده؟ چرا؟ به چه حقی؟ چه طور؟- این کد رو قبلا جای دیگه توی پروژه دیگه ندیدم؟ تکراری نیست؟
در نهایت قبل از تایید کد باید به این نکته توجه کنیم که همه چی رو فهمیده باشیم نتایجش، نحوه اجراش و ... چیزی نمونده که بعدا بیاد بخورمون؟
نکات:کد ریویو کار زمان‌بری هستش. توی برنامه ریزی‌ها براش وقت در نظر بگیریم.برای اینکه حداکثر انتقال دانش توی کد ریویو اتفاق بیافته خوبه که اول آدمای کم تجربه‌تر و تازه وارد ریویو رو انجام بدن بعدش آدمای با تجربه بیشتر یا تک لید تیم. اینجوری هم توی وقت افراد صرفه جویی میشه هم از طیف‌های مختلف نظر و ایده گرفته میشه!اگه کد ریویوتون زیاد کامنت خورد لزوما به معنی این نیست که شما برنامه نویس بدی هستین یا کد بدی نوشتین. این کد ریویو می‌تونه پر از درس و ایده باشه، هم برای شما، هم برای بقیه.
با کد ریویوها و ریویو کننده‌ها چیکار کنیم؟کد ریویوها رو در اولین فرصت بررسی کنیم، یه جایی، یه تیمی کارش لنگ ماست.فقط یک راه درست وجود نداره. پس برای پذیرش و شنیدن راه حل‌های مختلف آماده باشیم.ریویو کننده‌ها هم کار دارن ، سعی کنیم مزاحمشون نشیم! ازشون زمان بگیریم برای کد ریویو. تا می‌تونیم بریم پیش ریویو کننده‌ها به ارسال لینک اکتفا نکنیم.به ریویو کننده‌ها احترام بذاریم، اگه سوالی می‌پرسن مطمئن بشیم که جوابش رو می‌گیرن، پس کامنتی بدون جواب نمونه.کد ما با ما یکی نیست! اگه کسی به کد ما ایرادی وارد می‌کنه قصد تخریب ما رو نداره! پس با آرامش سعی در بهبود مهارت‌های خودمون داشته باشیم.
بهبود کیفیت کد ریویو:هیچ چیزی بدون اندازه‌گیری بهبود پیدا نمی‌کنه!برای اینکه حواسمون به کیفیت کد ریویوها باشه اگه می‌تونیم ۳ مقدار زیر رو اندازه بگیریم.۱. مدت زمان انجام ریویو
۲. تعداد کامنت‌هایی که روی ریویو می‌خوره در ساعت
۳. متوسط تعداد کامنت‌هایی که روی یک کد ریویو می‌خوره

توی لینک زیر هم می‌تونین ریویونامه رو توی داکستان بخونین.http://doc.voroodi.ir/pages/viewpage.action?pageId=56820022

۱۸:۲۸

سلامریویونامه (۵)
توی پست‌های قبلی در مورد چرایی و چگونگی کد ریویو صحبت کردیم. توی این پست خلاصه‌ای از هر چیزی که گفتیم رو در قالب مرام‌نامه مرور می‌کنیم.
مرام نامه بازبینی کد بله:۰. هیچ کد ریویویی بدون دقیقا ۲ تا تایید مرج نمی‌شود.۱. قبل از دادن کد ریویو حتما خودتون یه دور کد رو به دید خریدار نگاه کنین.۲. وقتی کد ریویو میدین دقت کنین کد ریویو واضح و گویا باشه. حتما در مورد هدف کارتون توضیح بدین و اگه نیاز به توضیح بیشتری هستش حتما به کد ریویو اضافه بشه، حتی شده در حد یه خط.۳. به هیچ وجه کد ریویو رو یک نفره انجام ندین، صاحب کد حتما باید کنارتون باشه و با هم کد ریویو کنین.۴. هیچ کامنتی توی کد ریویو نباید بدون پاسخ بمونه.۵. از تمسخر و شوخی توی کد ریویو پرهیز کنین ، به ریویو کننده و دهنده احترام بذارین.۶. اگه کدی قرار هستش ریفکتور بشه تا جای ممکن کوچیک کوچیک و بدون دستکاری منطقی باشه.۷. هیچ کد ریویویی قرار نیست بیش از ۶۰ دقیقه زمان بگیره.۸. هیچ کد ریویویی نباید بیش از ۲۴ ساعت به تعویق بیافته.۹. ریویو کننده‌ها رو توی کد ریویو منشن کنین.۱۰. پول‌ریکویست‌ها پس از تایید ریویو کننده‌ها فقط و فقط توسط سازنده‌ی پول‌ریکویست مرج بشن.
توی لینک زیر هم می‌تونین ریویونامه رو توی داکستان بخونین.http://doc.voroodi.ir/pages/viewpage.action?pageId=56820022

۱۴:۰۸

بازارسال شده از مهربد خیابانی
سلام(1) clean code
آیا تا به حال این اتفاق برای شما افتاده که موقع انجام کاری که باید یک ساعت طول می‌کشیده ساعت‌ها یا شایدم روز‌ها درگیر بودید؟آیا تا به حال شده بعد از مدتی ببینید که هرروز نوشتن کد جدید سخت‌تر و سخت‌تر می‌شه؟آیا تا به حال شده که کاری که برای اضافه کردن یک قابلیت جدید باید انجام می‌دادید خیلی متفاوت‌تر و سردرگم کننده‌تر از کاری بوده که انتظار داشتید؟چرا این اتفاق میوفته؟ چه چیزیه که باعث می‌شه بعد از مدتی اینقدر کدها بزرگ و سردرگم کننده بشن که حتی نویسنده‌ی اون کد هم علاقه‌ای به دیدن کد خودش نداشته باشه؟جواب:‌ کد کثیفبعضیا با یک حس ذاتی برای تشخیص کد کثیف و درست کردن اون به‌ دنیا میان. ولی برای تشخیص کد کثیف و تبدیل اون به کد تمیز مثل هرکار دیگه‌ای نیاز به مهارت: دانش + تمرین هست.در برنامه نویسی دانش نوشتن کد تشکیل شده از کلی از قواعد. اما بدون تمرین به مهارت نوشتن کد تمیز دست پیدا نمی‌کنیم.طی پیام‌های آینده سعی بر این داریم تا به طور خلاصه این قواعد که در کتاب Clean Code اومده رو بررسی کنیم و توضیح بدیم که البته این تنها مرحله‌ی اول فراگیری مهارت هست. تمام این قواعد نیاز به کند و کاو و بررسی و زیر و رو کردن دارن تا در اون‌ها ماهر بشیم.

۱۲:۱۲

بازارسال شده از مهربد خیابانی
سلام(2) clean code
فصل اول: کد تمیزاهمیت کد تمیز از اونجایی مشخص می‌شه که سال‌های سال با کد کثیف دست و پنجه نرم کردیم و مشکلاتشو به چشم دیدیم.همه‌ی ما قصه‌های زیادی از شرکت‌های مختلف شنیدیم که در شروع یه برنامه‌ی خفن نوشتن ولی بعد از یه مدت دیگه نتونستن با بقیه رقابت کنن. دلیلشم این بوده که بعد از مدتی کدشون اینقدر بزرگ و غیر قابل خوندن و گسترش شده که دیگه نتونستن فیچرای جدیدی بهش اضافه کنن یا باگاشو رفع کنن.احتمالا ماهم زیاد با این مساله مواجه شدیم که بخاطر کدهای بد سرعت کد زدنمون کم شده و کاری که باید چند ساعت طول می کشیده چندین روز وقتمون رو گرفته.و حتی از اون جالب تر...ما خودمونم کدای کثیف نوشتیم. چرا؟ شاید برای این بوده که می خواستیم سریع‌تر محصول رو برسونیم. شاید فکر می کردیم که وقت انجام دادن کار درست رو نداریم. شاید فکر می کردیم که اگه کارمون رو کمی بیشتر براش زمان بذاریم بقیه از دستمون عصبانی می‌شن. اما مطمین باشید نوشتن کد خوب همیشه ارزشش بیشتره. هرچقدر که کدای کثیف بیشتری تولید کنیم از اون طرفم ایجاد و گسترش فیچرای جدید یا رفع کردن باگ‌ها زمان بیشتری از ما میگیره چرا که نمی تونیم از کدای جدیدی که نوشته شده سر در بیاریم. کد کثیف رو احتمالا همه دیدیم...کدی که هرچی می خونیمش نمی تونیم از کاری که انجام می‌ده یا هدف از انجام کاراش سر در بیاریم. هرچی توش می‌گردیم بیشتر و بیشتر سردرگم می‌شیم و بعد یه مدت می بینیم که پروژه‌ای داریم که دیگه هیچی از کلش سر در نمیاریم.
هنر نوشتن کد تمیزفرض کنیم با این حرفا به این نتیجه رسیدید که کد تمیز چیز خوبیه و می خوایم کد تمیز بنویسیم. خب حالا سوال اینجاست که چطوری کد تمیز بنویسم؟ به اندازه‌ی تعداد برنامه نویسا برای این سوال جواب درست وجود داره. ولی ما اینجا به صورت سطحی به این سوال که کد تمیز چیست؟ که از چند نفر از برنامه نویسای بزرگ پرسیده شده اشاره می‌کنیم:-کدی که با سلیقه نوشته شده باشه-کارامد-منطق برنامه واضح باشه-وابستگی زیاد در ماژول ها موجود نباشه-با یک سیستم واحد ارور ها هندل شده باشن-کد به قدری بهینه باشه که بقیه تصمیم به عوض کردنش نگیرن.-فقط یک کار انجام بده.-ساده باشه مثل یک شعر زیبا و روان-مقصود نویسنده‌ی کد رو به طور واضح و مفهومی برسونه-به سادگی قابل خوندن و فهمیدن باشه-توسط دیگران قابل گسترش باشه-تمام تستای خودشو پاس کنه-اسم‌های با معنی داشته باشه-به جای ارایه‌ی چند راه حل برای یک کار فقط یک راه حل ارایه بده-کد تمیز به گونه‌ای نوشته شده که گویا کد برای نویسنده‌ی اون خیلی مهم بوده.-کد داپلیکیت -تعداد موجودیت ها رو به حداقل می‌رسونه-به طوری نوشته شده که هر کار تقریبا همونطور که به نظر می رسه انجام می‌شه-کد طوری نوشته شده باشه که انگار اون زبان برنامه نویسی فقط برای کد ما ساخته شده
و در آخراگه دقت کرده باشید در جاواداک بالای کد نام یک نویسنده که شمایید لازمه. ما نویسنده‌های کد هستیم. و به عنوان یک نویسنده لازمه اطمینان حاصل کنیم که کدمون قابل خوندن و روون باشه چرا که نویسنده برای خواننده‌ها می نویسه. طی پست‌های بعدی قصد داریم تا قوانینی که کد ما رو تمیز می کنه بررسی کنیم و سعی کنیم که با تمرین و مثال توی اونا مهارت پیدا کنیم. مسلما مهارت بدون تمرین به دست نمیاد.شاید بپرسید که خب حالا از الان به بعد اگه کد تمیز بنویسیم کدای تمیز قبلی رو چیکار کنیم؟ خب برای اینم راه‌های مختلفی هست ولی یک راه هست که بهتره سعی کنیم همیشه اونو انجام بدیم: قانون پیش‌‌آهنگ‌هااین قانون می‌گه که زمین رو از اون حالتی که واردش شدی تمیز تر ترک کن. و با رعایت این قانون آروم آروم کدای کثیف ما به کدای تمیز تبدیل خواهند شد.#clean_code

۶:۲۸

بازارسال شده از مهربد خیابانی
سلام(3) clean code
فصل دوم:‌ نام‌های معنی‌دار (۱ از ۲)اسم‌ها همه جا هستن. ما برای متغیرامون - توابعمون - کلاسامون - پکیجامون - فایلامون - آدرسامون و ... اسم انتخاب می‌کنیم. بنابراین چون خیلی زیاد این‌ کارو می‌کنیم بهتره که درست انجامش بدیم. در ادامه به یکسری قوانین ساده برای انتخاب اسم اشاره می‌شه. یک اسم باید به سوالای بزرگ ایجاد شده در رابطه با متغیر یا تابع مورد نظر پاسخ بده.
از اسامی رساننده‌ی مفهوم استفاده کنید:مساله‌ی انتخاب اسم با مفهوم مساله‌ی خیلی ساده ولی خیلی مهمیه. اگرچه این مساله ممکنه زمانبر باشه ولی مطمین باشید که بیشتر از اینکه زمان ببره زمان صرف شده برای فهمیدن کد رو کاهش می‌ده. به مثال زیر توجه کنید:‌

int d; // elapsed time in days
از حرف d که به عنوان اسم انتخاب شده چه چیزی می‌شه فهمید؟ آیا می‌شه از فقط همین یک حرف مفهوم گذر زمان به روز رو متوجه شد؟ به علاوه اگه اسمی برای فهمیدنش نیاز به کامنت داشته باشه پس واضحه که اسم درست انتخاب نشده. برای این مثال می‌شه از اسامی زیر استفاده کرد:

int elapsedTimeInDays;
int daysSinceCreation;
int daysSinceModification;
int fileAgeInDays;

از دادن اطلاعات غلط بپرهیزید:نباید با اسم‌ها اطلاعات اشتباهی منتقل کرد. برای مثال accountList در صورتی یه اسم مناسبه که واقعا نام یک لیست باشه. (البته جلو تر متوجه خواهیم شد که باز هم نیاز به تغییر داره) احتمالا accounts یا accountGroup نام مناسب‌تری برای این متغیره در صورتی که لیست نباشه. اسامی نباید طوری باشن که خیلییی جزیی با هم دیگه فرق دارن. مثلا HelloWorld و HellOWorld تشخیص تفاوتشون زمانبر هست. همینطور از استفاده از l (ال کوچک) و O (او بزرگ) در کد بپرهیزید که شبیه اعداد یک و صفر هستن و تشخیصشون سخته.
تفاوت‌های با معنی ایجاد کنید:برنامه نویسا وقتی فقط برای کار کردن کامپایلر اسمی رو انتخاب می‌کنن در اصل دارن برای خودشون دردسر درست می‌کنن. مثل نامگذاری با استفاده از پسوند شماره.‍‍‍```public static void copyChars(char a1[], char a2[]);```از کجا باید بفهمیم که از کدوم متغیر داخل کدوم متغیر دیگه ریخته می شه؟ شاید اسامی source و destination اسامی بهتری باشن. همینطور بعضی کلمات هستن که فقط یک صدای بی معنی هستن و اگرچه کامپایلر رو راضی میکنن ولی تغییری در معنی ایجاد نمیکنن. مثل Product ‌و کلمات ProductData , ProductInfo. دو کلمه Info , Data معنی کلمه‌ی اصلی رو تغییر ندادن و این باعث می‌شه خواننده‌ی کد متوجه نشه که از کدوم کلاس باید استفاده کنه.
از اسامی قابل تلفظ استفاده کنید:شاید به نظر ساده بیاد ولی به دلیل اینکه برنامه‌نویسی یک کار گروهی و اجتماعیه لازمه که اسامی رو قابل تلفظ بنویسید تا بقیه برای گفتنش به سختنی نیوفتن. به عنوان مثال int genymdhms یک مثال بده و تلفظ نشدنیه.
از اسامی قابل سرچ استفاده کنید:خیلی وقتا با سرچ کردن اسم مورد نظرمون به مقصودمون می‌رسیم. برای همین انتخاب اسمی که قابل جستجو باشه خیلی مهمه. کلمات کوتاه یا کلیشه‌ای و یا حروف برای سرچ مناسب نیستن. هرچقدر که یک کلمه طولانی تر باشه برای سرچ‌ کردن راحت‌تر هست. همینطور با توجه به اینکه IDE ها کلمات پیشنهادی خودشون رو با فقط تایپ کردن اول یک کلمه به ما می‌دن بهتره کلمه‌ی مرتبط به هم با حروف یکسانی شروع بشن و همینطور وقتی تفاوتشون واضح باشه انتخاب ساده تر خواهد بود.
@mehrbod#clean_codeادامه دارد...

۸:۲۲

بازارسال شده از مهربد خیابانی
سلام(4) Clean Code
فصل دوم: نام‌های معنی‌دار (۲ از ۲)از رمزگذاری بپرهیزید:ما به اندازه‌ی کافی با کدای رمز شده سر و کله می‌زنیم دیگه لازم نیست که توی نام‌هایی هم که انتخاب می‌کنیم رمزگذاری کنیم. به عوان مثال نوشتن نوع متغیر تو زبان‌هایی مثل جاوا که تایپ متغیر‌های معلوم هست. به عنوان مثال:

PhoneNumber phoneString;
همونطوری که تو مثال بالا می‌بینید برای متغیر نام phoneString انتخاب شده که نشون می‌ده قبلا نوع این متغیر از نوع String بوده ولی بعد از تغییر نوع متغیر نام متغیر عوض نشده. بنابراین توی اینجور زبان‌ها ما نیازی به گذاشتن اسم نوع متغیر در نام خود متغیر رو نداریم چرا که به راحتی می‌تونیم متوجه نوع متغیر بشیم.همینطور نیازی به گذاشتن پیشوند m برای فیلد‌های کلاس‌ها نداریم(که این موضوع بخصوص در اندروید شایع هست). به عنوان مثال:

public class Part {
private String mDesc;
{
همونطوری که می‌بینید پیشوند m بی‌مصرفه و می‌تونیم اسم متغیر رو با description جایگزین کنیم. به علاوه کلا ذهن اینطوره که به سرعت یاد می‌گیره تا پیشوند اسامی رو نبینه. :)
یک نکته‌ی مهم نامگذاری اینترفیس‌ها و پیاده‌شده‌ی اون‌هاست. خیلیا عادت دارن تا قبل اسم اینترفیس ها پیشوند I بذارن مثل IShapeFactory و پیاده‌شده‌ی اون ShapeFactory. اما بهتره که کاربر ندونه که اون چیزی که داره باهاش کار می‌کنه یه اینترفیسه. بنابراین اسم گذاری بهتر برای اینترفیس ShapeFactory و برای پیاده سازی اون ShapeFactroyImp هست.
از تصویر سازی ذهنی بپرهیزید:خوانندگان کد شما نباید مجبور باشن که کدی که شما نوشتین رو تو ذهن خودشون به یه چیز دیگه ترجمه کنن. این مشکل بخصوص زمانی زیاد پیش میاد که از یک حرف استفاده کنید. مثلا چطوری باید متوجه شد که حرف r شما به معنی url بدون هاست و اسکیمه؟ همینطور اساسا تک حرف باعث می‌شه که خواننده مجبور باشه اون حرف رو برای خودش تصویر سازی کنه تا متوجه بشه به چه چیزی فکر می‌کردید. البته i j k که برای حلقه‌ها استفاده می‌کنیم چون هم در اسکوپ کوچکی قرار دارن و هم هممون باهاشون آشناییم مشکلی ایجاد نمی‌کنه.تفاوت یه برنامه نویس باهوش و یه برنامه نویس حرفه‌ای اینه که برنامه نویس حرفه‌ای میدونه واضح کد نوشتن خیلی مهمه
نام کلاس‌ها:کلاس‌ها و شی‌ها باید اسم یا اسم حرف داشته باشن مثل Account - Customer - WikiPage و AddressParser. از اسامی‌ای مانند Manager - Processor - Data - Info بپرهیزید چرا که اسامی یک کلاس نباید قید باشن.
نام متدها:متدها بهتره نامشون فعل یا عبارت فعلی باشن مثل postPayment - deletePage یا save. همینطور از get set و is در جای درست خودشون برای دسترسی به فیلد‌ها باید استفاده بشن.
شیرین بازی در نیارید :) :کلمات رو به شوخی ننوسید. از کجا باید فهمید که HolyHandGranade یعنی DeleteItems؟
برای هر موضوع فقط یک کلمه انتخاب کنید:برای هر مفهوم فقط یک کلمه انتخاب کنید و همون رو ادامه بدید. به عنوان مثال fetch - retrieve و get همشونیک معنی دارن و نباید تو برنامتون از این‌ کلمات به طور متفاوت استفاده کنید.
برای موضوعات مختلف از یک کلمه استفاده نکنید:اگه از قانون قبلی استفاده کنید ممکنه که اینطور بشه تا کلی کلاس داشته باشیم با متد add. باید حواسمون رو جمع کنیم تا با add هایی که معانی مختلف دارن کدمون رو کثیف نکنیم.
از نام‌های مرتبط با راه‌حل مورد نظر استفاده کنید:به ‌یاد داشته باشید که خوانندگان کد شما برنامه‌نویس هستن. بنابراین می‌تونین راحت از اسامی مرتبط با کامپیوتر نام الگوریتم‌ها پترن‌ها اسامی ریاضی و ... استفاده کنید.
از نام‌های مرتبط با مساله استفاده کنید:وقتی روی مساله‌ای وقت می‌ذارید از نام‌های مرتبط با همون مساله استفاده کنید.
کانتکست با‌معنی ایجاد کنید:تعداد کلماتی که خودشون ذاتا معنی دارن زیاد نیستن. به جاش لازمه که کانتکست مناسب ایجاد کنیم تا این کلمات محدود رو به اندازه پروژمون گسترش بدیم. به عنوان مثال firstName lastName address phoneNumber به خودی خود می‌تونن برای هرچیزی باشن. اما وقتی توی یک کلاس به اسم Postal قرار بگیرن معلوم می‌شه که اطلاعات لازم یک فرد برای پست یک محصول هست.
کانتکست بی‌مصرف اضافه نکنید:فرض کنید برنامه‌ای به اسم Gas Station Deluxe داریم. به نظر شما منطقیه که اول اسم هر کلاسی GSD رو بنویسیم؟ اینکار باعث عدم کارایی IDE هامون تو پیدا کردن اسم‌هایی که دنبالشون می‌گردیم می‌شه.
سخن آخراسم‌گذاری از این جهت سخته که تکنیک توصیفی زیادی رو میطلبه. این بیشتر یک مبحث آموزشیه تا یه مبحث تکنیکی و با کمی آموزش و تمرین درست می‌شه.
@mehrbod#clean_code

۱۴:۲۶

بازارسال شده از میلاد فریدنیا
سلام (5)Clean Code
در این نوشته تلاش می‌کنیم که چکیده‌ای از فصل سوم کتاب عمو باب در مورد توابع را برای شما دوستان ارائه کنیم.برای این که بتوانیم توابع خوبی بنویسیم باید برخی از نکات ایمنی!!! را رعایت کنیم. در ادامه به شرح مختصر این نکات می‌پردازیم.
کوچکاحساس می‌کنم که عمو باب تمام چیزی را که قرار بود توضیح دهد را در همین تیتر ساده گنجانده است. توابع باید تا حد امکان کوچک باشند والسلام.تعداد خطوط یک تابع باید خیلی به سختی بیست خط برسد.طبق مثال‌ها و توصیه‌های عمو باب اندازه مناسب برای یک متد چیزی در حدود ۴ خط است. (پس ای کسانی که تابع شومصد و شصتاد خطی می‌نویسید. وای بر شما !!!)
بلاک‌هابا این توصیه‌ انتظار می‌رود که عبارات درون if و else و یا while و... یک خطی باشند که این خط احتمالا فراخوانی یک تابع است. با رعایت این نکته نه تنها توابعمان کوچکتر می‌شوند بلکه این توابع ارزش مستندی!!! نیز پیدا می‌کنند چرا که تابع درون یک بلاک می‌تواند دارای یک نام آگاه‌کننده و رساننده مفهوم باشد.به علاوه، توابع نباید انقدر بزرگ باشند که شامل ساختارهای تو در تو باشند.
فقط یک کار را انجام بدهخیلی ساده، واضح و مشخص. در این خصوص آن حضرت می فرمایند: توابع باید یک کار انجام دهند. توابع باید آن کار را به خوبی انجام دهند. آنها باید فقط همان کار را انجام دهند. زیبا نیست!!!خوب از کجا بفهمیم که توابع فقط یک کار را انجام می‌دهند؟ پاسخ: به سختی. اما اگر تابع کارهایی را انجام می‌دهد که فقط یه سطح از نام تابع پایین‌تر هستند پس این تابع فقط یک کار انجام می‌دهد. در ادامه برخی از توصیه‌ها در مورد نحوه تشخیص این مورد را بررسی می‌کنیم.
بخش‌های مختلف درون یک تابعاگر درون تابع شما بخش‌های مختلفی از جمله بخش تعاریف، مقداردهی و... وجود دارد این یعنی به طور قطع تابع شما بیش از یک کار را انجام می‌دهد.
یک مرحله از ابسترکشن به ازای هر تابعبرای اینکه دریابید تابع شما فقط یک کار را انجام می‌دهد باید از این مسئله اطمینان حاصل کنید که تمام عبارات درون تابع در یک سطح مشابه از ابسترکشن هستند و برای هر سطح که پایین تر می‌روید باید یک تابع جداگانه بنویسید.
سوئیچ‌هاسوئیچ‌ها ذاتا بیشتر از یک کار انجام می‌دهند. به این قطعه کد دقت کنید و اشکالات آن را پیدا کنید.
switch (e.type) { case COMMISSIONED:
return calculateCommissionedPay(e); case HOURLY:
return calculateHourlyPay(e); case SALARIED:
return calculateSalariedPay(e); default:
throw new InvalidEmployeeType(e.type); }
}
اول از همه این که این تابع بزرگ است. تازه با افزایش نوع کارمندان بزرگتر هم می‌شود.دوم: واضح است که بیش از یک کار را انجام می‌دهد.سوم: اصل اول Solid را نقض می‌کند. چون بیش از یک دلیل برای تغییر دادنش وجود دارد.چهارم: اصل دوم Solid را هم نقض می‌کند چون هنگامی که انواع جدیدی اضافه شوند باید تغییر کند.پنجم: و شاید بدترین ایراد این تابع آن است که با این طراحی تعداد فراوانی تابع دیگر هم با ساختار مشابه در کد پیدا می‌شوند. مثلا
isPayday(Employee e, Date date)``` و یا
```deliverPay(Employee e, Money pay)
برای بهبود این قطعه کد به طور خلاصه باید گفت که می‌توان سوئیچ را در جایی به نام abstract factory مخفی و دفن کرد و از انتشار بیشتر آن در کد جلوگیری کرد. مانند این کد:
public abstract public abstract public abstract
boolean isPayday();
Money calculatePay();
void deliverPay(Money pay);
}
-----------------
public interface EmployeeFactory {
public Employee makeEmployee(EmployeeRecord r) throws InvalidEmployeeType; }
-----------------
public class EmployeeFactoryImpl implements EmployeeFactory {
public Employee makeEmployee(EmployeeRecord r) throws InvalidEmployeeType { switch (r.type) {
case COMMISSIONED:
return new CommissionedEmployee(r) ;
case HOURLY:
return new HourlyEmployee(r);
case SALARIED:
return new SalariedEmploye(r);
default:
throw new InvalidEmployeeType(r.type);
} }
}
از نام‌های توضیح‌دهنده استفاده کنید.از انتخاب یک نام طولانی نترسید. یک نام بلند توضیح دهنده برای یک متد بهتر از یک کامنت بلند بالا در مورد آن متد است.
پی‌نوشت : امیدوارم این مطلب براتون مفید بوده باشه و در پایان چیزی به دانسته‌هاتون اضافه کرده باشه. خیلی خوشحال میشم که بازخوردتون رو در مورد این مطلب به آی‌دی‌‌ @miladfaridnia بفرستید.
ادامه دارد ...#Clean_Code

۱۱:۴۴

بازارسال شده از میلاد فریدنیا
سلام (6)Clean Code
پارامترهای ورودی یک تابعتعداد ایده آل پارامترهای ورودی یک تابع صفر است. (به قول بزرگی: تابع اگر تابع باشد که خودش بدون نیاز به پارامتر باید کارش را انجام دهد. قال آقا بهنام علیزاده )یک دو و سه پارامتر در مرحله‌ی بعد قرار می گیرند. اما چهار پارامتر را بسیار با احتیاط استفاده کنید. اگر به نظر می‌رسد که تابعی بیش از چهار پارامتر ورودی نیاز دارد به احتمال زیاد می‌توان این پارامترها را درون یک کلاس قرار داد.
تابع هیچ اثر جانبی ای نداشته باشدگاهی اوقات علی‌رغم اینکه تابع شما تضمین کرده که فقط یک کار را انجام دهد اما به صورت مخفیانه کار دیگری نیز انجام می‌دهد. گاهی اوقات باعث تغییرات غیر منتظره‌ای در مقدار متغیرهای درون کلاس می‌شود. این امر باعث ایجاد وابستگی‌های خوف انگیز درون برنامه می‌شود.
آرگومان‌های خروجیدر حالت کلی باید از آرگومان‌های خروجی حذر کنید. اگر نیاز دارید که مقدار چیزی را تغییر دهید، آن را مستقیما و توسط شی مربوط به خودش تغییر دهید.
جدا کردن کامند و کوئریهر تابع یا باید به پرسشی پاسخ بدهد و یا کاری را انجام دهد اما هر دو را نه. تابع شما یا اطلاعاتی را در مورد چیزی فراهم می‌کند و یا استیت یک شی را عوض می‌کند. اما حواسمان باشد که انجام همزمان این دو ممکن است باعث گیج شدن خواننده شود.
public boolean set(String attribute, String value);
برای مثال تابع بالا مقدار متغیری با نام attribute را ست کرده و در صورت موفقیت خروجی true را بر می‌گرداند. اگر بیشتر دقت کنید این تابع کمی گنگ و گیج کننده است. کسی از تابعی با این نام انتظار خروجی boolean ندارد. راه درست انجام این کار جدا کردن کامند و کوئری است. مانند کد زیر:
}

Exception ها را به بازگرداندن error code ترجیح دهید
Try catch بلاک ها را به یک متد استخراج کنیدبلاک‌های try catch به خودی خود زیبا نیستند. وجود آنها درون یک متد باعث ادغام روند اصلی برنامه با روند پردازش خطا می‌شود. بنابراین بهتر است که بدنه این بلاک ها را به صورت یک متد جداگانه استخراج کرد.هندل کردن خطاها خود به تنهایی یک کار است.حواسمان باشد که تابع ما باید فقط یک کار را انجام دهد و کنترل خطا خودش به تنهایی یک کار محسوب می‌شود.
خود را تکرار نکنیدشاید بتوان گفت که کد تکراری منبع همه‌ی پلیدی‌ها و پلشتی‌ها در نرم افزار است. همیشه دقت کنید که اگر دارید کاری را دوباره و دوباره انجام می‌دهید حتما جایی از کارتان می‌لنگد. شاید با طراحی بهتر نیازی به تکرار نباشد.
چگونه تابعی تمیز و بی‌ایراد بنویسیم؟حال با دانستن این نکات در مورد توابع شاید بپرسید که چطور می‌توان این همه نکته ریز و درشت را در نوشتن یک تابع رعایت کرد؟ در پاسخ باید گفت که در نوشتن توابع همانند نوشتن یک انشا ابتدا ممکن است یک چرکنویس ابتدایی داشته باشیم که اصلا زیبا و تمیز نیست. اما می‌توان پس از این مرحله با انجام اقداماتی نظیر کوچک‌تر کردن توابع، بهبود نام‌گذاری‌ها و از بین بردن کدهای تکراری کد نهایی را مانند داستانی شیرین تبدیل کرد که خواننده از خواندن آن لذت می‌برد. فقط باید کمی زمان گذاشت و با دلسوزی به این فرایند نگریست.
پی‌نوشت : امیدوارم این مطلب براتون مفید بوده باشه و در پایان چیزی به دانسته‌هاتون اضافه کرده باشه. خیلی خوشحال میشم که بازخوردتون رو در مورد این مطلب به آی‌دی‌‌ @miladfaridnia بفرستید.
ادامه دارد ...#Clean_Code

۱۵:۴۹

بازارسال شده از Amir Mashayekhi
دسته‌بندی کاربران با مدل RFM(بخش اول)
مقدمهیک مرکز خرید همانند فروشگاه شهروند با تعداد زیادی تامین کننده و مشتری را درنظر بگیرید. به نظر شما آیا این شرکت باید برای همه مشتریانش یک سیاست قیمت‌گزاری ثابت به‌کار گیرد یا این‌که بهتر است به کسانی که بیشتر می‌خرند تخفیف بیشتری دهد؟
یا یک سامانه خدمات تاکسی آنلاین را در نظر بگیرید که قصد دارد با ایجاد یک کمپین، میانگین روزانه تعداد سفر رانندگان را افزایش دهد. با توجه به هزینه تبلیغات به نظر شما آیا منطقی است که این تبلیغات برای همه راننده ها نمایش داده شود یا بهتر است برای رانندگانی که بیشتر سفر می‌کنند و احتمال پاسخشان به تبلیغات بیشتر است نمایش داده شود؟
مدل RFM به تحلیل رفتار و بیان تفاوت مشتریان با استفاده از 3 متغیر می‌پردازد :
تازگی خرید (Recency) : مدت زمان بین آخرین خرید و زمان حال. هرچه این مدت کوتاه‌تر باشد، ارزش R بیشتر است. مثلا آخرید تراکنش فرد 8 روز پیش است.
تعداد تکرار خرید (Frequency) : نشان دهنده تکرار خرید است و تعداد تراکنش ها در یک بازه مشخص را نشان می دهد. به عنوان مثال 2 بار در سال.
ارزش پولی خرید (Monetary) : نشان دهنده ارزش پولی صرف شده توسط یک مشتری در بازه زمانی خاص است. به عنوان مثال 300 هزار تومان در سال.
1. دسته بندی RFM به چه سوالاتی در رابطه با بیزینس پاسخ می‌دهد؟
بهترین مشتریان شما چه کسانی هستند؟کدام یک از مشتریان در آستانه Churn هستند؟کدام یک از کاربران توانایی تبدیل به مشتریان سودآور را دارند؟مشتریان وفادار شما چه کسانی هستند؟کدام گروه از مشتریان به احتمال زیاد می‌توانند به کمپین فعلی شما پاسخ دهند؟چه کسانی کاربران Churn شده شما هستند که نباید هزینه و زمان زیادی به آنها اختصاص دهید؟
تفسیر مدل RFMهر چه F بیشتر و R کمتر باشد احتمال آنکه تراکنش جدیدی با مشتری صورت بگیرد بیشتر است و همچنین اگر M نیز بزرگتر باشد احتمال بازگشت مشتری برای خرید بیشتر است. در مدل RFM فرض بر این است که مشتریانی که در هر یک از متغیرهای مدل دارای ارزش بالاتری هستند جزو بهترین مشتریان هستند. نکته اساسی در رابطه با RFM این است که نباید با یک‌بار اندازه گیری به نتایج و دسته بندی قانع شد. خاصیت مدل در این است که در بازه زمانی هر هفته یا هر ماه اندازه‌گیری شده و رفتار مشتریان در دسته‌های مختلف و در طول زمان مشخص شود.
منبع :‌ https://www.putler.com/rfm-analysis/#11segments

۱۳:۱۷

سلامتوی این قسمت می‌خوام در مورد خاطراتم در مورد لاگ و داده صحبت کنم.
شروع کار من توی بله با توسعه بک‌اند بانکی بود. وقتی داشتم بک‌اند رو می‌نوشتم توی ذهنم به اشتباه یک دغدغه بود. اونم دغدغه از دست ندادن داده‌ها و حل مشکلات احتمالی سیستم. باید حواسم می‌بود اگه تراکنشی انجام شد لاگ متناظر با اون همیشه موجود باشه، اما این کافی نبود یه جاهایی لازم بود اطلاعات دقیق‌تری از عملکرد سیستم داشته باشم. پس شروع کردم پیدا کردن نقاط حساس سیستم و برای هر کدومش لاگ گذاشتم. این شکلی اگه جایی از سیستم مشکلی پیش میومد می‌تونستم راحت دنبالش کنم و به مشکل برسم.توی این لاگ کردن خیلی حواسم بود که شلوغ کاری نکنم! به چند دلیل:
۱. از شلوغ کاری بدم میاد!
۲. لاگ کردن داده اضافی ایجاد مسئولیت می‌کرد برام.
۳. شلوغ شدن لاگ‌ها باعث می‌شد عملا کاربردش بیاد پایین و رسیدن به چیزی که ازش می‌خوام برام سخت‌تر بشه، ینی هزینه نگه‌داری و رجوع بهش بسیار بالا بره.
یه نگرانی که همیشه همراهم بود لاگ کردن چیزایی بودش که نباید لاگ می‌شد. مثل اطلاعات حساس کاربر و اطلاعات مالی کاربر. این نگرانی شاید هیچ وقت از بین نره و نیاز به دقت توی توسعه محصول داره و همه باید حواسشون بهش باشه. ولی یکی از ساده‌ترین کارایی که ما کردیم عقیم کردن آبجکت‌هایی بود که نباید لاگ می‌شدن مثلا اومدیم تابع toString رو براشون اورراید کردیم که دیگه چیزی که نباید رو چاپ نکنن مخصوصا وقتی حواسمون نیست و اتفاقی آبجکتی رو که شامل اطلاعات کارت میشه رو لاگ می‌کنیم.
نکته دیگه‌ای که بهش فکر می‌کردم ایجاد یه ساختار برای لاگ‌هام بودش جوری که بتونم به راحتی هر چیزی رو که میخوام توش پیدا کنم. برای این کار اومدم از gelf استفاده کردم که یه ساختار به لاگ‌هام می‌داد و این شکلی توی گری لاگ خیلی راحت می‌شد چیزی که میخوام رو پیدا کنم. ولی خب یه مشکل که بود و به ظاهر اجتناب ناپذیر بود، وجود چندین و چند نوع پیام بود. به خاطر اینکه جاهای مختلف سیستم و با کاربردهای مختلف لاگ‌های مختلفی داشتم که هر کدوم نشون دهنده چیزی توی سیستم بودن.
چند ماه اول همه چی داشت خوب پیش می‌رفت. اطلاعات کاملی که در اختیار پشتیبانی قرار می‌گرفت. آماری که از لاگ‌ها می‌تونستیم در بیاریم و بگیم احتمالا مشکل سیستم کجاست؟ اما یه ذره که گذشت دیدم حجم لاگ‌ها داره بیشتر و بیشتر میشه، یه سری چیزا دارم که به کارم نمیاد ولی باید نگهشون دارم. اینجا بود که یواش یواش شک کردم!
یواش یواش این ایده اومد توی ذهنم که از اول داشتم اشتباه می‌کردم! من نباید یک دغدغه میداشتم! "دغدغه از دست ندادن داده‌ها و حل مشکلات احتمالی سیستم" در حقیقت من باید ۲ تا دغدغه میداشتم!نگه‌داری داده و لاگ‌هایی که عملکرد سیستم رو نشون می‌دن باید از هم جدا می‌شدن. به نظر این شکلی می‌تونستم: ۱. خیلی ساخت یافته‌تر جریان لاگ‌ها رو کنترل کنم!
۲. داده‌هایی که بهشون نیاز ندارم رو از چیزایی که باید بلند مدت یا میان مدت نگه‌داری بشن جدا کنم.
۳. پردازش روی ۲ جریان لاگ با ساختارهای مشخص و کاربردهای مختلف رو ساده‌تر انجام بدم.
۴. با کنترل دسترسی روی جریان‌های مختلف لاگ، کمتر نگران داده‌های حساس باشم.

پس به نظر ایده بدی نیست که جریان داده رو از جریان لاگ‌های سرویس جدا کنیم.

۱۴:۰۵

thumbnail
از چه نموداری استفاده کنم؟

۶:۵۷

بازارسال شده از Amir Mashayekhi
دسته‌بندی کاربران با مدل RFM(بخش دوم)
رتبه‌بندی و امتیازدهی RFM :رویکردهای متفاوتی برای رتبه بندی و یا امتیازدهی در مدل وجود دارد که در ذیل به دو رویکرد متداول اشاره می شود:
رتبه بندی مقدماتیدر این روش مشتریان بر اساس هر کدام از پارامترهای R، F و M به صورت مجزا از 1 تا 5 امتیازدهی می شوند. اگر دیتای مورد نظر را به خوبی می‌شناسید و نسبت به روند حرکتیِ دیتا آگاه هستید، می‌توانید با شرط‌های مختلف به کاربران امتیاز دهید. در غیر این صورت ابتدا مشتریان بر حسب هر کدام از شاخص‌ها به صورت افزایشی (کاهشی) مرتب می گردند. در مرحله بعد به پنج بخش مساوی تقسیم می شوند. مشتریانی که در ۱/۵ فوقانی قرار می گیرند نشاندهنده ۲۰% از مشتریان هستند که بیشترین نمره را داشته اند و امتیاز 5 میگیرند. به همین ترتیب هر مشتری می تواند در یکی از خانه ها قرار گرفته و امتیاز مربوط را از 1 تا 5 کسب کند.
رتبه بندی خوشه ایدر این روش پس از پیش‌پردازش و آماده‌سازی داده‌ها، اقدام به نرمال‌سازی داده‌ها می‌شود تا توزیع یکسانی مابین همه شاخص‌ها برقرار گردد. سپس با یکی از روش‌های یادگیری ماشین بدون‌ناظر، داده‌های نرمال شده به عنوان ورودی به مدل داده شده و اقدام به خوشه‌بندی می‌کنیم. لازم به ذکر است در این روش انتخاب مدل مناسب و انتخاب بهینه پارامترها در نتیجه خوشه‌بندی بسیار موثر و تاثیر گذار است.
دسته‌بندی کاربران :
کاربران وفادار (Loyal) :دسته ای از کاربران که امتیازشان در همه شاخص های R، F و M بزرگتر مساوی 4 می‌باشد.ویژگی :‌ این دسته از کاربران پول خوبی را هزینه می‌کنند، به عبارت دیگر اخیرا خریده اند، اغلب می‌خرند و بیشتر هزینه می‌کنند. از آخرین فعالیتشان زمان زیادی نمی‌گذرد، در بازه های کوتاه مدت خرید را تکرار می‌کنند و ارزش پولی که هزینه کرده اند، در بالاترین دسته قرار می‌گیرد.اقدام : این کاربران به کمپین‌های تبلیغاتی واکنش خوبی نشان می‌دهند. به این دسته از کاربران پاداش بدهید، چرا که ارتقادهنده برند شما خواهند بود.
کاربران نیازمند توجه (Need Attention) :دسته ای از کاربران که امتیازشان در همه شاخص های R، F و M بین 2 تا 3 است.ویژگی :‌ عملکرد این دسته از کاربران در همه‌ي شاخص ها تقریبا میانه است. کاربرانی که از آخرین فعالیتشان حداقل تقریبا زمان زیادی می‌گذرد و ارزش پولی که هزینه کرده اند، تقریبا برابر متوسط پ کمتر از آن است اگر توجه ویژه‌ به این کاربران شود، رشد خوبی خواهند داشت.اقدام : برای این دسته کاربران کمپین Awareness تاثیر بسیار خوبی به همراه خواهد داشت. همچنین بر اساس خریدهای گذشته‌شان به ان‌ها Recommend دهید.
کاربران در خطر (At Risk) :دسته ای از کاربران که امتیازشان در شاخص R کوچکتر مساوی 2 و در شاخص‌های F و M بین 3 تا 5 است.ویژگی :‌ این دسته از کاربران اغلب می‌خرند، پول زیادی را هم نسبتا هزینه می‌کنند اما مدت زیادی است که خبری از آن‌ها نیست. کاربران ارزشمندی که یکباره ناپدید شده‌اند. از آخرین فعالیتشان حداقل مدت زیادی می‌گذرد (ماه‌ها). تا قبل از غیب شدنشان تکرارهای بسیار خوبی در خرید داشته اند و بازه های زمانی تقریبا منظمی خرید می‌کردند و همچنین ارزش پولی که هزینه کرده اند، مقدار متوسط و بالاتر از آن است. از دست می‌روند اگر Reactive نشوند.اقدام : با آن‌ها از طریق پوش و SMS دوباره ارتباط برقرار کنید. پیشنهاد محصولات با تخفیف را به این دسته فراموش نکنید.
کاربران از دست رفته (Lost) :دسته ای از کاربران که امتیازشان در همه شاخص های R، F و M کوچکتر مساوی 2 می‌باشد.ویژگی :‌ این دسته از کاربران به سختی دوباره فعال می‌شوند. مدت بسیار‌زیادی است که از آخرین فعالیتشان گذشته، به ندرت خرید کرده‌اند و ارزش پولی که هزینه کرده اند، در پایین‌ترین دسته بوده است. احتمالا جذب سایر رقبا شده اند.اقدام : ایجاد کمپین برای برگرداندن این دسته کاربران اثر قابل توجهی نداشته و بهتر است بدون کمپین و با ارتباط بی واسطه دوباره علاقه‌مندشان کنید.شکل 1 و 2 تعریف و اکشن‌ کلیه دسته‌هایی که با روش اول پتانسیل ایجاد شدن دارد را نشان می‌دهد.
منبع : https://www.putler.com/rfm-analysis/#11segments

۶:۵۸

بازارسال شده از omirabzadeh
انتخاب ابزار کد باز مناسب تحلیل و هوش تجاری-قسمت اولمقدمه (هدف)یکی از ابزارهای پر اهمیت در مسیر داده محور شدن سازمان ها، ابزارهای موسوم به تحلیل و هوش تجاری است. انتظارات اولیه از ابزارهای تحلیل و هوش تجاری و قابلیت های آنها را می توان در قالب موارد زیر دسته بندی کرد:۱. توانایی اتصال به منابع داده ای مختلف۲. توانایی تغییر داده ها پس از دریافت از منبع داده۳. توانایی بصری سازی داده ها۴. توانایی ارسال هشدارها و رخدادها۵. امکان مدیریت سطوح دسترسی۶. توانمندسازی کلیه اعضای سازمان در تحلیل داده ها بدون نیاز به دانش تخصصیبه تعبیری هدف اصلی بکار گیری این ابزارها در سازمان ها را می توان «توانمندسازی کلیه اعضای سازمان در پاسخگویی به پرسش های کسب و کاری از طریق داده ها و یادگیری از داده های سازمان» دانست.برای انتخاب ابزارهای تحلیل و هوش تجاری، معیارهای مختلفی پیشنهاد شده است که در ادامه و در یک بخش مجزا به معیارهای انتخاب ابزارهای تحلیل و هوش تجاری می پردازیم.چرا ابزارهای کد بازیکی از تصمیم های اساسی در زمینه انتخاب ابزار مناسب، تصمیم درباره کد باز بودن یا اختصاصی بودن نرم افزار است. در هر دو حوزه نیز نرم افزارهای شناخته شده ای به عنوان گزینه های قابل توجه وجود دارد.از جمله ابزارهای اختصاصی تحلیل و هوش تجاری که به عنوان SaaS ارائه می شود می توان به موارد ذیل اشاره کرد:undefined Microsoft Power BIundefined Tableau Cloudundefined Qlik Sense Cloudundefined IBM Watson Analyticsundefined TIBCO Spotfireundefined Domo.comبرای انتخاب از بین ابزارهای اختصاصی، معمولاً گزارش های تجاری نظیر گزارش Magic Quadrant گارتنر به عنوان یک راهنمای اولیه مناسب، در دسترس بوده و می توان برای انتخاب ابزار با توجه به معیارهای مورد نظر، از این ابزارها استفاده کرد.از جمله ابزارهای کد باز تحلیل و هوش تجاری که به صورت رایگان ارائه می شود می توان به موارد ذیل اشاره کرد:undefined Metabaseundefined Redashundefined Apache Superset (formerly was Caravel)undefined Grafanaundefined Kibanaاین مستند با این فرض نگاشته شده که سیاست ما، استفاده از ابزارهای کد باز تحلیل و هوش تجاری است و بررسی و مقایسه روی ۳ مورد از ابزارهای کد باز انجام شده است.از جمله مزایای استفاده از ابزارهای کد باز، امکان تخصیص تیم مستقل درون سازمان برای توسعه ابزار و شخصی سازی آن با توجه به نیازهای کسب و کاری خاص سازمان است. همچنین هزینه تعبیه این ابزارها در نرم افزارهای بومی سازمان و شخصی سازی آنها به نسبت نرم افزارهای اختصاصی کمتر است.گزینه های شناسایی شدهمهم ترین نرم افزارهای تحلیل و هوش تجاری کد باز شناسایی شده شامل موارد ذیل می شود:undefined Metabaseundefined Redashundefined Apache Superset (formerly was Caravel)undefined Grafanaundefined Kibanaگزینه های انتخاب شدهانتخاب گزینه های اولیه جهت بررسی بیشتر با توجه به نیازهای سازمان، قابلیت های ابزار، تجربه قبلی در زمینه استفاده از این ابزارها در سازمان، میزان بلوغ و چشم انداز توسعه آتی ابزارها انجام شده است و بر این اساس، در مرحله اول، ابزارهای Metabase، Redash، Apache Superset و Grafana به عنوان گزینه های بررسی بیشتر انتخاب شد. با توجه به تجربه قبلی در استفاده از ابزار Grafana برای کاربردهای مانیتورینگ، در این مطلب هدف بررسی ابزارهای Metabase، Redash و Apache Superset تعیین شده است.معیارهای ارزیابیمعیارهای کلی که در این بررسی برای تصمیم گیری درباره انتخاب ابزار، برگزیده شد عبارت است از:undefined سهولت نصب و راه اندازی و نگهداریundefined مشتریان استفاده کننده از ابزار با توجه ویژه به صنعت و اندازه کسب و کار آنهاundefined چشم انداز توسعه و میزان فعال بودن جامعه توسعه دهنده ابزارundefined پشتیبانی (در دسترس بودن مستندات و میزان فعال بودن جامعه در پاسخگویی به اشکال های احتمالی)undefined طرح های رایگان و پولی استفاده از ابزار و قابلیت های هر یک از طرح هاundefined میزان دانش فنی مورد نیاز برای کار با ابزار و یادگیری از داده هاundefined تنوع امکان ارتباط با سایر زیرساخت ها و سیستم های سازمانundefined تنوع نمودارها و قابلیت های بصری سازیundefined امکان بکارگیری خروجی گزارش ها در ابزارهای بومی سازمانهمچنین برای کلیه ابزارها، موارد زیر نیز حائز اهمیت است که در این بررسی، به طور ضمنی در مرحله انتخاب گزینه ها برای بررسی بیشتر در نظر گرفته شد.undefined چه کسانی از ابزار استفاده می کنند؟undefined اقلام قابل تحویل چه چیزهایی هستند؟undefined اندازه داده ها و مقیاس پذیری آن چیست؟undefined آیا این ابزار در یک فرآیند موجود قرار می گیرد یا جزء اصلی یک فرآیند جدید است؟در ادامه به بررسی ابزارهای مورد بررسی می پردازیم و در نهایت، آنها را بر اساس ۹ معیار اول معرفی شده در این بخش مقایسه می کنیم.

۸:۴۵