Getting Real - یک کتاب استراتژیک خوب

[eshpilen]

توصیه میکنم این کتاب رو بخونید. حالا تونستید خورده خورده.
منکه دو سه روزه الان تا صفحهء 123 رسیدم.
نظرات جالب و مستند و مستدلی در این کتاب مطرح شده دربارهء استراتژی های کلی برنامه نویسی (Focus اصلی روی برنامه نویسی وب است، ولی خیلی مواردش رو میشه عمومی تر دونست) که خیلی از روشهای کلاسیک توسعه نرم افزار رو زیر سوال میبره و مردود میدونه. ضمنا چون ظاهرا این علاوه بر تئوری با پشتوانهء تجربه و موفقیت شرکت و برنامه نویسان برجسته ای هست، میشه گفت چیزهایی که ادعا کرده فقط تئوری و حرف نیستن و در عمل خودشون آزمون کردن.

دانلود: http://gettingreal.37signals.com/?freepdf

البته این کتاب رو مدیر سایت برنامه نویس معرفی کرده بود: http://www.barnamenevis.org/showthread.php?342652

کلا حرفهای جالب و آموزنده ای داره که بخش عمدهء اونها به تفکر و روش خودمم میشه گفت شباهت و نزدیکی زیادی داره. در خیلی موارد باهاشون موافقم. ولی نمیتونم بگم 100% و با تمام موارد.

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

[eshpilen]

برای اینکه دستتون بیاد یه شمه ای از بعضی مطالب این کتاب رو فهرست وار میذارم.
تیتر چندتا از بخشهایی که میخواستم ترجمه کنم:

The Three Musketeers - سه تفنگدار!
در این بخش توضیح میده که تیم ها و شرکتهای کوچک برای توسعهء یک پروژه بهتره با سه نفر شروع کنن و نه بیشتر. میگه که چرا عدد 3 یک عدد طلایی هست برای این کار و چرا انتخاب تعداد نفرات بیشتر اغلب درست نیست.

Be Yourself - خودتان باشید.
در این بخش میگه سعی نکنید ادای شرکتهای بزرگ رو دربیارید و تازه شرکتهای کوچک مزایای مهمی دارن که شرکتهای بزرگ ندارن و باید از این مزایا حداکثر استفاده رو ببرن.

Ignore Details Early On - در ابتدا جزییات را نادیده بگیرید.
در این بخش میگه در شروع کار نباید روی جزییات وقت و انرژی خودتون رو هدر کنید.
مثلا اینکه فلان چیز دقیقا چه رنگی باشه یا چند پیکسل اون طرف تر باشه یا 7 خط کد رو بکنید 4 خط و غیره.

It’s a Problem When It’s a Problem - هرچیزی وقتی یک مشکل است که براستی/درعمل یک مشکل شود.
اینم که یکی از چیزهایی که بنده بارها بخصوص در ارتباط با مبحث وسواس در بهینه سازی تکرار کردم.
میگه وقت و انرژی خودتون رو روی مشکلاتی که هنوز وجود ندارن هدر ندید و به اولویت ها و واقعیت های جاری و موارد کاربردی درحال حاضر بپردازید. خیلی از مشکلات هرگز در عمل پیش نخواهند آمد یا بعدها پیش میان و اون موقع فرصت و امکان برطرف کردن اونها وجود داره.
مثلا میگه:
Do you really need to worry about scaling to 100,000 users today if it will take you two years to get there?
«آیا واقعا لازم است امروز دربارهء گسترش مقیاس کاربرد برنامه به صدهزار کاربر نگران باشید اگر برای شما تا رسیدن به چنان شرایطی دو سال طول میکشد؟»

Start With No - با نه شروع کنید.
در این بخش میگه چرا نباید از ابتدا برنامه رو خیلی وسیع و با امکانات و جزییات خیلی زیاد درنظر گرفت. میگه نباید همینطور هرکس هر امکاناتی رو که پیشنهاد میکنه بگید بله و توی برنامه بگنجانید. البته این بحث یک مقدار پیچیده و ظریف هست که خودتون باید بخونید تا منظورش رو بهتر متوجه بشید. هرچی میگه با دلایل و ذکر نمونه و تجربهء خودشون و همچنین نقل قولهایی از برنامه نویسان و افراد دیگری میگه. میگه در ابتدا باید از امکانات هسته ای و اصلی و مهمترین و مفیدترین چیزها شروع کرد و تمام وقت و انرژی و منابع رو به اونها اختصاص داد تا یک نرم افزار با کیفیت بتونه ساخته بشه بجای اینکه یک چیزی با کیفیت کمتر یا نصفه و نیمه از آب دربیاد، و هر امکانات اضافی رو باید تنها درصورتیکه بحد واقعا زیادی مفید و لازم باشه به نرم افزار اضافه کرد و نه اینکه همینطور زرت و زرت هر ایده ای و درخواستی که مطرح میشه رو جزو برنامه قرار داد.
حالا اگر موافق نیستید روی این قضیه بیشتر میشه بحث و بررسی کرد و حداقل بنظر بنده میشه یک تعادل بهتری بدست آورد، چون شاید خیلی افراد در این زمینه بعکس دچار افراط و وسواس باشن.

Build something you can manage - چیزی بسازید که میتوانید آنرا مدیریت کنید (یا از پس آن بربیایید).
میگه بیخودی زیر قولها و تعهداتی که از توانایی برآوردن و تامین کردن طولانی مدت اونها مطمئن نیستید نرید.

Forget Feature Requests - درخواستهای امکانات جدید را فراموش کنید.
در این بخش هم بیشتر توضیح میده که چرا همینطور هرکس هر امکانات جدیدی رو که خواستار شد نباید اون رو قبول و به برنامه اضافه کرد و بهتره فرایند قبول این درخواستها و پیشنهادات خیلی سختگیرانه تر باشه.

Rinse and Repeat - آبکشی کنید و تکرار کنید.
در این بخش از این صحبت میکنه که توسعهء نرم افزار، بخصوص نرم افزار وب و تیمهای و شرکتهای کوچک، یک فرایند تدریجی و چندباره و تکاملیه و نباید از ابتدا انتظار داشت و سعی کرد که برنامه از همه جهت کامل و دقیق باشه و نیازی به کار مجدد و تغییرات و تکامل تدریجی نداشته باشه و از ابتدا همه چیز رو بشه پیشبینی و دقیقا طراحی و پیاده سازی کرد.

Wordsmiths - نویسنده ها
در این بخش میگه چرا کسانی که نویسندگان خوبی هستن بهتر از کسانی هستن که توانایی نویسندگی خوبی ندارن. میگه این توانایی در کار عملا خیلی جاها بدرد میخوره، حتی اگر طرف فقط وظیفهء برنامه نویسی یا طراحی رو داشته باشه. ضمنا نویسندهء خوب بودن با برنامه نویس خوب بودن ارتباط داره.
یک نقل قول در این بخش:
Good writing skills are an indicator of an organized mind which is capable of
arranging information and argument in a systematic fashion and also helping
(not making) other people understand things
میگه «مهارتهای نویسندگی خوب نشانهء یک ذهن سازمان یافته هستند که قادر است اطلاعات را مرتب کرده و به یک شکل سیستماتیک استدلال کند و همچنین به بقیهء مردم کمک کند تا چیزها را بفهمند»
منم بعضی وقتا گفتم که تعجب میکنم چطور بعضی افراد نمیتونن دوتا مطلب و سوال و چندتا جمله رو درست و دقیق و طبق اصول منطق و تخصص و علم درست/بیان کنن، و اونوقت برنامه نویسی میکنن!!
بنظرتون یه آدمی که نمیتونه درست حرف بزنه و از پس منطق و سازماندهی دوتا جمله و معنا برنمیاد میتونه برنامه نویس قوی ای باشه؟ آدمهایی که نمیتونن یک عنوان روشن و هوشمندانه و حرفه ای برای مطالب و تاپیک ها یا سوالات خودشون انتخاب کنن آیا میتونن برنامه نویس قوی ای باشن؟

Interface First - رابط نخست.
کلا دربارهء اینکه چرا اینترفیس برنامه ها رو باید اول طراحی کرد، یا درواقع یک نمونه و ماکت اولیه از رابط کاربری اونها رو، زیاد تاکید و صحبت کرده در این کتاب.

Epicenter Design - طراحی هم مرکز.
در این بخش میگه که چرا در طراحی باید ابتدا از اصلی ترین و ذاتی ترین و ضروری ترین امکانات شروع کرد و نه جزییات و امکانات جانبی تر. ابتدا از هسته و به سمت بیرون.

Context Over Consistency - زمینه مرجح بر یکدستی/سازگاری.
در این بخش بیان میکنه که نباید فکر کرد و اصرار داشت که همهء بخشهای یک برنامه باید لزوما از یک الگو و Template یکسان پیروی کنن؛ مثلا نباید فکر کرد که همهء صفحات یک الگوی یکسان/مشابه داشته باشن (مثلا اصرار داشته باشیم که کادر جستجو در تمام صفحات وجود داشته باشه). بلکه باید بیشتر معنا و هدف و کاربرد هر صفحه و نیاز واقعی کاربر رو مد نظر قرار داد.

One Interface - یک اینترفیس.
میگه مثلا اینترفس ادمین رو یک اینترفیس و بخش جداگانه از بقیهء اینترفیس و بخشهای برنامه قرار ندید و سعی کنید همه مشترک و نزدیک/درکنار هم باشن.

There’s Nothing Functional about a Functional Spec - هیچ چیزی عملیاتی در ارتباط با یک سند مشخصهء عملیاتی وجود ندارد.
توضیح میده که چرا Functional Spec ها نه تنها بی خاصیت هستن بلکه میتونن مضر و ضد بازدهی بهینه باشن.
یک نقل قول جالبی هم از لینوس توروالدز داره در این مورد.

منم اعتقاد دارم خیلی چیزها رو نمیشه یا بهینه نیست از ابتدا دقیقا پیشبینی و طراحی و برنامه ریزی کرد و بهتره با عمل پیش رفت. مثلا اعتقادی ندارم که باید تمام ساختار دیتابیس و جزییات دیگر یک برنامهء پیچیده/بزرگ رو از قبل دقیقا طراحی کرد. بنظرم موقع برنامه نویسی آدم خیلی چیزها رو بهتر میفهمه و چیزهایی پیش میان که از قبل نمیشه پیشبینی کرد.

خب من تا اینجاش رو خوندم. بقیش رو باید ادامه بدم!!
راستی توی این مواردی که لیست کردم بعضی بخشها رو هم اصلا ذکر نکردما. بیشتر اونایی که بنظرم مهمتر و جالبتر بودن گفتم.