پس از جنگ جهانی دوم، ژاپنیها مفهومی تحت عنوان Kaizen را ابداع کردند که این واژهٔ یک کلمهای توانست آیندهٔ ژاپن و بالتبع دنیا را دستخوش تغییرات شگرفی کند! اگر بخواهیم این واژه را به صورت تحتالفظی به زبان فارسی برگردان کنیم، با معادلی همچون «بهبود مستمر» روبهرو خواهیم شد (Kai به معنی «تغییر» میباشد و Zen هم به معنی «خوب» است.) آنچه در این پست قصد داریم مورد بررسی قرار دهیم این است که به چه شکلی میتوان از کایزن ایده گرفت و در صنعت توسعهٔ نرمافزار به موفقیت دست یافت.
از جمله شرکتهای بزرگی که از کایزین در مدیریت و توسعهٔ کسبوکار خود استفاده نموده و هماکنون هم آن را به کار میبندند میتوان به تویوتا و کَنُن اشاره کرد. مکتب کایزن در مقابل فلسفهٔ اکثر کشورهای غربی قرار دارد که در آن گفته میشود «تا زمانی که چیزی خراب نشده است، نیازی به تعمیر آن نیست!» و این در حالی است که کایزن دقیقاً عکس این را عمل میکند بدین صورت که حتی اگر در کار خود مشکلی ندارید، برای بهبود و اِعمال تغییرات مثبت در آن تلاش کنید چرا که اگر این کار را نکنید، از آنهایی که این سیاست را دنبال میکنند عقب خواهید ماند. به طور خلاصه، چنانچه بخواهیم کایزن را به صورت خیلی ساده توضیح دهیم، میتوان گفت که:
کایزن به سازوکاری گفته میشود که در آن تغییرات کوچک به منظور بهبود عملکرد، اثربخشی زیادتر، راندمان بیشتر و در عین حال جلوگیری از اتلاف وقت، نیرو و انرژی کمتر اِعمال میشود.
در کشور مترقی ژاپن، کایزن فقط به کسبوکار محدود نشده بلکه زندگی خصوصی افراد، روابط بین آدمها و ... را نیز دستخوش تغییر ساخته است به طوری که میتوان گفت ژاپنیهایی که پیرو مکتب کایزن هستند، یکسری استاندارد خواه در کسبوکار و خواه در زندگی خصوصی خود تعریف کرده و دائماً در تلاش به منظور ارتقاء و بهبود آن استاندارها هستند (در همین راستا، توصیه میکنیم به مقالهٔ چگونه میتوانیم با خلق یکسری ارزشها و پایبندی به آنها، فرایند تصمیمگیری خود را تسهیل کنیم؟ مراجعه نمایید.)
چگونه از کایزین در کدنویسی استفاده کنیم؟
در واقع، آنچه در میان اکثر برنامهنویسان تازهکار مشاهده میشود این است که پس از فراگیری یکسری اصول، دستورات، مفاهیم و ... در زبان برنامهنویسی مد نظر خود، دیگر تلاش چندانی برای کسب علم بیشتر در حوزهٔ مربوطه نمیکنند! به طور مثال، بسیاری از دولوپرهای وب را میبینیم که کماکان از نسخههای قبلی زبان HTML استفاده میکنند و این در حالی است که شاهد تغییرات شگرفی در آخرین نسخه از این زبان (HTML5) شاهد هستیم که اگر این گروه از طراحان بتوانند خود را با تغییرات صورت گرفته در این نسخه تطبیق دهند، دست ایشان در طراحی وب خیلی بیشتر باز خواهد شد.
به عنوان مثالی دیگر، میتوان به عدم کامنتگذاری در اسکریپتها، کدنویسی به سبک اسپاگتی، نامگذاری متغیرها، متدها و کلاسها بدون توجه به ماهیت آنها اشاره کرد. حال ممکن است این سؤال برای کسانی که به این صورت کدنویسی میکنند پیش بیاد که «وقتی قرار نیست کسی کدهای اپلیکیشن ما را ببیند، پس چه لزومی دارد که تمیز کدنویسی کنیم؟» که در پاسخ به این پرسش میتوان به یکی از نقلقولهای استیو جابز استناد کرد که میگفت:
اون طرف از یک کمد دیواری که رو به دیوار هست رو هم باید به گونهای طراحی و رنگآمیزی کرد که اگه روزی کسی اساسکشی داشت و پشت آن کمد دیواری رو دید، شکه نشود!
با همین استراتژی بود که وی کامپیوترهای مکینتاش را به گونهای روانهٔ بازارهای جهانی کرد که علاوه بر زیبایی ظاهری، زیبایی درونی هم داشتند و همین مسئله منجر به ربودن گوی سبقت از رقبای اپل گشت.
قضیه در برنامهنویسی هم دقیقاً به همین صورت است. درست است که احتمالاً اسکریپتهایی که مینویسیم قرار است فقط و فقط توسط خودمان ویرایش شوند (که البته در بسیاری از مواقع هم این طور نیست)، اما فرض را بر این بگذاریم که ممکن است روزی پیش بیاد که یک برنامهنویس دیگر قرار باشد تا کدهای ما را ویرایش کند و آنجا است که اهمیت کدنویسی اصطلاحاً تمیز خود را به خوبی نشان خواهد داد. اگر بخواهیم از امروز کایزن را در کدنویسی به کار بندیم، با کار خیلی دشواری روبهرو نخواهیم بود زیرا همانطور که پیش از این توضیح دادیم، کایزن اصلاً به معنی تغییرات بزرگ نیست بلکه بدان معنا است که به مرور زمان سعی کنیم تمیزتر، اصولیتر و به طور کلی حرفهایتر کد بزنیم که این مهم فقط با یکسری تغییرات کوچک در طول زمان عملی خواهد شد.
علاوه بر بهبود مستمر، یکی دیگر از اصول مکتب کایزن جلوگیری از هدر رفتن وقت و انرژی است اما سؤال اینجا است که چگونه میتوان این اصل مهم کایزن را در برنامهنویسی هم اِعمال کرد؟ که برای روشن شدن مسئله، ابتدا مثالی میزنیم. فرض کنیم در حال توسعهٔ اپلیکیشنی هستیم که در آن یک اسکریپت را بارها و بارها باید مورد استفاده قرار دهیم. اگر بخواهیم این اسکریپت را که ممکن است هرچند کوتاه هم باشد هر دفعه بازنویسی کنیم، این کار منجر به اضافه شدن به حجم کدها، اتلاف وقت و مهمتر از همه ویرایش دشوار آن اسکریپت در آینده خواهد شد چرا که در صورت نیاز به اِعمال یک تغییر کوچک در اسکریپت خود، باید به هر تعداد که از آن اسکریپت در برنامه یا اپلیکیشن خود استفاده نمودهایم، دست به ویرایش کدها بزنیم.
حال اگر بخواهیم از اصل جلوگیری از هدر رفتن وقت و انرژی کایزن در فرآیند توسعهٔ نرمافزار استفاده کنیم، به سادگی خواهیم توانست تا اسکریپتهای تکراری را در قالب کلاسها و متدهای مختلف تعریف کرده و هر کجا که نیاز داشتیم، یک آبجکت جدید از روی آن کلاس ایجاد نموده و از ویژگیهای آن کلاس و بالتبع متدهای مربوط به آن استفاده کنیم که در این صورت حتی اگر اسکرپیت ما نیاز به تغییر داشته باشد، به سادگی خواهیم توانست تا کلاس مذکور را ویرایش نموده و بدون نیاز به کدنویسی بیشتر و اتلاف وقت، تغییرات صورت گرفته روی هر تعداد آبجکتی که از روی اسکریپت مربوطه ساخته باشیم اِعمال خواهد شد.
اینها فقط مثالهایی بودند از حوزههایی در برنامهنویسی که میتوان با به اصطلاح کایزنیزه کردن آنها و مسلماً ایجاد یک فرهنگ بهبود مستر در کدنویسی خود، مهارتهای کدنویسیمان را ارتقاء بخشیم. به طور خلاصه، دولوپری که فرهنگ کایزن در وی نهادینه شده باشد، خواه دولوپر فرانتاند باشد و خواه دولوپر بکاند، کسی است که موارد زیر را رعایت میکند:
- یادگیری دائمی در مورد فناوریهای مورد استفادهٔ خود
- بهبود سورسکد از دید پرفورمنس (راندمان)
- عدم پیروی از کدنویسی به سبک اسپاگتی
- نامگذاری اصولی متغیرها، کلاسها و متدها
- استفادهٔ بهینه از شیئگرایی در توسعهٔ نرمافزار
- در تعامل بودن با سایر دولوپرها و انتقادپذیری و تلاش در جهت رفع نقاط ضعف
- مشارکت در پروژهای اپنسورس به منظور بهبود آنها
- خلاقیت به خرج دادن هم در طراحی فرانتاند و هم در کدنویسی بکاند
- بازخورد گرفتن از کاربران و اِعمال نظرات ایشان روی اپلیکیشن و ...
حال نوبت به نظرات شما میرسد. فکر میکنید با دنبال کردن چه استراتژیهای دیگری میتوان مفهوم ژاپنی کایزن را در توسعهٔ نرمافزار نیز پیادهسازی کرد؟ نظرات، دیدگاهها و تجربیات خود را با سایر کاربران سکان آکادمی به اشتراک بگذارید.