خب همونطور که قبلا گفتم بصورت تک پاراگراف یا نوشته های کوتاه ترجمه شده که مطالب جالبی از این کتاب هست رو اینجا تکرار کنم و درموردش کمی فکر کنیم، ابتدا باید چند نکته رو برای کسایی که علاقه مند به خوندن این کتاب هستن بگم، برا تهیه این کتاب چیزی نمیگم حتما با یه سرچ راحت میتونین نسخه انگلیسی و فارسی رو پیدا کنید و این کتابی نیست که مثل روزنامه یا یه خبر تک باشه که در طول روز میخونی، باید بطور عمیق این کتاب رو خوند و برای هر بخش فکر ، تحلیل و تمرین کرد (بطور خلاصه باید اهمیت و وقت زیادی براش بزاری) بخاطر اینکه این کتاب قرار هست عادت های بدی رو که در طول این همه سال برای کد زدن داشتی رو عوض کنه پس اصلا کار آسونی نیست ! همونطور که نویسنده تو مقدمه به صراحت گفته کار خیلی سختی رو در پیش داری و اگر کسی هستی که تغییر برات سخته کتاب رو ببند و به زندگیت ادامه بده (به نظرم نمیتونه کار خیلی سخت یا غیر ممکنی باشه نویسنده اینطور نوشته تا مباحث رو خیلی جدی بگیریم و سر سری ازش نگذریم، اصلا درستش هم همینه اگه قراره که کتاب رو بخونیم و همون روال قبلی رو ادامه بدیم پس چرا اصلا وقت خودمونو میگیریم ؟ پس ترس به دل راه ندیم و تصمیم بگیریم که قراره تغییر کنیم، آتیشش کن بریم) خب بیشتر از این وقتو نگیرم و وارد بحث شیم.
(هنگامی که برای اولین بار در سال 1847 توسط Ignaz Semmelweis به پزشکان توصیه شد دستهای خود را بشویند، این توصیه به دلیل اینکه سر پزشکان خیلی شلوغ بود و وقت نداشتند میان ویزیت بیماران دستهای خود را بشویند رد شد.) به وضوح بیمار رئیس است. و با این وجود پزشک کاملاً باید از انجام عمل خودداری کند. چرا؟ زیرا پزشک بیشتر از بیمار از خطرات بیماری و عفونت اطلاع دارد. این که پزشک مطابق با خواست بیمار عمل کند (حتی اگر مجرمانه نباشد) غیرحرفه ای است. به همین ترتیب غیر حرفه ای است که برنامه‌نویسان به خواسته مدیرانی که ریسک ایجاد شلختگی‌ها را نمی‌فهمند تن در دهند.
در این قسمت یک مثال از رشته ی پزشکی آورده شده تا ما از زاویه ی دیگه ای به این موضوع نگاه کنیم و اهمیت چند مورد رو درک کنیم، اینجا متخصص که پزشک هست رو برای مثال آورده که بدون توجه به درست یا غلط بودن کار بخاطر وقت گیر بودن مسئله رد میکنه! این حس براتون آشناس نه ؟ خیلی از برنامه نویس ها وقتی پروژه ای رو بهشون سپرده میشه میخوان که زودتر تموم بشه و به همین دلیل از خیلی جهات موارد رو رعایت نمیکنن و یا برای خود من خیلی وقت ها پیش اومده که مشتری چون درک فنی نداره و فقط میخواد که زودتر محصول به دستش برسه میگه که مثلا من تا 20روز دیگه میخوام درصورتی که زمان بیشتری نیاز هست، حالا اینجا چند چالش پیش رو هست !
دو راه وجود داره زمانی که به این چالش ها برخورد کردیم :
- اول اینکه پروژه رو قبول کنیم و انجام بدیم هرچی که طرف خواسته و تمام! پول بزن به حساب و خداحافظ
به شخصه اصلا این راه رو نمیپسندم فرض کنید که انجام دادید و موفق شدید که پول رو بگیرید بعدش چی ؟ برای توسعه و پشتیبانیش فکری کردی ؟ به این فکر کردی که اصلا این پروژه قراره نماد کار تو باشه و مشتری هایی بعدی طبق همین اپلیکیشن ها سمتت بیان ؟
- دوم به طرف مقابل توضیح بدی (طرف مقابل ممکنه ارشد فنی مجموعه یا حسن ماست فروش باشه که چیزی از برنامه نویسی سر در نمیاره) امیدوارم حسن ها از دستم ناراحت نشن :) و قانعش کنی که این کار نیاز داره من وقت بیشتری بزارم چون واقعا نتیجه ی این پروژه برای من مهمه و میخوام که بهترین کار الان من بشه ، این روش ممکنه که با مخالفت طرف روبه رو شه و حتی اون پروژه رو ازتون بگیره اما من این روش رو می پسندم باید عادت کنیم که کاری رو اصول انجام بدیم و یا اصلا در غیر این صورت اصلا انجامش ندیم !
الان ممکنه تو ذهنتون باشه که انجامش بدم و بعدا بشینم سر فرصت کد هامو Refactor کنم که این مورد هم باز خودش جدا جای بحث داره.
خب تا اینجا بحث رو جمع میکنم و امیدوارم بعنوان اولین نوشته ام تو ویرگول تونسته باشم عملکرد مفیدی داشته باشم .
