Harry Roberts: مصاحبه با نابغهٔ CSS و طراح UI

Harry Roberts: مصاحبه با نابغهٔ CSS و طراح UI

Harry Roberts یک نابغهٔ CSS و طراح UI است که با مراجعه به اکانت گیت‌هاب هری رابرتز، خواهید دید که وی در زمینهٔ اشتراک‌گذاری دانش خود با دیگر دولوپرهای فرانت‌اند نیز بسیار فعال است. در این پست قصد داریم مصاحبهٔ صورت گرفته با وی را که حاوی یکسری دیدگاه‌ها و انتقال تجربیات وی به دیگر طراحان سایت است را مد نظر قرار دهیم.

هری رابرتز سخنرانی‌ها و سوابق آموزشی زیادی در رزومهٔ خود دارا است. او به مدت ۱ سال پیش از آنکه فعالیت ۳ سالهٔ خود را در شرکت Sky به عنوان دولوپر ارشد آغاز کند، برای خودش کار می‌کرد؛ اما او بیشتر به عنوان یک معلم CSS مشهور است (برای آشنایی بیشتر با وی، می‌توانید به اکانت توییتر وی مراجعه نمایید) و این در حالی است که او در این مصاحبه قرار است درس‌هایی را که تاکنون آموخته است را با دیگران به اشتراک بگذارد. اما قبل از هر چیز، بهتر است ببینیم Harry Roberts کیست؟ او در معرفی خود می‌گوید:

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

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

هری رابرتز به طور اتفاقی درگیر وب شده است. وقتی که نوجوان بود برنامهٔ او این بود که مهندس معمار شود و بعد از ظهرها وقت خود را با کار کردن در یک فروشگاه محلی لوازم چاپ سپری می‌کرد، که از این طریق با تعداد زیادی از مهندسان معمار و نقشه‌های ایشان در ارتباط بود. در این دوران بود که او و یکی از دوستانش شروع به انجام کارهای طراحی برای شرکت‌های محلی کردند (به گفتهٔ خودش کارت‌های ویزیت، لوگو و تبلیغات افتضاح درست می‌کردند). اما در ادامهٔ‌ فعالیت وی متوجه شد که باید آثار خود را به صورت آنلاین به نمایش بگذارد و در آنجا بود که به این نتیجه رسید اگر به توسعه‌دهندگی مشغول شود، به مراتب بیش از طراحی موفق خواهد شد.

همان‌طور که گفته شد، هری رابرتز هیچ آموزشی به صورت آکادمیک ندیده است و او خود را به قدر کافی در توسعهٔ وب باانگیزه یافته بود که خودش را کاملاً در آن غرق کند. از دید وی، خودآموزی یک نقطه مثبت دارد و یک نقطهٔ منفی؛ نقطهٔ مثبت این است چون می‌توانیم هر چیزی را با سرعت دلخواه خودم یاد بگیریم. در واقع، می‌توان هر چیزی را که می‌خواهیم در هر زمانی که اراده کنیم، یاد بگیریم. نقطهٔ منفی آن هم این است که اگر این مسیر را دنبال کنیم، به طور رسمی با زبان‌های برنامه‌نویسی آشنا نخواهیم شد و در چنین شرایطی کمتر کسی وجود دارد که به ما بگوید لازم است چه چیزهایی یاد بگیریم (جالب است بدانید که بر اساس آمار استک اورفلو، چیزی در حدود ۵۰٪ از دولوپرهای سرتاسر دنیا تحصیلات آکادمیک ندارند!)

عادت به بررسی سورس‌کد
در رابطه با سورس‌کد خوانی، هری رابرتز توضیح می‌دهد که سرگرمی وی در حل کردن مسائل و ور رفتن با اشیاء خلاصه می‌شود. رابرتز می‌گوید «من از آن دست افرادی هستم که می‌گویند اگر چیزی شکسته نشده، آن را بشکنید و ببینید چه‌طور کار می‌کند. من با هر چیزی کلنجار می‌روم و آن را مهندسی معکوس می‌کنم تا از ماهیت‌اش سر در بیاورم.» 

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

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

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

تمرکز بر SASS
یکی از حوزه‌هایی که به عقیدهٔ هری رابرتز نیاز به کمی سخت‌کوشی بیشتر دارد، کار کردن با پیش‌پردازنده‌ها است. پیش‌پردازنده‌ها، برنامه‌هایی هستند که داده‌های ورودی را می‌گیرند، آنها را پردازش می‌کنند، داده‌های خروجی تولید می‌کنند تا به عنوان خروجی در برنامه‌های دیگر استفاده شوند. SASS که مخفف Syntactically Awesome Style Sheet است، یکی از زبان‌های پیش‌پردازندهٔ CSS است و این امکان را به شما می‌دهد تا ویژگی‌هایی را که زبان CSS ندارد (مثل استفاده از متغیر، توابع و غیره ) برای کدهای CSS ایجاد کنید و با این کار سرعت و زیبایی کدهای CSS را افزایش دهید.

هری رابرتز توضیح می‌دهد که یک مسئله این است که در SASS اگر چیز به درد نخوری بگذارید، چیزی به درد نخوری هم تحویل خواهید گرفت! او تأکید می‌کند که این نکته بسیار مهم است که از این حقیقت آگاه باشیم که آنچه پیش‌پردازنده‌ها به عنوان خروجی تحویل می‌دهند، چیزی است که منتج به سیستم‌های کاربران می‌شود.

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

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

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

مذاکره با مشتریان
برخلاف سن نسبتاً کم هری رابرتز، پروژه‌های مهمی همچون BBC ،NHS ،Booking.com و Financial Times را در کارنامهٔ خود دارا است. او در مورد دورانی که در حال مشاوره با چنین سازمان‌های بزرگی بود، می‌گوید که در حقیقت معمولاً مسائل از سطح کسب‌وکار برمی‌خیزند. بسیاری از شرکت‌ها درک نمی‌کنند که عملکرد، یک مسئله‌ٔ مربوط به شرکت است نه فقط مربوط به توسعه‌دهنده. معمولاً آنها فکر می‌کنند چیزهای زیادی وجود دارد که صرفاً یک توسعه‌دهنده می‌تواند انجام دهد تا عملکرد ناشی از یک تصمیم‌گیری ضعیف را بهبود بخشد.

فرهنگ سازمانی مشتریان
هری رابرتز به قانون Conway رجوع می‌کند. این اصل به احترام برنامه‌نویسی به نام Melvin Conway نامگذاری شده است که در 1968 در اظهار نظری عنوان کرد با این مضمون که شرکت‌هایی که سیستم‌های نرم‌افزاری را طراحی می‌کنند، طرح‌هایی تولید می‌کنند که کپی‌هایی از ساختارهای ارتباطی آن سازمان‌ها هستند. در اصل، رابط کاربری نرم‌افزارها، ساختارهای اجتماعی شرکت‌هایی که آنها را تولید کرده‌اند را انعکاس می‌دهند.

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

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

بسازید تا بماند
در کنار ایجاد سایت‌هایی که به سرعت اجرا می‌شوند و پرفورمنس خوبی هم دارند، یکی موضوع مهم دیگر برای هری رابرتز ساخت سایت‌های پایدار است؛ آنهایی که پس از لانچ نیاز به پشتیبانی و نگهداری زیادی ندارند. به گفتهٔ وی، او در شرکت‌هایی کار کرده که عمر سایت‌هایشان به ۳ سال می‌رسد و احتمالاً لازم است که برای ۸ سال دیگر هم باقی بمانند و کار کنند. کلید این کار سادگی است. در عین حال، به خاطر داشته باشید که هیچ فریمورک یا زبان برنامه‌نویسی خاصی وجود ندارد که بتواند سایت شما را برای ۲۰ سال سرپا نگاه دارد.

عدهٔ زیادی از مشتریان مستعد آن هستند که گرفتار جذابیت آخرین، برترین و درخشان‌ترین فناوری‌های روز دنیا شوند. برای مثال، ممکن است آنها بخواهند از یک فناوری جدید استفاده کنند و برای اطمینان از سازگاری آن با مرورگرهای قدیمی، کلی هزینه محتمل شوند! اما با این کار، دولوپر دو کار اساساً اشتباه را برای خود ایجاد کرده است. در واقع، چیزهای جدیدی را برای مرورگرهای قدیمی و چیزهای قدیمی برای مرورگرهای جدید در نظر گرفته است! 

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

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

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