بازسازی (Refactoring) در برابر بازطراحی (Redesigning)


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

رویای همه‌ی آدمها طراحی، نوشتن، کار در ابتدای پروژه، توسعه و اجرای یک سرویس یا نرم افزار کاملا تازه است. رویای بنیان گذاران استارتاپ ها!

اما حتی اگر کار خود را روی پروژه های که فکر می کنید جدید هستند، شروع کنید، بازهم دیر یا زود باید تغییراتی روی آن انجام دهید و آن را بهبود دهید. بعضی اوقات این تغییرات بسیار گسترده است، و برای ورژن بندی این تغییرات باید از ورژن 1.0 به ورژن 2.0 بروید.

خیلی قبلتر، در سال 2000 میلادی، چوئل اسپلسکی نوشت که طراحان ...

در واقع در قلبشان معمارند! و با دیدن وبسایت، اولین کاری که میخواهند انجام دهند این است که با بولدوزر آن را بکوبند و از نو بسازند! ما با بهبود و نوسازی تدریجی، زیاد هیجان زده نمیشیم: سرهم بندی، بهبود و سپس کاشت دسته گل!

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

یک UI یا سیستم طراحی (design system) یا استایل ها، بدلیل تغییر نام تجاری شرکت یا بِرند، سرویس یا نرم افزار جدید، یا حتی تغییر سلیقه شرکا، رییس و مشتریان، نیاز به بروزرسانی و انطباق دارد.

وسوسه همیشه به ما میگوید "باید همه چیز را از صفر باز طراحی کنیم". "بیا از اول شروع کنیم".

در برنامه نویسی، وقتی میخواهید تغییرات بدهید 2 تا انتخاب دارید: بازنویسی یا تغییر شکل مجدد.

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

در طراحی هم همینطور است و تفاوت چندانی وجود ندارد. شرکت قصد دارد تا نرم افزار یا کتابخانه ای که قبلا طراحی شده را تغییر دهد. سیستم طراحی که ایجاد شده دیگر جوابگوی خدمات و وِیژگی های محصول نیست. تِرِند های جدید طراحی میتوانند ظاهر App را بروزتر کنند و ... .

سیستم طراحی خیلی خوب قابل درک است ولی مستندات و داکیومنت وحشتناکی دارد.

دلیل آن مهم نیست، که تغییرات نرم افزار یا طراحی باشد. زمان زیادی برای بازنویسی یا بازطراحی ندارید.

در برنامه نویسی وقتی یک برنامه کار می کند واضح است که باگ ها و اشکالات آن در کمترین میزان ممکن است. اما در طراحی اینطور نیست و مانند برنامه نویسی خیلی واضح نیست.

چه زمانی بازنویسی اختیاری نیست

زمانی که من مسئول استراتژی جدید برای دانشگاه بودم، باید در نظر می گرفتیم چگونه باید با تغییرات و مشکلات ناشی از افزایش پذیرش دانشجویان مقابله کرد.

کار قبلی من انجام شده بود. در واقع این کار قبلا چندین بار انجام شده بود. بیاید اشاره کوتاهی به لوگو بکنم.

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

2 یا 3 فایل image متفاوت از لوگو و آرم روی لباس دانشگاه وجود داشت. تفاوتی نه چندان بزرگ برای افراد غیر متخصص اما در عین حال مهم برای بخش بازاریابی دیجیتال و تبلیغات چاپی.

جزئیات ظریفی در شکل، نوع فونت و حتی پارامتر hue تنها بخش کوچکی از مشکل ما بود. مشکلات بزرگتری داشتیم مثل اینکه، لوگو بصورت bitmap ذخیره شده بود و هیچ فایل وکتوری از آن وجود نداشت.

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

اولین وسوسه این بود که از صفر آنها را بازطراحی کنیم و با لوگو این کار را شروع کنیم. اما با 2 مشکل برای انجام این کار مواجه شدیم.

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

ما تصمیم گرفتیم بجای بازطراحی آن را مجددا تغییر شکل دهیم.

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

برای طراحان فایل وکتور-محور و فایل bitmap در چند سایز و رزولوشن، برای چاپ و اسناد، نام تجاری (بِرند) و استایل دستی برای ایجاد تمایز بین لوگو و آرم روی لباس دانشگاه ساختیم.

ما میدانستیم که در آینده نه چندان دور باید همه چیز را بازطراحی کنیم اما در آن زمان نه.

بازسازی (Refactoring)

از تعریف معنی Refactoring توسط آقای مارتین فاولر خوشم آمد:

"بازسازی (Refactoring) فرآیند تغییر یک سیستم نرم افزاری است به گونه ای که باعث تغییر در رفتار خارجی کد نمی شود اما ساختار داخلی آن را بهتر می‌کند."

دوباره بگم که این جمله را میتوانید برای طراحی هم استفاده کنید. چیزی که در این تعریف دوست دارم این است: "ساختار داخلی را بهتر می‌کند".

در برنامه نویسی مانند طراحی، مشکل بازسازی (Refactoring) این است که در پایان، همه چیز مانند قبل به نظر میرسد. هیچ تغییر مشهودی در برنامه یا طراحی وجود ندارد.

خب، در طراحی بر خلاف برنامه نویسی، تغییرات ظاهری وجود دارد اما این تغییرات زیاد به چشم نمی آید.

عناصر در UI، می توانند نسبت بدی با سایر عناصر داشته باشند یا داخل یک گرید طراحی نشده باشند و یا داخل یک لایه. وبسایت می تواند از رنگ های متفاوتی بجای یک پالت رنگی ثابت استفاده کند. اما اپلیکیشن نمی‌تواند آماده‌ی accessibility standards (استانداردهای دسترسی پذیری) نباشد.

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

بازسازی شاید در ابتدا زمان زیادی از شما بگیرد اما در دراز مدت باعث صرفه جویی در وقت می شود. این مزیتی است که باید در نظر گرفته شود.

و شما میتوانید این مفهوم را در سایر زمینه ها نیز پیاده کنید. می‌توانید بجای بازنویسی، آن را بازسازی کنید. برای مثال. جابجایی چند جمله یا پاراگراف باعث بهود مقاله می شود.

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



این مقاله به قلم آقای Adolfo Ramírez Corona در تاریخ 30 ام ژانویه 2020 با نام refactoring vs redesigning منتشر شده است.

کانال تلگرام جامعه طراحان