אני מפתח אפליקציות אינטרנט כבר הרבה זמן. לפני זמן רב. יישומי האינטרנט הראשונים שלך בסביבה יצרתי באותם ימים שבהם המילה "גוגל" עדיין לא היה פועל, וכדי לחפש מידע באינטרנט אנשים השתמשו ב-Yahoo! ורמבלר. אני השתמשתי בזה אום - היה להם חיפוש מצטמצם ולא ממשק עמוס כל כך מכוער כמו Yahoo!
פיתוח אפליקציות, כל אפליקציות, לא רק עבור האינטרנט, הוא עבודה יצירתית. לא סביר שמישהו יתווכח עם האמירה הזו. ויופי ביצירתיות הוא כמו תרגול בידע מדעי - קריטריון של אמת. אבל אם הפרקטיקה המדעית היא אובייקטיבית ומבוססת על מדידות, אז היופי הוא נושא סובייקטיבי, תלוי במי שמסתכל. אז שאלתי את עצמי, מהי אפליקציית אינטרנט יפה עבורי באופן אישי?
(ב-KDPV העין היא לא שלי, זו עין של אישה, אבל, IMHO, עין של אישה על KDPV מתאימה יותר מזו של גבר, כי זה - !)
מתחת לגזרה מופיעים הקריטריונים שלי לאיזה יישום אינטרנט יכול להיחשב נכון לעכשיו. אמירה סובייקטיבית מאוד המבוססת על הניסיון האישי שלי. אולי לחלק הקריטריונים שלי ליופי ייראו כמו קריטריונים לכיעור. אל תתפלאו, פשוט יש לכם חוויה אחרת.
ומכיוון שכבר נכנסת לגזרה, נא להיזהר בהערותיך. הרי אם אתה יכול להפסיק לקרוא מאמר ברגע שהאמור בו נראה לך מכוער או אפילו מכוער, אז אני ככותב נאלץ לקרוא את כל התגובות.
בית גידול
פרוטוקולים
אני אפילו לא יודע אם כדאי לקבוע את הקריטריון הזה בנפרד. יישומי אינטרנט חיים ברשת ונאלצים לציית לחוקי האינטרנט (פרוטוקולים). הפרוטוקולים העיקריים באינטרנט הם: и . פרוטוקולים רבים אחרים מבוססים עליהם, אבל עבור יישומי אינטרנט אני מחשיב את החשוב ביותר (או ליתר דיוק, ההרחבה שלו על הבסיס ). כלומר, אפליקציית אינטרנט יפה זמינה באמצעות HTTPS/TLS (אופציונלי - באמצעות HTTP), ופרוטוקולים אחרים (LDAP, RPC, IMAP4, POP3, SMTP, FTP, NNTP,...) הופכים אותו לפחות יפה כשכל אחד מהם נתמך בנוסף נוהל. היישום עצמו יכול להשתמש במשאבים חיצוניים באמצעות פרוטוקולים נוספים אלה.
ביחס , אז אין לי מספיק ניסיון בשימוש בפרוטוקול זה עם יישומי אינטרנט. זה נראה יפה ומבטיח, אבל אני לא יכול להגיד כמה זה יציב ופרקטי.
דפדפנים
לאפליקציית אינטרנט יש רק רגל אחת בצד השרת, והשנייה בצד הלקוח. צד הלקוח הוא הדפדפן. דפדפן מודרני מספק , אשר אפליקציית אינטרנט מודרנית יכולה וצריכה להשתמש בה לטובתה. אפליקציית אינטרנט יפהפיה משתמשת ביכולות הדפדפן המודרניות ואינה נדרשת לעבוד בדפדפנים שאינם מספקים יכולות מודרניות. אני מבין ש - זה אמצעי הכרחי, אבל הוא מכוער. בסופו של דבר, לא רק מפתחים חייבים להתעדכן בטכנולוגיות מודרניות, זה חל גם על משתמשים ועסקים.
JP
עם שפות התכנות המשמשות ליצירת יישומי אינטרנט, הכל מאוד מבלבל. עבור צד הלקוח של יישומי אינטרנט, יש הרבה טכנולוגיות המאפשרות למפתח להקל על היצירה של שלישיית HTML/CSS/JS (דבר שכל הדפדפנים המודרניים מבינים). אבל בשלב מסוים באתי במגע קרוב עם ואני חושב שזה יפה כשמפתח רואה את הקוד המקורי בדפדפן, ולא תוצאה של קומפילציה או טרנספילציה. לכן השתמש "ומוצרים דומים להפקת קוד לקוח, IMHO, הם מכוערים. ככל שהקוד שרץ בדפדפן דומה יותר לקוד המקור שיצר המפתח, כך ייטב. לא מאמין לי? נסה לנפות באגים בקוד שנוצר על ידי GWT בייצור.
יש יותר חופש בצד השרת (Java, PHP, perl, python, C#, Ruby,...), אבל נראה לי שזה יפה כשמשתמשים באותה שפת תכנות גם בצד השרת וגם ב- דפדפן - JavaScript. עוֹד , וצוותים של אנשים בעלי דעות דומות פרודוקטיביים יותר.
אֶנוֹשִׁיוּת
יישום אינטרנט יפה אמור להיות שימושי. שימושי, קודם כל, לבני אדם, כצרכן הקצה. לכן, אני לא יכול לקרוא לזה יישום אינטרנט יפה . קשה לאדם רגיל (לא מפתח אינטרנט) לעבוד איתם. שירותי אינטרנט הם יפים בדרכם שלהם,
יישום אינטרנט יפה צריך להיות בעל ממשק אינטואיטיבי. אפשר להתווכח על זה דבר סובייקטיבי למדי. אף הכל הרבה יותר פשוט אם המשתמש לא יכול להשתמש באפליקציה ללא היקר - UX גרוע, יישום אינטרנט מכוער. יישומי האינטרנט היפים ביותר ביחס לקריטריון זה יכולים לשמש בקלות ילדים שעדיין לא יודעים לקרוא.
מדרגיות הפוכה
פעם אפשר היה להעביר תוכניות על תקליטונים, עכשיו - על כונני הבזק או להוריד מיד מהאינטרנט. העתקת אפליקציה רגילה והפעלתה על מחשב אחר היא משימה טריוויאלית. המצב עם יישומי אינטרנט הוא קצת מיוחד. הרשת היא סביבה גלובלית שבה אין צורך שיבוטים של אותה אפליקציית אינטרנט. באינטרנט מספיק פייסבוק, טוויטר, אינסטגרם, Mail.ru או Yandex. אתה יכול לקבל יישומי אינטרנט שונים באותה נישה נושאית, אבל עם קהלים שונים (כמו Facebook ו-Vkontakte, Mail.ru ו-Gmail, Google Maps ו-Azure Maps). יש צורך במשאבי חומרה כדי להבטיח זמינות גלובלית של יישומי אינטרנט כאלה, נניח, .
מעולם לא עבדתי עם יישומי אינטרנט ברמה זו כמפתח ואין לי מושג איך הם עובדים בפנים. כדי להבטיח את הפונקציונליות של יישומי אינטרנט כאלה, יש צורך בצוותים של מומחים רלוונטיים ומרכזי נתונים נפרדים. אני מעריץ את היכולת של אנשים לשתף פעולה בקנה מידה כזה וליצור מוצרים כאלה, אבל רמת היופי שלי היא אפליקציית אינטרנט שניתן להפעיל על מחשב נייד נפרד.
אפליקציית אינטרנט יפה משתנה לא רק כלפי מעלה והחוצה (עבור משתמשים), אלא גם כלפי מטה ופונה (למפתחים).
"אמפיביות"
כדי לגשת ליישומי אינטרנט מודרניים, משתמשים בשני סוגים של מכשירים:
- מחשבים (מחשבים ניידים, שולחניים);
- מכשירים ניידים (סמארטפונים וטאבלטים);
איפשהו באופק מתנשא יותר""אבל זהו לעת עתה.
מחשבים שונים ממכשירים ניידים באותה מידה שיצורי יבשה שונים מעופות מים. אלו הן סביבות שונות והן מציבות דרישות שונות מהיצורים (התוכניות) החיים בהן. יישומי אינטרנט יפים הם לא אלה שנראים כמו ואלה שבמים הם כמו דגים, ביבשה כמו חיות ובאוויר () - כמו ציפורים.
אני חושב שזה מכוער"", זה כמו לנסות לשבת על שני כסאות (עם SEO - שלושה). עדיף כמו פיונה משרק - אחת ביום ואחרת בלילה. כן, יותר יקר. אבל יותר טוב.
שיתוף צולב
כבר ציינתי בפסקה "מדרגיות הפוכה" שהגלובליות של הרשת מאפשרת יישום אינטרנט אחד לכל פלנט. לכן, כל אפליקציית אינטרנט חייבת להיות שונה לפחות במידת מה מאחרות על מנת להבטיח את הישרדותה. עם זאת, הניסיון רב השנים שלי עם (מסגרת לבניית חנויות מסחר אלקטרוני) אומר שייתכן שיש יותר דמיון בין יישומי אינטרנט בודדים מאשר הבדלים. אפליקציית אינטרנט נהדרת צריכה להיות לא רק מודולרית, היא צריכה גם לשתף את המודולים שלה עם יישומי אינטרנט אחרים. במידה מסוימת הרעיון הזה בא לידי ביטוי JSR 168 ו-JSR 286 ומסגרות כגון , ואותו הדבר Magentoככל שאפליקציית אינטרנט משתמשת ביותר מודולים, כך היא יפה יותר, לדעתי. שיתוף צולב מאפשר יצירת מודולים באיכות גבוהה יותר, וכתוצאה מכך, אפליקציות אינטרנט יציבות יותר.
במודול אני לא מתכוון לספריות כמו jQuery או RequireJS - אלא ישויות גדולות יותר, כמו תוספים ב и . אבל לגבי ספריות, התזה נכונה גם שההפצה הנרחבת של הספרייה מאפשרת להפוך אותה לטובה ובת קיימא יותר.
ארכיטקטורת הרווארד
, בניגוד לכדור השולט כרגע , מרמז על הפרדה של קוד ונתונים. הארכיטקטורה לא המריאה, אבל הרעיון עצמו נראה לי יפה. במיוחד עבור יישומי אינטרנט. כל סטטי (HTML/CSS/JS/Images/...) הוא קוד. אפשר וצריך לשמור אותו בצד השרת או בצד הלקוח. והנתונים כן / (יפה) או / (קצת פחות יפה). או WebSockets/JSON (אולי האפשרות הטובה ביותר, אבל לא ניסיתי אותה).
לוקליזציה
ישנם שני דברים שמעסיקים אותי במיוחד בעת פיתוח אפליקציות אינטרנט - ממשק רב לשוני ואזורי זמן. אני מלטביה, יש לנו שלוש שפות בשימוש: LV, RU, EN. אפליקציית אינטרנט יפה צריכה לא רק לאפשר לך להשתמש במספר שפות באפליקציה עצמה, אלא גם לאפשר לך להרחיב את מספר השפות בשימוש באמצעות משאבים חיצוניים, כגון . הדבר נכון גם לגבי המודולים שמהם מורכבת אפליקציית האינטרנט.
עם אזורי זמן הכל פשוט, בכל המקרים כשלא ברור איך לעבד תאריך-שעה, עשה זאת: כל מה שנמצא בשרת עובר לשרת ומגיע מהשרת - UTC, כל מה שמוצג בלקוח - לפי אזור הזמן מפרופיל המשתמש. זה יפה.
מחשל במקום כוכבי מוות
לפני זמן רב, לכל עיירה גדולה פחות או יותר הייתה מספחה משלה. אולי לא לבד. חלקם טובים יותר, חלקם גרועים יותר. היו נפחים ידועים בכל העולם, והיו גם כאלה שהגיעו אליהם כי לא הייתה אלטרנטיבה. היו מלחמות, מגיפות ואסונות טבע. כמה עיירות נעלמו יחד עם האוכלוסייה. אבל מלאכתו של הנפח נותרה בחיים. במקום הערים שנעלמו נבנו חדשות והופיעו בהן גם מחושות.
עכשיו תסתכל על שירות כמו . כאשר שרתי השורש יורדים, .
לדעתי, יישום אינטרנט יפה לא יכול להיות גדול כמו Facebook או Mail.ru. זה כבר יותר קרוב ל""הן מבחינת המשאבים הדרושים לבנייה, והן מבחינת המשאבים הדרושים לשמירה על תפעול. כן, אם פייסבוק תהרוס, האנושות לא תיעלם; הפונקציות שלה ישתלטו במהירות על ידי יישומים אחרים (אותו על שטח הפדרציה הרוסית והסביבה, אינסטגרם, טוויטר, ...). עם זאת, נעילת חלק נכבד מאוכלוסיית כדור הארץ לאפליקציה אחת אינה יפה. יתרה מכך, בהתחשב בזמינותן של חלופות הרבה יותר בנות קיימא (למשל. ).
תקציר
אם קראת עד הסוף ואתה מבולבל - "מה זה היה?"אז אני מביע את אהדתי הכנה אליך. לא הכרחתי אותך לקרוא את זה. פשוט ניסיתי לבטא את המחשבות שלי במילים כדי למצוא אחרים שחושבים באותה צורה. אולי אוכל לדון איתם בכמה היבטים של יצירת יישומי אינטרנט יפים ולגלות תשובות לשאלות שלי. ויש לי הרבה מהם.
תודה שקראת.
מקור: www.habr.com
