મેં કોડિંગ કરવાનું કેમ છોડી દીધું અને ડિઝાઇન કરવાનું કેમ શરૂ કર્યું
હું વિચારતો હતો કે સોફ્ટવેર ડેવલપમેન્ટ એટલે ફીચર્સ લખવા. મને લાગતું હતું કે મારું કામ entities બનાવવાનું, controllers બનાવવા અને databases ને કનેક્ટ કરવાનું છે.
તાજેતરના એક પ્રોજેક્ટથી મારો દ્રષ્ટિકોણ બદલાઈ ગયો. મેં શીખ્યું કે કોડિંગ એ ઉકેલનો માત્ર એક ભાગ છે. સાચું કામ તમે કોડની એક પણ લાઇન લખતા પહેલા જ શરૂ કરી દેવાનું હોય છે.
તમારે architecture નક્કી કરવું જોઈએ. તમારે પૂછવું જોઈએ કે તે કેમ યોગ્ય છે, તેની કિંમત શું છે, અને તે કયા જોખમોને હલ કરે છે.
અહીં મારા મુખ્ય પાઠ છે:
• Architecture પ્રોડક્ટના તબક્કા સાથે સુસંગત હોવું જોઈએ. તરત જ microservices, Kubernetes, અને જટિલ event queues નો ઉપયોગ કરવો આકર્ષક લાગે છે. અમારા પ્રોજેક્ટ માટે, અમે સિંગલ પ્રોસેસમાં એક layered architecture પસંદ કર્યું. આનાથી અમને ડિસ્ટ્રિબ્યુટેડ સિસ્ટમની માથાકૂટ વગર જવાબદારીઓ અલગ પાડવામાં મદદ મળી. જ્યારે તમે શરૂઆત કરો છો, ત્યારે ઘણીવાર સાદું હોવું એ વધુ સારું છે.
• કેટલાક નિર્ણયો અત્યારે સસ્તા છે પરંતુ પછીથી મોંઘા પડે છે. અમે પહેલા દિવસથી જ અમારા ડેટા મોડેલમાં TenantId ઉમેર્યું હતું. ભલે અમારી પાસે માત્ર એક જ ક્લાયન્ટ હતો, પરંતુ આનાથી ભવિષ્યમાં SaaS મોડેલ પર જવું સરળ બન્યું. જો તમે multi-tenancy ઉમેરવા માટે બહુ મોડું કરો છો, તો migration એક દુઃસ્વપ્ન બની જાય છે.
• ડિઝાઇન ભવિષ્યના અવરોધોને અટકાવે છે. Programming તાત્કાલિક સમસ્યાનો ઉકેલ લાવે છે. Designing ભવિષ્યના દરવાજા બંધ કર્યા વિના સમસ્યાનો ઉકેલ લાવે છે. અમે અલગ infrastructure પર સ્થાનાંતર સરળ બનાવવા માટે શરૂઆતમાં જ containers નો ઉપયોગ કર્યો. અમે providers બદલવાનું સરળ બનાવવા માટે interfaces નો ઉપયોગ કર્યો.
• Business ના ફેરફારો technical ફેરફારો લાવે છે. જ્યારે બિઝનેસ વધે છે ત્યારે સિસ્ટમ microservices તરફ જાય છે. એક સિંગલ ક્લિનિક એપ સેંકડો ક્લિનિક્સ માટે SaaS પ્લેટફોર્મ બની જાય છે. આ ફેરફાર તમે billing, subscriptions, અને scaling કેવી રીતે હેન્ડલ કરો છો તે બદલી નાખે છે.
• Reliability માટે સ્માર્ટ patterns ની જરૂર છે. અમે synchronous calls થી event-driven architecture તરફ વળ્યા. મેડિકલ સિસ્ટમમાં, નોટિફિકેશન સર્વિસ ધીમી હોવાને કારણે એપોઇન્ટમેન્ટ બુકિંગ ક્રેશ થવું જોઈએ નહીં. મેસેજ બ્રોકર નિષ્ફળ જાય તો પણ ડેટા સુરક્ષિત રહે તે સુનિશ્ચિત કરવા માટે અમે Outbox pattern નો ઉપયોગ કર્યો.
• Patterns ડોમેન (domain) મુજબ હોવા જોઈએ. Patterns નો અંધાધૂંધ ઉપયોગ કરશો નહીં. મેડિકલ ડાયગ્નોસિસ માટે મજબૂત consistency ની જરૂર હોય છે. દર્દીની સુરક્ષા માટે તમે eventual consistency પર આધાર રાખી શકતા નથી. જો તે તમારા audit trail ને તોડે છે, તો સંવેદનશીલ ક્લિનિકલ ડેટા માટે cache નો ઉપયોગ કરશો નહીં.
• DevOps એ પછીનો વિચાર નથી. Deployment, health checks, અને pipelines એ પ્રારંભિક ડિઝાઇનનો ભાગ છે. તમારે ખર્ચનો અંદાજ લગાવવો જોઈએ અને એવા components પસંદ કરવા જોઈએ જે ખરેખર તમારી જરૂરિયાતો પૂરી કરે.
પ્રોગ્રામર અને ડિઝાઇનર વચ્ચેનો તફાવત "શા માટે" માં છે.
એક પ્રોગ્રામર પૂછે છે: "હું આ કેવી રીતે કામ કરાવી શકું?" એક ડિઝાઇનર પૂછે છે: "આ ચોક્કસ સમસ્યા માટે આ સાચો ઉકેલ કેમ છે?"