در مورد مرتب‌سازی (tidying)
سوال اصلی این است: “من می خواهم کدی را تغییر بدهم ولی ساختار کد به گونه‌ای است که تغییر آن دشوار است. آیا ابتدا باید کد را مرتب کنم؟” بِک ادامه می‌دهد “من در مورد بازسازی (refactor) کدهای بزرگ صحبت نمی‌کنم. من در مورد تقسیم کدهای بزرگ و یک‌تکه به مایکروسرویس‌ها(microservice) و تصمیم‌های بزرگ و باشکوه در مقیاس بزرگ صحبت نمی‌کنم. من در مورد رابطه‌‌ی خودم با خودم صحبت می‌کنم. آیا برای خودم این ارزش قائل هستم که کارم را راحت‌تر کنم؟”با این اوصاف، برنامه نویسی نباید کاری اضطراب آور، دلهره‌آور و اعتماد به نفس خراب‌کن باشد. در نتیجه، قبول یک مساله‌ی پیچیده و شکستن آن به مساله‌های کوچکتر که درک آنها آسان‌تر است، عادت بی‌نهایت مفیدی است. او می‌گوید”اصطلاحی است که تقریباً ده سال پیش آن را پیشنهاد کردم: – MCETMEC تغییر را آسان کنید و بعد تغییر آسان را انجام دهید (Make the Change Easy Then Make the Easy Change).آسان کردن تغییر، قلمروی اصلی طراحی نرم افزار است. بنابراین به جای اینکه بخش‌های سخت و پیچیده را تغییر دهید که برای انجام آن هم مجبورید به صورت همزمان ۱۰۰ جای سیستم را تغییر دهید، می‌توانید ابتدا کدها را مرتب کنید، هزینه ایجاد همه آن تغییرات را کم کنید و سپس یک تغییر آسان را انجام دهید.”
در توسعه نرم‌افزار، زمانی‌که از یک ایده (مثلا”من به یک دکمه در سیستم برای ویرایش اطلاعات نیاز دارم”) به تغییر(UX، گردش کار و بک‌اند (backend) پشت آن) می رسیم، رفتار سیستم یعنی ویژگی‌های قابل مشاهده بیرونی آن -را تغییر می‌کنیم. تغییر در رفتار برنامه معمولا باعث ایجاد چرخه‌ای می‌شود که در آن، پیاده‌سازی هر ویژگی جدید باعث تولید مثل و تولد ویژگی‌های جدیدتری می‌شود. از سوی دیگر یک مسیر موازی و پنهان نیز وجود دارد که بخش ساختاری نرم‌افزار است (شبیه به کوه یخی که قسمت‌هایی از آن در زیر آب پنهان است). یکی از نکات زیبا و قشنگ در اینجا این است که ساختار نیز به‌تنهایی می‌تواند برای کارهای قابل انجام در سیستم، ایده‌‌هایی را پیشنهاد کند. و اگر بتوانید تمام این حلقه‌های بازخورد را با هم اجرا کنید، می‌توانید به سرعت کشف کنید که چگونه نرم‌افزار شما می‌تواند ارزش بیشتری خلق کند.
در چنین شرایطی ممکن است اختلالاتی هم رخ دهد. برخی از سبک‌های توسعه (development styles) روی حلقه “ایده → رفتار → ایده” تمرکز می کنند که باعث می‌شود دور باطلی ) از پیاده سازی ویژگی‌ها بدون توجه به ساختار سیستم ایجاد گردد. (مترجم؛ چرخ همستر یا دور باطل به فعالیتی گفته می‌شود که با انجام آن، شخص همیشه مشغول است اما هرگز به دستاورد مهم و ارزشمندی دست پیدا نمی‌کند و از سوی دیگر پایانی نیز برای آن فعالیت وجود ندارد.)
یکی دیگر از اختلالات، زمانی رخ می‌دهد که قبل از هر گونه پیاده‌سازی، تمام تلاش‌ها صرف تهیه‌ی یک طراحی کامل و بی‌نقص می‌شود (طراحی بزرگِ قبل از پیاده‌سازی، سلام! (Big Design Upfront)) در پی این تلاش‌ها، ساختارهای زیبا و خوش ساخت زیادی ایجاد می‌شوند در حالی که هیچ کاربرد و اهمیتی در پیاده‌سازی رفتارهای مورد نیاز کاربران ندارند. این روش سرمایه‌گذاری روی ساختارها، شما نه‌تنها بازده و منفعتی از سرمایه‌گذاری خود کسب نمی‌کنید بلکه بازخوردها را نیز به تاخیر می‌اندازید.
کنت بک طرفدار و مدافع این موضوع است که یک تکرار ( iteration) سریع باید در تمام حلقه‌های بازخورد بالا وجود داشته باشد. شما باید بتوانید ایده‌ها را به سرعت امتحان کنید، ساختار را به شکلی که برای رفتار جدید مناسب‌تر است تغییر دهید و سپس تغییر رفتار را کامل کنید و به پایان برسانید (گاهی تغییرات طراحی باعث پیشنهاد شدن ایده‌های جدیدی برای سیستم می‌گردد و شما را به مسیر جدیدی هدایت می کند). توانایی انجام این تغییرات در قالب بخش‌ها و تکه‌های کوچک است که ارزشی فوق العاده خلق می‌کند. (مترجم؛ کنت بک اعتقاد دارد پروژه‌ها باید به صورت بخش‌ها و تکه‌های کوچک انجام شوند و درست مانند رانندگی روی یخ، ذره ذره پیش رفت.)
گزیده:
پیشنهاد می‌کنم ۱۰ تا ۲۰ درصد از کل زمان توسعه خود را صرف سرمایه‌گذاری [روی برنامه‌نویسی استراتژیک] کنید. این زمان آن قدر کم است که تأثیر چندانی بر برنامه‌‌ریزی‌ها ندارد، اما آن قدر بزرگ است که بتواند به مرور و در طول زمان، نتایج قابل‌توجهی به بار آورد.»
از کتاب فلسفه طراحی نرم افزار نوشته‌ی جان اوسترهات،
دیدگاهتان را بنویسید