ನಿಮ್ಮ ಕೋಡ್‌ಬೇಸ್‌ಗೆ ಒಂದು ಸಂವಿಧಾನವನ್ನು ನೀಡಿ

ಜನರ ತಲೆಯಲ್ಲಿರುವ ಆರ್ಕಿಟೆಕ್ಚರ್ (Architecture) ಕೋಡಿಂಗ್ ಏಜೆಂಟ್‌ಗಳ ಮುಂದೆ ಉಳಿಯುವುದಿಲ್ಲ.

ವರ್ಷಗಳ ಕಾಲ, ಕೋಡ್‌ಬೇಸ್ ನಿಯಮಗಳು ಕೇವಲ ಅಲಿಖಿತ ಜ್ಞಾನದಂತೆ (tribal knowledge) ಅಸ್ತಿತ್ವದಲ್ಲಿದ್ದವು. ಯಾವ ಲೇಯರ್‌ಗಳು (layers) ಪರಸ್ಪರ ಸಂವಹನ ನಡೆಸಬಹುದು ಎಂಬುದು ಹಿರಿಯ ಇಂಜಿನಿಯರ್‌ಗಳಿಗೆ ತಿಳಿದಿತ್ತು. ಯಾವ ಡಿಪೆಂಡೆನ್ಸಿಗಳು (dependencies) ನಿಷೇಧಿತ ಎಂಬುದು ಅವರಿಗೆ ತಿಳಿದಿತ್ತು. ಹೊಸ ಇಂಜಿನಿಯರ್‌ಗಳು ವಿಷಯಗಳನ್ನು ಹಾಳುಮಾಡುವ ಮೂಲಕ ಮತ್ತು ರಿವ್ಯೂಗಳಲ್ಲಿ ತಿದ್ದುಪಡಿ ಪಡೆಯುವ ಮೂಲಕ ಕಲಿಯುತ್ತಿದ್ದರು.

ಇದು ಮನುಷ್ಯರಿಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಏಕೆಂದರೆ ಮನುಷ್ಯರು ಕಾಲಾನಂತರದಲ್ಲಿ ಸಂದರ್ಭವನ್ನು (context) ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತಾರೆ. ಏಜೆಂಟ್‌ಗಳು ಸಂದರ್ಭವನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದಿಲ್ಲ. ಅವುಗಳಿಗೆ ಕೇವಲ ಕಾಣಿಸುವ ವಿಷಯಗಳು ಮಾತ್ರ ತಿಳಿದಿರುತ್ತವೆ.

ಒಂದು ನಿಯಮವನ್ನು ಬರೆದಿಟ್ಟಿಲ್ಲದಿದ್ದರೆ, ಆ ನಿಯಮವೇ ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲ ಎಂದು ಏಜೆಂಟ್ ಭಾವಿಸುತ್ತದೆ. ಏಜೆಂಟ್‌ಗಳು ಒಳಗಿನ ಲೇಯರ್‌ಗಳನ್ನು ಹೊರಗಿನ ಲೇಯರ್‌ಗಳಿಗೆ ಜೋಡಿಸುವುದನ್ನು ನಾನು ನೋಡಿದ್ದೇನೆ. ನಾವು ನಿರ್ದಿಷ್ಟವಾಗಿ ತಪ್ಪಿಸಿದ ಡಿಪೆಂಡೆನ್ಸಿಗಳನ್ನು ಅವು ಪರಿಚಯಿಸುತ್ತವೆ. ಕೋಡ್ ಕೆಲಸ ಮಾಡುತ್ತದೆ, ಆದರೆ ಆರ್ಕಿಟೆಕ್ಚರ್ ದಾರಿ ತಪ್ಪುತ್ತದೆ.

ನಿಮ್ಮ ಆರ್ಕಿಟೆಕ್ಚರ್ ಅನ್ನು ಕೇವಲ ಜನಪದ ಕಥೆಗಳಂತಿರಬಾರದು, ಅದನ್ನು ಕಾನೂನನ್ನಾಗಿ ಪರಿವರ್ತಿಸಬೇಕು.

ಸಂವಿಧಾನವು ಡಾಕ್ಯುಮೆಂಟೇಶನ್ (documentation) ಅಲ್ಲ. ಡಾಕ್ಯುಮೆಂಟೇಶನ್ ಒಂದು ಸಿಸ್ಟಮ್ ಇಂದು ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಎಂಬುದನ್ನು ವಿವರಿಸುತ್ತದೆ. ಸಂವಿಧಾನವು ಒಂದು ಸಿಸ್ಟಮ್ ಏನಾಗಲು ಅನುಮತಿ ಇದೆ ಎಂಬುದನ್ನು ವ್ಯಾಖ್ಯಾನಿಸುತ್ತದೆ.

ನಿಮ್ಮ ಸಂವಿಧಾನವು ದೊಡ್ಡ ಮಟ್ಟದ ರಿಫ್ಯಾಕ್ಟರ್ (refactor) ನಂತರವೂ ಉಳಿಯುವ ವಿಷಯಗಳ ಮೇಲೆ ಕೇಂದ್ರೀಕರಿಸಬೇಕು. ಅದರಲ್ಲಿ ಇವುಗಳನ್ನು ಸೇರಿಸಬೇಕು:

  • ಕಾನೂನುಗಳು ಮತ್ತು ಇನ್ವೇರಿಯಂಟ್‌ಗಳು (invariants)
  • ಸಿಸ್ಟಮ್ ಬೌಂಡರಿಗಳು (system boundaries)
  • ಮೂಲಭೂತ ಊಹೆಗಳು (foundational assumptions)

ಅತ್ಯುತ್ತಮ ಸಂವಿಧಾನಗಳು ಸಂಕ್ಷಿಪ್ತವಾಗಿರುತ್ತವೆ, ನಿರ್ಬಂಧಾತ್ಮಕವಾಗಿರುತ್ತವೆ ಮತ್ತು ಬದಲಾವಣೆಗೊಳ್ಳಲು ನಿಧಾನವಾಗಿರುತ್ತವೆ.

ಆರ್ಕಿಟೆಕ್ಚರ್ ಅನ್ನು ಡೈರೆಕ್ಟರಿ ರಚನೆಗಳಿಗೆ (directory structures) ಕಟ್ಟುಹಾಕಬೇಡಿ. ಡೈರೆಕ್ಟರಿಗಳು ಬದಲಾಗುತ್ತವೆ. ಆರ್ಕಿಟೆಕ್ಚರ್ ಅನ್ನು ಜವಾಬ್ದಾರಿಗಳಿಗೆ (responsibilities) ಕಟ್ಟುಹಾಕಿ. ಡೊಮೇನ್ ಮಾಡೆಲ್ (domain model) ಅದರ ಫೋಲ್ಡರ್ ಏನೇ ಇರಲಿ, ಅದು ಡೊಮೇನ್ ಮಾಡೆಲ್ ಆಗಿಯೇ ಇರುತ್ತದೆ.

ಪ್ರತಿಯೊಂದು ಕಾನೂನಿಗೂ ಒಂದು ಕಾರಣ ಬೇಕು. ತರ್ಕವಿಲ್ಲದ ನಿಯಮವನ್ನು ಅದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳದ ವ್ಯಕ್ತಿಯೊಬ್ಬರು ಅಳಿಸಿಹಾಕುತ್ತಾರೆ. ನಿಯಮವು ನಡವಳಿಕೆಯನ್ನು ಕಲಿಸಿದರೆ, ಕಾರಣವು ವಿವೇಚನೆಯನ್ನು ಕಲಿಸುತ್ತದೆ.

ಎಲ್ಲಕ್ಕಿಂತ ಮುಖ್ಯವಾಗಿ, ನೀವು ನಿಮ್ಮ ಕಾನೂನುಗಳನ್ನು ಜಾರಿಗೆ ತರಬೇಕು.

ಸೂಚನೆಗಳು ಕೇವಲ ಮಾರ್ಗದರ್ಶನವಾಗಿರುತ್ತವೆ. ಜಾರಿ ಮಾಡುವುದು ವಾಸ್ತವವಾಗಿರುತ್ತದೆ. ಏಜೆಂಟ್ ಅಥವಾ ಮನುಷ್ಯ ಅಂತಿಮವಾಗಿ ಬರೆದ ಸೂಚನೆಯನ್ನು ನಿರ್ಲಕ್ಷಿಸಬಹುದು.

ಒಂದು ನಿಯಮವು ನಿರ್ಣಾಯಕವಾಗಿದ್ದರೆ, ಕೇವಲ ವಿವರಣೆಯ ಮೇಲೆ ಅವಲಂಬಿತರಾಗಬೇಡಿ. ಅದನ್ನು ನಿಮ್ಮ CI ನಲ್ಲಿ ಹಾಕಿ. ಲಿಂಟರ್ (linter) ನಲ್ಲಿ ಹಾಕಿ. ವ್ಯಾಲಿಡೇಟರ್ (validator) ನಲ್ಲಿ ಹಾಕಿ.

ಪ್ರತಿಯೊಂದು ಪ್ರಮುಖ ನಿಯಮಕ್ಕೂ ಎರಡು ರೂಪಗಳು ಬೇಕು:

  • ಮಾನವ ಆವೃತ್ತಿ: ಇದು ಉದ್ದೇಶವನ್ನು ವಿವರಿಸುತ್ತದೆ.
  • ಯಂತ್ರ ಆವೃತ್ತಿ: ಇದು ಅನುಸರಣೆಯನ್ನು ಖಚಿತಪಡಿಸುತ್ತದೆ.

ಇದು ಪ್ರಕ್ರಿಯೆಯನ್ನು ಹೆಚ್ಚಿಸುವುದರ ಬಗ್ಗೆ ಅಲ್ಲ. ಇದು ನಿಮ್ಮ ಕೆಲಸದ ಸಾಮರ್ಥ್ಯವನ್ನು (leverage) ಹೆಚ್ಚಿಸುವುದರ ಬಗ್ಗೆಯಾಗಿದೆ. ಆರ್ಕಿಟೆಕ್ಚರ್ ಅನ್ನು ಜಾರಿಗೆ ತರಲು ಸಾಧ್ಯವಾದಾಗ, ನೀವು ಪ್ರತಿಯೊಂದು ನಿರ್ಧಾರವನ್ನು ಪರಿಶೀಲಿಸುವ ಅಗತ್ಯವಿರುವುದಿಲ್ಲ. ಯಂತ್ರವು ಅದನ್ನು ನಿಮಗಾಗಿ ಮಾಡುತ್ತದೆ.

ನೀವು ಬೌಂಡರಿಗಳನ್ನು (boundaries) ನಂಬಿದಾಗ ಹೆಚ್ಚಿನ ಕೆಲಸವನ್ನು ನಿಯೋಜಿಸಬಹುದು.

ಹೇಗೆ ಪ್ರಾರಂಭಿಸುವುದು:

ನಿಮ್ಮ ರಿವ್ಯೂಗಳ ಕಡೆ ಗಮನ ಕೊಡಿ. ನೀವು ಪ್ರತಿ ಬಾರಿ "ನಾವು ಅದನ್ನು ಮಾಡುವುದಿಲ್ಲ ಏಕೆಂದರೆ..." ಎಂದು ಹೇಳಿದಾಗ, ನೀವು ಒಂದು ಕಾನೂನನ್ನು ಕಂಡುಕೊಂಡಿದ್ದೀರಿ ಎಂದರ್ಥ.

ಕೆಲವು ನಿಯಮಗಳೊಂದಿಗೆ ಪ್ರಾರಂಭಿಸಿ:

  • ಡಿಪೆಂಡೆನ್ಸಿ ದಿಕ್ಕು (Dependency direction)
  • ಸೀಕ್ರೆಟ್ ಹ್ಯಾಂಡ್ಲಿಂಗ್ (Secret handling)
  • ನಿರ್ಣಾಯಕ ಒಪ್ಪಂದಗಳು (Critical contracts)
  • ಬೌಂಡರಿ ಮಾಲೀಕತ್ವ (Boundary ownership)

ನಿಯಮವನ್ನು ಬರೆಯಿರಿ. ಕಾರಣವನ್ನು ಬರೆಯಿರಿ. ನಂತರ ಅದನ್ನು ಉಲ್ಲಂಘಿಸಲು ಸಾಧ್ಯವಾಗದಂತೆ ಮಾಡುವ ಕೋಡ್ ಚೆಕ್ ಅನ್ನು ಸೇರಿಸಿ.

ಜಾರಿಗೊಳಿಸದ ಕಾನೂನು ಕೇವಲ ಒಂದು ಸಲಹೆಯಷ್ಟೇ.

ಮೂಲ: https://dev.to/miteshethos/give-your-codebase-a-constitution-3k4h

ಐಚ್ಛಿಕ ಕಲಿಕಾ ಸಮುದಾಯ: https://t.me/GyaanSetuAi