Gitab logo Gitab
GitHub

فصل اول - یک فلسفۀ عمل‌گرایانه

این کتاب دربارهٔ شماست.
اشتباه نکنید؛ این مسیر شغلی شماست و مهم‌تر از آن، موضوع ۱، این زندگی شماست. شما صاحب آن هستید. این‌جا هستید، چون می‌دانید می‌توانید تبدیل به یک توسعه‌دهندۀ بهتر شوید و به دیگران نیز کمک کنید بهتر شوند. شما می‌توانید یک برنامه‌نویس عمل‌گرا شوید.

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

کلید دیگر موفقیت آن‌ها این است که برنامه‌نویسان عمل‌گرا مسئولیت همۀ کارهای خود را می‌پذیرند؛ موضوعی که آن را در موضوع ۲: گربه سورس‌کدم را خورد بررسی می‌کنیم. چون مسئولیت‌پذیرند، برنامه‌نویسان عمل‌گرا بی‌تفاوت نمی‌نشینند و نمی‌گذارند پروژه‌هایشان بر اثر بی‌توجهی فروبپاشد. در موضوع ۳: آنتروپی نرم‌افزار توضیح می‌دهیم که چگونه پروژه‌هایتان را در وضعیت سالم و پاکیزه نگه دارید.

بیشتر مردم با تغییر دست و پنجه نرم می‌کنند؛ گاهی به دلایل منطقی، و گاهی به‌خاطر اینرسی ساده. در موضوع ۴: سوپ سنگی و قورباغهٔ آب‌پز رویکردی برای آغاز تغییر بررسی می‌کنیم و در کنار آن، حکایت هشداردهندۀ دوزیستی را می‌آوریم که خطر تغییر تدریجی را نادیده گرفت.

یکی از مزایای درک کردن «متن» کاری که انجام می‌دهید این است که مشخص می‌شود نرم‌افزار شما باید تا چه حد خوب باشد. گاهی نزدیک به کمال، تنها گزینه است؛ اما اغلب پای مصالحه‌ها و انتخاب بین کیفیت‌ها در میان است. این موضوع را در موضوع ۵: نرم‌افزار به‌اندازۀ کافی خوب بررسی می‌کنیم.

طبیعتاً برای انجام همۀ این‌ها باید پایۀ گسترده‌ای از دانش و تجربه داشته باشید. یادگیری فرایندی مداوم و پیوسته است. در موضوع ۶: پرتفوی دانشتان چند راهکار برای حفظ شتاب یادگیری مطرح می‌کنیم.

در نهایت، هیچ‌کدام از ما در خلأ کار نمی‌کنیم. همۀ ما زمان زیادی را صرف تعامل با دیگران می‌کنیم. موضوع ۷: ارتباط برقرار کنید! روش‌هایی را فهرست می‌کند که به کمک آن‌ها می‌توانیم این کار را بهتر انجام دهیم.

برنامه‌نویسی عمل‌گرا از فلسفۀ «تفکر عمل‌گرایانه» سرچشمه می‌گیرد. این فصل بنیان‌های آن فلسفه را بنا می‌گذارد.

موضوع ۱ — زندگی توست

من در این دنیا نیامده‌ام که مطابق انتظارات تو زندگی کنم،
و تو هم در این دنیا نیامده‌ای که مطابق انتظارات من زندگی کنی.
— بروس لی

این زندگی توست. تو مالک آن هستی. تو آن را هدایت می‌کنی. تو آن را می‌سازی.

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

و پاسخی که همیشه به آن‌ها می‌دهیم یکی است:

«چرا نمی‌توانی تغییرش بدهی؟»

توسعهٔ نرم‌افزار باید در صدر فهرست مشاغلی باشد که در آن‌ها اختیار فراوان دارید.
مهارت‌های ما مورد تقاضا است. دانش ما مرزهای جغرافیایی را پشت سر می‌گذارد.
می‌توانیم به‌صورت دورکار کار کنیم.
درآمد خوبی داریم.
واقعاً می‌توانیم تقریباً هر کاری را که بخواهیم انجام دهیم.

اما به دلایلی، توسعه‌دهندگان اغلب در برابر تغییر مقاومت می‌کنند.
در لاک خود فرو می‌روند و امیدوارند اوضاع بهتر شود.
با بی‌تفاوتی نگاه می‌کنند که مهارت‌هایشان قدیمی می‌شود و از شرکت شکایت می‌کنند که آن‌ها را آموزش نمی‌دهد.
به تبلیغاتی دربارهٔ مکان‌های عجیب‌وغریب روی اتوبوس نگاه می‌کنند و بعد در باران سرد پیاده می‌شوند و به سر کار می‌روند.

و حالا، مهم‌ترین نکتهٔ این کتاب:

نکته ۳

تو اختیار داری — تو عامل تغییر هستی

محیط کارت مزخرف است؟ کارت خسته‌کننده است؟ سعی کن درستش کنی.
اما تا ابد تلاش نکن.

همان‌طور که مارتین فاولر می‌گوید:
«یا سازمانت را تغییر بده، یا سازمانت را تغییر بده.»

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

می‌خواهی دورکاری کنی؟
پرسیده‌ای؟
اگر جوابشان «نه» است، کسی را پیدا کن که «بله» بگوید.

این صنعت فرصت‌های فوق‌العاده‌ای در اختیار تو می‌گذارد.
فعال باش و از آن‌ها استفاده کن.

بخش‌های مرتبط

موضوع ۲ — گربه کد من را خورد

برخی افراد همیشه برای همه‌چیز بهانه دارند.

می‌گویند:
«دیشب دیر خوابیدم، نتوانستم تست بنویسم.»
«ابزار خراب بود، کارم عقب افتاد.»
«فلانی وظیفه‌اش را انجام نداد، پس من هم گیر کردم.»

اما برنامه‌نویس عمل‌گرا چنین نیست.

برنامه‌نویسان عمل‌گرا برای تمام کارهایی که انجام می‌دهند مسئولیت کامل می‌پذیرند.
آن‌ها بهانه نمی‌آورند.
آن‌ها شرایط را مقصر نمی‌کنند.
آن‌ها شکست را گردن دیگران نمی‌اندازند.

اگر چیزی خراب است، درستش می‌کنند.
اگر چیزی مبهم است، آن را شفاف می‌کنند.
اگر کاری مشکل است، راهی برای انجام دادنش پیدا می‌کنند.
اگر چیزی غیرممکن است، گزینه‌ای جایگزین می‌سازند.

بهانه آوردن باعث حل‌شدن هیچ مشکلی نمی‌شود—فقط باعث می‌شود دیگران نتوانند روی تو حساب کنند.

وقتی بهانه می‌آوری، این پیام را منتقل می‌کنی که تو قابل اعتماد نیستی، مسئول نیستی، و نمی‌توانی بر خروجی کار کنترل داشته باشی.

و مهم‌تر از همه، بهانه آوردن در نهایت به خودت آسیب می‌زند:
اعتماد دیگران کم می‌شود، کیفیت کار پایین می‌آید، و فرصت‌ها از دست می‌روند.

برنامه‌نویس عمل‌گرا، در مقابل، این‌طور فکر می‌کند:

نکته ۴

بهانه نیاور — مسئولیت را کامل بپذیر

وقتی مسئولیت را می‌پذیری،
دیگران هم به تو اعتماد می‌کنند،
و تو نیز کنترل بیشتری بر نتایج پیدا می‌کنی.

بخش‌های مرتبط

موضوع ۳ — آنتروپی نرم‌افزار

در علوم فیزیک، آنتروپی یعنی «گرایش طبیعی سیستم‌ها به‌سمت بی‌نظمی».
اگر انرژی صرف نکنید تا چیزی را مرتب نگه دارید، به‌طور طبیعی به سمت آشفتگی می‌رود.

در نرم‌افزار هم همین اتفاق می‌افتد.

اگر حواس‌تان نباشد، اگر بی‌توجهی کنید، اگر «فقط همین یک بار» یک میان‌بُر بزنید،
پروژه‌تان آرام‌آرام شروع به پوسیدن می‌کند.

فروپاشی نرم‌افزار معمولاً از یک چیز کوچک شروع می‌شود:

همین «چیزهای کوچک» مثل یک پنجرهٔ شکسته در یک ساختمان هستند.
اگر درستشان نکنید، پیام واضحی منتقل می‌شود:
«اینجا کسی اهمیت نمی‌دهد.»

و از این لحظه، فروپاشی سریع‌تر و سریع‌تر می‌شود.

برنامه‌نویس عمل‌گرا اجازه نمی‌دهد این زوال آغاز شود.

او نشانه‌های بی‌نظمی را به‌موقع تشخیص می‌دهد و بلافاصله درستشان می‌کند:

اگر بخشی از سیستم بوی بد بدهد،
اگر چیزی «درست به‌نظر نرسد»،
اگر احساس کنید چیزی دارد از کنترل خارج می‌شود،

این حس را جدی بگیرید.
این همان آنتروپی است که دارد وارد سیستم می‌شود.

برنامه‌نویس عمل‌گرا فعالانه جلوی آن را می‌گیرد،
نه اینکه منتظر فروپاشی کامل شود و بعد به فکر تعمیر بیفتد.

نکته ۵

پنجره‌های شکسته را همان لحظه تعمیر کن

هرچقدر دیرتر،
هزینهٔ بیشتر،
کیفیت کمتر،
و انگیزهٔ تیم پایین‌تر می‌آید.

بخش‌های مرتبط

موضوع ۴ — سوپ سنگی و قورباغهٔ پخته

اغلب مردم با تغییر مشکل دارند — گاهی به دلیل‌های منطقی،
و گاهی فقط به‌خاطر اینرسی قدیمی.

در این موضوع، به یک استراتژی برای آغاز کردن تغییر نگاه می‌کنیم،
و برای ایجاد تعادل، یک داستان هشداردهنده دربارهٔ موجودی را نقل می‌کنیم
که خطرات تغییر تدریجی را نادیده گرفت.

سوپ سنگی

داستان «سوپ سنگی» دربارهٔ گروهی مسافر است که وارد روستایی می‌شوند،
در شرایطی که روستاییان چیزی برای کمک ندارند یا نمی‌خواهند کمک کنند.
مسافران قابلمه‌ای آب را روی آتش می‌گذارند و یک سنگ در آن می‌اندازند.
روستاییان کنجکاو می‌شوند و جلو می‌آیند.

مسافران می‌گویند:

«داریم سوپ سنگی درست می‌کنیم،
فقط اگر کمی سبزی داشتیم، بهتر می‌شد…»

روستاییان کمی سبزی می‌آورند.

بعد می‌گویند:

«اگر کمی نمک بود، عالی می‌شد…»

و یکی نمک می‌آورد.

این روند همین‌طور ادامه پیدا می‌کند تا در نهایت،
بدون اینکه روستا متوجه شود،
یک دیگ کامل سوپ واقعی درست شده است —
نه به‌خاطر سنگ، بلکه به‌خاطر اینکه مردم کم‌کم مشارکت کردند.

نکتهٔ داستان:
گاهی برای آغاز یک تغییر بزرگ،
فقط لازم است کسی قدم اول را بردارد —
حتی اگر آن قدم کوچک و نمادین باشد.

این قدم کوچک باعث مشارکت، توجه و همکاری دیگران می‌شود.

قورباغهٔ پخته

حکایت دوم دربارهٔ قورباغه‌ای است که در ظرف آب ولرم قرار دارد.
اگر آب ناگهان جوش باشد، قورباغه بیرون می‌پرد.
اما اگر آب به‌آرامی گرم شود،
قورباغه متوجه تغییر نمی‌شود
و در نهایت می‌پزد.

این داستان هشداری است دربارهٔ خطر تغییرات کوچک اما پیوسته.

در پروژه‌ها هم همین اتفاق می‌افتد:

به‌تنهایی، هیچ‌کدام فاجعه‌بار نیستند.
اما وقتی این تغییرات تدریجی انباشته می‌شوند،
ممکن است خودت را در آبی جوشان بیابی
بدون اینکه بفهمی چطور به این نقطه رسیده‌ای.

برنامه‌نویس عمل‌گرا باید پیوسته محیط اطرافش را رصد کند،
متوجه تغییرات شود،
و پیش از آنکه دیر شود واکنش نشان دهد.

نکته ۶

تغییر را آغاز کن — و مراقب تغییرات تدریجی باش

قدم اول را بردار،
اما همیشه مراقب باش که درون آب داغ آرام آرام پخته نشوی.

موضوع ۵ — نرم‌افزار به‌اندازهٔ کافی خوب

«کمال‌گرایی» وسوسه‌ای است که بسیاری از توسعه‌دهندگان در دام آن می‌افتند.
اما در دنیای واقعی، کمال همیشه بهترین گزینه نیست —
و اغلب حتی ممکن نیست.

یکی از مزیت‌های درک بافت بزرگ‌تر پروژه این است که می‌فهمید
نرم‌افزار باید چقدر خوب باشد.

گاهی تقریباً بی‌نقص‌بودن تنها گزینهٔ قابل‌قبول است —
مثلاً در بخش‌هایی که با جان انسان‌ها، امنیت، یا پول زیاد سروکار دارد.

اما در بسیاری از موقعیت‌ها، شما در حال مواجهه با مجموعه‌ای از مصالحه‌ها هستید:

در چنین شرایطی، هدف همیشه «بهترینِ ممکن» نیست؛
بلکه باید به «به‌اندازهٔ کافی خوب» برسید.

به‌اندازهٔ کافی خوب یعنی:

اگر زمان زیادی را برای رساندن چیزی به کمال صرف کنید،
ممکن است:

برنامه‌نویس عمل‌گرا می‌داند کجا باید کمال‌گرایی را کنار بگذارد
و کجا باید روی کیفیت فشار بیاورد.

«خوبِ کافی» یک شکست نیست —
بلکه یک تصمیم هوشمندانه در چارچوب واقعیات پروژه است.

نکته ۷

بدان چه زمانی «به‌اندازهٔ کافی خوب» واقعاً کافی است

گاهی بهترین کار این است که محصول را منتشر کنید،
بازخورد بگیرید،
و در نسخهٔ بعدی بهترش کنید —
به‌جای آنکه برای همیشه در انتظار کمال بمانید.

موضوع ۶ — سبد دانشی شما

اگر بخواهید در حرفهٔ توسعهٔ نرم‌افزار رشد کنید و دوام بیاورید،
باید بدانید که دانش مهم‌ترین دارایی شماست.

ابزارها، زبان‌ها، کتابخانه‌ها و فریم‌ورک‌ها می‌آیند و می‌روند.
اما دانشی که کسب می‌کنید و تجربه‌ای که می‌سازید چیزی است که همیشه با شما می‌ماند.

به همین دلیل ما از استعارهٔ «سبد دانشی» استفاده می‌کنیم.
همان‌طور که سرمایه‌گذاران مالی، پول خود را در یک سبد متنوع قرار می‌دهند
تا از ریسک‌ها کم کنند و سود بلندمدت بیشتری به‌دست بیاورند،
شما هم باید دانش و مهارت‌های خود را متنوع کنید.

اگر سبد دانشی شما فقط شامل یک زبان برنامه‌نویسی باشد،
یا فقط یک ابزار،
یا فقط یک حوزهٔ محدود،

در برابر تغییرات صنعت آسیب‌پذیر خواهید بود.

صنعت ما بسیار سریع تغییر می‌کند:

اگر شما توقف کنید،
دنیا از شما جلو می‌افتد.

یادگیری باید «پیوسته» باشد

یادگیری یک اتفاق نیست؛
یک عادت است.

باید یادگیری را بخشی از برنامهٔ روزانهٔ خود کنید:

همهٔ این‌ها به مرور زمان،
یک «سبد دانشی محکم» برایت می‌سازد.

استراتژی‌های پیشنهادی برای رشد دانش

چرا این‌ها مهم هستند؟

چون اگر تنوع دانشی داشته باشی:

دانش، بهرهٔ مرکب دارد:
هرچقدر بیشتر بیاموزی،
توانایی‌ات برای یادگیری سریع‌تر نیز بیشتر می‌شود.

نکته ۸

همیشه روی سبد دانشی خود سرمایه‌گذاری کن

در دنیای ما، یادگیری انتخابی نیست —
بقا در گرو آن است.

موضوع ۷ — ارتباط برقرار کن

هیچ‌کدام از ما در خلأ کار نمی‌کنیم.
بخش بزرگی از زمان ما صرف تعامل با دیگران می‌شود:

داشتن مهارت‌های فنی عالی کافی نیست.
اگر نتوانی افکار، مقاصد و تصمیم‌های خود را منتقل کنی،
کار تیمی دشوار می‌شود و پروژه آسیب می‌بیند.

ارتباط خوب یعنی این:

۱) شفاف باش

وقتی حرف می‌زنی یا می‌نویسی،
هدف باید واضح باشد.
کلمات مبهم یا پیچیده فقط باعث سوءتفاهم می‌شوند.

۲) به مخاطب توجه کن

جوری صحبت کن که طرف مقابل بفهمد،
نه طوری که خودت دوست داری توضیح دهی.

۳) فعالانه گوش بده

گوش‌دادن فقط ساکت بودن نیست.
باید بفهمی طرف مقابل واقعاً چه می‌گوید،
نه اینکه منتظر باشی نوبت خودت شود.

۴) مستند کن

چیزهایی که باید یاد بمانند،
باید نوشته شوند.
نوشتن باعث جلوگیری از فراموشی،
اختلاف برداشت،
و دوباره‌کاری می‌شود.

۵) بازخورد بخواه

ارتباط یک‌سویه نیست.
بپرس:

این کار باعث مشارکت بیشتر و بهتر شدن نتیجه می‌شود.

۶) در انتقال ایده‌ها متواضع باش

وقتی ارتباط برقرار می‌کنی،
هدف «برنده‌شدن» نیست—
بلکه «فهم مشترک» است.

۷) در جلسات مؤثر باش

جلسه جایی است که تصمیم‌های مهم گرفته می‌شود.
آماده بیا،
حرف اضافه نزن،
خلاصه و دقیق صحبت کن،
و موضوع را در مسیر درست نگه دار.

نکته ۹

برای ارتباط خوب تلاش کن—این بخشی از کار توست

برنامه‌نویسان عمل‌گرا می‌دانند
که کیفیت کارشان تنها به کدی که می‌نویسند محدود نمی‌شود.
بلکه به چگونگی تعامل با دیگران نیز بستگی دارد.

ارتباط خوب ارزش ایجاد می‌کند.
ارتباط بد، زیان.

پایان فصل ۱

این آخرین موضوع از فصل «فلسفهٔ عمل‌گرایانه» است.