الگریتم!

چند هفته اس که میخوام از The Algorithm بنویسم و فرصت نمیشد، خود The Algorithm داخل اینترنت هست و میتونی بری بخونی، من اینجا مایندستی که خودم ازش پیروی میکنم رو مینویسم و این مایندست رو کاملا از ماسک الهام گرفتم و برای من نتیجه بخش بوده.

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

در درجه اول، من هیچ چیز رو کورکورانه قبول نمیکنم، این یعنی چی؟

خیلی اوقات پروداکت منیجر میاد میگه که "فرانت اند" یا "مارکتینگ" گفته که فلان تسک باید انجام بشه، بعد شما نشستی اون وسط میگی این "فرانت اند" و "مارکتینگ" دقیقا کی هست؟ مثلا "فرانت اند" شاید یک تیم شیش نفره باشه، شما هم میدونی این ۶ نفر کی هستن ولی دقیقا نمیدونی که کدومشون این درخواست رو داره.

حالا شاید این ۶ نفر شورا کرده باشن و به یه نتیجه ای رسیده باشن، و اون نتیجه ای که گرفتن اشتباه باشه یا نیاز به گفت و گو داشته باشه ( که زیاد پیش میاد )، اینجا شما نمیدونی بری با کی صحبت کنی در نتیجه به همون پروداکت منیجر میگی که برو به "فرانت اند" بگو که این کار شدنی نیست.

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

در نتیجه من به کلی اسم دپارتمان رو به عنوان ارائه دهنده تسک نمیپذیرم و میگم اسم اون آدمی که این تسک رو مطرح کرده بهم بدین و من برم مستقیم باهاش صحبت کنم و requirement رو در بیارم.

حالا این خیلی مشکل زا هست، چرا؟ چون اون دپارتمانی که اون تسک رو تعیین کرده، صرفا میخواسته یه چیزی رو از سر خودش باز کنه و پاس بده به دپارتمان بعدی و عملا خودشون هم نمیدونن که نیازمندیشون چی هست :)))

در نتیجه وقتی شما میری شفاف سازی انجام بدی، این بندگان خدا دچار ناراحتی میشن و سعی میکنن شمارو بپیچونن و در بلند مدت هم باهاتون دست به یقه میشن و ترجیحشون اینه که اون شفاف سازی صورت نگیره و فقط یه سری تسک رندوم داخل جیرا و کلیک آپ تیک بخوره، و بعد هم به مدیریت KPI نشون بدن که نگاه کن ما چقدر productive هستیم :)))

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

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

عزیزان من، همه این کد ها داخل ورژن کنترل ذخیره میشن و اگه لازم شد شما میری از گیت هیزتری خودت، اون کد رو برمیداری میذاری سرجاش، دیلیتش کن بره.

حالا این ساده ترین بخش کار هست و خیلی اوقات یک سری سرویس اضافه و legacy هست که هیچکس نمیدونه چرا و از کجا اومده ( به همون دلیل بالا که گفتم، خیلی ازین پیاده سازی ها کاملا رندوم هست و یه دپارتمانی میخواسته یه چیزی رو از سرش باز کنه ) و من معتقدم که این اضافات باید دیلیت بشن و سیستم ساده سازی بشه.

خیلی از آسیب پذیری های امنیتی از همین سرویس های لگسی میان که مدتهاست ول شدن به امون خدا و اصلا کسی نمیدونه اینا وجود خارجی دارن، در نتیجه: دیلیت دیلیت دیلیت.

مرحله سوم میشه آپتیمایز کردن.

بعد اینکه شما اضافات سیستم رو پاکسازی کردی، تازه میشینی و بهینه سازی انجام میدی. من دیدم خیلی از مهندسین نرم افزار، صاف میرن سراغ بهینه سازی و اینکار اشتباه هست.

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

هر موقع مطمئن شدی که به وجود اون سرویس نیاز هست، بعد تازه بشین بهینه اش کن.

مرحله آخر هم میشه اتومیشن.

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

حالت ایده آل اینه که شما یک سیستمی پیاده سازی کنی که بدون وجود شما هم مثل ساعت کار بکنه

و خب خیلی از برنامه نویس های کارکشته، به دلایل واضح با این حرف من کاملا مخالف هستن.

اینا هم تو خواب و بیداری نوشتم، اگه استقبال بشه بیشتر مینویسم و از چالش هایی هم که داشتم حرف میزنم :)

فعلا همینا داشته باشین. با تشکر بوس بوس فعلا خدافس