وقتی یک تغییر کوچک، کل ساختار نرم‌افزار را تغییر می‌دهد

یکی از تجربه‌هایی که در طراحی و توسعه نرم‌افزار به دست آوردم، مربوط به سامانه فیش حقوقی آنلاین است که برای شرکت‌ها و سازمان‌ها طراحی کرده‌ام.

در این سامانه، مشتری می‌توانست اطلاعات چند هزار نفر از کارکنان را از طریق یک فایل Excel با قالب و ساختار مشخص، در مدت کوتاهی بارگذاری کند و فیش‌های حقوقی به‌صورت خودکار ایجاد شوند. کارکنان نیز می‌توانستند با ورود به پنل کاربری خود، فیش‌های حقوقی‌شان را مشاهده کنند.

در ابتدا، ساختار فایل Excel مشخص و ثابت بود و سیستم نیز بر اساس همان ساختار طراحی شده بود.

چند ماه بعد، از واحد حسابداری یکی از سازمان‌ها با من تماس گرفتند و گفتند که واحد فناوری اطلاعات سازمان، ساختار فایل Excel را تغییر داده است. فایل جدید دیگر ساختار ستونی قبلی را نداشت و به شکل ماتریسی ارائه می‌شد.

این تغییر برای واحد حسابداری مشکل بزرگی ایجاد کرده بود. آنها باید اطلاعات چند صد نفر را وارد سامانه می‌کردند و تبدیل دستی فایل جدید به ساختار قبلی عملاً بسیار دشوار و زمان‌بر بود. از طرفی، این تغییر از سوی سازمان و به‌صورت دستوری انجام شده بود و واحد حسابداری امکان مخالفت یا درخواست بازگشت به فرمت قبلی را نداشت.

پس از بررسی موضوع، تصمیم گرفتم به جای اینکه از آنها بخواهم اطلاعات را به فرمت قبلی تبدیل کنند، خود نرم‌افزار را با شرایط جدید سازگار کنم.

در ظاهر، فقط ساختار فایل Excel تغییر کرده بود؛ اما در عمل، این تغییر روی بخش‌های مختلف نرم‌افزار اثر می‌گذاشت و لازم بود قسمت‌هایی از منطق برنامه، ساختار داده‌ها و بخش‌های مرتبط با پردازش اطلاعات تغییر کنند.

در عین حال، یک مسئله مهم دیگر وجود داشت.

اطلاعات ماه‌های گذشته که با ساختار قبلی وارد سیستم شده بودند، نباید تحت تأثیر این تغییر قرار می‌گرفتند. کارکنان باید همچنان می‌توانستند فیش‌های ماه‌های گذشته خود را مشاهده کنند و اطلاعات قبلی نیز باید بدون مشکل حفظ می‌شد.

پس از انجام تغییرات، سیستم توانست ساختار جدید فایل را نیز شناسایی و پردازش کند و واحد حسابداری بدون نیاز به تبدیل دستی اطلاعات، به کار خود ادامه داد.

اما این پایان ماجرا نبود.

در طول زمان، تغییرات مشابه چندین بار اتفاق افتاد و هر بار تجربه جدیدی برای من ایجاد کرد. به مرور متوجه شدم که نمی‌توانم نرم‌افزار را فقط بر اساس شرایط امروز طراحی کنم. در دنیای واقعی، سازمان‌ها و فرآیندهای آنها تغییر می‌کنند و نرم‌افزار نیز باید تا حد امکان توانایی هماهنگ شدن با این تغییرات را داشته باشد.

این تجربه باعث شد در ادامه توسعه این محصول، رویکردم را تغییر دهم و نرم‌افزار را به شکلی انعطاف‌پذیرتر طراحی کنم تا ساختارها و شرایط مختلف بیشتری را پوشش دهد و تغییرات آینده، با کمترین وابستگی به تغییرات اساسی در برنامه قابل مدیریت باشند.

یکی از اهدافم این بود که مشتری برای هر تغییر کوچک، مجبور نباشد دوباره هزینه‌ای بابت تغییر نرم‌افزار پرداخت کند.

جالب اینکه مدتی بعد، حسابدار مجموعه به من گفت توانایی سیستم در تبدیل ساختار جدید و ماتریسی Excel به فیش حقوقی، توجه و تعجب مسئولان فنی بالاتر سازمان را نیز به دنبال داشته است.

درسی که این تجربه به من داد

این تجربه به من یاد داد که انعطاف‌پذیری نرم‌افزار چیزی نیست که فقط هنگام بروز مشکل به آن فکر کنیم؛ بلکه باید از مرحله طراحی به آن توجه داشته باشیم.

ممکن است یک نیاز در زمان شروع پروژه کاملاً مشخص و ثابت به نظر برسد، اما چند ماه یا چند سال بعد شرایط تغییر کند.

هر تغییر کوچکی هم الزاماً کوچک نیست. گاهی تغییر یک فرمت ورودی می‌تواند روی دیتابیس، منطق پردازش و بخش‌های مختلف نرم‌افزار اثر بگذارد.

به همین دلیل، یکی از چیزهایی که بعدها در طراحی نرم‌افزار بیشتر به آن توجه کردم این بود که تا حد منطقی، نرم‌افزار را به شکلی طراحی کنم که پذیرای تغییرات آینده باشد و برای هر تغییر کوچک، نیاز به بازنویسی بخش‌های اساسی سیستم وجود نداشته باشد.

در نهایت، یک تغییر اجباری که ابتدا برای مشتری مشکل ایجاد کرده بود، برای من به یک تجربه ارزشمند تبدیل شد؛ تجربه‌ای که در طراحی نسخه‌های بعدی همان محصول و محصولات دیگر نیز به کار آمد.