مصاحبه با نابغه ی CSS، هری رابرتز و توصیه های او به توسعه دهندگان وب

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

هری رابرتز سخنرانی ها و سوابق آموزشی زیادی داشته است. او به مدت یک سال پیش از آن که فعالیت سه ساله ی خود را در شرکت Sky به عنوان توسعه دهنده ی ارشد آغاز کند، برای خودش کار می کرد. اما او بیش تر به عنوان یک معلم CSS مشهور است (از طریق حساب کاربری csswizardry@ در توییتر درس های خود را ارائه می دهد.) و این در حالی است که او در این مقاله درس هایی را که تاکنون آموخته است را در اختیار شما قرار می دهد.

اما قبل از هر چیز ببینیم هری کیست؟ او در معرفی خود می گوید: "من یک مشاور توسعه دهنده ی frontend و یک سازنده ی frontend هستم. من تمایل دارم در دوره های کاری کوتاه مدت با مشتریانی از سراسر دنیا کار کنم، به افراد کمک کنم تا ساختارهای واسط کاربری خود را بسازند و به تیم های حرفه ای کمک کنم تا در کنار هم روی محصولاتی با تاریخ مصرف بالا کار کنند."

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

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

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

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

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

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

خب، آیا رابرتز زمانی که در اینترنت می گردد بر حسب عادت کلیک راست می کند و سورس صفحات را باز می کند؟ او می گوید: "زمانی که در آغاز راه بودم در این کار بسیار بد بودم. این چیزی است که وب را به جلو حرکت داد و اگر نمی توانستم سورس صفحات را ببینم هرگز امروز یک توسعه دهنده ی وب نبودم. این کار روش بسیار خوبی برای یادگیری است."

با این وجود او سعی می کند این عادت را ترک کند، چون این عادت می تواند خسته کننده شود. او با تعجب می گوید: "دلم می خواهد بدانم وقتی گوردون رامزی (آشپز و رستوران دار معروف و موفق اسکاتلندی که رستوران های او توانسته جوایز بسیاری کسب کند،) بیرون می رود می تواند یک وعده غذا را بدون هیچ قضاوت و ابراز نظر کارشناسی در مورد آن بخورد؟ آیا او می تواند در مورد فرآیندهای آماده سازی آن فکر نکند؟ آیا می تواند به آن تنها به چشم یک غذا نگاه کند و از خوردن آن لذت ببرد؟"

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

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

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

رابرتز توضیح می دهد که: "یک مسئله این است که Sass می تواند به نوعی جعبه سیاه (یا دستگاه پیچیده ای که می توان دید و به کار برد اما نمی شود از کار آن سر درآورد) باشد. شما چیزهایی را داخل آن می گذارید و افراد اغلب آن چه را از انتهای دیگر خارج می شود نادیده می گیرند. آن چه شما باید به خاطر بسپارید این است که، "اگر چیز به درد نخورد در آن بگذارید، چیزی به درد نخور تحویل خواهید گرفت." او تأکید می کند که این نکته بسیار بسیار مهم است که از این حقیقت آگاه باشیم که آن چه پیش پردازنده ها بیرون می دهند، چیزی است که منتهی به سیستم های کاربران می شود.

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

رابرتز به یاد می آورد: "اخیراً من در یک کنفرانس مباحثه ای داغ با جان الساپ داشتم. موضع او این بود: از Sass استفاده نکنید، در حالی که موضع من این بود که نه – اگر شما نمی توانید درست با Sass کار کنید از آن استفاده نکنید."

به عقیده ی رابرتز همه چیز به شرایط وابسته است. او توضیح می دهد: "اگر شما به درستی از Sass استفاده نکنید این پتانسیل را دارد که بد باشد. مثل این است که بگوییم اسلحه ها بد هستند. آیا اسلحه ها بد هستند؟ در صورتی که با آن ها شکار کنید، نه. آیا چاقوها وسایل بدی هستند؟ در صورتی که بخواهید برای خرد کردن سبزیجات از آن ها استفاده کنید، نه!"

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

بنگاه تجاری
برخلاف سن نسبتاً کم او (امسال او مفتخر به کسب جایزه ی سال توسعه دهنده ی جوان شبکه ی اینترنت شده است)، رابرتز اکنون در لیگ سطح بالا بازی می کند، وقتی که با مشتریان رو به رو می شود یک سابقه ی بلند بالا از نمونه کارهایش ارائه می دهد که تأیید BBC، NHS،  Booking.com و ژورنال Financial Times را به رخ می کشد.

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

بنابراین او وارد حل چه نوع مسائلی می شود؟ به عبارت دیگر، شرکت ها چه می کنند که منجر به ایجاد سایت هایی می شود که ضعیف عمل می کنند؟

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

رابرتز اغلب شرکتی را پیدا می کند که ممکن است درک درستی از عملکرد نداشته باشد. به بیان دقیق تر نظر شرکت این است که سرعت، عملکرد و کارایی سایت مسائل توسعه دهندگان هستند که باید حل شوند. رابرتز تأکید می کند که: "شما نمی توانید به این شکل کار کنید."

"بخش زیادی از کاری که من انجام می دهم این است که چیزهای اضافه و غیر ضروری را کنار می زنم . . . می گویم کاربران این را از دست نخواهند داد، با این وجود آن ها نگران خواهند بود که اکنون از وب سایتی با سرعت پایین تر و ضعیف تر استفاده کنند."

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

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

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

"من می توانم به بعضی از سورس کدها نگاه کنم و فکر کنم چه قدر آن کدها مزخرفند! چرا توسعه دهنده چنین کاری را انجام داده است؟ و ... اما من می توانم برای پنج دقیقه با آن توسعه دهنده ها بنشینم و آن ها می توانند توضیح دهند که –به هر دلیلی– مجبور شده اند کاری که در ظاهر اشتباه به نظر می رسد را انجام دهند. یک دفعه متوجه می شوید که او توسعه دهنده ی بدی نیست، در واقع او توسعه دهنده ی خوبی است که در یک شرایط بسیار سخت کار می کند. بنابراین این بار که به کد نگاه کنید می بینید آن ها چه قدر مدبرانه هستند و بر اساس اصول تجاری تدوین شده اند."

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

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

او می گوید: "من در شرکت هایی کار می کنم که ممکن است عمر سایت های آن ها اکنون به سه سال برسد و احتمالاً لازم است که برای هشت سال دیگر هم باقی بمانند و کار کنند. کلید این کار سادگی است. تعداد بخش های مؤثر را کاهش دهید –اگر می توانید از شر آن ها خلاص شوید- و حتما این کار را بکنید. هیچ فریم ورک یا زبان برنامه نویسی وجود ندارد که بتواند سایت شما را برای بیست سال سرپا نگه دارد، چنان که گویی سحر آمیز است."

او توضیح می دهد: "عده ی زیادی از مشتریان مستعد آن هستند که گرفتار جذابیت آخرین، برترین و درخشان ترین فناوری های روز دنیا شوند. برای مثال ممکن است آن ها بخواهند از یک فناوری جدید استفاده کنند و برای اطمینان از سازگاری آن ها با مرورگرهای قدیمی، کلی هزینه محتمل شوند! شما در یک لحظه دو فقره کار را برای خود ایجاد کرده اید. شما چیزهای جدیدی را برای مرورگرهای قدیمی و چیزهای قدیمی برای مرورگرهای جدید دارید. موضوع این است که، چیزهای قدیمی در همه جا کار می کنند. بنابراین اگر سایت شما لازم باشد که برای مدت طولانی باقی بماند –و این یکی از مواضع غیر جذاب است که اتخاذ شود– تنها از چیزی استفاده کنید که در همه جا کار می کند."

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

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

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

0







از طریق این فرم، می توانید بدون ثبت نام نظر دهید و یا اگر قبلا ثبت نام کرده اید، با ورود ناحیه ی کاربری می توانید علاوه بر ثبت نظر، به مدیریت نظرات خود نیز بپردازید.
(فیلد اجباری)
(فیلد اجباری)
(فیلد اجباری)
(فیلد اجباری)