සංවිධාන තුළ තීරණ ගත කිරීමේ ලේඛනයක් ලෙස ADR (Architecture Decision Record) භාවිතා කරනවා. නමුත් බොහෝ කණ්ඩායම් ලියන ලේඛන වැරදි අන්තර්ගතයෙන් පිරී, ප්රධාන තොරතුරු අඩු වෙලා ඉතිරි වෙනවා.
ADR එකේ ප්රධාන කාර්යය වන්නේ “වැඩි වියදම් ඇති වෙනස් කිරීමක් තහවුරු කරමින්, එයට ගොඩනැගිල්ලේ හේතු ලියනවා”. එය නිර්මාණ ලේඛනයක්, විස්තරාත්මක විශේෂණයක්, හෝ පර්යේෂණ එකතුවක් නොවේ. මෙම මූලික අදහස පවත්වාගෙන යන්නේ නම්, ඇතුළත් කළ යුතු දේවල් සහ ඉවත් කළ යුතු දේවල් ස්වභාවිකව තීරණය වේ.
මයිකල් නයිගාර්ඩ් 2011 දී හඳුන්වාදුන් ADR ආකෘතිය (title, status, context, decision, consequences) තවමත් ප්රචලිතයි. එය කියන්නේ: පසුගිය පරිශීලකයාට අවශ්ය ප්රධාන ප්රශ්න – තත්වය කුමක්ද? අපි තීරණය කළේ කුමක්ද? අපි කුමක් අත්හැරුවෙමු? ඒවාට පිළිතුරු දෙන්න. තවත් අතිරේක කොටස් (owners, risk matrix, approval list) එක් කිරීම ලේඛනය දිගු කර, කියවීමට අමාරු කරයි.
ශ්රී ලංකාවට ඇති වැදගත්කම
- සංවර්ධකයින්ට – කෙටි, පැහැදිලි ADR එකක් ලියන විදිය ඉගෙන ගත හැකිය. එය කණ්ඩායම් අතර සන්නිවේදනය වේගවත් කරයි.
- ව්යාපාරිකයින්ට – තීරණය කරන විට ඇති වියදම් සහ පරිනත ප්රතිඵල ඉක්මනින් හඳුනා ගත හැකි බැවින්, ව්යාපාරික අවදානම් අඩු කරයි.
- ඉගෙනුම් ආයතනවලට – ADR ආකෘතිය පාඨමාලා අඩංගුවක් ලෙස භාවිතා කර, නව පුරෝගාමී තාක්ෂණ තීරණ පිළිබඳ වාස්තු විද්යාව ඉගැන්විය හැකිය.
ADR එකේ ඇතුළත් කළ යුතු දේ: තීරණය (උදා: “ඕඩර් සහ ඉන්වෙන්ටරි සේවාවන් අතර event‑driven integration භාවිතා කරමු”), එයට ගැටුම් වූ සීමා (latency vs consistency, ownership vs shared DB), සැලකිලිමත් කරන ලද විකල්ප සහ ඒවා තෝරා නොගත් හේතු, සහ තීරණයේ පසුබැසි ප්රතිඵල (eventual consistency, debug කටයුතු බරපතළ වීම).
ඇතුළත් නොකළ යුතු දේ: කේත විස්තර, API endpoint, class නාම, තවදුරටත් තීරණය නොගත් විකල්ප. ඒවා වෙනම design doc හෝ spike ticket එකක් ලෙස රඳවා තබා ගත යුතුය.
ඉතා කෙටි, 600 වචන ඉක්මවා නොයන ADR එකක් ලියන්න. එය ඔබේ සංවිධානයේ තාක්ෂණික ඉතිහාසය සුරකිමින්, අනාගත තීරණ ගැන කාර්යක්ෂමව සලකා බලන්න උදව් කරයි.
