اصول ، الگوها و شیوه های برنامه نویسی متوسط

این اولین پاس من در لیستی از ضد قیمتی ، ضد الگوی و ضد عمل است که برنامه نویسی متوسط را تشکیل می دهد. من امیدوارم که این لیست را اصلاح کرده و این لیست را بر اساس بازخورد جامعه به روز کنید ، بنابراین لطفاً نظر خود را بگذارید یا با من تماس بگیرید تا به من اطلاع دهید که چه چیزی را از دست داده ام ، و اگر شما با یک نام و پیوند به شما اعتبار می دهم اگر شما با نام و پیوند به شما اعتبار می دهم'D Like.

اصول

Beats Fast درست (FBR) - مهمتر از این است که کاری را انجام دهید که احتمالاً کار کند ، یا همین حالا کار می کند حتی اگر تغییر بعداً سخت باشد ، از اینکه وقت خود را صرف اطمینان از صحیح بودن یا طراحی خوب کنید. این تفکر کلاسیک "Cowboy Coder" یا "برنامه نویس نوار مجرای" است ، و گاهی اوقات ممکن است مدیریت با بیان اینکه برای یک ویژگی خاص یا نمونه اولیه ، سرعت از هر چیز دیگری مهمتر است. با این حال ، برای پروژه های معمولی و بلند مدت که شخصی برای سالهای آینده مجبور به حفظ برنامه است ، این می تواند یک اصل بسیار گران قیمت باشد.

اصل (های) ترجیحی

"توجه مستمر به تعالی فنی و طراحی خوب باعث افزایش چابکی می شود" - مانیفست Agile

Creaturitis Feaping Driven (FCD) - پروژه ای که با استفاده از FCD ساخته نشده است ، هرگز چرخه ای را انجام می دهد که به طور مناسب تکمیل شود. درست وقتی می توانید افق را ببینید ، کسی در تیم نازل یا ارزشی دیگری را اضافه می کند که به شدت عاشق آن هستند.

اصل (های) ترجیحی

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

"نرم افزار کار را به طور مکرر ، از دو هفته تا دو ماه ، با اولویت به بازه زمانی کوتاه تر تحویل دهید."- مانیفست

منبع

راجر پنس (با اعتبار به PL Plauger برای اصطلاح "ایجاد Creaturitis")

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

برخی از سؤالات معمولی "فرضیه":

"منظورت چیست ، شما نمی توانید پیکربندی را روی یک میزبان مشترک تغییر دهید؟"

"چرا کاربر زباله ها را در نوار آدرس تایپ می کند؟"

"چه کسی سعی می کند یک پرونده اسکریپت را از طریق این فرم بارگذاری تصویر قرار دهد؟"

"چرا کسی باید SQL را در یک جعبه متنی با برچسب "نام کاربری" تایپ کند؟"

ADP اغلب منجر به اشکالات و حفره های امنیتی "مسیر غم انگیز" می شود.

اصل (های) ترجیحی

مقداری کدنویسی دفاعی را تمرین کنید و بررسی کنید که ورودی های روش شما همان چیزی است که قبل از کار با آنها انتظار دارید.

با مشتری تعریف کنید که در صورت وقوع غیرمنتظره چه اتفاقی باید بیفتد و با این رفتار مانند هر ویژگی دیگری رفتار کنید.

یک تست برای "مسیر شاد (منتظره)" بنویسید اما چندین تست برای "مسیرهای غم انگیز" مختلف بنویسید که ممکن است همه چیز اشتباه پیش برود.

منبع

فلیکس پلشویانو

اصل بازاریاب تلفنی (TP) برنامه نویسی در مورد کنترل است و بهترین راه برای اطمینان از اینکه نرم افزار شما دقیقاً همان کاری را که می خواهید انجام می دهد این است که شما دقیقاً زمان و نحوه رفتار آن را همیشه مدیریت کنید. اصل بازاریاب تلفنی به این صورت خلاصه می شود: «با هر چیزی که ممکن است در سیستم برای برنامه خود نیاز دارید تماس های زیادی برقرار کنید». اگر کنترل را به ماژول های دیگر واگذار کنید یا به سیستم یا چارچوبی اجازه دهید کارهایی را از طرف شما انجام دهد، آیا واقعاً می توانید مطمئن باشید که آنها این کار را به درستی انجام خواهند داد؟و در هر صورت، فراموش نکنید که برای هر چیز واقعاً مهمی همیشه می توانید **چرخ (RTW)** را دوباره اختراع کنید و به جای آن، روال خود را در همه جا فراخوانی کنید.

اصل (های) ترجیحی

از اصل هالیوود پیروی کنید: «به ما زنگ نزنید. ما با شما تماس خواهیم گرفت.»برای مثال اگر متوجه شدید که در حال ایجاد Response. Write یا Console. Write یا Window. Draw در منطق کسب و کار خود هستید، احتمالاً طراحی شما از این اصل سود می برد.

Dependency Inversion Principle همچنین می تواند به حذف وابستگی هایی از این دست کمک کند و توانایی تماس گیرنده را برای تبدیل شدن به تماس گیرنده تنظیم کند.

(اصول بیشتری برای برنامه نویسی متوسط دارید؟ در زیر نظر بدهید!)

الگوها

الگوی چسبندگی استاتیک (SCP) - روش ها و اشیاء استاتیک (جهانی) اغلب روشی مناسب برای افزودن برخی قابلیت ها به یک برنامه کاربردی بدون صرف نگرانی در مورد مکان «مناسب» آن برای زندگی است. استفاده از روش های استاتیک برای عملیات های واقعاً بدون حالت که فقط بر روی پارامترهای ارسال شده کار می کنند و وابستگی دیگری ندارند، خوب است، اما مشکلات زمانی به وجود می آیند که روش های ایستا اشیاء را نمونه سازی می کنند یا روش های دیگر را خارج از محدوده پارامترهای ارسال شده فراخوانی می کنند. هنگامی که این برای مدتی ادامه یافت، وارد کردن درزها به برنامه برای جدا کردن اجزای آن از یکدیگر می تواند بسیار دشوار باشد - شروع به "چسبیدن استاتیک" شده است.

الگو(های) برگزیده

اصل وارونگی وابستگی. تماس با روشهای استاتیک وابستگی مستقیم است که به راحتی نمی توان تزریق کرد. آنها را با رابط ها و تماس ها به روش های نمونه در مورد اشیاء تزریق شده جایگزین کنید.

خواندن بیشتر

روشهای استاتیک مرگ تا آزمایش است

منبع

باب لی ، (از Guice) - (Vianate Kohari)

الگوی سازه های جلیقه ای (VSP) - هنگامی که ویژگی ها آن را حذف می کنند ، چندین لایه ، بیت هایی که دیگر استفاده نمی شوند "فقط در مورد" باقی مانده اند. همانطور که در زیست شناسی ، ساختارهای جلیقه ای معمولاً در یک بیماری انحطاط ، آتروفی یا ابتدایی قرار دارند و تمایل دارند بسیار متغیر تر از قسمت های مشابه باشند. اگرچه ساختارهایی که معمولاً "جلیقه" خوانده می شوند ، عمدتاً یا کاملاً بی عملکرد هستند ، یک ساختار جلیقه ممکن است عملکردهای کمتری را حفظ کند یا عملکردهای جدیدی را ایجاد کند.

الگو(های) برگزیده

ساختارهای جلیقه ای به طور معمول علائم یک معماری گل آلود هستند ، جایی که می توان گفت که یک ویژگی به کجا ختم می شود و دیگری شروع می شود. همچنین Big Ball of Mud را ببینید.

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

منبع

ریچارد دینگوال

پرچم های روی اشیاء (FOO) - به جای استفاده از اشیاء ، پلی مورفیسم یا هیئت ، خیلی سریعتر است که فقط یک پرچم را به یک کلاس اضافه کنید و آن را در معرض دید قرار دهید. سپس در هر نقطه از سیستم که به آن شرایط اهمیت می دهد می تواند به سادگی IF (foo. isbar ()) را اضافه کند<…>بند برای مقابله با این شرایط. چه کسی به وراثت احتیاج دارد؟

الگو(های) برگزیده

شرطی را با پلی مورفیسم ، اصلاح مجدد ، P255 (آنلاین) جایگزین کنید

منبع

کرتیس کولی

God Class (TGC)-همه می دانند که برنامه نویسی شی گرا بسیار عالی است زیرا به ما اجازه می دهد تا از کلاس ها استفاده کنیم و دوباره استفاده کنیم تا تمام کارها را در برنامه های خود انجام دهیم. و البته ، هیچ کس نمی خواهد برای انجام کاری به دنبال کلاس مناسب باشد و هرچه کلاس های بیشتری داشته باشید ، هر یک قدرت کمتری نیز دارد. خیلی بهتر است فقط بنویسید (در اینجا صدای ارباب حلقه ها) یک کلاس برای حاکم کردن همه آنها ، یک کلاس استاد ، قادر به انجام هر کاری و هر آنچه ممکن است درخواست شما باشد. و چه کسی اهمیت می دهد اگر 5000 خط کد باشد؟

الگو(های) برگزیده

از اصل مسئولیت واحد (SRP) پیروی کنید ، که بیان می کند که یک کلاس فقط باید یک دلیل برای تغییر داشته باشد. اگر کلاس شما بیش از یک مسئولیت دارد ، باید به چندین کلاس تقسیم شود.

منبع

کوری کوگان

کلاس Iceberg (TIC) - حدود 88 ٪ توده کوه یخ زیر آب است. چه مقدار از کلاس شما در آنجا پایین است؟کلاس را در نظر بگیرید که روشهای عمومی کمتری نسبت به روشهای خصوصی دارد - گاهی اوقات بارها و بارها از عملکرد عمومی. آیا چنین کلاسهایی از طراحی خوبی برخوردار هستند یا ممکن است چندین کلاس بالقوه را که منتظر هستند از هم جدا شوند ، نشان دهند؟

الگو(های) برگزیده

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

منبع

مایکل پرز

معماری محور داده (DDA) - توسعه دهندگان حرفه ای می دانند که ساخت و ساز برنامه ها در لایه ها یا ردیف ها بهترین روش است. رویکرد سنتی این است که حداقل 3 لایه از این دست داشته باشید: UI ، تجارت و داده ها. هنگامی که به دنبال الگوی DDA سازماندهی می شود ، لایه تجاری به لایه داده ها مراجعه می کند و لایه UI به لایه تجارت مراجعه می کند. این بدیهی است ، از آنجا که به وضوح لایه تجاری باید بتواند داده ها را واکشی و پابرجا کند ، بنابراین باید به لایه داده مراجعه کند ، و لایه UI نیاز به ارائه رابط به لایه تجاری دارد و بنابراین باید آن را ارجاع دهد. فواید این رویکرد لایه بندی شده این است که لایه داده می تواند از لحاظ تئوری کاملاً بازنویسی شود بدون اینکه هیچ تغییری در لایه UI ایجاد شود. فقط لایه یک قدم باید تغییر کند (و باید تغییر کند ، زیرا هر رابط مورد استفاده نمی تواند با استفاده از این روش متعلق به لایه تجاری باشد ، زیرا در این صورت لایه داده برای اجرای چنین رابط هایی نیاز به مراجعه به لایه تجاری دارد.، ایجاد یک مرجع دایره ای.

الگو(های) برگزیده

لایه تجاری برنامه باید هسته اصلی آن باشد. در صورت امکان نباید به هر چیزی بستگی داشته باشد و مطمئناً به زیرساخت هایی مانند دسترسی به داده ها نیست. تمام وابستگی های پروژه باید به لایه / هسته تجاری اشاره کند ، که باید رابط هایی را که به همکاران خود نیاز دارد ، تعریف کند. به معماری پیاز و معماری شش ضلعی مراجعه کنید.

اصل وارونگی وابستگی می تواند در دستیابی به این معکوس جهت مرجع پروژه ارزشمند باشد.

وسواس بدوی (PO) - ایجاد انواع چیزی است که باید از آن اجتناب کرد - هرچه انواع بیشتری در برنامه خود داشته باشید، فایل های بیشتری وجود دارد و پیچیده تر به نظر می رسد. به علاوه، همه می دانند که اعداد صحیح، رشته ها و زمان های تاریخ بسیار سریع تر از کلاس های سفارشی کار می کنند. چه کسی اهمیت می دهد که شما هیچ ایده ای ندارید که یک آرایه ناهموار از int،int، int قرار است چه باشد این همان چیزی است که نشانه گذاری مجارستانی به کار می رود، درست است؟

الگو(های) برگزیده

از انواع برای محدود کردن رفتار و انتقال هدف استفاده کنید. اگر پول کار می کنید و روش هایی برای انتقال وجه از حساب A به حساب B دارید و مبالغ منفی نباید مجاز باشد، از یک نوع پول سفارشی استفاده کنید که فقط می تواند مقادیر مثبت داشته باشد. اگر می خواهید مقداری داده را به View ارسال کنید، یک کلاس ViewModel با تایپ قوی (یا حتی یک شی پویا با ویژگی های نام گذاری شده) به جای یک تاپل در نظر بگیرید.

(آیا الگوهای بیشتری از برنامه نویسی متوسط دارید؟ نظر خود را در زیر بنویسید!)

تمرین ها

** یافت شده در اینترنت (FOI) **وقتی با مشکلی مواجه می شوید، سریع ترین راه حل اغلب جستجو در اینترنت است. این یک روش ارزشمند و مؤثر برای تحقیق در مورد راه حل ها است. با این حال، رویکرد برنامه نویس متوسط در این مورد این است که اولین پست وبلاگ یا پاسخ فروم را که به نظر می رسد برای مشکل مورد نظر مناسب است، پیدا کند و سپس کد را برش داده و جایگذاری کند، آن را هک کند تا زمانی که کامپایل شود، وبرنامه را اجرا کنید تا ببینید کار می کند یا خیر. اگر چنین شد، به آتش بعدی بروید. اگر نه، به هک کردن ادامه دهید تا این کار انجام شود یا به مورد بعدی در نتایج جستجو بروید.

تمرین(های) ترجیحی

یک راه حل را با استفاده از کد پیدا شده مشخص کنید و ببینید آیا در سناریوهای مختلف کار می کند یا خیر.

چند آزمایش بنویسید تا تأیید کنید که رفتار کد آنچه را که ادعا می کند انجام می دهد و مطابق انتظارات شما عمل می کند.

انواع رویکردهای ممکن برای مشکل را مرور کنید و سعی کنید قبل از اینکه به راه حل احتمالی بپردازید، مشخص کنید که آیا واقعاً سؤال درستی می پرسید یا خیر.

بهینه سازی زودرس (PO) توسعه دهندگان دوست دارند کدی بنویسند که در سریع ترین زمان ممکن اجرا شود. مطمئناً عملکرد تقریباً در همه نرم افزارها یک عامل است، اما مانند همه عوامل باید با سایر ویژگی ها مانند قابلیت نگهداری و سرعت ارائه ویژگی سنجیده شود. تمرین بهینه سازی کد قبل از اینکه کسی بداند در کد فعلی تنگنا وجود دارد یا اینکه عملکرد تولید واقعی برنامه بدون چنین بهینه سازی کافی نیست، منجر به اتلاف می شود. در اغلب موارد، کدی که بهینه می شود یا به اندازه کافی خوب است، یا به سادگی گلوگاه نیست و بنابراین هر گونه بهینه سازی انجام شده روی آن تأثیری بر عملکرد واقعی برنامه نخواهد داشت.

تمرین(های) ترجیحی

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

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

Copy-Paste-Compile (CPC) - گاهی اوقات یک برنامه یک اشکال را نشان می دهد یا به عملکرد جدیدی نیاز دارد که قبلاً در جای دیگری اصلاح شده است. تنها کاری که باید انجام شود این است که بخش صحیح کد را پیدا کنید، آن را کپی کنید و در بخشی از کد که به این رفتار نیاز دارد، جایگذاری کنید. مطمئن شوید که هنوز کامپایل می شود و آن را بررسی کنید. یک کار دیگر کامل شد!

تمرین(های) ترجیحی

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

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

(اوه، آیا کسی موارد بالا را کپی و پیست کرده و فراموش کرده است که آن را به روز کند؟)

خود را تکرار نکنید و منطقی که تکرار می شود را به روش ها یا اشیاء خاص خود حرکت دهید. هر جا که آن را در کد خود پیدا کردید، با تکثیر مبارزه کنید.

اختراع مجدد چرخ (RTW)-بخشی از یک برنامه نیاز به یک الگوریتم یا ابزار کمی دارد که بدون شک شخص دیگری قبلاً با آن روبرو شده است ، اما به جای استفاده از یک کلاس چارچوب موجود یا راه حل مشهور صنعت ، توسعه دهنده این فرصت را به عنوان فرصتی برای نوشتن می گیردبهترین ابزار XXX تاکنون. نوشتن یک الگوریتم یا بیان منظم اغلب سرگرم کننده تر از ارائه فرم یا گزارش شغلی خسته کننده دیگر است ، اما اختراع مجدد چرخ ارزش افزوده ای نمی کند.(همچنین گاهی اوقات در اینجا اختراع نشده است (NIH)).

تمرین(های) ترجیحی

می دانید و از چارچوب استفاده می کنید. اگر شما یک توسعه دهنده .net هستید ، چارچوب .net دارای یک تن عملکرد در آن است و معمولاً مکان اول خوبی برای نگاه کردن است.

دانش را در سازمان خود به اشتراک بگذارید. احتمالاً شخص دیگری در شرکت شما قبلاً این مشکل را حل کرده است.

به سرعت زمان لازم را برای ساخت عملکرد از ابتدا و هزینه زمان خود تخمین بزنید. ببینید آیا یک ابزار تجاری می تواند کار را کمتر انجام دهد ، و ببینید که آیا مدیریت مایل به سرمایه گذاری در چنین ابزاری است یا خیر.

نسخه های پوشه (CFV) را کپی کنید - گاهی اوقات ، تغییر در یک برنامه به اندازه کافی بزرگ است که به نظر می رسد ترسناک است (حتی برای یک رمزگذار گاوچران) ، بنابراین آنها تصمیم می گیرند پشتیبان تهیه کنند. البته ، هیچ نرم افزار کنترل منبع در حال استفاده نیست ، بنابراین به طور طبیعی راه رفتن این است که یک نسخه از پوشه حاوی پروژه تهیه کنید (و اگر شما حرفه ای فوق العاده هستید ، آن را از "کپی (2) Fooproject" تغییر نام دهیدبه چیزی مفیدتر).

تمرین(های) ترجیحی

از کنترل منبع استفاده کنید! لطفاً ، اگر هنوز از نوعی کنترل منبع استفاده نمی کنید ، امروز این کار را شروع کنید!

به طور جدی ، از کنترل منبع استفاده کنید.

منبع

Brendan Enrick به این تیم کمک کرد.

Golden Hammer (GH) - چکش طلایی به یک زبان ، چارچوب ، کتابخانه یا ابزاری که با آن آشنا هستید ، اشاره دارد و با آن مطمئن هستید که می توانید هر مشکلی را حل کنید. هنگام استفاده از چکش طلایی ، هر مانعی مانند ناخن به نظر می رسد ، و هرگونه پیشنهادی از سوی هم تیمی ها مبنی بر اینکه سایر ابزارها ممکن است بهتر از این کار باشند ، ناشناخته باشند.(با نام مستعار نقره ای ، گلوله جادویی)

تمرین(های) ترجیحی

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

منبع

پیتر هیکمن

Toy Toy (ST) - اسباب بازی براق جدیدترین ، جالبترین ابزار یا فناوری موجود است. پتانسیل آن بی حد و مرز است. این می تواند گرسنگی جهان را حل کند و آرامش پایدار را در خاورمیانه به وجود آورد. اما هنوز هم بتا است ، بنابراین شما باید مدتی را برای یادگیری آن صرف کنید ، زیرا هنوز هیچ اسناد برای آن وجود ندارد و هیچ کس که از آن چیزی نشنیده اید ، یک برنامه زنده را منتشر کرده است که با آن اجرا می شود. شما مطمئن هستید که هر کاری که برنامه به آن نیاز دارد انجام خواهد داد ، هرچند ، بدون تلاش بیش از حد بیش از حد ... (این مربوط به تمرین Golden Hammer است ، در بالا ، اما به حالت مخالف است. گاهی اوقات کسی را پیدا خواهید کرد که فکر می کند اسباب بازی براق آنها استیک چکش طلایی ، هر چند!).

تمرین(های) ترجیحی

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

منبع

کوین بابکاک (تغییر نام "اسباب بازی براق" توسط استیو اسمیت)

(آیا شما بیشتر در مورد برنامه نویسی متوسط دارید؟ نظر زیر را بگذارید!)