من مدت زیادی است که در حال توسعه برنامه های وب هستم. مدت ها پیش. اولین برنامه های وب شما در محیط من در آن روزها ایجاد کردم که کلمه "گوگل" هنوز یک فعل نبود و برای جستجوی اطلاعات در اینترنت مردم از Yahoo! و رامبلر من از آن استفاده کردم اوم - آنها یک جستجوی محدود داشتند و نه یک رابط پربار زشت مانند یاهو!
توسعه برنامه ها، هر برنامه ای، نه فقط برای وب، یک کار خلاقانه است. بعید است که کسی با این بیانیه استدلال کند. و زیبایی در خلاقیت مانند تمرین در دانش علمی است - معیار حقیقت. اما اگر عمل علمی عینی و مبتنی بر اندازه گیری باشد، زیبایی یک موضوع ذهنی است، بسته به اینکه چه کسی به دنبال آن است. بنابراین از خودم پرسیدم که یک برنامه وب زیبا برای شخص من چیست؟
(در KDPV چشم مال من نیست، چشم یک زن است، اما، IMHO، چشم یک زن روی KDPV از چشم یک مرد مناسب تر است، زیرا اینطور است - !)
در زیر برش معیارهای خودم برای اینکه چه برنامه وب را می توان در حال حاضر زیبا دانست، آمده است. یک بیانیه بسیار ذهنی بر اساس تجربه شخصی من. شاید برای برخی معیارهای من برای زیبایی معیاری برای زشتی به نظر برسد. تعجب نکنید، شما فقط یک تجربه متفاوت دارید.
و چون قبلا وارد برش شده اید لطفا در نظرات خود دقت کنید. به هر حال، اگر بتوانید به محض اینکه مطالبی که در آن نوشته شده برای شما زشت یا حتی زشت به نظر برسد، خواندن آن را متوقف کنید، من به عنوان نویسنده مجبور هستم همه نظرات را بخوانم.
زیستگاه
پروتکل ها
من حتی نمی دانم که آیا ارزش آن را دارد که این معیار را جداگانه تعیین کنم. برنامه های کاربردی وب روی وب زندگی می کنند و مجبور هستند از قوانین وب (پروتکل ها) پیروی کنند. پروتکل های اصلی در اینترنت عبارتند از: и . بسیاری از پروتکل های دیگر بر اساس آنها ساخته شده اند، اما برای برنامه های وب مهمترین آنها را می دانم (یا بهتر بگوییم، گسترش آن روی پایه ). یعنی یک برنامه وب زیبا از طریق HTTPS/TLS (اختیاری - از طریق HTTP) در دسترس است و پروتکل های دیگر (LDAP، RPC، IMAP4، POP3، SMTP، FTP، NNTP، ...) با پشتیبانی اضافی از هر کدام زیبایی آن را کاهش می دهند. پروتکل خود برنامه می تواند از منابع خارجی با استفاده از این پروتکل های اضافی استفاده کند.
با توجه به اینکه ، پس من تجربه کافی در استفاده از این پروتکل با برنامه های وب ندارم. زیبا و امیدوارکننده به نظر می رسد، اما نمی توانم بگویم که چقدر پایدار و کاربردی است.
مرورگرها
یک برنامه وب فقط یک پا در سمت سرور و پای دیگر در سمت مشتری دارد. سمت مشتری مرورگر است. یک مرورگر مدرن ارائه می دهد ، که یک برنامه وب مدرن می تواند و باید از آن به نفع خود استفاده کند. یک برنامه وب زیبا از قابلیت های مرورگر مدرن استفاده می کند و نیازی به کار در مرورگرهایی که قابلیت های مدرن را ارائه نمی دهند نیست. میفهمم، متوجه هستم، درک میکنم - این یک اقدام لازم است، اما قبیح است. در پایان، نه تنها توسعهدهندگان باید با فناوریهای مدرن همگام باشند، این امر در مورد کاربران و کسبوکارها نیز صدق میکند.
JP
با زبان های برنامه نویسی که برای ایجاد برنامه های کاربردی وب استفاده می شود، همه چیز بسیار گیج کننده است. برای سمت مشتری برنامه های کاربردی وب، فناوری های زیادی وجود دارد که به توسعه دهنده اجازه می دهد تا ایجاد سه گانه HTML/CSS/JS (چیزی که همه مرورگرهای مدرن آن را درک می کنند) تسهیل کند. اما یک زمانی با او ارتباط نزدیکی برقرار کردم و من فکر میکنم وقتی یک توسعهدهنده کد اصلی را در مرورگر میبیند زیباست، نه نتیجه کامپایل یا ترجمه. بنابراین استفاده کنید و محصولات مشابه برای تولید کد مشتری، IMHO، زشت هستند. هر چه کدی که در مرورگر اجرا می شود شبیه کد منبع ایجاد شده توسط توسعه دهنده باشد، بهتر است. باور نمی کنی؟ سعی کنید کد تولید شده توسط GWT را در تولید اشکال زدایی کنید.
در سمت سرور آزادی بیشتری وجود دارد (جاوا، پی اچ پی، پرل، پایتون، سی شارپ، روبی، ...)، اما به نظر من وقتی از یک زبان برنامه نویسی هم در سمت سرور و هم در سرور استفاده می شود، زیباست. مرورگر - جاوا اسکریپت. هنوز ، و تیم هایی از افراد همفکر سازنده تر هستند.
بشریت
یک برنامه وب زیبا باید مفید باشد. مفید، اول از همه، برای انسان، به عنوان مصرف کننده نهایی. بنابراین، من نمی توانم آن را یک برنامه وب زیبا بنامم . برای یک فرد معمولی (نه یک توسعه دهنده وب) کار با آنها دشوار است. وب سرویس ها در نوع خود زیبا هستند،
یک برنامه وب زیبا باید یک رابط بصری داشته باشد. می توان در مورد آن بحث کرد e یک چیز نسبتاً ذهنی است. بینی همه چیز بسیار ساده تر است اگر کاربر نتواند از برنامه بدون نیاز به ارزش استفاده کند - UX بد، برنامه وب زشت. زیباترین برنامه های تحت وب نسبت به این معیار می توانند به راحتی توسط کودکانی که هنوز خواندن بلد نیستند استفاده کنند.
مقیاس پذیری معکوس
روزی روزگاری، برنامه ها می توانستند روی فلاپی دیسک ها منتقل شوند، اکنون - در درایوهای فلش یا بلافاصله از اینترنت دانلود شوند. کپی کردن یک برنامه معمولی و اجرای آن بر روی یک دستگاه دیگر یک کار بی اهمیت است. وضعیت برنامه های وب تا حدودی خاص است. شبکه یک محیط جهانی است که در آن نیازی به داشتن کلون های یک برنامه وب مشابه نیست. در اینترنت، یک فیس بوک، توییتر، اینستاگرام، Mail.ru یا Yandex کافی است. میتوانید برنامههای وب متفاوتی را در یک جایگاه موضوعی، اما با مخاطبان مختلف (مانند فیسبوک و Vkontakte، Mail.ru و Gmail، Google Maps و Azure Maps) داشته باشید. منابع سخت افزاری برای اطمینان از در دسترس بودن جهانی چنین برنامه های کاربردی وب مورد نیاز است، فرض کنید، .
من هرگز به عنوان یک توسعه دهنده با برنامه های تحت وب در این سطح کار نکرده ام و نمی دانم چگونه آنها در داخل کار می کنند. برای اطمینان از عملکرد چنین برنامه های کاربردی وب، تیم هایی از متخصصان مربوطه و مراکز داده جداگانه مورد نیاز است. من توانایی افراد برای همکاری در چنین مقیاسی و ایجاد چنین محصولاتی را تحسین می کنم، اما استاندارد زیبایی من یک برنامه وب است که می تواند روی یک لپ تاپ جداگانه اجرا شود.
یک برنامه وب زیبا نه تنها به سمت بالا و بیرون (برای کاربران)، بلکه به سمت پایین و درون (برای توسعه دهندگان) مقیاس می شود.
"دوزیستی"
برای دسترسی به برنامه های کاربردی وب مدرن، از دو نوع دستگاه استفاده می شود:
- کامپیوتر (لپ تاپ، دسکتاپ)؛
- دستگاه های تلفن همراه (گوشی های هوشمند و تبلت)؛
جایی در افق بیشتر نمایان می شود""اما فعلا همین است.
تفاوت کامپیوترها با دستگاه های تلفن همراه به همان اندازه که موجودات خشکی با پرندگان آبزی تفاوت دارند. اینها محیط های متفاوتی هستند و خواسته های متفاوتی از موجودات (برنامه ها) ساکن در آن ها می گیرند. برنامه های وب زیبا آنهایی نیستند که به نظر برسند و کسانی که در آب هستند مانند ماهی و در خشکی مانند حیوانات و در هوا هستند.) - مانند پرندگان.
به نظر من زشته"«، مثل این است که بخواهید روی دو (با سئو - سه) صندلی بنشینید. بهتر است مانند فیونا از شرک - یکی در روز و دیگری در شب. بله گرون تره ولی بهتره
اشتراک گذاری متقابل
من قبلاً در پاراگراف "مقیاس پذیری معکوس" اشاره کردم که جهانی بودن شبکه امکان داشتن یک برنامه وب در هر سیاره را فراهم می کند. بنابراین، هر برنامه وب باید حداقل تا حدودی با بقیه متفاوت باشد تا بقای آن تضمین شود. با این حال، تجربه چندین ساله من با (چارچوبی برای ساخت فروشگاههای تجارت الکترونیک) میگوید که ممکن است شباهتهای بیشتری بین برنامههای کاربردی وب فردی وجود داشته باشد تا تفاوتها. یک برنامه وب عالی نه تنها باید ماژولار باشد، بلکه باید ماژول های خود را با سایر برنامه های وب نیز به اشتراک بگذارد. تا حدودی این ایده در JSR 168 و JSR 286 و فریمورک هایی مانند , و همان Magentoبه نظر من، هر چه یک برنامه وب از ماژولهای بیشتری استفاده کند، زیباتر است. اشتراکگذاری متقابل امکان ایجاد ماژولهای با کیفیت بالاتر و در نتیجه، برنامههای وب پایدارتر را فراهم میکند.
منظور من از ماژول کتابخانههایی مانند jQuery یا RequireJS نیست - موجودیتهای بزرگتر، مانند افزونهها در и . اما در مورد کتابخانه ها، این تز نیز صادق است که توزیع گسترده کتابخانه امکان بهتر و پایدارتر کردن آن را فراهم می کند.
معماری هاروارد
، بر خلاف توپ فعلی حاکم ، به معنای جداسازی کد و داده است. معماري بلند نشد، اما خود اين ايده شخصاً براي من زيبا به نظر ميرسد. به خصوص برای برنامه های تحت وب. هر گونه ثابت (HTML/CSS/JS/Images/…) کد است. می تواند و باید در سمت سرور یا در سمت سرویس گیرنده ذخیره شود. و داده است / (زیبا) یا / (کمی کمتر زیباتر). یا WebSockets/JSON (ممکن است بهترین گزینه باشد، اما من آن را امتحان نکرده ام).
بومی سازی
دو چیز وجود دارد که به ویژه هنگام توسعه برنامه های کاربردی وب من را نگران می کند - یک رابط چند زبانه و مناطق زمانی. من اهل لتونی هستم، ما سه زبان در حال استفاده داریم: LV، RU، EN. یک برنامه وب زیبا نه تنها باید به شما اجازه دهد از چندین زبان در خود برنامه استفاده کنید، بلکه به شما امکان می دهد تعداد زبان های مورد استفاده را با استفاده از منابع خارجی مانند . همین امر در مورد ماژول هایی که برنامه وب از آنها مونتاژ می شود نیز صادق است.
با مناطق زمانی همه چیز ساده است، در همه مواردی که نحوه پردازش تاریخ-زمان مشخص نیست، این کار را انجام دهید: هر چیزی که روی سرور است به سرور می رود و از سرور می آید - UTC، همه چیزهایی که در مشتری نمایش داده می شود. - با توجه به منطقه زمانی از نمایه کاربر. زیبا است.
به جای ستاره های مرگ جعل می کند
خیلی وقت پیش، هر شهر کم و بیش بزرگی فورج مخصوص به خود را داشت. شاید تنها نباشد. برخی بهتر هستند، برخی بدتر. آهنگرهایی در سرتاسر دنیا شناخته شده بودند و کسانی هم بودند که چون جایگزینی نداشتند به سراغشان آمدند. جنگ ها، بیماری های همه گیر و بلایای طبیعی وجود داشت. برخی از شهرها همراه با جمعیت ناپدید شدند. اما صنعت آهنگر زنده ماند. به جای شهرهای ناپدید شده، شهرهای جدیدی ساخته شد و آهنگری نیز در آنها ظاهر شد.
اکنون به خدماتی مانند نگاه کنید . وقتی سرورهای ریشه از کار میافتند، .
به نظر من یک وب اپلیکیشن زیبا نمی تواند به اندازه فیس بوک یا Mail.ru باشد. این در حال حاضر نزدیک تر است به ""هم از نظر منابع لازم برای ساخت و ساز و هم از نظر منابع لازم برای حفظ عملکرد. بله، اگر فیس بوک نابود شود، بشریت ناپدید نخواهد شد؛ عملکردهای آن به سرعت توسط برنامه های کاربردی دیگر (همان). در قلمرو فدراسیون روسیه و مناطق اطراف، اینستاگرام، توییتر، ...). با این حال، قفل کردن بخش قابل توجهی از جمعیت سیاره به یک برنامه زیبا نیست. علاوه بر این، با توجه به در دسترس بودن جایگزین های بسیار پایدارتر (مانند. ).
خلاصه
اگر تا آخر خوانده اید و گیج شده اید - "چی بود؟"سپس من همدردی صمیمانه خود را با شما ابراز می کنم. مجبورت نکردم اینو بخونی من فقط سعی کردم افکارم را در قالب کلمات بیان کنم تا دیگرانی را پیدا کنم که همینطور فکر می کنند. شاید بتوانم با آنها در مورد برخی از جنبه های ایجاد برنامه های کاربردی وب زیبا صحبت کنم و پاسخ سوالات خود را بیابم. و من تعداد زیادی از آنها را دارم.
با تشکر برای خواندن.
منبع: www.habr.com
