نوشته های یاسر مرادی

کار تیمی

یاسر مرادی — Sat, 30 May 2020 15:23:07 +0430

۱- تو نانوایی ۲ نفر کار می‌کنن، یکی صبح خمیر رو آماده می‌کنه و در طول روز چونه می‌گیره! دیگری هم تو تنور قرار میده و در میآره! (فرضا) یه روز وارد یه نانوایی میشید‌ و میبینید که توش عوض ۲ نفر، یه نفر داره سخت کار می‌کنه! <صبح پا نشده خمیر رو آماده کنه>، الآن که شما وارد میشید۲- کمی آرد رو با آب قاطی می‌کنه و می فرسته داخل تنور! شما هم اون آشغالی که از تنور به اسم نون در میآد رو می‌خورید و دل درد میگیرید! از طرف می‌پرسید که چرا آخه؟ میگه من وظیفه خودمو دارم درست انجام میدم (گذاشتن خمیر تو آتش) و راست هم میگه! این مثال خیلی جنون وار به نظر میآد، درسته؟۳- واقعیت کار تیمی خیلی از ماها همینه! در بهترین حالت کار خودمون رو درست انجام میدیم، بدون توجه به این که کلیت سیستم جواب میده یا نه! نهایت غر یا فحش زیر لب، راهکار ما برای باقی قسمت های سیستم هستن که به زعم ما درست نیستن و کارشون هم البته وظیفه ما نیست!۴- نانوایی استعاره از دنیای واقعی ماست! اون آدمهایی هم که دل درد میگیرن، مشتری‌های نرم افزارهامون! اگه قسمتی از سیستم اشکال داره، سعی کنید فراتر از یه پیرزن ۷۰ ساله یا یه پسر بچه ۶ ساله عمل کنید! فراتر از نق زدن عمل کنید! سعی کنید مدیر مربوطه رو با توضیحات دقیق به مسیر درست ببرید۵- اگه مدیر توجیه نمیشه، سعی کنید اون قسمت مشکل دار رو خودتون هندل کنید. یه محصول نرم افزاری از Product design تا UI/UX تا development تا تست و ... میتونه بلنگه! اگه دوست دارید و می‌تونید، کمک کنید به بهبود هر یک از اینها که لنگ میزنن!۶- اگه در نهایت هیچ کدوم جواب نمیده، یادتون نره که درخت نیستید و لازم نیست سالها تو یه سیستم معیوب، نون داغون به خورد مشتری‌ها بدید! برید شرکت دیگه ای که ساختار بهتری داره، تا به جای تلف شدن عمرتون تو یه ساختار معیوب، در جای درست، در تیم درست، در شرکت درست، بهترین ممکن باشید!لینک رشته توییت مربوطه

ساختار تیم توسعه نرم افزار

یاسر مرادی — Sat, 30 May 2020 15:20:22 +0430

۱- اخیرا یه شبه جنگ جهانی شکل گرفت در مورد اینکه آیا میشه یه نفر هم Back بزنه و هم Front؟ میخوام تجربه خودم رو که به نظرم جوابی بهتر از جداسازی developerهای Back/Front داده رو این‌جا بنویسم، امیدوارم که به کارتون بیاد. البته اگه کسی فکر می‌کنه Front == HTML+CSS، ادامه نده بهتره!۲- در یه پروژه نرم افزاری، کلی keyword میآد وسط! Docker، Kube، Stored Procedure، Logging، Identity، DataGrid، State Management و هزار و یک کوفت و زهر مار دیگه! اگه این مدلی به قضیه نگاه کنیم، تو حوضه های Data | DevOps | Backend | Frontend کلی جا واسه عمیق شدن هست.۳- ولی اگه این طوری به قضیه نگاه کنیم که تو هر زمینه، متخصص مربوطه رو توی تیم داریم، قسمت دیگه ای از پروژه باقی می‌مونه که اتفاقا مهم تره و اون منطق برنامه است که بابتش داره پول پرداخت میشه و نیاز رو داره بر طرف می‌کنه!۴- به نظرم سبک نوشتن logic بین front و back آنچنان تفاوت عمیقی نداره و و با فرض cover شدن توسعه دهنده ها توسط افرادی در تیم که دانش فنی بیشتری دارن، به صورت عملی ممکن هست که یه نفر back و front رو با هم بزنه. اگه این وسط زبان برنامه نویسی بین front و back هم مشترک باشه چه بهتر!۵- البته یه نفر نباید back و front یه task رو خودش بزنه، این فقط باعث وابستگی به یه قسمتی از پروژه به یه نفر میشه. صحبت اینه که اگه تیم ۵ نفر هست، اینا همه قسمت‌های پروژه رو با هم بزنن. نه این که تقسیم بشن به دو گروه ۳ و ۲ نفره!۶- این روش واقعا موثرتر هست، کلی از بلاک شدن اعضاء تیم رو کم می‌کنه. درک متقابل رو بالاتر می‌بره و با برنامه نویس‌هایی که ۳ سال به بالا سابقه کاری داشته باشن، کاملا قابل اجراست!۷- حالا آیا این به معنای اینه که اون نفر باید صفر تا صد همه چی رو بدونه؟‌ نه! ساختار درست داره فرد رو پوشش میده! البته که اون فرد بنا به علاقه اش میتونه تو یک زمینه ای سعی کنه خیلی عمیق بشه و پیشرفت هم کنه.۸- صادقانه بگم، وقتی یه تیمی رو به این شکل ایجاد کردید، و بعد سری به تیم های دیگه می‌زنید، فقط میخواهید سرتون رو به دیوار بکوبید چون تازه متوجه میشید که چقدر غیر موثر دارن کار می‌کنن.۹- البته اون افرادی در تیم که قراره مسلط باشن هم میشن ۲ نفر و نصفی نهایتا برای Back/Front/DevOps و البته که داشتن اونها علاوه بر این که اجازه میده کل اعضاء تیم Back/Front رو با هم بزنن و مزیت‌هاش، یه مزیت دیگه هم تو جذب نیرو داره که ریسک جذب نیروهای با تجربه کمتر رو کاهش میده.لینک رشته توییت مربوطه

روستا

یاسر مرادی — Sat, 30 May 2020 15:17:32 +0430

۱- مدتی پیش رفتم خرید، از جون مرغ خریدم تا شیر آدمیزاد. صندلی کامپیوتر رو به همراه مانیتور و کیس و هر چی که کمک کنه لااقل تا دو هفته لازم نباشه برم خرید رو ریختم توی ماشین و شبانه راهی ده شدم. ۲- قصدم سفر و تفریح نبود. نرفتم که سه روزه برگردم. رفتم که توی قرنطینه بمونم و تو این مدت با کسی سلام و علیک هم نکردم، چه برسه دید و بازدید. فقط خرید، اون هم دو هفته یک بار. هر چی که می‌بینم نیست یا تموم میشه رو تو یه لیست برای خرید آینده میآرم.۳- این مقدمه رو نوشتم تا بدون این‌که قضاوت بی‌جا بشم، بتونم براتون از اتفاقات ده بگم. خب میز نداشتم، ولی آجر بود، و یکی ساختم! خوشبختانه سرعت نت خوبه! ده مگ و پینگ 60ms۴- درختای حیاط تازه دارن جون می‌گیرن و سبزی‌ها تنها چیزی هستن که فعلا درست و حسابی خودنمایی می‌کنن. خوشبختانه دقیقا کنار ده هست خونه و اگه بخوام برم سر به کوه و بیابون بگذارم، تو راهم به کسی یا چیزی بر نمیخورم!۵- "چند ماه پیش" که خونه مادرم بودم و داشتم ظرفها رو میشستم، در نهایت به روشی دستکش‌ها رو درآوردم که نزدیک بود پاره بشن، مادرم با حالتی عجیب گفت چه کار داری می‌کنی؟! من گفتم تهش پاره میشه از مغازه بغلی می‌خریم!۶- الآن تو قرنطینه فقط دو تا دستکش دارم. میگم نکنه پاره بشن. مغازه بغلی هست، ولی واسه دستکش نمیخوام برم خرید، میگذارم برا ۲ هفته دیگه. میگن تجریبات این مدلی تو روان آدمی ‌می‌مونه و تازه مادرم رو ‌می‌فهمم! دو تا دستکش دارم، دوستشون دارم! بدون اونها زندگی سخت میشه!۷- کوه‌ها تو برف و مه فرو رفتن! یه جورایی زمستونه انگاری! جوجه رو درست کردم و با کمک زغال آتشین برای جوراب پام هم هواخور درست کردم! کارهامم جالبه، از حل مشکل Angular SSR میرم به Xamarin و بعد فرغون و دسته بیل و مجدد کامپیوتر و به طیور غذا دادن و اسم و فامیل بازی کردن!لینک رشته توییت مربوطه در توییتر

توسعه ‌دهنده ‌نرم‌افزار‌ خوب

یاسر مرادی — Sat, 30 May 2020 15:10:56 +0430

۱) در این سه توییت میخوام دیدگاهم رو نسبت به #توسعه‌دهنده‌نرم‌افزار‌خوب بگم تا بتونم چند سال بعد بهش برگردم. شرط اول اینه که اعتقاد داشته باشه مشتری که محصولش رو داره استفاده می‌کنه "آدمه"! اگه خودش با سایپا و پراید مشکل داره، چیزی تو همون مایه‌ها رو تحویل مشتری نده!۲) دوم اینه که ارزش بلد بودن یه تکنولوژی رو در ارزش خلق کردن یا مشکل رو رفع کردن ببینه. صرف این که یه چیزی رو یاد گرفته باشه، ولی تو دنیای واقعی نتونسته باهاش مشکلی رو حل کنه و صرفا داشته با JavaScript کدهای دو زاری میزده و حالا میخواد این رو به Go هم تعمیم بده ابدا جالب نیست!۳) سوم اینه که توسعه نرم افزار رو چیزی فراتر از تایپ کردن با کیبورد بدونه. بدیهیات Agile و DevOps و همچنین درگیر شدن در بیزینس پروژه و در نهایت کمک به هم تیمی هاش رو هم جزئی از کارش بدونه.لینک رشته توییت در توییتر