https://virgool.ir/feed/@ali.behzadianfa2026-11-11 15:08:38https://files.virgool.ir/upload/users/104/avatar/HcX4NR.pnghttps://virgool.ir/@ali.behzadianhttps://virgool.ir/Smartlab/۲-شرکت-شما-یک-محصول-است-crl6o9bglfawشرکت شما یک محصول استبا این ایده شروع می‌شود: شرکت شما یک محصول است. قبول که چیزهایی که می‌سازید یا خدماتی که ارائه می‌دهید محصول هستند، اما چیزی که آن‌ها را می‌سازد شرکت شما است. به همین دلیل است که شرکت شما باید بهترین محصول شما باشد.همه چیز در این کتاب حول این تفکر شکل می‌گیرد که مثل توسعه محصول پیشرفت از طریق تکرار به دست می‌آید. اگر بخواهید محصولی را بهتر کنید باید مدام تغییر بدهید، بازنگری و تکرار کنید. همه این‌ها برای شرکت هم همین‌گونه است.اما وقتی به شرکت‌ها می‌رسیم، خیلی‌ها متوقف می‌شوند. آن‌ها ممکن است چیزی را که می‌سازند تغییر بدهند اما چگونگی ساخت آن مثل قبل می‌ماند. آن‌ها یک بار روش کار خود را انتخاب می‌کنند و به همان می‌چسبند. هر چقدر که اشتیاق در محیط کاری در ابتدا داغ باشد، به مرور زمان سرد و سخت می‌شود. سیاست‌ها در سیمان منجمد می‌شوند. شرکت‌ها به خودشان گیر می‌کنند.اما وقتی به شرکت به عنوان یک محصول فکر می‌کنی، سوال‌های متفاوتی می‌پرسی: آیا افرادی که اینجا کار می‌کنند می‌دانند که جطور باید از شرکت استفاده کنند؟ آیا ساده است؟ پیچیده است؟ آیا نحوه کارش واضح است؟ کجا سریع عمل می‌کند؟ کجا کند عمل می‌کند؟ خطا دارد؟ کدام خطاهایش را می‌توانیم سریع ترمیم کنیم و کدام به زمان طولانی‌تری احتیاج دارد؟شرکت مثل یک نرم‌افزار است. باید قابل استفاده باشد. باید مفید باشد و احتمالا چندین خطا دارد: وقت‌هایی که شرکت به دلیل طراحی سازمانی بد یا اشتباه‌های فرهنگی، سقوط می‌کند.وقتی که شرکت را به عنوان محصول ببینی، تمام امکان‌های تغییر و ارتقا آشکار می‌شوند. وقتی می‌فهمی که شیوه کار کردن روان و شکل‌پذیر است، می‌توانی چیزی جدید را قالب‌ریزی کنی، چیزی به مراتب بهتر.ما در چرخه‌های شش هفته‌ای روی پروژه‌ها کار می‌کنیم. بعد از آن دوهفته از کار زمان‌بندی شده فاصله می‌گیریم تا کمی پرسه بزنیم و از فشارها کم کنیم. ما نظریه‌ای نداریم که روش کار ما بهترین روش است. ما در ابتدا با روش «کار کردن بر روی پروژه‌ها تا هر زمان که طول بکشد» کار می‌کردیم. بعد از آن دیدیم که پروژه‌‌ها ظاهرا هیچگاه به انجام نمی‌رسند. پس تصمیم گرفتیم از بازه‌های زمانی سه ماهه استفاده کنیم و سرانجام به اینجا رسیدیم، بازه‌های زمانی شش هفته‌ای. ما با تکرار دریافتیم که زمان مناسب برای ما چقدر است. در کتاب درباره این موضوع صحبت می‌کنیم.ما همینطوری فرض نکردیم که ارتباط ناهمزمان بیشتر وقت‌ها بهتر از از ارتباط بلادرنگ است. ما بعد از سال‌ها استفاده از ابزارهای پیام‌رسانی به این نتیجه رسیدیم. ما دیدیم که چطور حواس‌پرتی بیشتر می‌شود و کار کمتر. پس از آن ما روشی برای برقراری بهتر ارتباط پیدا کردیم. در کتاب درباره این موضوع صحبت می‌کنیم.ما از ابتدا با مزایایی که الان داریم شروع نکردیم. ما در مسیر ‌آن‌ها حرکت کردیم. ما نمی‌دانستیم که پرداخت هزینه‌های تعطیلات کارکنان بهتر از پرداخت پاداش نقدی است. ما با پرداخت پاداش نقدی شروع کردیم و بعد فهمیدیم که پاداش نقدی جزئی از حقوق تلقی می‌شود. ما این تجربه را به سایر مزایا هم اعمال کردیم. در کتاب درباره این موضوع صحبت می‌کنیم.ما با رویکرد آرامش به مذاکره حقوق وارد نشدیم. ما با کار به این نتیجه رسیدیم. تعیین حقوق و تضمین افزایش آن در بیس‌کمپ هم مانند سایر شرکت‌ها اضطراب آفرین بود تا این که ما با تکرار به یک شیوه جدید دست یافتیم. در کتاب درباره این موضوع صحبت می‌کنیم.ما روی شرکت هم به همان سختی کار بر روی محصولات، کار می‌کنیم. مردم معمولا یک شماره نسخه در انتهای نام نرم‌افزار اضافه می‌کنند. «این iOS 10.1 یا ۱۰٫۲ یا ۱۰٫۵ یا ۱۱ یا … است.» ما درباره شرکت هم همین‌طور فکر می‌کنیم. الان شرکت بیس‌کمپ (مسئولیت محدود) نسخه مثلا ۵۰٫۳ است. ما با تلاش فهمیدیم که چه چیزی برای ما مناسب است و به اینجا رسیدیم.متاسفانه، اداره آرام یک شرکت، این روزها، روش پیش‌فرض اداره یک شرکت نیست. باید مدتهای طولانی علیه غرایز کار کنید. باید هنجارهای مسموم صنعتی را کنار بگذارید. باید بفهمید که «این دیوانگی در کار است» درست نیست. هدف و مقصد آرامش است و ما روشی که به آرامش رسیدیم و در آرامش ماندیم را با شما در میان می‌گذاریم.شرکت ما یک محصول است. انتظار ما این است که شما هم همین دیدگاه را برای شرکت خود داشته باشید، چه مالک شرکت باشید یا مدیر شرکت یا «فقط» کارمند آن. همه برای بهتر کردن آن دخیل هستیم.این مطلب در ادامه ترجمه کتاب «دیوانگی در کار لازم نیست» است. مطلب قبلی «دیوانگی در کار لازم نیست» را هم ببینید. این نوشته اولین بار در «اسمارت‌لب» منتشر شده است.علی بهزادیان نژادعلی بهزادیان نژادMon, 09 Dec 2019 09:35:40 +0330https://virgool.ir/Smartlab/دیوانگی-در-کار-لازم-نیست-yfyed6n14waoدر دوران تاریک اینترنتی و قطع آن، شروع کردم به خواندن کتاب It doesn't have to be crazy at work. کتاب رو خوندم و از خوندنش لذت بردم. گفتم قسمت‌هایی از کتاب، یا اگر توفیق شد همه کتاب رو ترجمه و به مرور منتشر کنم. کتاب نوشته «جیسون فراید» و «دیوید هاینمایر هانسن» دو بنیانگذار شرکت بیس‌کمپ است. از این دو نفر پیش از این کتاب «واقعی شدن» را ترجمه کرده‌ام که در وبسایتش می‌تونید بخونید. کتاب‌های Rework و Remote هم به دست دیگران ترجمه شده و در دسترس است.این مطلب را پیش از این در وب‌سایت «اسمارت‌لب» منتشر کرده‌ام.این دیوانگی در کار استتا به حال چند  بار شنیده‌اید که «این دیوانگی در کار است»؟ حتا شاید خودت هم این را گفته باشی. برای خیلی‌ها «این دیوانگی است» کاملا عادی شده است. اما چرا این قدر دیوانگی؟دو دلیل عمده وجود دارد: (۱) روز کاری با هجوم حواس‌پرتی‌های فیزیکی و مجازی به چند بخش کوچک و فرار کاری تقسیم می‌شود. و (۲) وسواس ناسالم رشد کردن با هر هزینه‌ای، باعث توقعات سر به فلک کشیده و غیر واقعی می‌شود و آدم‌ها را مضطرب می‌کند.شکی نیست که آدم‌ها بیشتر کار می‌کنند، زودتر یا دیرتر کار می‌کنند، یا آخر هفته‌ها و هر زمانی که وقتی خالی داشته باشند.  آن‌ها نمی‌توانند کار را سر کار تمام کنند. این باعث می‌شود که زندگی محدود شود به زمان‌های باقیمانده از کار؛ ظرف اضافه غذای رستوران.بدتر این که این روزها ساعت‌های طولانی کار، مشغولیت بیش از حد و کمبود خواب به نشان افتخار برای خیلی‌ها تبدیل شده است. خستگی مستمر نشان افتخار نیست، نشان حماقت است.این موضوع محدود به سازمان‌ها نیست. افراد عادی، پیمانکارها و کارآفرینان تنها هم به شکلی کاملا مشابه، خودشان را نابود می‌کنند.ممکن است فکر کنید که با این زمانی که آدم‌ها صرف کار می‌کنند و با وعده‌های فناوری ‌های پیشرفته، حجم کار کمتر شده باشد اما این طور نیست. هر روز حجم کار بیشتر و سنگین‌تر می‌شود.اما نکته این است که دیگر کاری نمانده است که به طور ناگهانی انجام شود. مشکل این است که یافتن زمانی بدون حواس‌پرتی و کاملا مختص به انجام کار، بسیار سخت شده است.آدم‌ها بیشتر کار می‌کنند و کمتر کاری به انجام می‌رسد. تا زمانی که توجیهی منطقی برای عمده زمانی که در کارهای بی اهمیت به هدر می‌رود نداشته باشید، این مشکل حل نمی‌شود.توقع از خیلی افراد این است که هفته‌ای ۶۰ یا ۷۰ یا ۸۰ ساعت را به کار بپردازند. چقدر از این ساعت‌ها واقعا برای خود کار صرف می‌شود؟ و چقدر از این زمان در جلسات به هدر می‌رود یا با حواس‌پرتی دور ریخته می‌شود یا با روال‌های کاری ناکارآمد ذره ذره از بین می‌رود؟ تقریبا همه‌اش.راه‌حل ساعت‌های کاری بیشتر نیست، چرندیات کمتر است. دور ریز کمتر است نه تولید بیشتر.  و حواس‌پرتی‌های خیلی خیلی کمتر و اشتیاق کمتر به «همیشه در دسترس بودن» و دوری کردن از اضطراب.اضطراب از سازمان به کارکنان و از کارکنان به یکدیگر  و پس از آن از کارکنان به مشتری منتقل می‌شود. اضطراب هرگز محدود و مقید به محیط کاری نمی‌ماند . زندگی را نابود می‌کند. رابطه شما را با دوستان، خانواده و فرزندانتان آلوده می‌کند.وعده‌ها ادامه خواهد یافت. روش‌های بهتر مدیریت زمان. راه‌های بیشتری برای برقراری ارتباط. و مطالبات جدید همچنان بر روی هم انباشته می‌شوند. برای توجه کردن به گفتگوهای بیشتر در مکان‌های بیشتر، برای ارسال پاسخ در کمتر از یک دقیقه. همیشه سریع‌تر و سریعتر. برای چه؟اگر دیوانگی در کار دائمی است، ما برای شما یک راه‌حل دو کلمه‌ای داریم: گور باباش. دو کلمه راهگشای دیگر: دیگه بسه.الان زمان آن فرارسیده است تا شرکت‌ها درخواست از کارکنان برای پیگیری بی وقفه اهداف بی‌شمار و فزاینده و دنبال کردن اهداف ساختگی را متوقف کنند. زمان آن فرا رسیده است تا به کارکنان زمانی بدون توقف داده شود که در آن بر روی مطالبات واقعی کار کنند. وقت آن است که تقدیس دیوانگی در کار را متوقف کنیم.ما حدود ۲۰ سال تلاش کردیم تا بیس‌کمپ را به شرکتی آرام تبدیل کنیم. شرکتی که سوخت محرک آن اضطراب، یا «در اسرع وقت»، یا عجله و شتاب، یا تا دیر وقت کار کردن، یا شب‌کاری خرد کننده یا وعده‌های غیر ممکن، یا گردش مالی بالا، یا ضرب‌العجل‌های همیشه با تاخیر، یا پروژه‌هایی که به نظر می‌رسد هیچوقت تمام نمی‌شوند، نباشد.نه به رشد با هر هزینه‌ای. نه به مشغله دروغین. نه به اهداف خودمحور. نه به چشم و هم‌چشمی. نه به «فرصت سر خاراندن نداشتن». با این حال کسب و کار ما هر سال سود ده بوده است.ما در یکی از رقابتی‌ترین کسب و کارها در جهان هستیم. علاوه بر غول‌های فناوری، صنعت نرم‌افزار جولانگاه استارتاپ‌هایی است که صدها میلیون دلار پول از سرمایه‌گذاران ماجراجو گرفته‌اند. ما هیچ پولی نگرفته‌ایم. درآمد ما از کجا است؟ مشتری‌ها. ما را از مد افتاده یا محافظه‌کار بنامید.به عنوان یک شرکت نرم‌افزاری توقع این است که ما هم در بازی «یک شبه پولدار شدن» سیلیکون‌ولی بازی کنیم اما ما حتا یک کارمند در سیلیکون‌ولی نداریم. در حقیقت ۵۴ کارمند ما در حدود ۳۰ شهر در اقصا نقاط دنیا پراکنده هستند.ما بیشتر طول سال ۴۰ ساعت در هفته و در تابستان‌ها ۳۲ ساعت در هفته کار می‌کنیم. ما هر سه سال کارکنان را به یک تعطیلات یک ماهه می‌فرستیم. ما نه تنها در طول این یک ماه حقوق آن‌ها را پرداخت می‌کنیم بلکه هزینه خود تعطیلات آن‌ها را هم می‌پردازیم.نه، دوشنبه ساعت ۹ شب نه. کار می‌تواند تا سه‌شنبه ساعت ۹ صبح منتظر بماند. جمعه نه، شنبه.آیا گهگاه لحظات پر استرسی پیش خواهد آمد؟ حتما، کار هم مثل زندگی است. آیا هر روز کار «هلو در گلو» است؟قطعا نه. اگر بگوییم اینگونه است دروغ گفته‌ایم. اما همه تلاشمان را می‌کنیم تا این موارد استثنا باشند. ما به انتخاب خودمان، و با تمرین، متعادل و آرام هستیم. ما از روی عمد اینطور هستیم. ما در آرامش تصمیم‌های متفاوتی می‌گیریم.ما شرکتمان را متفاوت طراحی کرده‌ایم. در اینجا می‌خواهیم درباره تصمیم‌هایی که گرفته‌ایم و چرایی خیلی از آن‌ها با شما صحبت کنیم. برای هر شرکتی که بخواهد تصمیم‌های مشابهی بگیرد راهی وجود دارد. باید واقعا آن را بخواهید. شما هم می‌توانید شرکتی آرام داشته باشید.فضای کاری نوین بیمار است. آشوب نباید وضعیت طبیعی کار باشد. تشویش و اضطراب نباید پیش‌نیاز پیشرفت باشد. تمام طول روز جلسه داشتن لازمه موفقیت نیست. همه این‌ها انحراف از کار است؛ اثر جانبی مدل‌های از کار افتاده و خراب و از صخره‌ها پایین پریدن. کنار بمانید تا هر کس که می‌خواهد از صخره پایین بپرد، بپرد.آرامش محافظت از زمان و توجه آدم‌ها است.آرامش حدود ۴۰ ساعت در هفته کار کردن است.آرامش توقعات منطقی است.آرامش تقویت زمان‌های غیر کاری است.آرامش کوچک‌تر بودن است.آرامش افقی در دیدرس است.آرامش جلسات را به عنوان آخرین راه‌حل دیدن است.آرامش تقدم غیر همزمان بر بلادرنگ است.آرامش استقلال بیشتر و وابستگی کمتر است.آرامش شیوه‌های پایدار برای مدت طولانی است.آرامش سودمندی است.مختصری درباره ماما جیسون و دیوید هستیم. ما با هم از سال ۲۰۰۳ بیس‌کمپ را اداره می‌کنیم. جیسون مدیر اجرایی (CEO) و دیوید مدیر فنی (CTO) است. ما تنها مدیران C شرکت هستیم.بیس‌کمپ هم نام شرکت ما و هم نام محصول ما است. محصول بیس‌کمپ برنامه‌ای ابری است که به شرکت‌ها در ساماندهی پروژه‌ها و ارتباطات داخلی کمک می‌کند. وقتی همه چیز در بیس‌کمپ است، همه می‌دانند چه کار باید بکنند، ‌هر چیزی کجا است و وضعیت کارها چیست و هیچ چیزی آن لابه‌لا گم نمی‌شود.ما در اداره کسب و کارمان تجربه‌های زیادی اندوخته‌ایم. در این کتاب چیزی که برای ما جواب داده است و نیز مشاهده‌ها و درک خودمان درباره چیزهایی که کسب و کار را سالم، طولانی مدت و پایدار می‌کند را با شما به اشتراک می‌گذاریم. فارغ از همه این توصیه‌ها، مسیر شما ممکن متفاوت باشد. از این ایده‌ها به عنوان منبع الهام‌بخش برای تغییر استفاده کنید نه وحی منزل.در پایان، منظور ما از لفظ دیوانگی در این کتاب همان است که مردم برای توصیف ترافیک دیوانه‌کننده در ساعت‌های شلوغی یا هوای دیوانه‌وار بیرون، یا صف‌های دیوانه‌کننده و شلوغ فرودگاه استفاده می‌کنند. وقتی ما می‌گوییم دیوانگی، منظورمان موقعیت دیوانه‌وار یا دیوانه‌کننده است نه آدم‌ها.با این مقدمه، بیایید شروع کنیم.در ادامه «شرکت شما یک محصول است» را بخوانید.علی بهزادیان نژادعلی بهزادیان نژادWed, 04 Dec 2019 12:29:24 +0330https://virgool.ir/Smartlab/۸-قانون-بوی-اسکات-qtwr0rffmupmاردوگاه «بوی اسکات» یک قانون دارد: «همیشه محوطه را تمیزتر از زمانی که به آن وارد شده‌اید ترک کنید.» اگر زباله‌ای روی زمین دیدی، بدون توجه به این که چه کسی آن را انداخته است، تمیزش کن. نیت‌ات این باشد که اردوگاه را برای گروه بعدی که می‌آیند بهتر کنی. (در واقع شکل اصلی این قانون که «رابرت استفنسن اسمیت بیدن پاول*» بنیانگذار اردوگاه اسکات بیان کرده است، این بود: «سعی کن وقتی دنیا را ترک می‌کنی، دنیا بهتر از وقتی باشد که به آن وارد شدی.»)اگر ما قانونی مشابه این را در کدنویسی داشته باشیم چه اتفاقی می‌افتد: «همیشه وقتی یک ماژول را تحویل می‌دهی تمیزتر از وقتی باشد که آن را تحویل می‌گیری»؟ بدون توجه به این که نویسنده اولیه آن ماژول چه کسی بوده است، چی می‌شود اگر ما مقداری (هر چند ناچیز) تلاش کنیم تا آن را بهبود بدهیم؟ نتیجه چه خواهد شد؟من فکر می‌کنم اگر ما همین قانون ساده را دنبال کرده بودیم شاهد پایان «بدتر شدن مداوم» سیستم‌های نرم‌افزاری‌مان بودیم. سیستم‌هایمان همانطور که تکمیل می‌شدند بهتر و بهتر هم می‌شدند. همچنین می‌دیدیم که تیم‌ها نگران سیستم به عنوان یک کل بودند نه این که هر کسی نگران بخش کوچک کار خودش باشد.من فکر می‌کنم که پایبندی به این قانون خواسته زیادی نیست. لازم نیست همه ماژول‌ها را قبل از تحویل، کامل و بی و عیب نقص کنی. فقط کافی است آن را یک ذره بهتر از زمانی که تحویل گرفته‌ای، برگردانی. در این شکی نیست که باید کدی که به ماژول اضافه می‌کنی تمیز باشد، حداقل یک چیز دیگر را هم قبل از این که ماژول را تحویل بدهی تمیز کن. این کار می‌تواند به سادگی بهبود نام یک متغیر یا شکستن یک تابع طولانی به دو تابع کوچک‌تر باشد یا شاید شکستن یک وابستگی حلقه‌ای یا اضافه کردن یک رابط و جدا کردن سیاست‌ها از جزئیات.صادقانه بگویم انجام این کار از نظر من نشانه شخصیت شما است، مثل شستن دست بعد از مستراح یا انداختن زباله در سطل آشغال به جای پرت کردن آن روی زمین. علاوه بر این رها کردن آشغال در کد باید همانند آشغال ریختن روی زمین از نظر اجتماعی ناپسند باشد. کاری که به هیچ وجه نباید انجام داد.این موضوع حتا فراتر از این‌ها است. نگران کد خود بودن یک مسأله است و نگرانی و دغدغه داشتن برای کد «تیم» موضوع دیگری است. اعضای تیم به هم کمک می‌کنند و کار یکدیگر را تمیز می‌کنند. آن‌ها قانون «بوی اسکات» را دنبال می‌کنند چون برای همه سودمند است نه این که فقط برای خودشان مفید باشد.نویسنده: Robert C. Martin یا عمو بابرابرت سی مارتین معروف به عمو بابپ.ن: کتاب «۹۷ چیزی که هر برنامه‌نویس باید بداند، مجموعه‌ای از پندهای نخبگان» را خیلی‌ها «چنین گفت زرتشت» برنامه‌نویس‌ها می‌دانند. این کتاب مجموعه‌ای از مقالات بسیار کوتاه از برنامه‌نویسان مطرح و شناخته شده است که هر کدام به یک موضوع از منظر خودشان پرداخته‌اند. به مرور سعی می‌کنم همه آن‌ها را ترجمه کنم.(این نوشته پیش از این در اسمارت‌لب منتشر شده است)علی بهزادیان نژادعلی بهزادیان نژادFri, 13 Jul 2018 11:51:19 +0430https://virgool.ir/Smartlab/زیبایی-در-سادگی-است-u05ynd1fmlj9نقل قولی از افلاطون است که من فکر می‌کنم خصوصا برای توسعه دهندگان مناسب است و باید آن را در نزدیک قلبشان نگه دارند:«زیبایی متن و هماهنگی و ظرافت و جذابیت و موزونی بسته به سادگی است.»این گفته همه آن چیزی که ما به عنوان توسعه دهنده نرم‌افزار در آرزوی آن هستیم را در یک جمله بیان می‌کند.چیزهایی هستند که ما تلاش می‌کنیم در کد خود داشته باشیم:خوانا بودنقابل نگهداری بودنسرعت در توسعهزیبایی کیفیافلاطون به ما می‌گوید عاملی که ما را در رسیدن به این سطح از کیفیت توانا می‌کند سادگی است.کد زیبا چیست؟ این پرسشی است که بالقوه پاسخ‌های زیادی دارد. درک زیایی بسیار وابسته به گذشته افراد است، دقیقا همانطور که درک ما از خیلی چیزها به گذشته ما بستگی دارد. آدم‌هایی که مطالعات هنری دارند با آدم‌هایی دارند که در علوم مطالعه می‌کنند، درک متفاوت (یا حداقل شیوه متفاوتی در درک) زیبایی دارند. استادان هنر تمایل دارند زیبایی نرم‌افزار را با زیبایی آثار هنری مقایسه کنند در حالی که استادان علوم دوست دارند درباره تقارن و نسبت طلایی صحبت کنند و تلاش می‌کنند هر چیزی را به یک فرمول تنزل بدهند. طبق تجربه من اساس همه بحث‌ها درباره زیبایی از سوی دو طرف سادگی است.به سورس کدهایی که خوانده‌ای فکر کن. اگر تا به حال برای خواندن کد دیگران وقت نگذاشته‌ای، خواندن این مطلب را متوقف کن و بگرد به دنبال یک سورس کد باز برای مطالعه. کاملا جدی می‌گویم. برو و در وب و یک سورس کد به زبان مورد نظر خودت که یک حرفه‌ای شناخته شده و مورد احترام نوشته شده است را جستجو کن.برگشتی؟ بسیار عالی! کجا بودیم؟ آهان… من فهمیده‌ام که کدهایی که با من همسازند و آن‌ها را زیبا می‌دانم چند ویژگی مشترک دارند. اصلی‌ترین ویژگی مشترک آن‌ها سادگی است. من فهمیده‌ام که فارغ از این که کل برنامه یا سیستم چقدر پیچیده است، بخش‌های مجزای کد باید ساده باشند: اشیایی ساده با یک مسئولیت، شامل متدهای ساده و متمرکز و نام‌های گویا. بعضی فکر می‌کنند که کوتاه نگه داشتن متدها در حد ۵ تا ۱۰ خط خیلی افراطی است و در بعضی از زبان‌های برنامه‌نویسی این کار خیلی سخت است. اما من معتقدم که این اختصار، یک هدف مطلوب است.نکته آخر این که کد زیبا کد ساده است. هر بخش مجزای کد ساده است و مسئولیتی ساده دارد و رابطه آن با سایر بخش‌های سیستم ساده است. با این کار است که می‌توانیم در طول زمان از سیستم نگهداری کنیم. با کد تمیز، ساده و تست شدنی که سرعت توسعه بالا را در طول دوران زندگی سیستم تضمین می‌کند.زیبایی زاده سادگی است و در سادگی یافت می‌شود.Jørn Ølmheimپ.ن: کتاب «۹۷ چیزی که هر برنامه‌نویس باید بداند، مجموعه‌ای از پندهای نخبگان» را خیلی‌ها «چنین گفت زرتشت» برنامه‌نویس‌ها می‌دانند. این کتاب مجموعه‌ای از مقالات بسیار کوتاه از برنامه‌نویسان مطرح و شناخته شده است که هر کدام به یک موضوع از منظر خودشان پرداخته‌اند. به مرور سعی می‌کنم همه آن‌ها را ترجمه کنم.(این نوشته پیش از این در اسمارت‌لب منتشر شده است)علی بهزادیان نژادعلی بهزادیان نژادSat, 14 Apr 2018 11:53:31 +0430https://virgool.ir/Smartlab/قبل-از-بازنویسی-کد-wrbk7d7jdv0eهمه برنامه‌نویس‌ها در مواقعی باید کد موجود را بازنویسی کنند. اما قبل از این که بخواهی این کار را بکنی، لطفا به موارد پایین فکر کن چون این‌ها می‌تواند باعث صرفه‌جویی زیادی در زمان تو و دیگران بشود و البته کاهش درد و رنج:بهترین روش برای بازسازی با بررسی کدهای موجود و تست‌هایی که برای آن نوشته شده است آغاز می‌شود. این کار به درک نقاط قوت و ضعف کد در وضعیت فعلی کمک می‌کند. با این کار می‌توانی مطمئن شوی که در عین دوری از خطاها، نقاط قوت را حفظ می‌کنی. همه ما گمان می‌کنیم که می‌توانیم کار را بهتر از سیستم فعلی انجام دهیم… تا زمانی که در آخر کار نتیجه نه تنها بهتر نمی‌شود که حتا ممکن است بدتر از سیستم قبلی هم بشود، به خاطر این که از خطاهای سیستم موجود درس نگرفتیم.در برابر وسوسه بازنویسی همه چیز مقاومت کن. بهترین کار این است که تا جای ممکن از کدهای موجود استفاده مجدد کنی. اصلا مهم نیست که چقدر کد زشت است، این کد پیش از این تست و بازنگری و … شده است. دور ریختن کد قدیمی -به خصوص اگر در حال استفاده باشد- به این معنی است که کدی که ماه‌ها (یا سال‌ها) تست شده و در مشکلات مقاوم شده است را دور می‌ریزی، کدی که ممکن است شامل برخی راه‌حل‌ها و حل خطاهایی باشد که حتا از وجود آن‌ها مطلع نیستی. اگر این نکته را جدی نگیری ممکن است کد تازه‌ای که نوشته‌ای به همان خطاهای مرموز بخورد که در کد قبلی اصلاح شده‌اند. این مشکل ممکن است زمان زیادی را به هدر بدهد و سختی‌های زیادی را به تو تحمیل کند و به دانشی که در طول سال‌ها به دست آمده است لطمه بزند.تعداد زیادی تغییرات تدریجی بهتر از یک تغییر عظیم است. تغییرات تدریجی اجازه می‌دهد که تاثیر بر روی سیستم را از طریق بازخورد و تست بسیار ساده‌تر اندازه بگیری. دیدن صدها تست ناموفق بعد از یک تغییر اصلا مسأله جذابی نیست. این موضوع به ناامیدی منجر می‌شود و فشاری که به تو وارد می‌کند باعث می‌شود تصمیم‌های بد بگیری. سر و کله زدن با چند تا تست ناموفق در هر مرحله بسیار ساده‌تر است و تو را به روشی مدیریت شده بعد از هر چرخه هدایت می‌کند. مهم است که تست‌های فعلی همه با موفقیت انجام بشوند. اگر تست‌های فعلی برای پوشش تغییراتی که در کد داده‌ای کافی نبود تست‌های جدید اضافه کن. تست‌های موجود کد قدیمی را بدون دلیل موجه دور نریز. در یک نگاه سطحی ممکن است برخی از این تست‌ها در طراحی جدید تو کاربردی نداشته باشند اما عمیق شدن در آن‌ها و کشف علت نوشته شدن این تست‌ها ارزشمند است.ترجیحات شخصی و احساسات نباید در این کار دخیل باشند. اگر چیزی از کار نیفتاده است، چرا می‌خواهی آن را تعمیر کنی؟ [سری که درد نمی‌کند را دستمال نبند.] این که سبک کد نویسی یا ساختار آن کد مطابق ترجیحات شخصی تو نیست دلیل معتبری برای بازنویسی نیست. این نکته هم که فکر می‌کنی می‌توانی کار را بهتر از برنامه‌نویس قبلی انجام بدهی دلیل موجهی نیست.فناوری جدید دلیل کافی برای بازنویسی نیست. یکی از بدترین دلایل برای بازنویسی این است که کد فعلی بسیار عقب‌تر از فناوری‌های با حالی است که این روزها ما در اختیار داریم و معتقدیم که زبان جدید یا چارچوب جدید می‌تواند کارها را بسیار شیک‌تر انجام دهد. تا زمانی که تحلیل هزینه-فایده ثابت نکرده است که زبان یا چارچوب جدید باعث ارتقای عظیم در کارایی، قابلیت نگهداری، بهره‌وری می‌شود، بهتر است به آن‌ها دست نزنی.به یاد داشته باش که انسان جایزالخطا است. بازسازی همیشه تضمین نمی‌کند که کد جدید بهتر از -یا حتا به خوبی- تلاش‌های قبلی باشد. من تعداد زیادی بازنویسی‌های ناموفق را دیده‌ام و در برخی از آن‌ها مشارکت داشته‌ام. تجربه قشنگی نبود، ولی انسان است و خطاهایش.Rajith Attapattu پ.ن: کتاب «۹۷ چیزی که هر برنامه‌نویس باید بداند، مجموعه‌ای از پندهای نخبگان» را خیلی‌ها «چنین گفت زرتشت» برنامه‌نویس‌ها می‌دانند. این کتاب مجموعه‌ای از مقالات بسیار کوتاه از برنامه‌نویسان مطرح و شناخته شده است که هر کدام به یک موضوع از منظر خودشان پرداخته‌اند. به مرور سعی می‌کنم همه آن‌ها را ترجمه کنم. (این نوشته اولین بار در اسمارت لب منتشر شده است) علی بهزادیان نژادعلی بهزادیان نژادFri, 13 Apr 2018 14:07:01 +0430