مخصوص اعضای ویژه 
برنامه‌نویسی مانند ساختن وسیله‌ای با لگو است. هر توسعه‌دهنده می‌تواند مجموعه جدیدی از لگو را انتخاب کند و طبق دستورالعمل‌ها آن را بسازد. این کار بسیار لذت‌بخش است. در مورد وارد شدن به این مسیر فکر کنید.
پروژه نرم‌افزاری واقعی متفاوت است. مانند ساختن یک مجموعه قلعه خیلی بزرگ می‌باشد. فکر کنید این قلعه از قبل ساخته شده است. کسی آن را با ضربات وحشیانه تکه تکه می‌کند. قسمت‌های بزرگ‌تر در کنار هم باقی می‌مانند. اما قطعات کوچک‌تر کاملا خرد می‌شوند. بعضی از عناصر از پنجره بیرون می‌افتند.
جعبه‌ای در اختیار شما قرار می‌گیرد که حاوی چیزهایی است که باقی مانده است، که هزاران قطعه از مجموعه‌های دیگر است. و البته دستورالعمل‌ها از بین رفته‌اند. شما فقط می‌توانید به یک تصویر تکیه کنید تا متوجه شوید که قلعه چه شکلی است.
جالب است! بیایید ببینیم چه کاری می‌‌توانیم انجام دهیم تا در چنین محیطی به طور موثر کار کنیم.
1. ناشناخته‌ها را بپذیرید
اولین قدم از کار هر توسعه‌ای این است که بدانید چه کارهایی باید انجام دهید. واضح به نظر می‌رسد، و با این حال، هر چه کار بزرگ‌تر باشد، متغیرهای ناشناخته‌تری به دست می‌آورید. در اینجا باید انتظارات روشنی را تنظیم کنید.
اگر هیچ سر نخی برای شروع کار ندارید، برای فکر کردن و تصویرسازی به مدت طولانی زمان نگذارید. کار را شروع کرده و عناصر اصلی که نیاز دارید را به دست آورید. سپس دوباره فکر کنید. اگر کسی از شما برآورد یا مهلت زمانی خواست، با او صادق باشید. برخی قسمت‌های سیستم شما ناشناخته هستند یا ممکن است آن‌ها را متوجه نشوید.
به پلت‌فرم‌هایی مثل Facebook، Netflix یا Oracle فکر کنید. یا هر نرم‌افزار شرکت بزرگ‌تری که وجود دارد. تعداد کمی از افراد می‌توانند حوزه کامل آن‌ها را درک کنند؛ کسانی که یا آن را ساخته‌اند یا سال‌ها با آن کار کرده‌اند. بنابراین اول از همه، برای اینکه بتوانید همه چیز را بشناسید به خودتان زمان و استراحت دهید، و مهم‌تر از همه بپذیرید که شما همه چیز را نمی‌دانید.
به مجموعه قلعه‌ای که می‌خواهید بازسازی کنید فکر کنید. بگویید کسی تصویری از قلعه یا جعبه را به شما بدهد، تصویر نهایی کار را از مشتری بخواهید و از شما پرسیده می‌شود برای ساختن آن چقدر زمان نیاز دارید؟ هیچ پاسخ خوبی برای آن وجود ندارد به جز "من هنوز نمی‌دانم. اجازه دهید شروع کنم و ببینم بعد از یکی دو روز در کجای کار هستم".
رویکرد نهایی "ترس از ناشناخته‌ها" برای این کار می‌تواند به این صورت باشد که تمام عناصر را از جعبه بیرون بیاورید. سعی کنید آن‌ها را بر اساس رنگ و شکل مجموعه‌ای که به آن تعلق دارند جدا کنید. سپس به تصویر نگاه کنید و یک نقشه ذهنی در مورد نحوه سوار کردن قطعات بسازید.
این رویکرد به دو دلیل چندان موثر نیست. اول اینکه اگر قلعه خیلی بزرگ باشد، احتمالا هرگز انجام نخواهد شد. دوم و مهم‌تر از اولی اینکه شما نمی‌توانید مسیر پیش رو را ارزیابی کنید. شما می‌توانید در مسیر درست باشید یا اصلا نباشید. شما هیچ حلقه بازخوردی ندارید.
روش دیگر شروع ساخت قلعه است. همانطور که پیش می‌روید یاد می‌گیرید که آیا پیدا کردن قطعات مورد نیازتان آسان است یا نه. شما خواهید فهمید آیا تصویر همه جزئیات را نشان می‌دهد یا اینکه ساخت و ساز پیچیده‌تر از آن است که به نظر می‌رسد.
بر اساس این اطلاعات شما می‌توانید میزان زمان و تلاش خود برای انجام کار را حدس بزنید، و اینکه آیا اصلا ارزشش را دارد.
اگر شما باید آن را فردا صبح بسازید، شاید رفتن به فروشگاه و خرید دوباره همان قلعه کار بهتری باشد. ممکن است شما تصمیم به ساخت آن نداشته باشید، اما راه‌حل‌ها برای یک مشکل همیشه با کد بیشتر همراه نیستند.
2. سازش را بپذیرید
توسعه‌دهندگان اغلب "توجه زیاد به جزئیات" را مورد ستایش و ارزش قرار می‌دهند. هر شغلی که وجود دارد این مساله را در فرم استخدام خود دارد. این موضوع خوب است اما توجه به جزئیات را با لجاجت و کمال‌گرایی اشتباه نگیرید.
هنگام شروع یک کار بزرگ، باید دو نسخه از آن تعریف کنید. نسخه اول حداقل موارد مورد نیاز شما برای چیزهایی است که به همان روشی که شما فکر می‌کنید باید کار کنند، کار خواهند کرد.
این چیزی است که ما به آن "کار افقی" می‌گوییم. هر بخش از کار بزرگ‌تر شما عمودی است. لازم نیست برای به دست آوردن اولین نتایج عمیق شوید. ابتدا بر روی موارد یا سناریوی اصلی متمرکز شوید.
مواردی که شما می‌توانید در نسخه اول آن‌ها را رها کنید:
مدیریت خطاها
کدنویسی تمیز
پیکربندی
لازم نیست در مرحله اول به همه این‌ها به صورت عمیق فکر کنید و کد مورد نیاز خود را همانطور که از انگشتان‌تان جاری می‌شود بنویسید. شما باید به سرعت به یک عملکرد بالا برسید. مطمئنا انتقال این نسخه ساده به نسخه نهایی زمان زیادی خواهد برد. پس نکته چیست؟
این یک روش ایمن‌تر برای پیشرفت است. شما می‌خواهید فرضیات خود را تایید کنید. هر چه که می‌توانید باهوش و توانا باشید، طراحی و تصویرسازی فقط می‌تواند شما را تا اینجا ببرد. این روند دانش و بینش بیشتری نسبت به هر نوع "فکر کردن از طریق آن" را به شما می‌دهد.
این همان اصل به کار گرفتن MVP برای محصولات یا ویژگی‌های جدید برای تجارت است. این رویکرد همچنین از این مزیت برخوردار است که می‌توانید نسخه اول خود را نشان داده و بازخورد را دریافت کنید. یا سوال کنید.
ممکن است شما یک مشکل را شناسایی کنید، اما حل کامل آن دشوار باشد. بیایید این را بپذیریم و به سمت کشف سایر موانع دیگر که هنوز آن‌ها را نمی‌شناسیم حرکت کنیم. پذیرش سازش مانع از گیر افتادن شما می‌شود.
حتی اگر شما نرسید تا آن مشکل را حل کنید، می‌توانید به مشتری خود بگویید: این تمام برنامه است، ما می‌دانیم که باید این قسمت را بهبود ببخشیم، اما تا حدودی کار می‌کند. این گفته بسیار بهتر از این است که بگوییم: برنامه تاخیر خواهد داشت، زیرا زمان زیادی طول کشید تا فلان بخش را بسازیم. اما نگاه کنید این بخش به خوبی کار می‌کند، حالا ما می‌رویم تا بقیه کار را انجام دهیم.
3. با دنیای بیرونی شروع کنید
موارد زیادی وجود دارد که می‌توانید کنترل کنید و چیزهایی که نمی‌توانید. گاهی اوقات ممکن است مواردی وجود داشته باشد که شما نمی‌توانید به خوبی کنترل کنید. مثلا وقتی در حال کار بر روی یک API هستید. در عرض چند دقیقه مستندات API را می‌خوانید. خیلی راحت به نظر می‌رسد. یک مجموعه داده آزمایشی ایجاد کرده و شروع به نوشتن کد می‌کنید. و سپس آن را با API واقعی تست می‌کنید.
چند روز بعد کار شما تقریبا تمام شده و فکر می‌کنید که یک API خوب و تمیز طراحی کرده‌اید. اما همین طور که پیش می‌روید متوجه می‌شوید که یک چیز اشتباه است. کل روز آن را چک می‌کنید و کار خود را مضاعف می‌سازید. اما فایده‌ای ندارد.
روزها می‌گذرد و شما درگیر آن خواهید بود و به جایی می‌رسید که احساس می‌کنید شکست خورده‌اید. بالاخره بعد از روزها و شاید هفته‌ها کار شما به اتمام می‌رسد (البته نه با کدنویسی تمیز).
بنابراین ممکن است کارهایی وجود داشته باشد که شما نتوانید کنترل کنید. پس هر فرضیاتی که در مورد محیط دارید را تایید کنید. از روش‌های دستی و کم هزینه برای تست کردن کارها در اسرع وقت استفاده کنید.
اگر مشکلی در کار وجود دارد، به سرعت آن را با مشتری در میان بگذارید. وقتی شما زود اقدام به کاری می‌کنید، مردم به طرز شگفت‌آوری با مشکلات خوب برخورد می‌کنند. کشف سریع مشکلات راه‌حل‌های امکان‌پذیرتری را به روی شما باز می‌کند.
4. یک خط روشن بکشید
هنگامی که شروع به کار بر روی یک ویژگی جدید برای سیستم موجود می‌کنید، با تعریف نحوه اتصال آن با کد موجود شروع کنید. البته شما باید از اصول SOLID و غیره پیروی کنید. اما بخش اصلی ساده‌تر از آن است.
وقتی شما به روشنی مسائل را تعریف کنید باعث بهبود راه‌حل شما می‌شود. این امر شما را وادار می‌کند تا به سوالات اصلی پاسخ دهید: کاربران یا سیستم چگونه از کد من استفاده می‌کنند؟ چه ورودی‌هایی دریافت می‌کنند؟ چه خروجی‌هایی باید تولید کنم؟
این مساله حتی اگر شما هنوز چیز زیادی در مورد سیستمی که بر روی آن کار می‌کنید نمی‌دانید نیز صادق است. این یک فرصت خوب برای کشف ناشناخته‌ها قبل از عمیق شدن در آنچه که از قبل می‌دانید است.
5. بیش از حد DRY را اعمال نکنید
DRY مخفف Don't Repeat Yourself (جلوگیری از تکرار) است. این احتمالا ساده‌ترین قانونی است که باید از آن پیروی کنید. به محض دیدن خطوط تکراری کد، فکری برای آن کنید. این می‌تواند یک کلاس اولیه، helper method یا هر چیز دیگری باشد.
پس چه اتفاقی می‌افتد؟ نفرات بعدی می‌آیند و برای پوشش دادن موارد بیشتر کد مشترک را باید تغییر دهند. آن‌ها موارد دیگری را اضافه می‌کنند. به زودی 5 خط اولیه ساده به 30 خط تبدیل می‌شود و تشخیص اینکه چه اتفاقی می‌افتد دشوار است.
خوانایی ضعیف داد و ستد خوبی برای تکرار کد نیست.
بهتر است که خطوط تکراری را حذف کنیم. شما می‌توانید هر نمونه را آن طور که می‌خواهید تغییر دهید.
یک واقعیت کلیدی
هوشمندانه کار کردن در رابطه با کد بهتر نیست. بلکه درمورد این است که می‌دانیم چه کاری باید انجام دهیم، و با اطمینان به سمت هدف پیش می‌رویم.
توسعه‌های بزرگ و چالش‌برانگیز ناشناخته‌ها را به همراه خواهند داشت. آن‌ها را در آغوش بگیرید و یاد بگیرید با آن‌ها کار کنید.
اگر مسائل را ساده نگه دارید و انتظارات مربوط به نتایج را با تیم، رئیس، مشتری و به طور ایده‌آل با هر شخصی هم‌تراز کنید، تولید بیشتری خواهید داشت. موفق باشید!
نظرات کاربران در رابطه با این دوره