ದೋಷಗಳನ್ನು ಹುಡುಕಲು ಬಳಸುವ ಬದಲು ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ಸ್ಥಿರ ವಿಶ್ಲೇಷಣೆಯನ್ನು ಅಳವಡಿಸಿ

ನನ್ನ ಗಮನಕ್ಕೆ ಬರುತ್ತಿರುವ ಸ್ಥಾಯೀ ವಿಶ್ಲೇಷಣೆಯ ಹೆಚ್ಚಿನ ಪ್ರಮಾಣದ ವಸ್ತುಗಳಿಂದ ಈ ಲೇಖನವನ್ನು ಬರೆಯಲು ನಾನು ಪ್ರೇರೇಪಿಸಿದ್ದೇನೆ. ಮೊದಲನೆಯದಾಗಿ, ಇದು PVS-ಸ್ಟುಡಿಯೋ ಬ್ಲಾಗ್, ಓಪನ್ ಸೋರ್ಸ್ ಪ್ರಾಜೆಕ್ಟ್‌ಗಳಲ್ಲಿ ತಮ್ಮ ಉಪಕರಣದಿಂದ ಕಂಡುಬರುವ ದೋಷಗಳ ವಿಮರ್ಶೆಗಳ ಸಹಾಯದಿಂದ ಹ್ಯಾಬ್ರೆಯಲ್ಲಿ ಸಕ್ರಿಯವಾಗಿ ಪ್ರಚಾರ ಮಾಡುತ್ತದೆ. ಇತ್ತೀಚೆಗೆ PVS-ಸ್ಟುಡಿಯೋ ಅಳವಡಿಸಲಾಗಿದೆ ಜಾವಾ ಬೆಂಬಲ, ಮತ್ತು, ಸಹಜವಾಗಿ, IntelliJ IDEA ಯ ಡೆವಲಪರ್‌ಗಳು, ಅವರ ಅಂತರ್ನಿರ್ಮಿತ ವಿಶ್ಲೇಷಕವು ಬಹುಶಃ ಇಂದು ಜಾವಾಗೆ ಹೆಚ್ಚು ಮುಂದುವರಿದಿದೆ, ದೂರ ಉಳಿಯಲು ಸಾಧ್ಯವಾಗಲಿಲ್ಲ.

ಅಂತಹ ವಿಮರ್ಶೆಗಳನ್ನು ಓದುವಾಗ, ನಾವು ಮ್ಯಾಜಿಕ್ ಎಲಿಕ್ಸಿರ್ ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತಿದ್ದೇವೆ ಎಂಬ ಭಾವನೆಯನ್ನು ನೀವು ಪಡೆಯುತ್ತೀರಿ: ಗುಂಡಿಯನ್ನು ಒತ್ತಿ, ಮತ್ತು ಇಲ್ಲಿದೆ - ನಿಮ್ಮ ಕಣ್ಣುಗಳ ಮುಂದೆ ದೋಷಗಳ ಪಟ್ಟಿ. ವಿಶ್ಲೇಷಕರು ಸುಧಾರಿಸಿದಂತೆ, ಹೆಚ್ಚು ಹೆಚ್ಚು ದೋಷಗಳು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಕಂಡುಬರುತ್ತವೆ ಮತ್ತು ಈ ರೋಬೋಟ್‌ಗಳಿಂದ ಸ್ಕ್ಯಾನ್ ಮಾಡಿದ ಉತ್ಪನ್ನಗಳು ನಮ್ಮ ಕಡೆಯಿಂದ ಯಾವುದೇ ಪ್ರಯತ್ನವಿಲ್ಲದೆ ಉತ್ತಮ ಮತ್ತು ಉತ್ತಮವಾಗುತ್ತವೆ ಎಂದು ತೋರುತ್ತದೆ.

ಆದರೆ ಯಾವುದೇ ಮಾಂತ್ರಿಕ ಅಮೃತಗಳಿಲ್ಲ. "ನಮ್ಮ ರೋಬೋಟ್ ಕಂಡುಹಿಡಿಯಬಹುದಾದ ವಿಷಯಗಳು ಇಲ್ಲಿವೆ" ಎಂಬ ಪೋಸ್ಟ್‌ಗಳಲ್ಲಿ ಸಾಮಾನ್ಯವಾಗಿ ಮಾತನಾಡದಿರುವ ಬಗ್ಗೆ ನಾನು ಮಾತನಾಡಲು ಬಯಸುತ್ತೇನೆ: ವಿಶ್ಲೇಷಕರು ಏನು ಮಾಡಲಾಗುವುದಿಲ್ಲ, ಸಾಫ್ಟ್‌ವೇರ್ ವಿತರಣಾ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ಅವರ ನಿಜವಾದ ಪಾತ್ರ ಮತ್ತು ಸ್ಥಾನ ಏನು ಮತ್ತು ಅವುಗಳನ್ನು ಸರಿಯಾಗಿ ಕಾರ್ಯಗತಗೊಳಿಸುವುದು ಹೇಗೆ .

ರಾಟ್ಚೆಟ್ (ಮೂಲ: ವಿಕಿಪೀಡಿಯಾ).

ಸ್ಥಿರ ವಿಶ್ಲೇಷಕರು ಏನು ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ

ಪ್ರಾಯೋಗಿಕ ದೃಷ್ಟಿಕೋನದಿಂದ ಮೂಲ ಕೋಡ್ ವಿಶ್ಲೇಷಣೆ ಎಂದರೇನು? ನಾವು ಕೆಲವು ಮೂಲ ಕೋಡ್ ಅನ್ನು ಇನ್‌ಪುಟ್‌ನಂತೆ ಒದಗಿಸುತ್ತೇವೆ ಮತ್ತು ಔಟ್‌ಪುಟ್‌ನಂತೆ, ಕಡಿಮೆ ಸಮಯದಲ್ಲಿ (ಚಾಲನೆಯಲ್ಲಿರುವ ಪರೀಕ್ಷೆಗಳಿಗಿಂತ ಕಡಿಮೆ) ನಾವು ನಮ್ಮ ಸಿಸ್ಟಂ ಕುರಿತು ಕೆಲವು ಮಾಹಿತಿಯನ್ನು ಪಡೆಯುತ್ತೇವೆ. ಮೂಲಭೂತ ಮತ್ತು ಗಣಿತದ ದುಸ್ತರ ಮಿತಿಯೆಂದರೆ ನಾವು ಈ ರೀತಿಯಲ್ಲಿ ಸಾಕಷ್ಟು ಕಿರಿದಾದ ವರ್ಗದ ಮಾಹಿತಿಯನ್ನು ಮಾತ್ರ ಪಡೆಯಬಹುದು.

ಸ್ಥಿರ ವಿಶ್ಲೇಷಣೆಯನ್ನು ಬಳಸಿಕೊಂಡು ಪರಿಹರಿಸಲಾಗದ ಸಮಸ್ಯೆಯ ಅತ್ಯಂತ ಪ್ರಸಿದ್ಧ ಉದಾಹರಣೆಯಾಗಿದೆ ಸ್ಥಗಿತಗೊಳಿಸುವ ಸಮಸ್ಯೆ: ಇದು ಒಂದು ಸಾಮಾನ್ಯ ಅಲ್ಗಾರಿದಮ್ ಅನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುವುದು ಅಸಾಧ್ಯವೆಂದು ಸಾಬೀತುಪಡಿಸುವ ಪ್ರಮೇಯವಾಗಿದ್ದು, ಪ್ರೋಗ್ರಾಂನ ಮೂಲ ಕೋಡ್‌ನಿಂದ ಅದು ಸೀಮಿತ ಸಮಯದಲ್ಲಿ ಲೂಪ್ ಆಗುತ್ತದೆಯೇ ಅಥವಾ ಕೊನೆಗೊಳ್ಳುತ್ತದೆಯೇ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸಬಹುದು. ಈ ಪ್ರಮೇಯದ ವಿಸ್ತರಣೆಯಾಗಿದೆ ರೈಸ್ ಪ್ರಮೇಯ, ಕಂಪ್ಯೂಟಬಲ್ ಫಂಕ್ಷನ್‌ಗಳ ಯಾವುದೇ ಕ್ಷುಲ್ಲಕವಲ್ಲದ ಆಸ್ತಿಗಾಗಿ, ಅನಿಯಂತ್ರಿತ ಪ್ರೋಗ್ರಾಂ ಅಂತಹ ಆಸ್ತಿಯೊಂದಿಗೆ ಕಾರ್ಯವನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡುತ್ತದೆಯೇ ಎಂದು ನಿರ್ಧರಿಸುವುದು ಅಲ್ಗಾರಿದಮಿಕ್ ಆಗಿ ಪರಿಹರಿಸಲಾಗದ ಸಮಸ್ಯೆಯಾಗಿದೆ ಎಂದು ಹೇಳುತ್ತದೆ. ಉದಾಹರಣೆಗೆ, ಯಾವುದೇ ಮೂಲ ಕೋಡ್‌ನಿಂದ ವಿಶ್ಲೇಷಿಸಲ್ಪಡುವ ಪ್ರೋಗ್ರಾಂ ಒಂದು ಪೂರ್ಣಾಂಕದ ವರ್ಗವನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡುವ ಅಲ್ಗಾರಿದಮ್‌ನ ಅಳವಡಿಕೆಯಾಗಿದೆಯೇ ಎಂದು ನಿರ್ಧರಿಸಬಹುದಾದ ವಿಶ್ಲೇಷಕವನ್ನು ಬರೆಯುವುದು ಅಸಾಧ್ಯ.

ಹೀಗಾಗಿ, ಸ್ಥಿರ ವಿಶ್ಲೇಷಕಗಳ ಕಾರ್ಯವು ದುಸ್ತರ ಮಿತಿಗಳನ್ನು ಹೊಂದಿದೆ. ಸ್ಥಾಯೀ ವಿಶ್ಲೇಷಕವು ಎಲ್ಲಾ ಸಂದರ್ಭಗಳಲ್ಲಿ ಪತ್ತೆಹಚ್ಚಲು ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ, ಉದಾಹರಣೆಗೆ, ಶೂನ್ಯದ ಮೌಲ್ಯವನ್ನು ಅನುಮತಿಸುವ ಭಾಷೆಗಳಲ್ಲಿ "ಶೂನ್ಯ ಪಾಯಿಂಟರ್ ವಿನಾಯಿತಿ" ಸಂಭವಿಸುವುದು ಅಥವಾ ಎಲ್ಲಾ ಸಂದರ್ಭಗಳಲ್ಲಿ "" ಸಂಭವಿಸುವಿಕೆಯನ್ನು ನಿರ್ಧರಿಸಲು ಕ್ರಿಯಾತ್ಮಕವಾಗಿ ಟೈಪ್ ಮಾಡಿದ ಭಾಷೆಗಳಲ್ಲಿ ಗುಣಲಕ್ಷಣ ಕಂಡುಬಂದಿಲ್ಲ. ಅತ್ಯಾಧುನಿಕ ಸ್ಥಾಯೀ ವಿಶ್ಲೇಷಕವು ಮಾಡಬಹುದಾದ ಎಲ್ಲಾ ವಿಶೇಷ ಪ್ರಕರಣಗಳನ್ನು ಹೈಲೈಟ್ ಮಾಡುವುದು, ನಿಮ್ಮ ಮೂಲ ಕೋಡ್‌ನೊಂದಿಗಿನ ಎಲ್ಲಾ ಸಂಭವನೀಯ ಸಮಸ್ಯೆಗಳ ನಡುವೆ, ಉತ್ಪ್ರೇಕ್ಷೆಯಿಲ್ಲದೆ, ಸಾಗರದಲ್ಲಿನ ಕುಸಿತವಾಗಿದೆ.

ಸ್ಥಾಯೀ ವಿಶ್ಲೇಷಣೆಯು ದೋಷಗಳನ್ನು ಕಂಡುಹಿಡಿಯುವ ಬಗ್ಗೆ ಅಲ್ಲ

ಮೇಲಿನಿಂದ, ತೀರ್ಮಾನವು ಅನುಸರಿಸುತ್ತದೆ: ಸ್ಥಾಯೀ ವಿಶ್ಲೇಷಣೆಯು ಪ್ರೋಗ್ರಾಂನಲ್ಲಿನ ದೋಷಗಳ ಸಂಖ್ಯೆಯನ್ನು ಕಡಿಮೆ ಮಾಡುವ ಸಾಧನವಲ್ಲ. ನಾನು ಹೇಳಲು ಸಾಹಸ ಮಾಡುತ್ತೇನೆ: ನಿಮ್ಮ ಪ್ರಾಜೆಕ್ಟ್‌ಗೆ ಮೊದಲ ಬಾರಿಗೆ ಅನ್ವಯಿಸಿದಾಗ, ಅದು ಕೋಡ್‌ನಲ್ಲಿ "ಆಸಕ್ತಿದಾಯಕ" ಸ್ಥಳಗಳನ್ನು ಕಂಡುಕೊಳ್ಳುತ್ತದೆ, ಆದರೆ, ಹೆಚ್ಚಾಗಿ, ಇದು ನಿಮ್ಮ ಪ್ರೋಗ್ರಾಂನ ಗುಣಮಟ್ಟದ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುವ ಯಾವುದೇ ದೋಷಗಳನ್ನು ಕಂಡುಹಿಡಿಯುವುದಿಲ್ಲ.

ವಿಶ್ಲೇಷಕರಿಂದ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಕಂಡುಬರುವ ದೋಷಗಳ ಉದಾಹರಣೆಗಳು ಆಕರ್ಷಕವಾಗಿವೆ, ಆದರೆ ದೊಡ್ಡ ಕೋಡ್‌ಬೇಸ್‌ಗಳ ದೊಡ್ಡ ಗುಂಪನ್ನು ಸ್ಕ್ಯಾನ್ ಮಾಡುವ ಮೂಲಕ ಈ ಉದಾಹರಣೆಗಳು ಕಂಡುಬಂದಿವೆ ಎಂಬುದನ್ನು ನಾವು ಮರೆಯಬಾರದು. ಅದೇ ತತ್ವದಿಂದ, ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ಖಾತೆಗಳಲ್ಲಿ ಹಲವಾರು ಸರಳ ಪಾಸ್‌ವರ್ಡ್‌ಗಳನ್ನು ಪ್ರಯತ್ನಿಸಲು ಅವಕಾಶವನ್ನು ಹೊಂದಿರುವ ಹ್ಯಾಕರ್‌ಗಳು ಅಂತಿಮವಾಗಿ ಸರಳ ಪಾಸ್‌ವರ್ಡ್ ಹೊಂದಿರುವ ಖಾತೆಗಳನ್ನು ಕಂಡುಕೊಳ್ಳುತ್ತಾರೆ.

ಸ್ಥಿರ ವಿಶ್ಲೇಷಣೆಯನ್ನು ಬಳಸಬಾರದು ಎಂದು ಇದರ ಅರ್ಥವೇ? ಖಂಡಿತ ಇಲ್ಲ! ಮತ್ತು "ಸರಳ" ಪಾಸ್‌ವರ್ಡ್‌ಗಳ ಸ್ಟಾಪ್ ಪಟ್ಟಿಯಲ್ಲಿ ಅದನ್ನು ಸೇರಿಸಲಾಗಿದೆಯೇ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ಪ್ರತಿ ಹೊಸ ಪಾಸ್‌ವರ್ಡ್ ಅನ್ನು ಪರಿಶೀಲಿಸುವುದು ಯೋಗ್ಯವಾಗಿದೆ ಎಂಬ ಒಂದೇ ಕಾರಣಕ್ಕಾಗಿ.

ಸ್ಥಾಯೀ ವಿಶ್ಲೇಷಣೆಯು ದೋಷಗಳನ್ನು ಕಂಡುಹಿಡಿಯುವುದಕ್ಕಿಂತ ಹೆಚ್ಚು

ವಾಸ್ತವವಾಗಿ, ವಿಶ್ಲೇಷಣೆಯಿಂದ ಪ್ರಾಯೋಗಿಕವಾಗಿ ಪರಿಹರಿಸಲಾದ ಸಮಸ್ಯೆಗಳು ಹೆಚ್ಚು ವಿಶಾಲವಾಗಿವೆ. ಎಲ್ಲಾ ನಂತರ, ಸಾಮಾನ್ಯವಾಗಿ, ಸ್ಥಾಯೀ ವಿಶ್ಲೇಷಣೆಯು ಮೂಲ ಕೋಡ್‌ಗಳನ್ನು ಪ್ರಾರಂಭಿಸುವ ಮೊದಲು ನಡೆಸುವ ಯಾವುದೇ ಪರಿಶೀಲನೆಯಾಗಿದೆ. ನೀವು ಮಾಡಬಹುದಾದ ಕೆಲವು ವಿಷಯಗಳು ಇಲ್ಲಿವೆ:

• ಪದದ ವಿಶಾಲ ಅರ್ಥದಲ್ಲಿ ಕೋಡಿಂಗ್ ಶೈಲಿಯನ್ನು ಪರಿಶೀಲಿಸಲಾಗುತ್ತಿದೆ. ಇದು ಫಾರ್ಮ್ಯಾಟಿಂಗ್ ಅನ್ನು ಪರಿಶೀಲಿಸುವುದು, ಖಾಲಿ/ಹೆಚ್ಚುವರಿ ಆವರಣಗಳ ಬಳಕೆಯನ್ನು ಹುಡುಕುವುದು, ರೇಖೆಗಳ ಸಂಖ್ಯೆ/ ವಿಧಾನದ ಸೈಕ್ಲೋಮ್ಯಾಟಿಕ್ ಸಂಕೀರ್ಣತೆಯಂತಹ ಮೆಟ್ರಿಕ್‌ಗಳ ಮೇಲೆ ಮಿತಿಗಳನ್ನು ಹೊಂದಿಸುವುದು, ಇತ್ಯಾದಿ. - ಕೋಡ್‌ನ ಓದುವಿಕೆ ಮತ್ತು ನಿರ್ವಹಣೆಗೆ ಸಂಭಾವ್ಯವಾಗಿ ಅಡ್ಡಿಪಡಿಸುವ ಯಾವುದಾದರೂ. ಜಾವಾದಲ್ಲಿ, ಅಂತಹ ಸಾಧನವು ಚೆಕ್ಸ್ಟೈಲ್ ಆಗಿದೆ, ಪೈಥಾನ್ - ಫ್ಲೇಕ್8. ಈ ವರ್ಗದ ಕಾರ್ಯಕ್ರಮಗಳನ್ನು ಸಾಮಾನ್ಯವಾಗಿ "ಲಿಂಟರ್ಸ್" ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ.
• ಕಾರ್ಯಗತಗೊಳಿಸಬಹುದಾದ ಕೋಡ್ ಅನ್ನು ಮಾತ್ರ ವಿಶ್ಲೇಷಿಸಲಾಗುವುದಿಲ್ಲ. JSON, YAML, XML, .ಪ್ರಾಪರ್ಟೀಸ್‌ನಂತಹ ಸಂಪನ್ಮೂಲ ಫೈಲ್‌ಗಳನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಮಾನ್ಯತೆಗಾಗಿ ಪರಿಶೀಲಿಸಬಹುದು (ಮತ್ತು ಮಾಡಬೇಕು!). ಎಲ್ಲಾ ನಂತರ, ಪರೀಕ್ಷಾ ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆ ಅಥವಾ ರನ್ ಸಮಯಕ್ಕಿಂತ ಸ್ವಯಂಚಾಲಿತ ಪುಲ್ ವಿನಂತಿ ಪರಿಶೀಲನೆಯ ಆರಂಭಿಕ ಹಂತದಲ್ಲಿ ಕೆಲವು ಜೋಡಿಯಾಗದ ಉಲ್ಲೇಖಗಳಿಂದಾಗಿ JSON ರಚನೆಯು ಮುರಿದುಹೋಗಿದೆ ಎಂದು ಕಂಡುಹಿಡಿಯುವುದು ಉತ್ತಮವೇ? ಸೂಕ್ತವಾದ ಪರಿಕರಗಳು ಲಭ್ಯವಿದೆ: ಉದಾ. YAMLlint, JSONLint.
• ಸಂಕಲನ (ಅಥವಾ ಡೈನಾಮಿಕ್ ಪ್ರೋಗ್ರಾಮಿಂಗ್ ಭಾಷೆಗಳಿಗೆ ಪಾರ್ಸಿಂಗ್) ಸಹ ಒಂದು ರೀತಿಯ ಸ್ಥಿರ ವಿಶ್ಲೇಷಣೆಯಾಗಿದೆ. ಸಾಮಾನ್ಯವಾಗಿ, ಕಂಪೈಲರ್‌ಗಳು ಮೂಲ ಕೋಡ್ ಗುಣಮಟ್ಟದ ಸಮಸ್ಯೆಗಳನ್ನು ಸೂಚಿಸುವ ಎಚ್ಚರಿಕೆಗಳನ್ನು ಉತ್ಪಾದಿಸುವ ಸಾಮರ್ಥ್ಯವನ್ನು ಹೊಂದಿರುತ್ತವೆ ಮತ್ತು ನಿರ್ಲಕ್ಷಿಸಬಾರದು.
• ಕೆಲವೊಮ್ಮೆ ಸಂಕಲನವು ಕಾರ್ಯಗತಗೊಳಿಸಬಹುದಾದ ಕೋಡ್ ಅನ್ನು ಕಂಪೈಲ್ ಮಾಡುವುದಕ್ಕಿಂತ ಹೆಚ್ಚಾಗಿರುತ್ತದೆ. ಉದಾಹರಣೆಗೆ, ನೀವು ಸ್ವರೂಪದಲ್ಲಿ ದಸ್ತಾವೇಜನ್ನು ಹೊಂದಿದ್ದರೆ ಅಸ್ಸೈಡಾಕ್ಟರ್, ನಂತರ ಅದನ್ನು HTML/PDF ಆಗಿ ಪರಿವರ್ತಿಸುವ ಕ್ಷಣದಲ್ಲಿ AsciiDoctor ಹ್ಯಾಂಡ್ಲರ್ (ಮಾವೆನ್ ಪ್ಲಗಿನ್) ಎಚ್ಚರಿಕೆಗಳನ್ನು ನೀಡಬಹುದು, ಉದಾಹರಣೆಗೆ, ಮುರಿದ ಆಂತರಿಕ ಲಿಂಕ್‌ಗಳ ಬಗ್ಗೆ. ಮತ್ತು ದಾಖಲಾತಿ ಬದಲಾವಣೆಗಳೊಂದಿಗೆ ಪುಲ್ ವಿನಂತಿಯನ್ನು ಸ್ವೀಕರಿಸದಿರಲು ಇದು ಉತ್ತಮ ಕಾರಣವಾಗಿದೆ.
• ಕಾಗುಣಿತ ತಪಾಸಣೆ ಕೂಡ ಒಂದು ರೀತಿಯ ಸ್ಥಿರ ವಿಶ್ಲೇಷಣೆಯಾಗಿದೆ. ಉಪಯುಕ್ತತೆ ಆಸ್ಪೆಲ್ ದಸ್ತಾವೇಜನ್ನು ಮಾತ್ರವಲ್ಲದೆ C/C++, Java ಮತ್ತು Python ಸೇರಿದಂತೆ ವಿವಿಧ ಪ್ರೋಗ್ರಾಮಿಂಗ್ ಭಾಷೆಗಳಲ್ಲಿ ಪ್ರೋಗ್ರಾಮ್ ಮೂಲ ಕೋಡ್‌ಗಳಲ್ಲಿ (ಕಾಮೆಂಟ್‌ಗಳು ಮತ್ತು ಅಕ್ಷರಶಃ) ಕಾಗುಣಿತವನ್ನು ಪರಿಶೀಲಿಸಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ. ಯೂಸರ್ ಇಂಟರ್‌ಫೇಸ್ ಅಥವಾ ದಾಖಲಾತಿಯಲ್ಲಿನ ಕಾಗುಣಿತ ದೋಷವೂ ದೋಷವಾಗಿದೆ!
• ಕಾನ್ಫಿಗರೇಶನ್ ಪರೀಕ್ಷೆಗಳು (ಅವುಗಳ ಬಗ್ಗೆ - ನೋಡಿ. ಇದು и ಇದು ವರದಿಗಳು), ಪೈಟೆಸ್ಟ್‌ನಂತಹ ಯುನಿಟ್ ಟೆಸ್ಟ್ ರನ್‌ಟೈಮ್‌ನಲ್ಲಿ ಕಾರ್ಯಗತಗೊಳಿಸಲಾಗಿದ್ದರೂ, ವಾಸ್ತವವಾಗಿ ಅವು ಒಂದು ರೀತಿಯ ಸ್ಥಿರ ವಿಶ್ಲೇಷಣೆಯಾಗಿದೆ, ಏಕೆಂದರೆ ಅವುಗಳು ಅವುಗಳ ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆಯ ಸಮಯದಲ್ಲಿ ಮೂಲ ಕೋಡ್‌ಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವುದಿಲ್ಲ.

ನೀವು ನೋಡುವಂತೆ, ಈ ಪಟ್ಟಿಯಲ್ಲಿ ದೋಷಗಳನ್ನು ಹುಡುಕುವುದು ಕಡಿಮೆ ಪ್ರಮುಖ ಪಾತ್ರವನ್ನು ವಹಿಸುತ್ತದೆ ಮತ್ತು ಉಚಿತ ತೆರೆದ ಮೂಲ ಸಾಧನಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಉಳಿದೆಲ್ಲವೂ ಲಭ್ಯವಿದೆ.

ನಿಮ್ಮ ಯೋಜನೆಯಲ್ಲಿ ನೀವು ಯಾವ ರೀತಿಯ ಸ್ಥಿರ ವಿಶ್ಲೇಷಣೆಯನ್ನು ಬಳಸಬೇಕು? ಸಹಜವಾಗಿ, ಹೆಚ್ಚು ಉತ್ತಮ! ಮುಖ್ಯ ವಿಷಯವೆಂದರೆ ಅದನ್ನು ಸರಿಯಾಗಿ ಕಾರ್ಯಗತಗೊಳಿಸುವುದು, ಅದನ್ನು ಮತ್ತಷ್ಟು ಚರ್ಚಿಸಲಾಗುವುದು.

ಬಹು-ಹಂತದ ಫಿಲ್ಟರ್ ಆಗಿ ವಿತರಣಾ ಪೈಪ್‌ಲೈನ್ ಮತ್ತು ಅದರ ಮೊದಲ ಹಂತವಾಗಿ ಸ್ಥಿರ ವಿಶ್ಲೇಷಣೆ

ನಿರಂತರ ಏಕೀಕರಣದ ಶ್ರೇಷ್ಠ ರೂಪಕವು ಪೈಪ್‌ಲೈನ್ ಆಗಿದ್ದು, ಅದರ ಮೂಲಕ ಮೂಲ ಕೋಡ್ ಬದಲಾವಣೆಯಿಂದ ಉತ್ಪಾದನೆಗೆ ವಿತರಣೆಯವರೆಗೆ ಬದಲಾವಣೆಗಳು ಹರಿಯುತ್ತವೆ. ಈ ಪೈಪ್ಲೈನ್ನಲ್ಲಿನ ಹಂತಗಳ ಪ್ರಮಾಣಿತ ಅನುಕ್ರಮವು ಈ ರೀತಿ ಕಾಣುತ್ತದೆ:

1. ಸ್ಥಿರ ವಿಶ್ಲೇಷಣೆ
2. ಸಂಕಲನ
3. ಘಟಕ ಪರೀಕ್ಷೆಗಳು
4. ಏಕೀಕರಣ ಪರೀಕ್ಷೆಗಳು
5. UI ಪರೀಕ್ಷೆಗಳು
6. ಹಸ್ತಚಾಲಿತ ಪರಿಶೀಲನೆ

ಪೈಪ್‌ಲೈನ್‌ನ N ನೇ ಹಂತದಲ್ಲಿ ತಿರಸ್ಕರಿಸಿದ ಬದಲಾವಣೆಗಳನ್ನು ಹಂತ N+1 ಗೆ ವರ್ಗಾಯಿಸಲಾಗುವುದಿಲ್ಲ.

ಏಕೆ ನಿಖರವಾಗಿ ಈ ರೀತಿಯಲ್ಲಿ ಮತ್ತು ಇಲ್ಲದಿದ್ದರೆ? ಪೈಪ್ಲೈನ್ನ ಪರೀಕ್ಷಾ ಭಾಗದಲ್ಲಿ, ಪರೀಕ್ಷಕರು ಪ್ರಸಿದ್ಧ ಪರೀಕ್ಷಾ ಪಿರಮಿಡ್ ಅನ್ನು ಗುರುತಿಸುತ್ತಾರೆ.

ಪರೀಕ್ಷಾ ಪಿರಮಿಡ್. ಮೂಲ: ಲೇಖನ ಮಾರ್ಟಿನ್ ಫೌಲರ್.

ಈ ಪಿರಮಿಡ್‌ನ ಕೆಳಭಾಗದಲ್ಲಿ ಬರೆಯಲು ಸುಲಭವಾದ, ಕಾರ್ಯಗತಗೊಳಿಸಲು ವೇಗವಾದ ಮತ್ತು ವಿಫಲಗೊಳ್ಳುವ ಪ್ರವೃತ್ತಿಯನ್ನು ಹೊಂದಿರದ ಪರೀಕ್ಷೆಗಳಿವೆ. ಆದ್ದರಿಂದ, ಅವುಗಳಲ್ಲಿ ಹೆಚ್ಚಿನವು ಇರಬೇಕು, ಅವುಗಳು ಹೆಚ್ಚು ಕೋಡ್ ಅನ್ನು ಒಳಗೊಂಡಿರಬೇಕು ಮತ್ತು ಮೊದಲು ಕಾರ್ಯಗತಗೊಳಿಸಬೇಕು. ಪಿರಮಿಡ್‌ನ ಮೇಲ್ಭಾಗದಲ್ಲಿ, ವಿರುದ್ಧವಾಗಿ ನಿಜವಾಗಿದೆ, ಆದ್ದರಿಂದ ಏಕೀಕರಣ ಮತ್ತು UI ಪರೀಕ್ಷೆಗಳ ಸಂಖ್ಯೆಯನ್ನು ಅಗತ್ಯ ಕನಿಷ್ಠಕ್ಕೆ ಇಳಿಸಬೇಕು. ಈ ಸರಪಳಿಯಲ್ಲಿರುವ ವ್ಯಕ್ತಿಯು ಅತ್ಯಂತ ದುಬಾರಿ, ನಿಧಾನ ಮತ್ತು ವಿಶ್ವಾಸಾರ್ಹವಲ್ಲದ ಸಂಪನ್ಮೂಲವಾಗಿದೆ, ಆದ್ದರಿಂದ ಅವನು ಅತ್ಯಂತ ಕೊನೆಯಲ್ಲಿ ಮತ್ತು ಹಿಂದಿನ ಹಂತಗಳು ಯಾವುದೇ ದೋಷಗಳನ್ನು ಕಂಡುಹಿಡಿಯದಿದ್ದರೆ ಮಾತ್ರ ಕೆಲಸವನ್ನು ನಿರ್ವಹಿಸುತ್ತಾನೆ. ಆದಾಗ್ಯೂ, ಪರೀಕ್ಷೆಗೆ ನೇರವಾಗಿ ಸಂಬಂಧಿಸದ ಭಾಗಗಳಲ್ಲಿ ಪೈಪ್ಲೈನ್ ​​ಅನ್ನು ನಿರ್ಮಿಸಲು ಅದೇ ತತ್ವಗಳನ್ನು ಬಳಸಲಾಗುತ್ತದೆ!

ಬಹು-ಹಂತದ ನೀರಿನ ಶೋಧನೆ ವ್ಯವಸ್ಥೆಯ ರೂಪದಲ್ಲಿ ನಾನು ಸಾದೃಶ್ಯವನ್ನು ನೀಡಲು ಬಯಸುತ್ತೇನೆ. ಕೊಳಕು ನೀರು (ದೋಷಗಳೊಂದಿಗೆ ಬದಲಾವಣೆಗಳು) ಇನ್ಪುಟ್ಗೆ ಸರಬರಾಜು ಮಾಡಲಾಗುತ್ತದೆ; ಔಟ್ಪುಟ್ನಲ್ಲಿ ನಾವು ಶುದ್ಧ ನೀರನ್ನು ಪಡೆಯಬೇಕು, ಇದರಲ್ಲಿ ಎಲ್ಲಾ ಅನಗತ್ಯ ಮಾಲಿನ್ಯಕಾರಕಗಳನ್ನು ತೆಗೆದುಹಾಕಲಾಗುತ್ತದೆ.

ಬಹು-ಹಂತದ ಫಿಲ್ಟರ್. ಮೂಲ: ವಿಕಿಮೀಡಿಯ ಕಣಜದಲ್ಲಿ

ನಿಮಗೆ ತಿಳಿದಿರುವಂತೆ, ಶುಚಿಗೊಳಿಸುವ ಫಿಲ್ಟರ್‌ಗಳನ್ನು ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿದೆ ಇದರಿಂದ ಪ್ರತಿ ನಂತರದ ಕ್ಯಾಸ್ಕೇಡ್ ಹೆಚ್ಚು ಸೂಕ್ಷ್ಮವಾದ ಮಾಲಿನ್ಯಕಾರಕಗಳನ್ನು ಫಿಲ್ಟರ್ ಮಾಡಬಹುದು. ಅದೇ ಸಮಯದಲ್ಲಿ, ಒರಟಾದ ಶುದ್ಧೀಕರಣ ಕ್ಯಾಸ್ಕೇಡ್ಗಳು ಹೆಚ್ಚಿನ ಥ್ರೋಪುಟ್ ಮತ್ತು ಕಡಿಮೆ ವೆಚ್ಚವನ್ನು ಹೊಂದಿವೆ. ನಮ್ಮ ಸಾದೃಶ್ಯದಲ್ಲಿ, ಇನ್‌ಪುಟ್ ಗುಣಮಟ್ಟದ ಗೇಟ್‌ಗಳು ವೇಗವಾಗಿರುತ್ತವೆ, ಪ್ರಾರಂಭಿಸಲು ಕಡಿಮೆ ಪ್ರಯತ್ನದ ಅಗತ್ಯವಿರುತ್ತದೆ ಮತ್ತು ಕಾರ್ಯಾಚರಣೆಯಲ್ಲಿ ಹೆಚ್ಚು ಆಡಂಬರವಿಲ್ಲದವು - ಮತ್ತು ಇವುಗಳನ್ನು ನಿರ್ಮಿಸಿದ ಅನುಕ್ರಮವಾಗಿದೆ. ಸ್ಥಿರ ವಿಶ್ಲೇಷಣೆಯ ಪಾತ್ರ, ನಾವು ಈಗ ಅರ್ಥಮಾಡಿಕೊಂಡಂತೆ, ಕೇವಲ ಸ್ಥೂಲವಾದ ದೋಷಗಳನ್ನು ಮಾತ್ರ ಹೊರಹಾಕುವ ಸಾಮರ್ಥ್ಯವನ್ನು ಹೊಂದಿದೆ, ಇದು ಫಿಲ್ಟರ್ ಕ್ಯಾಸ್ಕೇಡ್ನ ಅತ್ಯಂತ ಆರಂಭದಲ್ಲಿ "ಮಣ್ಣಿನ" ಗ್ರಿಡ್ನ ಪಾತ್ರವಾಗಿದೆ.

ಸ್ಥಾಯೀ ವಿಶ್ಲೇಷಣೆಯು ಅಂತಿಮ ಉತ್ಪನ್ನದ ಗುಣಮಟ್ಟವನ್ನು ಸುಧಾರಿಸುವುದಿಲ್ಲ, ಹಾಗೆಯೇ "ಮಡ್ ಫಿಲ್ಟರ್" ನೀರನ್ನು ಕುಡಿಯಲು ಯೋಗ್ಯವಾಗುವುದಿಲ್ಲ. ಮತ್ತು ಇನ್ನೂ, ಪೈಪ್ಲೈನ್ನ ಇತರ ಅಂಶಗಳ ಜೊತೆಯಲ್ಲಿ, ಅದರ ಪ್ರಾಮುಖ್ಯತೆ ಸ್ಪಷ್ಟವಾಗಿದೆ. ಮಲ್ಟಿಸ್ಟೇಜ್ ಫಿಲ್ಟರ್‌ನಲ್ಲಿ ಔಟ್‌ಪುಟ್ ಹಂತಗಳು ಇನ್‌ಪುಟ್ ಹಂತಗಳು ಮಾಡುವ ಎಲ್ಲವನ್ನೂ ಸೆರೆಹಿಡಿಯಲು ಸಮರ್ಥವಾಗಿದ್ದರೂ, ಇನ್‌ಪುಟ್ ಹಂತಗಳಿಲ್ಲದೆ ಕೇವಲ ಸೂಕ್ಷ್ಮ-ಶುದ್ಧೀಕರಣ ಹಂತಗಳ ಮೂಲಕ ಮಾಡುವ ಪ್ರಯತ್ನದಿಂದ ಯಾವ ಪರಿಣಾಮಗಳು ಉಂಟಾಗುತ್ತವೆ ಎಂಬುದು ಸ್ಪಷ್ಟವಾಗಿದೆ.

"ಮಣ್ಣಿನ ಬಲೆ" ಯ ಉದ್ದೇಶವು ನಂತರದ ಕ್ಯಾಸ್ಕೇಡ್‌ಗಳನ್ನು ಬಹಳ ಸ್ಥೂಲವಾದ ದೋಷಗಳನ್ನು ಹಿಡಿಯುವುದರಿಂದ ನಿವಾರಿಸುವುದು. ಉದಾಹರಣೆಗೆ, ಕನಿಷ್ಠ, ಕೋಡ್ ವಿಮರ್ಶೆಯನ್ನು ಮಾಡುವ ವ್ಯಕ್ತಿಯು ತಪ್ಪಾಗಿ ಫಾರ್ಮ್ಯಾಟ್ ಮಾಡಲಾದ ಕೋಡ್ ಮತ್ತು ಸ್ಥಾಪಿತ ಕೋಡಿಂಗ್ ಮಾನದಂಡಗಳ ಉಲ್ಲಂಘನೆಯಿಂದ ವಿಚಲಿತರಾಗಬಾರದು (ಹೆಚ್ಚುವರಿ ಆವರಣಗಳು ಅಥವಾ ತುಂಬಾ ಆಳವಾಗಿ ನೆಸ್ಟೆಡ್ ಶಾಖೆಗಳು). NPE ಗಳಂತಹ ದೋಷಗಳನ್ನು ಯುನಿಟ್ ಪರೀಕ್ಷೆಗಳಿಂದ ಹಿಡಿಯಬೇಕು, ಆದರೆ ಪರೀಕ್ಷೆಯ ಮುಂಚೆಯೇ ವಿಶ್ಲೇಷಕವು ದೋಷವು ಸಂಭವಿಸಲಿದೆ ಎಂದು ನಮಗೆ ಸೂಚಿಸಿದರೆ, ಇದು ಅದರ ಫಿಕ್ಸಿಂಗ್ ಅನ್ನು ಗಮನಾರ್ಹವಾಗಿ ವೇಗಗೊಳಿಸುತ್ತದೆ.

ಸಾಂದರ್ಭಿಕವಾಗಿ ಬಳಸಿದರೆ ಸ್ಥಾಯೀ ವಿಶ್ಲೇಷಣೆಯು ಉತ್ಪನ್ನದ ಗುಣಮಟ್ಟವನ್ನು ಏಕೆ ಸುಧಾರಿಸುವುದಿಲ್ಲ ಮತ್ತು ಒಟ್ಟು ದೋಷಗಳೊಂದಿಗೆ ಬದಲಾವಣೆಗಳನ್ನು ಫಿಲ್ಟರ್ ಮಾಡಲು ನಿರಂತರವಾಗಿ ಬಳಸಬೇಕು ಎಂಬುದು ಈಗ ಸ್ಪಷ್ಟವಾಗಿದೆ ಎಂದು ನಾನು ನಂಬುತ್ತೇನೆ. ಸ್ಥಾಯೀ ವಿಶ್ಲೇಷಕವನ್ನು ಬಳಸುವುದರಿಂದ ನಿಮ್ಮ ಉತ್ಪನ್ನದ ಗುಣಮಟ್ಟ ಸುಧಾರಿಸುತ್ತದೆಯೇ ಎಂಬ ಪ್ರಶ್ನೆಯು ಸರಿಸುಮಾರು ಕೇಳುವುದಕ್ಕೆ ಸಮನಾಗಿರುತ್ತದೆ, "ಕೊಳಕು ಕೊಳದಿಂದ ತೆಗೆದ ನೀರನ್ನು ಕೊಲಾಂಡರ್ ಮೂಲಕ ಹಾದುಹೋದರೆ ಕುಡಿಯುವ ಗುಣಮಟ್ಟದಲ್ಲಿ ಸುಧಾರಣೆಯಾಗುತ್ತದೆಯೇ?"

ಪಾರಂಪರಿಕ ಯೋಜನೆಯಾಗಿ ಅನುಷ್ಠಾನಗೊಳಿಸುವುದು

ಒಂದು ಪ್ರಮುಖ ಪ್ರಾಯೋಗಿಕ ಪ್ರಶ್ನೆ: "ಗುಣಮಟ್ಟದ ಗೇಟ್" ಆಗಿ ನಿರಂತರ ಏಕೀಕರಣ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ಸ್ಥಿರ ವಿಶ್ಲೇಷಣೆಯನ್ನು ಹೇಗೆ ಕಾರ್ಯಗತಗೊಳಿಸುವುದು? ಸ್ವಯಂಚಾಲಿತ ಪರೀಕ್ಷೆಗಳ ಸಂದರ್ಭದಲ್ಲಿ, ಎಲ್ಲವೂ ಸ್ಪಷ್ಟವಾಗಿದೆ: ಪರೀಕ್ಷೆಗಳ ಒಂದು ಸೆಟ್ ಇದೆ, ಅವುಗಳಲ್ಲಿ ಯಾವುದಾದರೂ ವೈಫಲ್ಯವು ಅಸೆಂಬ್ಲಿ ಗುಣಮಟ್ಟದ ಗೇಟ್ ಅನ್ನು ಹಾದುಹೋಗಲಿಲ್ಲ ಎಂದು ನಂಬಲು ಸಾಕಷ್ಟು ಕಾರಣವಾಗಿದೆ. ಸ್ಥಿರ ವಿಶ್ಲೇಷಣೆಯ ಫಲಿತಾಂಶಗಳ ಆಧಾರದ ಮೇಲೆ ಅದೇ ರೀತಿಯಲ್ಲಿ ಗೇಟ್ ಅನ್ನು ಸ್ಥಾಪಿಸುವ ಪ್ರಯತ್ನವು ವಿಫಲಗೊಳ್ಳುತ್ತದೆ: ಪರಂಪರೆ ಕೋಡ್‌ನಲ್ಲಿ ಹಲವಾರು ವಿಶ್ಲೇಷಣೆ ಎಚ್ಚರಿಕೆಗಳಿವೆ, ನೀವು ಅವುಗಳನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ನಿರ್ಲಕ್ಷಿಸಲು ಬಯಸುವುದಿಲ್ಲ, ಆದರೆ ಉತ್ಪನ್ನವನ್ನು ಸಾಗಿಸುವುದನ್ನು ನಿಲ್ಲಿಸುವುದು ಅಸಾಧ್ಯ ಏಕೆಂದರೆ ಇದು ವಿಶ್ಲೇಷಕ ಎಚ್ಚರಿಕೆಗಳನ್ನು ಒಳಗೊಂಡಿದೆ.

ಮೊದಲ ಬಾರಿಗೆ ಬಳಸಿದಾಗ, ವಿಶ್ಲೇಷಕವು ಯಾವುದೇ ಯೋಜನೆಯಲ್ಲಿ ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ಎಚ್ಚರಿಕೆಗಳನ್ನು ಉತ್ಪಾದಿಸುತ್ತದೆ, ಅವುಗಳಲ್ಲಿ ಹೆಚ್ಚಿನವು ಉತ್ಪನ್ನದ ಸರಿಯಾದ ಕಾರ್ಯನಿರ್ವಹಣೆಗೆ ಸಂಬಂಧಿಸಿಲ್ಲ. ಈ ಎಲ್ಲಾ ಕಾಮೆಂಟ್‌ಗಳನ್ನು ಒಂದೇ ಬಾರಿಗೆ ಸರಿಪಡಿಸುವುದು ಅಸಾಧ್ಯ, ಮತ್ತು ಹಲವು ಅಗತ್ಯವಿಲ್ಲ. ಎಲ್ಲಾ ನಂತರ, ಸ್ಥಿರ ವಿಶ್ಲೇಷಣೆಯನ್ನು ಪರಿಚಯಿಸುವ ಮೊದಲು ನಮ್ಮ ಉತ್ಪನ್ನವು ಒಟ್ಟಾರೆಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂದು ನಮಗೆ ತಿಳಿದಿದೆ!

ಪರಿಣಾಮವಾಗಿ, ಅನೇಕವು ಸ್ಥಿರ ವಿಶ್ಲೇಷಣೆಯ ಸಾಂದರ್ಭಿಕ ಬಳಕೆಗೆ ಸೀಮಿತವಾಗಿದೆ, ಅಥವಾ ಅಸೆಂಬ್ಲಿ ಸಮಯದಲ್ಲಿ ವಿಶ್ಲೇಷಕ ವರದಿಯನ್ನು ಸರಳವಾಗಿ ನೀಡಿದಾಗ ಅದನ್ನು ಮಾಹಿತಿ ಕ್ರಮದಲ್ಲಿ ಮಾತ್ರ ಬಳಸುತ್ತಾರೆ. ಇದು ಯಾವುದೇ ವಿಶ್ಲೇಷಣೆಯ ಅನುಪಸ್ಥಿತಿಗೆ ಸಮನಾಗಿರುತ್ತದೆ, ಏಕೆಂದರೆ ನಾವು ಈಗಾಗಲೇ ಅನೇಕ ಎಚ್ಚರಿಕೆಗಳನ್ನು ಹೊಂದಿದ್ದರೆ, ಕೋಡ್ ಅನ್ನು ಬದಲಾಯಿಸುವಾಗ ಮತ್ತೊಂದು (ಎಷ್ಟು ಗಂಭೀರವಾಗಿದ್ದರೂ) ಸಂಭವಿಸುವಿಕೆಯು ಗಮನಿಸುವುದಿಲ್ಲ.

ಗುಣಮಟ್ಟದ ಗೇಟ್‌ಗಳನ್ನು ಪರಿಚಯಿಸುವ ಕೆಳಗಿನ ವಿಧಾನಗಳು ತಿಳಿದಿವೆ:

• ಎಚ್ಚರಿಕೆಗಳ ಒಟ್ಟು ಸಂಖ್ಯೆಯ ಮೇಲೆ ಮಿತಿಯನ್ನು ಹೊಂದಿಸುವುದು ಅಥವಾ ಕೋಡ್‌ನ ಸಾಲುಗಳ ಸಂಖ್ಯೆಯಿಂದ ಭಾಗಿಸಿದ ಎಚ್ಚರಿಕೆಗಳ ಸಂಖ್ಯೆ. ಇದು ಕಳಪೆಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ಏಕೆಂದರೆ ಅಂತಹ ಗೇಟ್ ಹೊಸ ದೋಷಗಳೊಂದಿಗೆ ಬದಲಾವಣೆಗಳನ್ನು ಹಾದುಹೋಗಲು ಮುಕ್ತವಾಗಿ ಅನುಮತಿಸುತ್ತದೆ, ಎಲ್ಲಿಯವರೆಗೆ ಅವುಗಳ ಮಿತಿಯನ್ನು ಮೀರುವುದಿಲ್ಲ.
• ಒಂದು ನಿರ್ದಿಷ್ಟ ಕ್ಷಣದಲ್ಲಿ, ಕೋಡ್‌ನಲ್ಲಿರುವ ಎಲ್ಲಾ ಹಳೆಯ ಎಚ್ಚರಿಕೆಗಳನ್ನು ನಿರ್ಲಕ್ಷಿಸಿದಂತೆ ಸರಿಪಡಿಸುವುದು ಮತ್ತು ಹೊಸ ಎಚ್ಚರಿಕೆಗಳು ಸಂಭವಿಸಿದಾಗ ನಿರ್ಮಿಸಲು ನಿರಾಕರಿಸುವುದು. ಈ ಕಾರ್ಯವನ್ನು PVS-ಸ್ಟುಡಿಯೋ ಮತ್ತು ಕೆಲವು ಆನ್‌ಲೈನ್ ಸಂಪನ್ಮೂಲಗಳಿಂದ ಒದಗಿಸಲಾಗಿದೆ, ಉದಾಹರಣೆಗೆ, ಕೊಡಸಿ. ಪಿವಿಎಸ್-ಸ್ಟುಡಿಯೋದಲ್ಲಿ ಕೆಲಸ ಮಾಡಲು ನನಗೆ ಅವಕಾಶವಿರಲಿಲ್ಲ, ಕೊಡಸಿಯೊಂದಿಗಿನ ನನ್ನ ಅನುಭವದ ಪ್ರಕಾರ, ಅವರ ಮುಖ್ಯ ಸಮಸ್ಯೆಯೆಂದರೆ "ಹಳೆಯ" ಮತ್ತು "ಹೊಸ" ದೋಷ ಯಾವುದು ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುವುದು ಯಾವಾಗಲೂ ಕಾರ್ಯನಿರ್ವಹಿಸದ ಸಂಕೀರ್ಣ ಅಲ್ಗಾರಿದಮ್ ಆಗಿದೆ. ಸರಿಯಾಗಿ, ವಿಶೇಷವಾಗಿ ಫೈಲ್‌ಗಳನ್ನು ಹೆಚ್ಚು ಮಾರ್ಪಡಿಸಿದ್ದರೆ ಅಥವಾ ಮರುಹೆಸರಿಸಿದರೆ. ನನ್ನ ಅನುಭವದಲ್ಲಿ, ಕೊಡಸಿಯು ಪುಲ್ ವಿನಂತಿಯಲ್ಲಿ ಹೊಸ ಎಚ್ಚರಿಕೆಗಳನ್ನು ನಿರ್ಲಕ್ಷಿಸಬಹುದು, ಅದೇ ಸಮಯದಲ್ಲಿ ನೀಡಿರುವ PR ನ ಕೋಡ್‌ನಲ್ಲಿನ ಬದಲಾವಣೆಗಳಿಗೆ ಸಂಬಂಧಿಸದ ಎಚ್ಚರಿಕೆಗಳ ಕಾರಣದಿಂದಾಗಿ ಪುಲ್ ವಿನಂತಿಯನ್ನು ರವಾನಿಸುವುದಿಲ್ಲ.
• ನನ್ನ ಅಭಿಪ್ರಾಯದಲ್ಲಿ, ಅತ್ಯಂತ ಪರಿಣಾಮಕಾರಿ ಪರಿಹಾರವೆಂದರೆ ಪುಸ್ತಕದಲ್ಲಿ ವಿವರಿಸಲಾಗಿದೆ ನಿರಂತರ ವಿತರಣೆ "ರಾಟ್ಚೆಟಿಂಗ್ ವಿಧಾನ". ಮೂಲ ಕಲ್ಪನೆಯೆಂದರೆ, ಸ್ಥಿರ ವಿಶ್ಲೇಷಣೆಯ ಎಚ್ಚರಿಕೆಗಳ ಸಂಖ್ಯೆಯು ಪ್ರತಿ ಬಿಡುಗಡೆಯ ಆಸ್ತಿಯಾಗಿದೆ ಮತ್ತು ಒಟ್ಟು ಎಚ್ಚರಿಕೆಗಳ ಸಂಖ್ಯೆಯನ್ನು ಹೆಚ್ಚಿಸದ ಬದಲಾವಣೆಗಳನ್ನು ಮಾತ್ರ ಅನುಮತಿಸಲಾಗುತ್ತದೆ.

ರಾಟ್ಚೆಟ್

ಇದು ಈ ರೀತಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ:

1. ಆರಂಭಿಕ ಹಂತದಲ್ಲಿ, ವಿಶ್ಲೇಷಕರು ಕಂಡುಹಿಡಿದ ಕೋಡ್‌ನಲ್ಲಿನ ಎಚ್ಚರಿಕೆಗಳ ಸಂಖ್ಯೆಯ ಬಿಡುಗಡೆಯ ಬಗ್ಗೆ ಮೆಟಾಡೇಟಾದಲ್ಲಿ ದಾಖಲೆಯನ್ನು ಮಾಡಲಾಗಿದೆ. ಆದ್ದರಿಂದ, ನೀವು ಅಪ್‌ಸ್ಟ್ರೀಮ್ ಅನ್ನು ನಿರ್ಮಿಸಿದಾಗ, ನಿಮ್ಮ ರೆಪೊಸಿಟರಿ ಮ್ಯಾನೇಜರ್ ಕೇವಲ "7.0.2 ಬಿಡುಗಡೆ" ಎಂದು ಬರೆಯುವುದಿಲ್ಲ, ಆದರೆ "7.0.2 ಚೆಕ್‌ಸ್ಟೈಲ್ ಎಚ್ಚರಿಕೆಗಳನ್ನು ಹೊಂದಿರುವ 100500 ಅನ್ನು ಬಿಡುಗಡೆ ಮಾಡಿ." ನೀವು ಸುಧಾರಿತ ರೆಪೊಸಿಟರಿ ಮ್ಯಾನೇಜರ್ ಅನ್ನು ಬಳಸಿದರೆ (ಆರ್ಟಿಫ್ಯಾಕ್ಟರಿಯಂತಹ), ನಿಮ್ಮ ಬಿಡುಗಡೆಯ ಬಗ್ಗೆ ಅಂತಹ ಮೆಟಾಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸುವುದು ಸುಲಭ.
2. ಈಗ ಪ್ರತಿ ಪುಲ್ ವಿನಂತಿಯನ್ನು ನಿರ್ಮಿಸಿದಾಗ, ಪ್ರಸ್ತುತ ಬಿಡುಗಡೆಯಲ್ಲಿ ಲಭ್ಯವಿರುವ ಎಚ್ಚರಿಕೆಗಳ ಸಂಖ್ಯೆಯೊಂದಿಗೆ ಫಲಿತಾಂಶದ ಎಚ್ಚರಿಕೆಗಳ ಸಂಖ್ಯೆಯನ್ನು ಹೋಲಿಸುತ್ತದೆ. PR ಈ ಸಂಖ್ಯೆಯಲ್ಲಿ ಹೆಚ್ಚಳಕ್ಕೆ ಕಾರಣವಾದರೆ, ನಂತರ ಕೋಡ್ ಸ್ಥಿರ ವಿಶ್ಲೇಷಣೆಗಾಗಿ ಗುಣಮಟ್ಟದ ಗೇಟ್ ಅನ್ನು ರವಾನಿಸುವುದಿಲ್ಲ. ಎಚ್ಚರಿಕೆಗಳ ಸಂಖ್ಯೆ ಕಡಿಮೆಯಾದರೆ ಅಥವಾ ಬದಲಾಗದಿದ್ದರೆ, ಅದು ಹಾದುಹೋಗುತ್ತದೆ.
3. ಮುಂದಿನ ಬಿಡುಗಡೆಯಲ್ಲಿ, ಬಿಡುಗಡೆ ಮೆಟಾಡೇಟಾದಲ್ಲಿ ಮರು ಲೆಕ್ಕಾಚಾರ ಮಾಡಿದ ಎಚ್ಚರಿಕೆಗಳ ಸಂಖ್ಯೆಯನ್ನು ಮತ್ತೆ ದಾಖಲಿಸಲಾಗುತ್ತದೆ.

ಆದ್ದರಿಂದ ಸ್ವಲ್ಪಮಟ್ಟಿಗೆ ಆದರೆ ಸ್ಥಿರವಾಗಿ (ರಾಟ್ಚೆಟ್ ಕೆಲಸ ಮಾಡುವಾಗ), ಎಚ್ಚರಿಕೆಗಳ ಸಂಖ್ಯೆಯು ಶೂನ್ಯಕ್ಕೆ ಒಲವು ತೋರುತ್ತದೆ. ಸಹಜವಾಗಿ, ಹೊಸ ಎಚ್ಚರಿಕೆಯನ್ನು ಪರಿಚಯಿಸುವ ಮೂಲಕ ಸಿಸ್ಟಮ್ ಅನ್ನು ಮೋಸಗೊಳಿಸಬಹುದು, ಆದರೆ ಬೇರೊಬ್ಬರನ್ನು ಸರಿಪಡಿಸಬಹುದು. ಇದು ಸಾಮಾನ್ಯವಾಗಿದೆ, ಏಕೆಂದರೆ ದೂರದವರೆಗೆ ಇದು ಫಲಿತಾಂಶಗಳನ್ನು ನೀಡುತ್ತದೆ: ಎಚ್ಚರಿಕೆಗಳನ್ನು ನಿಯಮದಂತೆ ಸರಿಪಡಿಸಲಾಗುತ್ತದೆ, ಪ್ರತ್ಯೇಕವಾಗಿ ಅಲ್ಲ, ಆದರೆ ಒಂದು ನಿರ್ದಿಷ್ಟ ಪ್ರಕಾರದ ಗುಂಪಿನಲ್ಲಿ ಏಕಕಾಲದಲ್ಲಿ, ಮತ್ತು ಸುಲಭವಾಗಿ ತೆಗೆಯಬಹುದಾದ ಎಲ್ಲಾ ಎಚ್ಚರಿಕೆಗಳನ್ನು ತ್ವರಿತವಾಗಿ ತೆಗೆದುಹಾಕಲಾಗುತ್ತದೆ.

ಅಂತಹ "ರಾಟ್ಚೆಟ್" ನ ಆರು ತಿಂಗಳ ಕಾರ್ಯಾಚರಣೆಗಾಗಿ ಚೆಕ್ಸ್ಟೈಲ್ ಎಚ್ಚರಿಕೆಗಳ ಒಟ್ಟು ಸಂಖ್ಯೆಯನ್ನು ಈ ಗ್ರಾಫ್ ತೋರಿಸುತ್ತದೆ ನಮ್ಮ OpenSource ಯೋಜನೆಗಳಲ್ಲಿ ಒಂದಾಗಿದೆ. ಎಚ್ಚರಿಕೆಗಳ ಸಂಖ್ಯೆಯು ಪರಿಮಾಣದ ಕ್ರಮದಿಂದ ಕಡಿಮೆಯಾಗಿದೆ ಮತ್ತು ಇದು ಉತ್ಪನ್ನ ಅಭಿವೃದ್ಧಿಗೆ ಸಮಾನಾಂತರವಾಗಿ ಸ್ವಾಭಾವಿಕವಾಗಿ ಸಂಭವಿಸಿದೆ!

ನಾನು ಈ ವಿಧಾನದ ಮಾರ್ಪಡಿಸಿದ ಆವೃತ್ತಿಯನ್ನು ಬಳಸುತ್ತೇನೆ, ಪ್ರಾಜೆಕ್ಟ್ ಮಾಡ್ಯೂಲ್ ಮತ್ತು ವಿಶ್ಲೇಷಣಾ ಸಾಧನದ ಮೂಲಕ ಪ್ರತ್ಯೇಕವಾಗಿ ಎಚ್ಚರಿಕೆಗಳನ್ನು ಎಣಿಸುತ್ತೇನೆ, ಇದರ ಪರಿಣಾಮವಾಗಿ ಬಿಲ್ಡ್ ಮೆಟಾಡೇಟಾದೊಂದಿಗೆ YAML ಫೈಲ್ ಈ ರೀತಿ ಕಾಣುತ್ತದೆ:

celesta-sql:
  checkstyle: 434
  spotbugs: 45
celesta-core:
  checkstyle: 206
  spotbugs: 13
celesta-maven-plugin:
  checkstyle: 19
  spotbugs: 0
celesta-unit:
  checkstyle: 0
  spotbugs: 0

ಯಾವುದೇ ಸುಧಾರಿತ CI ವ್ಯವಸ್ಥೆಯಲ್ಲಿ, ಪ್ಲಗಿನ್‌ಗಳು ಮತ್ತು ಥರ್ಡ್-ಪಾರ್ಟಿ ಉಪಕರಣಗಳನ್ನು ಅವಲಂಬಿಸದೆ ಯಾವುದೇ ಸ್ಥಿರ ವಿಶ್ಲೇಷಣಾ ಸಾಧನಗಳಿಗೆ ರಾಟ್‌ಚೆಟ್ ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಬಹುದು. ಪ್ರತಿ ವಿಶ್ಲೇಷಕವು ತನ್ನದೇ ಆದ ವರದಿಯನ್ನು ಸರಳ ಪಠ್ಯ ಅಥವಾ XML ಸ್ವರೂಪದಲ್ಲಿ ಉತ್ಪಾದಿಸುತ್ತದೆ, ಅದು ವಿಶ್ಲೇಷಿಸಲು ಸುಲಭವಾಗಿದೆ. CI ಸ್ಕ್ರಿಪ್ಟ್‌ನಲ್ಲಿ ಅಗತ್ಯವಾದ ತರ್ಕವನ್ನು ಬರೆಯುವುದು ಮಾತ್ರ ಉಳಿದಿದೆ. ಜೆಂಕಿನ್ಸ್ ಮತ್ತು ಆರ್ಟಿಫ್ಯಾಕ್ಟರಿಯನ್ನು ಆಧರಿಸಿದ ನಮ್ಮ ಓಪನ್ ಸೋರ್ಸ್ ಯೋಜನೆಗಳಲ್ಲಿ ಇದನ್ನು ಹೇಗೆ ಅಳವಡಿಸಲಾಗಿದೆ ಎಂಬುದನ್ನು ನೀವು ನೋಡಬಹುದು ಇಲ್ಲಿ ಅಥವಾ ಇಲ್ಲಿ. ಎರಡೂ ಉದಾಹರಣೆಗಳು ಗ್ರಂಥಾಲಯವನ್ನು ಅವಲಂಬಿಸಿರುತ್ತದೆ ರಾಟ್ಚೆಟ್ಲಿಬ್: ವಿಧಾನ countWarnings() ಸಾಮಾನ್ಯ ರೀತಿಯಲ್ಲಿ ಚೆಕ್‌ಸ್ಟೈಲ್ ಮತ್ತು ಸ್ಪಾಟ್‌ಬಗ್‌ಗಳಿಂದ ರಚಿಸಲಾದ ಫೈಲ್‌ಗಳಲ್ಲಿ xml ಟ್ಯಾಗ್‌ಗಳನ್ನು ಎಣಿಸುತ್ತದೆ ಮತ್ತು compareWarningMaps() ಅದೇ ರಾಟ್ಚೆಟ್ ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುತ್ತದೆ, ಯಾವುದೇ ವರ್ಗಗಳಲ್ಲಿ ಎಚ್ಚರಿಕೆಗಳ ಸಂಖ್ಯೆಯು ಹೆಚ್ಚಾದಾಗ ದೋಷವನ್ನು ಎಸೆಯುತ್ತದೆ.

"ರಾಟ್ಚೆಟ್" ನ ಆಸಕ್ತಿದಾಯಕ ಅನುಷ್ಠಾನವು ಕಾಮೆಂಟ್‌ಗಳ ಕಾಗುಣಿತ, ಪಠ್ಯ ಅಕ್ಷರಶಃ ಮತ್ತು ಆಸ್ಪೆಲ್ ಬಳಸಿ ದಾಖಲಾತಿಗಳನ್ನು ವಿಶ್ಲೇಷಿಸಲು ಸಾಧ್ಯವಿದೆ. ನಿಮಗೆ ತಿಳಿದಿರುವಂತೆ, ಕಾಗುಣಿತವನ್ನು ಪರಿಶೀಲಿಸುವಾಗ, ಪ್ರಮಾಣಿತ ನಿಘಂಟಿಗೆ ತಿಳಿದಿಲ್ಲದ ಎಲ್ಲಾ ಪದಗಳು ತಪ್ಪಾಗಿರುವುದಿಲ್ಲ; ಅವುಗಳನ್ನು ಬಳಕೆದಾರ ನಿಘಂಟಿಗೆ ಸೇರಿಸಬಹುದು. ನೀವು ಪ್ರಾಜೆಕ್ಟ್‌ನ ಮೂಲ ಕೋಡ್‌ನ ಕಸ್ಟಮ್ ನಿಘಂಟನ್ನು ಭಾಗವಾಗಿ ಮಾಡಿದರೆ, ಕಾಗುಣಿತ ಗುಣಮಟ್ಟದ ಗೇಟ್ ಅನ್ನು ಈ ರೀತಿ ರೂಪಿಸಬಹುದು: ಪ್ರಮಾಣಿತ ಮತ್ತು ಕಸ್ಟಮ್ ನಿಘಂಟಿನೊಂದಿಗೆ ಆಸ್ಪೆಲ್ ಅನ್ನು ಚಾಲನೆ ಮಾಡುವುದು ಮಾಡಬಾರದು ಯಾವುದೇ ಕಾಗುಣಿತ ದೋಷಗಳನ್ನು ಕಂಡುಹಿಡಿಯಬೇಡಿ.

ವಿಶ್ಲೇಷಕ ಆವೃತ್ತಿಯನ್ನು ಸರಿಪಡಿಸುವ ಪ್ರಾಮುಖ್ಯತೆಯ ಬಗ್ಗೆ

ಕೊನೆಯಲ್ಲಿ, ನಿಮ್ಮ ವಿತರಣಾ ಪೈಪ್‌ಲೈನ್‌ನಲ್ಲಿ ನೀವು ವಿಶ್ಲೇಷಣೆಯನ್ನು ಹೇಗೆ ಕಾರ್ಯಗತಗೊಳಿಸಿದರೂ, ವಿಶ್ಲೇಷಕದ ಆವೃತ್ತಿಯನ್ನು ಸರಿಪಡಿಸಬೇಕು ಎಂಬುದು ಗಮನಿಸಬೇಕಾದ ಅಂಶವಾಗಿದೆ. ವಿಶ್ಲೇಷಕವನ್ನು ಸ್ವಯಂಪ್ರೇರಿತವಾಗಿ ನವೀಕರಿಸಲು ನೀವು ಅನುಮತಿಸಿದರೆ, ಮುಂದಿನ ಪುಲ್ ವಿನಂತಿಯನ್ನು ಜೋಡಿಸುವಾಗ, ಕೋಡ್ ಬದಲಾವಣೆಗಳಿಗೆ ಸಂಬಂಧಿಸದ ಹೊಸ ದೋಷಗಳು "ಪಾಪ್ ಅಪ್" ಆಗಬಹುದು, ಆದರೆ ಹೊಸ ವಿಶ್ಲೇಷಕವು ಹೆಚ್ಚಿನ ದೋಷಗಳನ್ನು ಕಂಡುಹಿಡಿಯಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ ಎಂಬ ಅಂಶಕ್ಕೆ ಸಂಬಂಧಿಸಿದೆ - ಮತ್ತು ಇದು ಪುಲ್ ವಿನಂತಿಗಳನ್ನು ಸ್ವೀಕರಿಸುವ ನಿಮ್ಮ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಮುರಿಯುತ್ತದೆ. ವಿಶ್ಲೇಷಕವನ್ನು ನವೀಕರಿಸುವುದು ಪ್ರಜ್ಞಾಪೂರ್ವಕ ಕ್ರಿಯೆಯಾಗಿರಬೇಕು. ಆದಾಗ್ಯೂ, ಪ್ರತಿ ಅಸೆಂಬ್ಲಿ ಘಟಕದ ಆವೃತ್ತಿಯ ಕಟ್ಟುನಿಟ್ಟಾದ ಸ್ಥಿರೀಕರಣವು ಸಾಮಾನ್ಯವಾಗಿ ಅಗತ್ಯವಾದ ಅವಶ್ಯಕತೆಯಾಗಿದೆ ಮತ್ತು ಪ್ರತ್ಯೇಕ ಚರ್ಚೆಗೆ ಒಂದು ವಿಷಯವಾಗಿದೆ.

ಸಂಶೋಧನೆಗಳು

• ಸ್ಥಿರ ವಿಶ್ಲೇಷಣೆಯು ನಿಮಗಾಗಿ ದೋಷಗಳನ್ನು ಕಂಡುಹಿಡಿಯುವುದಿಲ್ಲ ಮತ್ತು ಒಂದೇ ಅಪ್ಲಿಕೇಶನ್‌ನ ಪರಿಣಾಮವಾಗಿ ನಿಮ್ಮ ಉತ್ಪನ್ನದ ಗುಣಮಟ್ಟವನ್ನು ಸುಧಾರಿಸುವುದಿಲ್ಲ. ವಿತರಣಾ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ಅದರ ನಿರಂತರ ಬಳಕೆಯ ಮೂಲಕ ಗುಣಮಟ್ಟದ ಮೇಲೆ ಸಕಾರಾತ್ಮಕ ಪರಿಣಾಮವನ್ನು ಮಾತ್ರ ಸಾಧಿಸಬಹುದು.
• ದೋಷಗಳನ್ನು ಕಂಡುಹಿಡಿಯುವುದು ವಿಶ್ಲೇಷಣೆಯ ಮುಖ್ಯ ಕಾರ್ಯವಲ್ಲ; ಬಹುಪಾಲು ಉಪಯುಕ್ತ ಕಾರ್ಯಗಳು ಓಪನ್ ಸೋರ್ಸ್ ಉಪಕರಣಗಳಲ್ಲಿ ಲಭ್ಯವಿದೆ.
• ಲೆಗಸಿ ಕೋಡ್‌ಗಾಗಿ "ರಾಟ್ಚೆಟ್" ಅನ್ನು ಬಳಸಿಕೊಂಡು ವಿತರಣಾ ಪೈಪ್‌ಲೈನ್‌ನ ಮೊದಲ ಹಂತದಲ್ಲಿ ಸ್ಥಿರ ವಿಶ್ಲೇಷಣೆಯ ಫಲಿತಾಂಶಗಳ ಆಧಾರದ ಮೇಲೆ ಗುಣಮಟ್ಟದ ಗೇಟ್‌ಗಳನ್ನು ಅಳವಡಿಸಿ.

ಉಲ್ಲೇಖಗಳು

1. ನಿರಂತರ ವಿತರಣೆ
2. A. ಕುದ್ರಿಯಾವ್ಟ್ಸೆವ್: ಪ್ರೋಗ್ರಾಂ ವಿಶ್ಲೇಷಣೆ: ನೀವು ಉತ್ತಮ ಪ್ರೋಗ್ರಾಮರ್ ಎಂದು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು ಹೇಗೆ ಕೋಡ್ ವಿಶ್ಲೇಷಣೆಯ ವಿವಿಧ ವಿಧಾನಗಳ ಕುರಿತು ವರದಿ ಮಾಡಿ (ಸ್ಥಿರ ಮಾತ್ರವಲ್ಲ!)

ಮೂಲ: www.habr.com