• 0 رای - 0 میانگین
  • 1
  • 2
  • 3
  • 4
  • 5
Getting Real - یک کتاب استراتژیک خوب
#1
توصیه میکنم این کتاب رو بخونید. حالا تونستید خورده خورده.
منکه دو سه روزه الان تا صفحهء 123 رسیدم.
نظرات جالب و مستند و مستدلی در این کتاب مطرح شده دربارهء استراتژی های کلی برنامه نویسی (Focus اصلی روی برنامه نویسی وب است، ولی خیلی مواردش رو میشه عمومی تر دونست) که خیلی از روشهای کلاسیک توسعه نرم افزار رو زیر سوال میبره و مردود میدونه. ضمنا چون ظاهرا این علاوه بر تئوری با پشتوانهء تجربه و موفقیت شرکت و برنامه نویسان برجسته ای هست، میشه گفت چیزهایی که ادعا کرده فقط تئوری و حرف نیستن و در عمل خودشون آزمون کردن.

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

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

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

حالا من همینطور که میخوندم یک بخشهایی رو جدا کرده بودم که بعدا ترجمه کنم بذارم، ولی دیدم حجمش زیاد شد و بیشتر کتاب مطالب مفید و ارزشمندی هست درکل، بنابراین از ترجمه منصرف شدم چون وقتش رو ندارم.
  پاسخ
تشکر شده توسط : admin Y.P.Y oia Bojbaj
#2
برای اینکه دستتون بیاد یه شمه ای از بعضی مطالب این کتاب رو فهرست وار میذارم.
تیتر چندتا از بخشهایی که میخواستم ترجمه کنم:

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
میگه «مهارتهای نویسندگی خوب نشانهء یک ذهن سازمان یافته هستند که قادر است اطلاعات را مرتب کرده و به یک شکل سیستماتیک استدلال کند و همچنین به بقیهء مردم کمک کند تا چیزها را بفهمند»
منم بعضی وقتا گفتم که تعجب میکنم چطور بعضی افراد نمیتونن دوتا مطلب و سوال و چندتا جمله رو درست و دقیق و طبق اصول منطق و تخصص و علم درست/بیان کنن، و اونوقت برنامه نویسی میکنن Big Grin
بنظرتون یه آدمی که نمیتونه درست حرف بزنه و از پس منطق و سازماندهی دوتا جمله و معنا برنمیاد میتونه برنامه نویس قوی ای باشه؟ آدمهایی که نمیتونن یک عنوان روشن و هوشمندانه و حرفه ای برای مطالب و تاپیک ها یا سوالات خودشون انتخاب کنن آیا میتونن برنامه نویس قوی ای باشن؟

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

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

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

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

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

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

خب من تا اینجاش رو خوندم. بقیش رو باید ادامه بدم!!
راستی توی این مواردی که لیست کردم بعضی بخشها رو هم اصلا ذکر نکردما. بیشتر اونایی که بنظرم مهمتر و جالبتر بودن گفتم.
  پاسخ
تشکر شده توسط : Y.P.Y admin hosseintdk775 oia Bojbaj
#3
منم این کتاب رو خوندم کتاب خوبی هست. البته کامل نخوندم تا وسطاش خوندن بودم . حدود دو سال پیش بود.

البته تجربه به من میگه که سعی کنید برای خودتون یک هسته داشته باشید. فرقی نمی کنه چی باشه می تونه یه فریم ورک باشه می تونه هسته خودتون باشه. نیازهاتون رو با سلیقه خودتون توش بکونجونید. نمی دونم توی این کتاب بود یا کتاب دیگه. اما گفته بود هر نرم افزار موفقی نیاز به یک هسته داره هر چه هسته موفقتر باشه نرم افزار موفقتر خواهد بود. من برای خودم یک هسته دارم. این هسته رو در طول برنامه نویسی که داشتم ۴ بار بازنویسی مجدد ( حتی شده از اول نوشتم چون اون چیزی که می خواستم نشده بود) اما الان ازش راضی هستم . نیازهام رو سریع جواب میده. ( البته خودش شامل doctrine و zf و extjs به عنوان لایه نمایش هست) که با ادغام اینها تونستم به ابزاری برسم که سریعتر به نیازهام من رو برسونه.
با وسواس در بهنیگی هم باهات موافقم توی گذشته خیلی روی بهینگی وسواس داشتم ( ماله خیلی وقت پیشه) اما بعدش دیدم فایده ای نداره بیشتر تمرکز روی پیاده سازی و روشهایی برای پیاده سازی سریعتر کردم. اما این دلیل نمیشده که از تجربیاتی که قبلا در زمینه بهینه سازی که در عمل بهش خوردم استفاده نکنم.
یک چیزی دیگه ای هم که خودم رعایت می کنم این هست که وقتی که برنامه می نویسم اول از همه می خوام به هدفم برسم. سعی می کنم اون چیزی رو که نیاز دارم رو پیاده کنم. ممکنه یک سری جاها بر حسب تجربه یا هر چیز دیگه ای بدونم این قسمت ممکنه دچار مشکل بهینگی بشه یا ممکنه دچار مشکل امنیتی بشه یا حتی ممکنه توی بعضی از موارد دچار اخطار بشه با گذاشتن یک todo به کار خودم ادامه میدم تا به هدف برسم و بعد بر می گردم و به اون todo ها یک نگاهی میندازم ( اکثر ادیتورها از todo پشتیبانی می کنن.)
توی شرکتهای کوچیک باید دنبال سریعتر توسعه دادن با حداقل نیرو بود.
  پاسخ
تشکر شده توسط : vejmad oia
#4
من فک می کنم این کتاب رو من نوشتم Smile
  پاسخ
تشکر شده توسط :
#5
به یکی گفتم تا وقتی به یه مشکلی بر نخوردی روش وقت نذار. انگار بهش رکیک ترین حرف دنیا رو زدم Big Grin
  پاسخ
تشکر شده توسط :


پرش به انجمن:


کاربران در حال بازدید این موضوع: 1 مهمان