פריות
- פותח הנושא jellymean
- פורסם בתאריך
זו שאלה של עלות מול תועלת
יש באמת בעיתיות בזה שסיפריות הן יותר מידיי דינמיות ובכדי לקבל גרסה עם תיקוני באגים אתה צריך גם לשנות את הקוד שלך שמשתמש בספריה.
 
אולי יש סוגי פרוייקטים שבהם התועלת היא לא גדולה במיוחד מהסיפריה ואז אולי לא שווה להיכנס לזה. ברוב הפרוייקטים אני מניח שהספריות האלו יחסכו לך המון זמן ומאמץ ויעזרו לך להוציא מוצר טוב יותר.
 
אחת הבעיות עם הספריות האלו זה ה-pit falls ואלה דברים שאתה לא תמיד מודע אליהם בפרוייקט הראשון שאתה כותב עם ספריה מסויימת ואז יצא שהספריה הכניסה לך יותר בעיות ממה שהיא פתרה וזה יכול להיות מתסכל.
קישור לדוגמא: https://nathanleclaire.com/blog/2014/04/19/5-angularjs-antipatterns-and-pitfalls/
 
אין תחליף לנסיון בדברים האלו ואם אתה עובד לבד אז אתה לא רוצה להתגלח על הלקוח הראשון שתכניס לפרוייקט שלו את הספריה הזו. אפשר אולי במקרה כזה לעשות את הפרוייקט בשיתוף עם מישהו מנוסה בספריה או לעשות פרוייקט בהתנדבות לאיזו עמותה.
יש באמת בעיתיות בזה שסיפריות הן יותר מידיי דינמיות ובכדי לקבל גרסה עם תיקוני באגים אתה צריך גם לשנות את הקוד שלך שמשתמש בספריה.
 
אולי יש סוגי פרוייקטים שבהם התועלת היא לא גדולה במיוחד מהסיפריה ואז אולי לא שווה להיכנס לזה. ברוב הפרוייקטים אני מניח שהספריות האלו יחסכו לך המון זמן ומאמץ ויעזרו לך להוציא מוצר טוב יותר.
 
אחת הבעיות עם הספריות האלו זה ה-pit falls ואלה דברים שאתה לא תמיד מודע אליהם בפרוייקט הראשון שאתה כותב עם ספריה מסויימת ואז יצא שהספריה הכניסה לך יותר בעיות ממה שהיא פתרה וזה יכול להיות מתסכל.
קישור לדוגמא: https://nathanleclaire.com/blog/2014/04/19/5-angularjs-antipatterns-and-pitfalls/
 
אין תחליף לנסיון בדברים האלו ואם אתה עובד לבד אז אתה לא רוצה להתגלח על הלקוח הראשון שתכניס לפרוייקט שלו את הספריה הזו. אפשר אולי במקרה כזה לעשות את הפרוייקט בשיתוף עם מישהו מנוסה בספריה או לעשות פרוייקט בהתנדבות לאיזו עמותה.
נכון עדיף כמה שיותר לא להשתמש בספריות
אפילו אם אפשר לפתח את מערכת ההפעלה עצמה עליה תרוץ האפליקציה שלך.
זה חוסך תלות בספריות\מערכות הפעלה שפיתחו אחרים :
- הספריות משתנות ללא הרף וצריך להתעדכן בשינוים שעלולים לגרור שינויים בישום שלך.
- אין לך שליטה מלאה על הקוד של הספריות ולא תמיד קל להבין "מה קורה בפנים" והאם הבג הוא שלך או של הקוד בספריה.
- ספריות לפעמים מוגבלות משפטית תחת רשיונות שונים ומשונים וכדי להפיץ את התוכנה שלך אתה צריך לשלם, אולי תמלוגים ( עוד כאב ראש להתעסק עם כל הסוגיות המשפטיות ...)
אבל לפעמים אין ברירה המאמץ בלפתח את הספריות הוא גדול מידי ונאלצים להעזר בספריות חיצוניות ( למשל מי שבונה UI בדסקטופ צריך ספריה גרפית כמו MFC או QT או אחר)
אפילו אם אפשר לפתח את מערכת ההפעלה עצמה עליה תרוץ האפליקציה שלך.
זה חוסך תלות בספריות\מערכות הפעלה שפיתחו אחרים :
- הספריות משתנות ללא הרף וצריך להתעדכן בשינוים שעלולים לגרור שינויים בישום שלך.
- אין לך שליטה מלאה על הקוד של הספריות ולא תמיד קל להבין "מה קורה בפנים" והאם הבג הוא שלך או של הקוד בספריה.
- ספריות לפעמים מוגבלות משפטית תחת רשיונות שונים ומשונים וכדי להפיץ את התוכנה שלך אתה צריך לשלם, אולי תמלוגים ( עוד כאב ראש להתעסק עם כל הסוגיות המשפטיות ...)
אבל לפעמים אין ברירה המאמץ בלפתח את הספריות הוא גדול מידי ונאלצים להעזר בספריות חיצוניות ( למשל מי שבונה UI בדסקטופ צריך ספריה גרפית כמו MFC או QT או אחר)
אכן שאלת השאלות
אני יכול להגיד שאני עובד כרגע בסטארטאפ שהמייסד נכווה מספריות קליינט בעבר (GWT, אני לא צריך להגיד יותר). אז הוא פיתח את כל המוצר בונילה אפילו jquery אין. יש כמה ספריות מינימליות כמו איזה משהו שמוסיף פונקציות רבות לObject וString ועוד איזה כלי לרינדור templates קטנים אבל באמת הUI הוא פשוט JS/CSS/HTML "נקי". אני אומר "נקי" במרכאות כי מה שקרה זה שהקוד הגיע למצב שהוא בלתי ניתן לתחזוקה. גרוע מכך, הם הסתמכו על איזה מתכנת שהוא מעצב גרפי במקצועו שלימד את עצמו תוך כדי עבודה, הקוד מובן רק לו, ואפילו אני עם כל שנות הנסיון שלי מצליח בקושי להכניס שינויים בלי לשבור מליון דברים.
גם הקוד עצמו הרבה הרבה יותר מדי וורבוסי ומנופח עם מימוש של דברים שמזמן כבר לא מממשים. היתרון היחיד זה שהוא עובד טוב (מהיר, יעיל, רזה ותומך בכל הדפדפנים מושלם) בין השאר כי המתכנת שכתב את הבלגן הוא פדנט והקפיד על הרבה כללים שהוא המציא לעצמו.
אני יכול להגיד שאני עובד כרגע בסטארטאפ שהמייסד נכווה מספריות קליינט בעבר (GWT, אני לא צריך להגיד יותר). אז הוא פיתח את כל המוצר בונילה אפילו jquery אין. יש כמה ספריות מינימליות כמו איזה משהו שמוסיף פונקציות רבות לObject וString ועוד איזה כלי לרינדור templates קטנים אבל באמת הUI הוא פשוט JS/CSS/HTML "נקי". אני אומר "נקי" במרכאות כי מה שקרה זה שהקוד הגיע למצב שהוא בלתי ניתן לתחזוקה. גרוע מכך, הם הסתמכו על איזה מתכנת שהוא מעצב גרפי במקצועו שלימד את עצמו תוך כדי עבודה, הקוד מובן רק לו, ואפילו אני עם כל שנות הנסיון שלי מצליח בקושי להכניס שינויים בלי לשבור מליון דברים.
גם הקוד עצמו הרבה הרבה יותר מדי וורבוסי ומנופח עם מימוש של דברים שמזמן כבר לא מממשים. היתרון היחיד זה שהוא עובד טוב (מהיר, יעיל, רזה ותומך בכל הדפדפנים מושלם) בין השאר כי המתכנת שכתב את הבלגן הוא פדנט והקפיד על הרבה כללים שהוא המציא לעצמו.
מאוד קשה לעשות זאת בצד הקליינט מכמה סיבות
1. בגלל הדינאמיות והמחסור בtypes ושום דבר לא restricted. אתה יכול לעשות refactoring כמה שאתה רוצה, השאלה איזה דברים יפסיקו לעבוד, כמה זמן יקח לגלות זאת ומה המחיר של זה.
2. בקליינט יש בעיה מובנית והיא ניהול state מה שברוב הסרברים שכתובים נכון אין כמעט. בשרת הstate יישמר בצורה מסודרת, או בDB (יכול להיות חיצוני, פנימי, כן SQL, לא SQL אפילו קובץ, זה לא משנה) או לפעמים במבנה סטטי בזכרון כשרוב המתכנתים ידאגו לסקלבליות, סנכרון ובאופן כללי סדר בקוד.
בקליינט לעומת זאת בסופו של דבר הסטייט הוא מאוד חשוב כי המשתמש עובד עם UI עשיר והפעולות שלו משפיעות על הסטייט ונשמרות. אופן השמירה בדרך כלל נעשה בסופו של דבר ע"י משתנים גלובליים. גם הפרימוורקים בסוף שומרים הכל באיזה משתנה בשם $ או משהו כזה. ואם לסבך עוד קצת, אז היום כבר עושים שימוש בפיצ'רים חדשים כמו הlocal storage, session storage ודברים כאלה.
נוצר מצב שבו מאוד קשה לשכתב דברים כשכל חלק בקוד מניח הנחות לגבי סטייט גלובלי שנשמר "איפשהו" ומתועד בעיקר בראש של המתכנת. אז אם אתה משתמש בFW, הטוטוריאלס די מכווינים אותך להשתמש בקונבנציות של הFW ואז זה אוכף מוסכמה מסויימת. בוונילה, אם יש לך מהנדס מצויין אתה יכול להגיע לקוד טוב אבל יש מעט מאוד מתכנתים שהם גם מהנדסים טובים וגם כותבים קליינט. התוצאה היא בדרך כלל קוד שכתב מישהו חצי חובבן וככה זה גם נראה.
ואפילו אם יש מישהו מעולה שכתב תשתית מסודרת, מתכנת חדש צריך ללמוד את המוסכמות והתשתית שזה יותר קשה כשזה פרי דמיונו של מתכנת אחד מאשר FW עם קהילה תומכת ומתעדת.
1. בגלל הדינאמיות והמחסור בtypes ושום דבר לא restricted. אתה יכול לעשות refactoring כמה שאתה רוצה, השאלה איזה דברים יפסיקו לעבוד, כמה זמן יקח לגלות זאת ומה המחיר של זה.
2. בקליינט יש בעיה מובנית והיא ניהול state מה שברוב הסרברים שכתובים נכון אין כמעט. בשרת הstate יישמר בצורה מסודרת, או בDB (יכול להיות חיצוני, פנימי, כן SQL, לא SQL אפילו קובץ, זה לא משנה) או לפעמים במבנה סטטי בזכרון כשרוב המתכנתים ידאגו לסקלבליות, סנכרון ובאופן כללי סדר בקוד.
בקליינט לעומת זאת בסופו של דבר הסטייט הוא מאוד חשוב כי המשתמש עובד עם UI עשיר והפעולות שלו משפיעות על הסטייט ונשמרות. אופן השמירה בדרך כלל נעשה בסופו של דבר ע"י משתנים גלובליים. גם הפרימוורקים בסוף שומרים הכל באיזה משתנה בשם $ או משהו כזה. ואם לסבך עוד קצת, אז היום כבר עושים שימוש בפיצ'רים חדשים כמו הlocal storage, session storage ודברים כאלה.
נוצר מצב שבו מאוד קשה לשכתב דברים כשכל חלק בקוד מניח הנחות לגבי סטייט גלובלי שנשמר "איפשהו" ומתועד בעיקר בראש של המתכנת. אז אם אתה משתמש בFW, הטוטוריאלס די מכווינים אותך להשתמש בקונבנציות של הFW ואז זה אוכף מוסכמה מסויימת. בוונילה, אם יש לך מהנדס מצויין אתה יכול להגיע לקוד טוב אבל יש מעט מאוד מתכנתים שהם גם מהנדסים טובים וגם כותבים קליינט. התוצאה היא בדרך כלל קוד שכתב מישהו חצי חובבן וככה זה גם נראה.
ואפילו אם יש מישהו מעולה שכתב תשתית מסודרת, מתכנת חדש צריך ללמוד את המוסכמות והתשתית שזה יותר קשה כשזה פרי דמיונו של מתכנת אחד מאשר FW עם קהילה תומכת ומתעדת.
Copyright©1996-2021,Tapuz Media Ltd. Forum software by XenForo® © 2010-2020 XenForo Ltd.