Python Hints

بنظر من توانایی درک و خوندن کدهای باقی افراد و کار کردن با اون فرمت کد خودش یک تخصص و مزیت هست توی کار برنامه نویسی تخصصی که متاسفانه خیلی از برنامه‌نویس‌های ایرانی ندارند حتی در سطوح بالاتر.

برای همین توی ایران تا دلتون بخواد ریفکتور می‌بینیم (خیلی موارد البته بخاطر شیت کد بودن هست) ؛ ریفکتورهایی که فقط استانداردها رو تغییر دادند و وقتی کد رو مقایسه می‌کنید لزومی نمی‌بینید برای وقتی که گذاشته شده

برای این موضوع ما ۳ هفته وقت رو از دست دادیم روی یک پروژه (مربوط به ۳ ماه قبل هست) و خیلی دوست داشتم راجبش بنویسم چون دقیقا بعد از این موضوع توی تیم خودم روشی که خودم برای ریفکتور کردن دنبال می‌کنم رو ارائه دادم

نکته : اگر دارید system design رو تغییر میدید دیگه اسمش refactor نمی‌شه و این تکنیک جواب نمیده
اما اگر بعنوان مثال کدی رو روی پروداکشن دارید که داره کار می‌کنه و system design مناسبی داره و فقط کدها بد پیاده سازی شده و پرفورمنس خوبی نداره اونوقت به ریفکتور نیاز دارید و تکنیکی که میگم :

شخصا از تکنیکی استفاده می‌کنم که توی تیم بهش میگیم
3 step refactor
وقتی بیزینس درخواست فیچر جدیدی میده که اصن معلوم نیست موندگار هست یا رفتنی یا ... و فعلا فقط روی سرور تست قرار هست بالا بیاد
step 1:
do it as fast as possible (even shit code is ok)
توی سریعترین زمان ممکن اون رو توسعه میدیم حتی اگر shit code باشه (شیت کد رو هم توی تیم براش سقف گذاشتیم)

برای همین خیلی از فیچرها و اید‌ه‌های اولیه در ۵-۳۰ دقیقه پیاده‌سازی می‌شه
Fail fast

اما اگر کدی که قبلا زده شده رو داریم می‌بینم چون بیزینس توی یک بخشی تغییر خواسته یا سرعت بالاتر خواسته و ما توی بررسی به یک کد dependent هم برخورد کردیم
step 1 (not new feature):
Tag it as first seen ( CHECKED: )

با یک کلید مشترک (کل تیم سرش اجماع کردند) بصورت کامنت تگ میزنید مثلا توی تیم من کلید CHECKED: هست.
نکته این کلیدهارو به ابزارهای highlight توی IDE اضافه می‌کنید که سریعتر و راحت تر دیده بشه

اگر خود شما یا دولوپر دیگری توی تیم مجددا این کد رو ببینه اولین کاری که می‌کنه تبدیل تگ هست
step 2 (see it again) :
Tag it with ( Attention: )

اگر مجدد برای بار سوم اون تابع یا کلاس یا ... رو دیدید باید refactor بزنید رو سرش
step 3 ( 3rd time) :
PROBLEM: first priority is to refactor the code

توی این لحظه اولویت اصلی شما ریفکتور کردن تایع هست (هیچ چیزی مهمتر از این نیست)

البته شرایط خاص و ۱٪ هم داریم که در اون مواقع فقط tag میزنیم بدون ریفکتور
PROBLEM:

هر کدوم از اعضای تیم وقتی کدی رو pull - fetch میکنه اولین کاری که می‌کنه اینه که دنبال PROBLEM: باید بگرده و مشکلش رو برطرف کنه.
بعد می‌تونه به کار خودش ادامه بده.


توی پروژه خیلی از توابع و کلاس‌ها هستند که ممکنه سالی ۱ بار استفاده بشه یا اصلا استفاده نشه و انقدر پروژه بزرگ هست که کسی متوجه این موضوع نمیشه

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

@PyHints

پ.ن : وقتی یک نیرو تسک برای انجام دادن نداشته باشه بجای منتظر موندن تگ‌ها رو توی کد بر اساس اهمیت refactor سرچ میکنه و شروع به refactor کردن

👍33❤3👎1

www.tgoop.com/pyHints/85

3.56K viewsedited  May 1, 2023 at 10:13

بنظر من توانایی درک و خوندن کدهای باقی افراد و کار کردن با اون فرمت کد خودش یک تخصص و مزیت هست توی کار برنامه نویسی تخصصی که متاسفانه خیلی از برنامه‌نویس‌های ایرانی ندارند حتی در سطوح بالاتر.

برای همین توی ایران تا دلتون بخواد ریفکتور می‌بینیم (خیلی موارد البته بخاطر شیت کد بودن هست) ؛ ریفکتورهایی که فقط استانداردها رو تغییر دادند و وقتی کد رو مقایسه می‌کنید لزومی نمی‌بینید برای وقتی که گذاشته شده

برای این موضوع ما ۳ هفته وقت رو از دست دادیم روی یک پروژه (مربوط به ۳ ماه قبل هست) و خیلی دوست داشتم راجبش بنویسم چون دقیقا بعد از این موضوع توی تیم خودم روشی که خودم برای ریفکتور کردن دنبال می‌کنم رو ارائه دادم

نکته : اگر دارید system design رو تغییر میدید دیگه اسمش refactor نمی‌شه و این تکنیک جواب نمیده
اما اگر بعنوان مثال کدی رو روی پروداکشن دارید که داره کار می‌کنه و system design مناسبی داره و فقط کدها بد پیاده سازی شده و پرفورمنس خوبی نداره اونوقت به ریفکتور نیاز دارید و تکنیکی که میگم :

شخصا از تکنیکی استفاده می‌کنم که توی تیم بهش میگیم
3 step refactor
وقتی بیزینس درخواست فیچر جدیدی میده که اصن معلوم نیست موندگار هست یا رفتنی یا ... و فعلا فقط روی سرور تست قرار هست بالا بیاد
step 1:
do it as fast as possible (even shit code is ok)
توی سریعترین زمان ممکن اون رو توسعه میدیم حتی اگر shit code باشه (شیت کد رو هم توی تیم براش سقف گذاشتیم)

برای همین خیلی از فیچرها و اید‌ه‌های اولیه در ۵-۳۰ دقیقه پیاده‌سازی می‌شه
Fail fast

اما اگر کدی که قبلا زده شده رو داریم می‌بینم چون بیزینس توی یک بخشی تغییر خواسته یا سرعت بالاتر خواسته و ما توی بررسی به یک کد dependent هم برخورد کردیم
step 1 (not new feature):
Tag it as first seen ( CHECKED: )

با یک کلید مشترک (کل تیم سرش اجماع کردند) بصورت کامنت تگ میزنید مثلا توی تیم من کلید CHECKED: هست.
نکته این کلیدهارو به ابزارهای highlight توی IDE اضافه می‌کنید که سریعتر و راحت تر دیده بشه

اگر خود شما یا دولوپر دیگری توی تیم مجددا این کد رو ببینه اولین کاری که می‌کنه تبدیل تگ هست
step 2 (see it again) :
Tag it with ( Attention: )

اگر مجدد برای بار سوم اون تابع یا کلاس یا ... رو دیدید باید refactor بزنید رو سرش
step 3 ( 3rd time) :
PROBLEM: first priority is to refactor the code

توی این لحظه اولویت اصلی شما ریفکتور کردن تایع هست (هیچ چیزی مهمتر از این نیست)

البته شرایط خاص و ۱٪ هم داریم که در اون مواقع فقط tag میزنیم بدون ریفکتور
PROBLEM:

هر کدوم از اعضای تیم وقتی کدی رو pull - fetch میکنه اولین کاری که می‌کنه اینه که دنبال PROBLEM: باید بگرده و مشکلش رو برطرف کنه.
بعد می‌تونه به کار خودش ادامه بده.


توی پروژه خیلی از توابع و کلاس‌ها هستند که ممکنه سالی ۱ بار استفاده بشه یا اصلا استفاده نشه و انقدر پروژه بزرگ هست که کسی متوجه این موضوع نمیشه

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

@PyHints

پ.ن : وقتی یک نیرو تسک برای انجام دادن نداشته باشه بجای منتظر موندن تگ‌ها رو توی کد بر اساس اهمیت refactor سرچ میکنه و شروع به refactor کردن

BY Python Hints