נושא לדיון - טיב מוצר

[bnayal]

נושא לדיון - טיב מוצר

נושא שאני חושב עליו בימים האחרונים בגלל מקרה שנתקלתי בו,

בן אדם השקיע את מיטב כספו על מנת להקים אתר אינטרנט \ אפליקצייה כלשהי.
אין לו ידע טכני.
הוא פנה לחברת פיתוח שתפתח לו את המוצר שהוא צריך על פי איפיון. נניח שהכל עובד כמו שהוא מצפה אבל הוא מגלה שברמה הטכנית (ע"י מישהו צד ג' שכן מבין קצת, נניח אני) הקוד כתוב גרוע, לא מאובטח (פתוח לגמרי ל SQL Injection, שימוש במערך $_REQUEST, בקיצור קוד ברמה של כיתה ג').

איך צריך לדעתכם לנהוג במקרה כזה? יותר מבחינת הלקוח. איך הוא צריך לנהוג מול חברת הפיתוח?

פשוט מרתיח אותי רמת החאפריות שאני רואה.

בניה

 

[zeshe shoel]

שאלת השאלות...

בדר"כ כלל אני מתאר לעצמי שזה קורה אצל ה"זולים"...

לא זוכר מי אמר כאן פעם.

"מי שמשלם בבוטנים מקבל קופים".

 

[bnayal]

מסכים ב100%, לצערי זה לא המקרה.

מה שמעניין אותי להבין ולבדוק זה מה ההתחייבות \ חובות מבחינת איכות הקוד ורמת האבטחה של המוצר.

 

[zeshe shoel]

הכל תלוי בחוזה...

האם יש סעיף שאומר קוד קריא \ הערות \ פיתוח המערכת ב OOP \ אתר מאובטח וכו'...?

גם אז אפשר לדון בשאלה מהוא קוד קריא או מהו אתר מאובטח (הרי אין אתר שמאובטח 100%).

לנו יש לקוחות למשל שדרשו CSS SPRITES ועוד כל מיני דרישות בפיתוח מאחר והם לקחו יועץ חיצוני. הם דרשו זאת מראש...

 

[bnayal]

בקיצור בפרוייקט רציני חובה יועץ צד ג'

במיוחד כשהלקוח לא מבין כלום בטכנולוגיה.

 

[zeshe shoel]

מממ...

לנו יש לקוח שיש להם מחלקת IT אז הם מבינים קצת אינטרנט והיו להם גם דרישות.

בכל מקרה, הכי חשוב זה המלצות על החברה שאתה מעוניין שתפתח לך את המערכת.

 

[bennysg]

צד ג ? אין לזה סוף תמיד יש דגים גדולים יותר

אני בטוח שהמתכנת הראשון סבר שעשה טובה, הוא עשה מה שהוא יודע אין לו שום אינטרס לרמות. בא מתכנת מנוסה יותר ורואה קוד לא בנוי טוב, ואומר אני אעשה יותר טוב, ואח"כ צד ג מנוסה יותר ואומר מתכנת ב עשה עבודה לא מספיק טובה שלי יותר טובה, וכן הלאה,

 

[ברבוריאן]

 

[ברבוריאן]

מעבר לחוזה, יש תכלס - שימושיות

טכנולוגיה נשפטת בהתאם לשימושיות שלה. בידי אחד היא חיובית ובידי אחר היא שלילית. הבנה של הרעיון הזה, עוזרת לשווק משהו שהוא לא מושלם. כך נוצרה שרשרת מזון למוצרים, שבלעדיה לא היתה מתפתחת תעשיה שלמה ורווחית. (תחשוב על הדינמטיקה עם וירוסים והדרעק הזה....).
לקוח שמזמין אתר/אפליקציה, מבקש בעצם למכן פעילות אנושית. הוא משלם בתמורה לזה שזה עובד כמו שהוא רוצה. למשל: מישהו קונה ממנו משהו, משלם, הכסף מגיע אליו, והמוצר מגיע ללקוח - כולם מרוצים. לסנריו הזה יכולים להיות כל מיני וריאציות שנועדו לבדוק תקינותו במצבים שונים - זה QA. כאן המקום לציין ש-QA לא מקבל את היחס הראוי. אבל נגיד שכולם עובדים היטב, והאתר/אפליקציה מאובטחים מקסימום, והעסק בקושי זז. אז יש מצב שפונקציונלית המוצר עושה מה שהוא צריך ומאובטח כראוי, אבל מצד שני השימושיות שלו נמוכה מאוד ופורמת את הסבלנות של הגולשים והם פשוט עוברים הלאה...
אז על מה שילם בעלי האתר/אפליקציה ? האם על מוצר שייעל ויגדיל את ההכנסות שלו או על מוצר שהוא קליל השלמות הטכנית אבל דפוק בשימושיות שלו ?
לכן נכנס כאן אלמנט נוסף בעסקים - בתי משפט (חלק משרשרת המזון). אם האתר/אפליקציה חשופים לפשעים ומישהו מנצל את זה, כולם יכולים לבוא בטענות זה לזה - בבית משפט. לבנתיים, העסק ממשיך לתפקד

אם זוכרים שאין 100% אבטחה (גם בלי קשר למחשבים) מבינים את שרשרת המזון, ולומדים לסמוך (להלן" תרבות הסמוך), אז הכל ידוע מראש....
בימינו יש עבריינות רשת בלי קשר לאיכות המוצר, ויש האקרים שלוקחים דמי חסות מחברות בתמורה לאי הפצה של חומר מסווג שלא הם בהכרח פרצו וגנבו...
אז נחזור להתחלה: יש טכנולוגיה (אקדח) האם בידיי המתכנת (שוטר) היא טובה אבל בידי האקר (מהסוג הפושע) היא רעה ? לדעתי לא, כי גם דמיי חסות זה חלק משרשרת המזון, מטבע הדברים

 

[gilad1987]

מה הבעיה להשתמש במערך $_request ??

אני דיי חדש בנושא אשמח לשמוע מה הבעיה?
אני יודע שצריך לעשות הבטחה בשאילתות ושמוצאים פלט לאתר אבל למה לא מאובטח להשתמש במערך הזה ומה האופציה הנוספת?

תודה מראש

 

[ברבוריאן]

הבעיה שלו שהוא יותר מידי פרטני....

request_$ למעשה הוא קיבוץ של נתוני הקלט מהמשתמש. לכן הוא מכיל עם את נתוני post/get אבל גם את נתוני העוגיות וזאת הצרה הגדולה. כמובן שכמתכנת תותח אתה לא מעלה בדמיון שתתיחס לנתונים מהמתודות השונות בצורה זהה. האסון הוא שלפי סדר המשתנים של PHP העוגיה תדרוס כל נותן זהה אחר. כלומר אם יש לך נתון post/get שקבלת מהמשתמש אבל מישהו עשה ככה שהעוגיה תכיל אותו נתון עם ערך אחר (ועוד כל מיני וריאציות מרושעות) המינימום שיקרה הוא שהטופס יתקע והמקסימום זה סבוטז' כללי באתר

ולכן ! request_$ נחשבת ללא אמינה ופדיחה לא מוסברת...

 

[gilad1987]

אז במה משתמשים? אך אתה מקבל נתונים מהיוזר?

צריף פשוט לבדוק את הנתונים לא?
הבתי את הבעיה מה הפתרון
בתור אנשים מנוסיפם אני בטוח שיש לכם ...

תודה

 

[CaTz]

פשוט להשתמש במערכים שמהם אתה מצפה לקבל את

הנתונים, ז"א אתה מצפה נתונים מטופס שנשלחים בPOST,
אז אתה עובד מול $_POST וכו'...
ברור שעדיין צריך לוודא נכונות של הנתונים אבל זה הרעיון של לא להשתמש עם REQUEST...

 

[gilad1987]

אה...הבנתי באמת ככה אני עושה בד"כ.

תודה בכל אופן כי באמת לא ידעתי שזה שומר גם נתונים של הססשן

 

[CaTz]

לצערי נתקלתי לא פעם ולא פעמיים

"בלסיים פרוייקט" כפי שמתואר בפי הלקוח
ובסופו של דבר כשאני רואה את הקוד, אני לא מוכן לעבוד עליו....אלא לשכתב מאפס.

אני חושב שכמו שאנשים שהולכים לקנות רכב, לוקחים איתם מישהו "שמבין"
(לפחות את הדברים הבסיסיים) ככה לקוח שאין לו שמץ צריך להשתמש בצד ג' כמו שתיארת את זה...
אין מה לעשות, העולם מלא בחלאות, שמנסים רק לקמבן עליך.

 

[bnayal]

 

[intval]

כדי לא ליפול פעמיים:

כמו שנאמר, באמת תלוי בחוזה.
עם הפיתוח הנוכחי אין ללקוח הרבה מה לעשות חוץ מלשלם עוד פעם לצד ג'. ורוב הסיכויים שצד ג' יראה את הקוד ויחליט שיהיה יותר זול ומהר לפתח מחדש.

מה שאני ממליץ ללקוחות לעשות במקרים עתידיים הוא להוסיף לחוזה סעיף דרישה פשוט בסגנון
"המפתח מתחייב ללא פחות מ 50% test coverage"
אחרי המשפט הקסום הזה כל ה"קופים" מתאדים.

 

[bnayal]

לא הבנתי מה משמעות המשפט הזה?

שמחוייבים בבדיקות כלשהן?

 

[amitayh]

שה - Unit Tests יכסו לפחות 50% מהקוד

רעיון יפה, למרות שלא יודע אם תצליח למצוא מישהו ככה

 

[ברבוריאן]

ואיך הלקוח יוודא ביצוע ? אם לא ישלם עוד לצד ג

בכל מקרה...
נראה לי מוזר שאתם מכחישים את זכות הקיום של רמות שונות. אבל זה אולי יותר באספקט הפילוסופי כמו דברי הקודמים.
מה שכן, הכי מעצבן, הוא הלקוח שמבין קצת.... וחופר וחופר וחופר

אז אם המבצע רגיש הוא בהחלט יכול להרגיש אפס אחרי חוויה כזאת חחחח מסקנה: כדאי שכל אחד יאמין שהוא הכי טוב שיש בהתאם לנסיבות (במסתכמות בעומק הכיס)