این سوالی است است که ماتیاس کارلسون(Mattias karlsson§)، در کتاب 97Things Every Programmer Should Know،از خواننده خود پرسیده است. قبلا اینجا §درباره‌ی کتاب 97 چیزی که یک برنامه‌نویس باید بداند مطلبی را نوشته‌ام و در اینجا لازم به توضیحات اضافی نیست و یک راست می‌روم سر اصل مطلب.
در حقیقت ماتیاس کارلسون در کتاب 97 چیزی که یک برنامه‌نویس باید بداند در صفحه 28 نمی‌گوید که چرا باید کُد را بازبینی کرد، بلکه می‌گوید، بهتر است که شما کُد را بازبینی کنید.
مطالعه کتاب گیک شدن Being Geek(+) را بعد از مدت ها شروع کرده ام. ابتدا کتاب گیک شدن را که تهیه کردم از عنوان اش خیلی خوشم عنوانش نیامد. Geek
چون امروزه همه جا از این صفت استفاده می شود. از شغل شریف گارسونی تا مهندسی معدن.(بیخیال)
التبه کتاب، گیک شدن را به معنای خاصی تعریف کرده است. همین که مطالعه کتاب را در صفحات اولیه شروع می کنید، با System Thinker شروع می کند.
کتاب The Design of Design(+) ( طراحیِ یک طراحی ) ، نوشته Frederick Phillips "Fred" Brooks Jr (+) ، یکی از بهترین و جامع ترین کتاب های موجود در زمینه طراحی نرم افزار است .
این کتاب یک کتاب مقدماتی نیست. بهتر بگویم ، یک کتاب پیشرفته طراحی نرم افزار است. یعنی شما باید پایه و اصول طراحی نرم افزار را بدانید. هدفم از معرفی این کتاب بدین دلیل است که بعد از اتمام هر فصل از نقشه راه یکی از فصل های این کتاب را با هم بحث می کنیم.
طراحی نرم افزار یکی از بهترین و زیربنایی ترین شغل های مربوط به صنعت نرم افزار است. فیلد طراحی نرم افزار در اکثر مواقع با طراحی فتوشاپ و طراحی وب اشتباه گرفته می شود.
در زمینه طراحی نرم افزار بیشتر به این می پردازیم که یک نرم افزار
Continuous Delivery is the ability to get changes of all types—including new features, configuration changes, bug fixes and experiments—into production, or into the hands of users, safely and quickly in a sustainable way.
Our goal is to make deployments—whether of a large-scale distributed system, a complex production environment, an embedded system, or an app—predictable, routine affairs that can be performed on demand.
We achieve all this by ensuring our code is always in a deployable state, even in the face of teams of thousands of developers making changes on a daily basis. We thus completely eliminate the integration, testing and hardening phases that traditionally followed “dev complete”, as well as code freezes.
مقدمه :
چرا تعداد زیادی از پروژه های نرم افزاری با شکست رو به رو می شود ؟
با وجود اینکه هم نیرو داریم و هم بودجه کافی و هم زیر ساخت مناسب .
چگونه می توان با مشکلاتی که در ساخت نرم افزار پدید می آید ، برخورد مناسبی داشته باشیم. به گونه ای که متحمل کمترین خسارت های مالی و زمانی (تاخیرات تحویل ) در ساخت نرم افزار خود شویم ؟
با توجه به نمودار مربوط به ساخت نرم افزار (برگرفته از کتاب Code Complete ) در فازهای مختلف ، متوجه میشویم که بهتر است که در همان ابتدا، نقص های نرم افزاری شناخته و بر طرف شود تا هزینه های سنگینی که در ادامه ساخت نرم افزار با آن مواجه می شویم را ، کاهش دهد.
