70% מהפרויקטים עם כיסוי בדיקות גבוה (80%+) חווים רגרסיות בלוגיקה העסקית — זו הסטטיסטיקה מהביקורות שלנו. הסיבה: הבדיקות מכסות את ה-UI ואת ה-getters, ולא את ה-Use Cases וה-ViewModels. תרחיש טיפוסי: אתה מוסיף תכונה חדשה, ה-CI ירוק, אבל אחרי המיזוג, פונקציונליות עובדת נשברת. ביקורת קוד של אפליקציית מובייל מוצאת "נקודות עיוורות" כאלה ומראה היכן באמת נדרשות בדיקות. הניסיון שלנו מאבחן בעיות שנשארות חבויות ב-60% מהפרויקטים עד התקרית הראשונה. אנו מבטיחים שהדוח יכיל המלצות מעשיות, לא משפטים כלליים.
כיצד ביקורת קוד מונעת רגרסיות?
בדיקת קוד בודקת PR בודד: סגנון, לוגיקה, באגים. ביקורת עונה על השאלה: "האם אנחנו יכולים לחיות עם הקוד הזה לשנתיים-שלוש הקרובות, להוסיף תכונות ללא רגרסיות קבועות, לקלוט מפתחים חדשים בזמן סביר?" זהו ניתוח של חוב טכני מערכתי, לא בעיות נקודתיות. תלות מחזורית בין מודולים מתרחשת ב-40% מהפרויקטים, מפתחות API מקודדים ב-30%. ללא ביקורת, המספרים האלה נשארים חבויים עד התקרית הראשונה. לפי מדריך הבדיקות לאבטחת מובייל של OWASP, פגיעויות כאלה מסווגות כסיכון גבוה.
מה בדיוק אנחנו בודקים?
קוהרנטיות ארכיטקטונית. אנו בוחנים את גרף התלות: האם יש תלות מחזורית בין מודולים, האם גבולות השכבות מופרים, האם ה-UI תלוי ישירות בספריות רשת ספציפיות? ל-iOS — אנו בודקים הפרדה למודולי תכונה או לפחות הקפדה על MVVM/VIPER בתוך יעד יחיד. ל-Android — Clean Architecture עם Use Cases, או שהכל מושלך לתוך Activity. כלים: Xcode Dependency Graph, Android Studio Module Dependencies, ArchUnit לבדיקה אוטומטית.
כיסוי בדיקות. אנו מסתכלים לא רק על האחוז אלא גם על מה שמכוסה. כיסוי של 80% על getters טריוויאליים ו-10% על לוגיקה עסקית גרוע יותר מ-30% של בדיקות נכונות על Use Cases ו-ViewModels. אנו בודקים בדיקות אינטגרציה (UI, XCUITest, Espresso), מוקים לתלות רשת, בדיקות למקרי קצה (רשימה ריקה, שגיאת רשת, timeout). ב-70% מהפרויקטים, כיסוי הבדיקות של הלוגיקה העסקית אינו עולה על 20%, מה שמוביל לרגרסיות. ניתוח אוטומטי מקצר את זמן הביקורת פי 3-5 בהשוואה לביקורת ידנית.
ניהול תלות. CocoaPods מול SPM, קטלוגים של Gradle, גרסאות מיושנות. ספריות עם CVE ידוע — אנו בודקים דרך OWASP Dependency-Check או תמונת מצב מ-pod outdated / ./gradlew dependencyUpdates. אנו שמים דגש מיוחד על ספריות המבקשות הרשאות מופרזות (Analytics SDK, Ad SDK) — הן עלולות להפר את מדיניות הפרטיות של App Store/Play Store.
ביצועים ודליפות זיכרון. ניתוח סטטי אינו מחליף פרופיילר, אבל ב-90% מהמקרים הוא מוצא דפוסים: משימות סינכרוניות על ה-thread הראשי, image שנוצרו ללא caching בלולאה, URLSession שנוצרו לכל בקשה במקום singleton. ל-Flutter — קונסטרוקטורים של const שאינם בשימוש במקומות שבהם הם נדרשים, חישובים יקרים ב-build(). תדירות ממוצעת של דליפות זיכרון בפרויקטים גדולים היא 3-5 לכל 1000 שורות קוד.
אבטחה. ניתוח אוטומטי דרך MobSF (Mobile Security Framework) או Semgrep עם כללי מובייל. אנו מחפשים: מפתחות API מקודדים בקוד או ב-plist, לוגים של נתונים רגישים, IPC לא מאובטח (Activities מיוצאות ללא הרשאה), שימוש באלגוריתמים מיושנים (MD5, SHA1 לפעולות קריטיות). אנו בודקים גם הגדרות Code Signing, פרופילי provisioning, הגדרות Push Notifications (APNs/FCM), deep linking (Universal Links / App Links), ו-ATT (App Tracking Transparency). לפי הנחיות הביקורת של App Store, יש לטפל בנתוני משתמש בזהירות — אישורים מקודדים הם הפרה ישירה.
באילו כלים אנו משתמשים?
| משימה | iOS | Android |
|---|---|---|
| ניתוח סטטי | SwiftLint, Periphery (קוד לא בשימוש) | Detekt, Android Lint |
| תלות/CVE | pod audit + OWASP Dependency-Check |
OWASP Dependency-Check |
| מורכבות קוד | SonarQube | SonarQube |
| אבטחה | MobSF | MobSF |
| דליפות זיכרון | Instruments (Leaks) | LeakCanary |
SonarQube משתלב ב-CI ומחשב מורכבות ציקלומטית, כפילות קוד, מורכבות קוגניטיבית. פונקציה עם מורכבות > 15 היא מועמדת ל-refactoring — זה לא עניין של טעם, אלא סיכון מדיד.
| בעיה | תדירות בפרויקטים |
|---|---|
| תלות מחזורית בין מודולים | 40% |
| כיסוי בדיקות של לוגיקה עסקית < 20% | 70% |
| ספריות מיושנות עם CVE | 5-8 בממוצע לפרויקט |
| דליפות זיכרון | 60% |
| מפתחות API מקודדים | 30% |
מדוע כלים אוטומטיים אינם מחליפים ניתוח ידני?
למרות שכלים כמו Periphery מוצאים קוד לא בשימוש ו-MobSF מזהה פגיעויות, רק ביקורת ארכיטקטונית ידנית יכולה להעריך כיצד חוב טכני ישפיע על פיתוח עתידי. בפרויקט אחד, גילינו תלות מחזורית שהגדילה את זמן הבנייה ב-40% — האנליזטור הסטטי לא הראה אותה כי התלות הייתה דרך reflection. הניסיון שלנו מונע מצבים כאלה.
כיצד אנו מבצעים ביקורת?
- איסוף מדדים — ניתוח סטטי של כל הקוד, גרף תלות, כיסוי בדיקות.
- סקירת ארכיטקטורה מעמיקה — זיהוי תלות מחזורית, הפרות של Clean Architecture.
- בדיקת אבטחה ידנית — סקירת תצורות, manifests, plists.
- פרופיילינג ביצועים — חיפוש דליפות וצווארי בקבוק.
- יצירת דוח — מפת דרכים עם הערכת סיכונים וסדרי עדיפויות.
שימוש בכלים אוטומטיים מקצר את זמן הניתוח פי 3-5 בהשוואה לביקורת ידנית. Periphery ל-iOS מוצא פונקציות, מחלקות ופרוטוקולים שאינם בשימוש. בקוד גדול מצטברים אלפי שורות של קוד מת — שנקראות, מתוחזקות, ומפחדים למחוק אותן.
מה אתה מקבל כתוצאה?
- דוח עם ארבע רמות: קריטי (תיקון מיידי — דליפת נתונים, קריסה), גבוה (הספרינט הבא — סיכון ארכיטקטוני, בעיית אבטחה), בינוני (חוב טכני, תכנון), נמוך (המלצות איכות).
- מפת דרכים ל-refactoring עם הערכת סיכונים וסדרי עדיפויות — מה לשפץ קודם, מה ניתן לדחות.
- תיעוד של הבעיות שנמצאו והמלצות לפתרון.
- רשימת תלות מיושנת עם CVE וגרסאות העברה.
- המלצות לשיפור CI/CD לאוטומציה של בקרת איכות.
צור קשר להערכת פרויקט. קבל ייעוץ על הביקורת — אנו נעריך לוחות זמנים והיקף באופן אישי. ביקורת ללא תוכנית פעולה היא מסמך חסר משמעות, ולכן אנו תמיד נותנים המלצות מעשיות.
לוחות זמנים — מ-3 עד 5 ימים לפרויקט בינוני (עד 200 אלף שורות). פרויקטים גדולים (300 אלף+ שורות, פלטפורמות מרובות) — עד שבועיים. העלות המדויקת מחושבת לאחר סקירת הפרויקט. חיסכון בתקציב על refactoring עם ההמלצות שלנו יכול להגיע ל-40% הודות לתעדוף בעיות קריטיות.