فرار از ریفکتور و پاک کردن صورت مسئله

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

یوزرهای فعلی

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

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

۱- Race Condition

خطرناکترین مدلی که من توی مجموعه ها دیدم قاطی کردن این هست که اگه چیزی رو توی ترنزاکشن بگذارن

پس در نتیجه هیچ race condition پیش نخواهد اومد در صورتی که این تفکر به شدت غلطه و در مواقعی که یک قسمت خیلی حساسه باید از lock یا update با شرایط خاص استفاده کرد مثلا optimistic locking یا pessimistic locking که البته شرایط استفادشون با هم فرق میکنه

۲- ما کد تمیز می نویسیم

یک داستان خیلی بدی که امروزه درگیرش هستیم این هست که برنامه نویس ها نوشتن یک اسم متغیر صحیح رو همراه با فانکشنال کردنش clean code در نظر میگیرن خیلی ها از SOLID فقط قضیه single responsibility رو میدونن که اون رو هم به اشتباه این میدونن که یک کلاس فقط باید یک وظیفه داشته باشه در صورتی که یکی از چیزهای مهم این قضیه این هست که یک کلاس فقط باید یک دلیل برای تغییر داشته باشه اینکه شما در اولین سرچتون به زبان انگلیسی به مفاهیم solid می رسید و فکر میکنید که کاملا concept ها رو فهمدید یک اشتباه بزرگه بزرگترین هدف در clean code تغییر پذیری راحت یک سیستم بدون فرو ریزی قسمت های دیگست و تمامی نکات در حقیقت برای رسیدن به این داستانه به شدت کتاب clean code از robert c martin یا همون عمو باب uncle bob خودمون هست حواستون باشه این کتاب رو به کتاب clean coder اشتباه نگیرید به نظر من تمامی فصل های این کتاب رو هر برنامه نویسی تحلیل گر سیستمی lead developer و هرکسی که توی زمینه فنی این پروسه فعالیت میکنه باید بخونه.

نمونه دیگه مفهوم open close principle هست خیلی ها فکر میکنن یک کلاس رو که نوشتن دیگه حق تغییر اون کلاس رو ندارن و باید اونقدر ایده ال باشه که نیاز به تغییر نداشته باشه خیر در حقیقت شما باید جوری کلاس ها تون رو بسازید و مثلا از مفاهیم factory design pattern استفاده کنید یا مثلا کلاستون رو بشکونید تا برای افزودن یک خاصیت جدید فقط یک چیز اضافه کنید نه اینکه قسمت های دیگر رو تغییر بدید.

مشکل بعدی مفهوم dependency injection هست خیلی ها دوباره اصلا استفاده از این قضیه رو نمی دونن و فکر میکنن inject کردن کلاس یوزر مثلا در لاروال میتونه کارشون رو حل بکنه در صورتی که این قضیه هنوز شما رو به اون کلاس بی نیاز نکرده در حقیقت شما باید اول مفهوم inversion of control رو متوجه بشید و بعد ببینید چطور dependecy injection توی این قضیه بهتون کمک میکنه داستان بعدی هم اینکه مفهوم dependency injection با singelton فرق میکنه و برای این نیست که شما یه چیزی رو از اول برنامتون مثل bootstrap load کنید.

ونویسی آسونه اما ما که نمی نویسیم کردن

اکثر مجموعه هایی که من دیدم با مانیتور کردن کوئری هاشون تونستم متوجه بشم که خیلی از اونها یا کوئری هاشون مانیتور نکردن و یا هر فیلدی که توی دیتابیس رو داشتن روش سرچ میزدن تک تک ایندکس کردن و اصلن از ایندکس چندتایی و ترتیب ایندکسینگ بر اساس کوئری سرچ آگاهی نداشن . یا مثلا چثدر میتونه hash column ها به جلوگیری از ایندکسهای بزرگ کمک منه میتونید اطلاعات بیشتر رو از اینجا ببینید و فکر میکنم خوندن این صفحه میتونه بهتون خیلی کمک بکنه

۴-عدم استفاده از queue و message broker

خیلی از کسایی که دیدم هنوز خیلی از صف هاشون رو در جاهایی که نیاز نیست خودشون با دیتابیس هندل میکنن بماند که باید دوباره مفاهیم race condition رو در pickup کردن جاب ها در نظر بگیرن و اصلا اگاهی از وجود beanstalkd و ....... نداشتن

5- عدم استفاده از interface

یکی از مفاهیمی که خیلی در حقش ظلم میشه و همه فقط اسمشو شنیدن اینو توی پروداکتهای بزرگ و با تغییرات بالا دیدیم interface هست اصلا چرا از interface استفاده میشه چطور میتونه کمک بکنه چقدر design pattern ها با کمک interface پیاده سازی میشن

6- عدم توجه به sql anti patterns

این مورد رو فقط میتونم موکول کنم به کتاب اقای bill karwin sql antipatterns که فوق العادست من کل این کتاب رو خوندم و به شدت پیشنهاد میکنم کسایی که میخوان دیتابیس طراحی کنن قبل از اینکه هیچی نشده سریعا تصمیم به دیتابیس های nosql پناه میبرن در مواردی که اصلا نیاز نیست اول این کتاب رو بخونن

7- تست نویسی آسونه اما ما که نمی نویسیم

قطعا یکی از بزرگترین دروغ هایی که شنیدم این بوده که tdd اولش سخته و سرعت کد نویسی رو بالا میبره نه tdd سرعت maintenance رو بالا میبره ولی در کل کد نویسی شما رو نسبت به بزن برو جلو زمان بر تر میکنه اگه دیدید کسی گفت این جملرو بدونید tdd ننوشته و بزرگترین مسئله شما بعد از پاس کردن هر تست موظف به ریفکتور هستید نه اینکه تستون رو جوری بنویسید که سورس ریفکتور شده تولید کنید این خیلی مهمه در ابتدای کار و گرنه دچار کمالگرایی میشید و دیگه نمیتونید تست بنویسید

و .......

خیلی موارد دیگه هست که به نظرم باید بگم که شاید یک نوشته دیگه براش نوشتم اما سعی کردم توی این شلوغی های کاری این مطالب رو عنوان کنم شاید بتونه کمکی به چندین نفر بکنه .