RSS

کیمیاگری

08 سپتامبر

در حال حاضر و با تموم شدن پروژه قبلیم ( که در آینده با تفصیل بیشتر ازش خواهم گفت ) مشغول کار بر روی یک نوع Code Generator شدم ( جزئیاتش خارج از حوصله این پست است ).
پس از مشخص شدن حدودی صورت پروژه شروع کردم با تمام وجود کلنجار رفتن برای بیرون کشیدن یک ساختار کامل، جامع، مانع و شامل برای بنا کردن کد، یه چارچوب که بتونه تا جای ممکن امکاناتی که به ذهنم می‌رسید رو پشتیبانی‌ کنه، در واقع همون Design که تو دانشگاه بهمون یاد دادند و اینهمه روش تاکید داشتن.

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

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

خوب، با کمی‌ تامل بیشتر در رابطه با این موضوع، میبینیم که چنین پیشامدی واقعا محتمل مینمود. تلاش من در قاعده و قانون بخشیدن به چیزی که ازش شناخت خوبی‌ ندارم مسلما نمیتونه من رو به جایی‌ برسونه. در واقع میشه گفت «کاری که ما با نوشتن یک برنامه صدد انجام اون هستیم مثل ساختن یه ماده شیمیایی جدیده، راه برای ما مشخص نیست، نمی‌دونیم دقیقا می‌خوام به کجا برسیم و راه مناسب کدومه. تنها کاری که می‌تونیم بکنیم مرحله به مرحله جلو رفتن و Refactor کردن دائمی کد، در کنار نگاه داشتن سابقه از کارهای قبلی‌ با استفاده از Unit-Test هاست»

اشتیاق به داشتن یه سند جامع که همه نکات سیستم در اون قرار داره و ترس ما از عوض کردن ناگهانی و وسیع کد رو می‌شه دو تا از عمده‌ترین دلایلی دونست که پیشروی توی چنین مسیری رو سخت کنه. اما این حقیقتی است. ما چطور می‌خوایم شناختی‌ همه جانب از چیزی داشته باشیم که تا حالا باهاش روبرو نشدیم. کتاب Pragmatic Programmer این نکته رو این‌چنین بیان می‌کنه که : There are no final decisions . همواره باید آماده تغییر بود. در نظر نگرفتن این مسائل در نهایت نتیجش می‌شه هدر رفت وقت و هزینه. علاوه بر این، کد‌های به درد نخوره زیادی به سیستم اضافه می‌شه که صرفاً پیچیدگی‌ برنامه و شانس برای Duplication رو بالا میبره، اما همونجا می‌مونن چون میگیم «شاید یه روزی به درد بخورن».

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

یکی‌ از مقالات پر مغزی که در این زمینه وجود داره و خوندنش پیشنهاد می‌شه Stop Over-engineering نام داره. خیلی‌ کوتاه و مختصره، اما حرف‌های بسیار زیادی برای گفتن و شنیدن داره. در واقع برسی‌ تکنینکی همین حرف‌هاییست که من در اینجا زدم. یه نگاه بندازید.

 
بیان دیدگاه

نوشته شده توسط در سپتامبر 8, 2013 در Fa, Software Engineering

 

برچسب‌ها: , , ,

پاسخی بگذارید

در پایین مشخصات خود را پر کنید یا برای ورود روی شمایل‌ها کلیک نمایید:

نشان‌وارهٔ وردپرس.کام

شما در حال بیان دیدگاه با حساب کاربری WordPress.com خود هستید. بیرون رفتن / تغییر دادن )

تصویر توییتر

شما در حال بیان دیدگاه با حساب کاربری Twitter خود هستید. بیرون رفتن / تغییر دادن )

عکس فیسبوک

شما در حال بیان دیدگاه با حساب کاربری Facebook خود هستید. بیرون رفتن / تغییر دادن )

عکس گوگل+

شما در حال بیان دیدگاه با حساب کاربری Google+ خود هستید. بیرون رفتن / تغییر دادن )

درحال اتصال به %s

 
%d وب‌نوشت‌نویس این را دوست دارند: