به گفته هری رابرتز ، توسعه دهنده ارشد UI در BSkyB ، توسعه دهندگان باید از مفهومی به نام embar.css برای سیلو کردن هرگونه CSS رفع سریع هک در پروژه ها استفاده کنند.
رابرتز در یک پست وبلاگ توضیح داد که این امر به طور بالقوه باعث می شود توسعه دهندگان هک شده در کل CSS را رد کنند و بنابراین فکر می کنند چنین مواردی به طور پیش فرض قابل قبول هستند.
علاوه بر این ، مقاله یادآور شد که چنین رویکردی ، اگر به درستی مستند شود و همراه با ابزار تکرار باشد ، می تواند پیشرفت سریعتر به سمت CSS تمیزتر را در پروژه هایی که از هک استفاده شده است (به هر دلیلی) امکان پذیر کند.
.net با رابرتز (HB) درباره هک کردن CSS و مزایای بالقوه شرمساری که cs می تواند در صورت استفاده صحیح از آن استفاده کند ، صحبت کرد.
.net: آیا فکر می کنید برخی افراد در صنعت تمایل دارند که در مورد نیاز به هک های کوتاه مدت (امیدوارم) کوتاه مدت برای کارکردن سایت غیرواقعی باشند؟
منابع انسانی: وقت بزرگ اگر در یک سایت یا محصولی کار می کنید که سالانه میلیون ها پوند درآمد کسب می کند ، هر گونه اشکال ، شکستگی یا اختلال در اسرع وقت نیاز به رفع مشکل دارد. صاحب محصول شما برای کامل بودن CSS اهمیتی ندارد - آنها به فکر بالا بودن و عملکرد سایت هستند و بیش از این درآمد کسب می کنند. کد خوب است مهم است و هک ها کاملاً ایده آل نیستند ، اما اینکه فکر کنید همیشه می توانید از هک و رفع کوتاه مدت / سریع جلوگیری کنید ، چیز نامطلوبی است.
.net: بنابراین شما می گویید که آنها فقط یک شر ضروری در تجارت هستند؟
منابع انسانی: وقتی مشتری از گردن شما نفس می کشد - یا ویژگی در یک سایت زنده خراب است - باید اطمینان حاصل کنید که ذینفعان مناسب را راضی نگه دارید. اگر شما یک ساعت وقت صرف نوشتن راه حل مناسب برای چیزی کنید که می توانستید در عرض دو دقیقه به صورت سطحی آن را برطرف کنید ، می گویم که شما فرد اشتباه را خوشحال می کنید - یعنی خودتان!
در کارهای خودم ، من متوجه شده ام که "نیاز" به هک نسبتاً متناسب با اندازه پروژه افزایش می یابد ، اما نکته خوب در این مورد این است که بعداً زمان بیشتری برای اختصاص دادن آن هک خواهید داشت.
.net: از کجا شرم آور است. css وارد می شود. با این مفهوم ، شما به طور خاص هک CSS را در نظر می گیرید؟
منابع انسانی: کاری که با توجه به زمان بیشتر می توان بهتر انجام داد. دشوار است که به مثالهایی خارج از متن فکر کنید ، اما من فکر می کنم که شما اغلب می دانید چه چیزی هک است. مطلبی را نوشته اید که از توضیح آن برای یک همکار خجالت می کشید؟ این احتمالاً هک است!
بنابراین ، embar.css درمورد تهیه پرونده ای از کارهایی است که می توانستید بهتر انجام دهید و زمانی که وقت بازدید مجدد از آنها را دارید می توانید کارهای بهتری انجام دهید. در واقع این یک لیست کار خودنوشت است - یک پرونده هک که در یک طرف قرار می دهید تا وقتی بیشتر وقت دارید فکر کنید.
.net: در مقاله خود ، شما به هک کردن مستندات اشاره می کنید ، اما آیا بحثی وجود ندارد که توسعه دهندگان به جای اینکه فقط برای هک ها باشند ، باید CSS را بیشتر مستند کنند؟
منابع انسانی: آره! اگر یک کار وجود دارد که همه توسعه دهندگان باید بیشتر انجام دهند ، نوشتن نظر است. شما باید درباره هر چیزی که بلافاصله فقط از طریق کد مشخص نیست نظر دهید. کد خود را مستند کنید تا اگر در راه رفتن به خانه با اتوبوس برخورد کردید ، همکار شما بتواند روز بعد مسئولیت را بر عهده بگیرد.
.net: از نظر تلفیق شرم. css ، چه پیشنهادی دارید؟
منابع انسانی: اگر از پیش پردازنده استفاده می کنید ، @وارد كردن شرم آور. [scss | کمتر | و غیره] در انتها ، در حالت ایده آل ، پرونده را ارسال کنید. (این همیشه می تواند منجر به مشکلات خاص و نظم منبع شود ، بنابراین مسافت پیموده شده شما ممکن است متفاوت باشد.)
اگر از پردازنده پیش پردازنده استفاده نمی کنید ، اما روند ساخت مناسبی دارید ، تمام CSS شما باید قبل از استقرار بهم پیوسته و کوچک شود ، بنابراین ، دوباره ، embar.css می تواند به انتهای آن پیچیده شود.
اگر از پیش پردازنده استفاده نمی کنید و شما یک روند ساخت ندارید ، پس یک ، شما احتمالاً باید آن را برطرف کنید ، و دو ، یک بخش هک در انتهای صفحه سبک شما احتمالاً بهترین شرط شماست. Shame.css برای بازدید عموم در نظر گرفته نشده است ، بنابراین هرگز یک صفحه سبک جداگانه با یک عنصر پیوند در نشانه گذاری خود نداشته باشید. شما باید فقط یک صفحه سبک متصل شده و کوچک ارائه دهید.
.net: اگر واقعاً شرم آور باشد. css به نظر شما چگونه می تواند روند طراحی و وب سایت ها را به طور کلی تغییر دهد؟
منابع انسانی: Shame.css فقط به اندازه توسعه دهندگانی که آن را پیاده سازی می کنند مفید است. همه خوب و خوب است که هک ها را جدا و مستند کنید ، اما اگر هرگز آنها را برطرف یا دوباره مرور نکنید ، فقط در همان قایق قبلی هستید.
برای من ، shit.css یک تغییر گسترده تر در توسعه را نشان می دهد. لازم نیست محدود به CSS شود. این مفهوم صرفاً "تحقق ، مستند سازی و ساختن نکته ای از هک های شماست". می توانید این تفکر را در همه موارد به کار بگیرید.
کار واقعی با شرمساری.css این است که تیم فوری (توسعه دهندگان) خود را در آن شرکت دهید و سپس کسب و کار / نخست وزیران / استادان اسکرام / کارشناسی / صاحبان محصولات (و غیره) را از این واقعیت آگاه کنید که یک محصول گاهی اوقات شامل کالاهای کمتری خواهد بود. از کد ایده آل ، اما این کد برای پاسخگویی به نیازهای تجاری وجود دارد.
به آنها بگویید که هک ها را منزوی و مستند می کنید و کمی زمان توسعه برای مرتب سازی امور اختصاص دهید. اگر می توانید کمیت آن را تنظیم کنید ، تهیه یک پرونده تجاری برای مرتب کردن یک کد پایه آسان تر است. به سادگی به مدیر پروژه خود بگویید ، "من قبل از رفتن به ویژگی X بعضی چیزها را مرتب می کنم" همیشه این کار را نمی کند! لیستی از موارد را به PM خود برسانید و سعی کنید نصف روز زمان دو سرعت برای صرف نظافت داشته باشید.
ایده پشت شرم.css این است که هک های شما شفاف تر ، قابل اندازه گیری و منزوی شود. این شما هستید که با این اطلاعات چه کار می کنید!
