دارم کتابی رو میخونم با عنوان Thinking Architecturally نه تنها اطلاعات خوبی در زمینه مدیریت پروژه و برنامه نویسی می دهد که در زمینه های دیگر نیز قابل بسط و استفاده می باشد.
کتاب ساده و روانی با صفحات کم هست از این کتاب هایی که راحت میشه خوند و خیلی خسته کننده نیست
بخش هایی از اون رو سعی می کنم میخونم بنویسم و دراینجا قرار بدم
فصل یکم
تکنولوژی تغییر می کند
اگر مدتی در دنیای نرم افزار بوده اید، می دانید که تکنولوژی تغییر می کند. این اجتناب ناپذیر است. در اوایل کارم ناامید شدم زیرا فکر می‌کردم «موج» برخی فناوری‌ها را از دست داده‌ام. چیزی که در آن زمان قدردان آن نبودم این بود که فناوری‌های جدید بسیار شبیه اتوبوس‌ها هستند - هر 15 دقیقه یا بیشتر یکی می‌آید. به عنوان معمار، باید به خاطر داشته باشیم که نمی‌توانیم جلوی تغییر را بگیریم، اما می‌توانیم آن را مدیریت کنیم. در ادامه این فصل، ما دروسی را که گذشته می‌تواند آموزش دهد را پوشش می‌دهیم، یادآوری این که نمی‌توانید آینده را پیش‌بینی کنید و چرا نباید آنقدر سریع مهارت‌های میراث را کنار بگذارید.
آیا قبلاً این را ندیده بودیم؟
کسانی که نمی توانند گذشته را به خاطر بیاورند محکوم به تکرار آن هستند. - جورج سانتایانا
برای اکثر توسعه دهندگان، زمان با اولین زبانی که یاد گرفتند شروع شد. آن تجربه اولیه تبدیل به ستاره اصلی ما می شود و ما اغلب زبان های جدید را با آن تجربه افتتاحیه مقایسه می کنیم، که به داستان منشأ برنامه نویسی ما تبدیل می شود. در حالی که زبان اول ما واقعاً اساسی است، اما می تواند ما را کوته بین بگذارد. بسیاری از توسعه دهندگان درک نمی کنند که ویژگی 'جدید' که به زبان مورد علاقه آنها اضافه شده است، در واقع بخشی از برنامه نویسی برای دهه ها بوده است. هنگامی که جاوا 8 عبارات لامبدا را اضافه کرد، برخی از توسعه دهندگان متوجه نشدند که چرا به این ویژگی 'جدید فانگل' نیاز دارند. من مطمئن هستم که بیش از چند برنامه نویس Lisp این ادعا را سرگرم کننده دانسته اند.
با تجربه، متوجه خواهید شد که فناوری ها اغلب خود را تکرار می کنند
برای لحظه ای به برنامه های توزیع شده فکر کنید. امروزه صحبت در مورد میکروسرویس ها و فناوری های بدون سرور مد شده است. اما یک دقیقه عقب نشینی کنید و به تکامل از سرورهای سفارشی به ماشین های مجازی و کانتینرها نگاه کنید. اگر کمی چشمک بزنید، پژواک معماری های سرویس گرا را تشخیص خواهید داد.
در واقع، برخی از مردم دوست دارند بگویند میکروسرویس ها فقط SOA را به درستی انجام می دهند. تمام پست های وبلاگ، مقالات، کتاب ها و گفتگوهای کنفرانس اختصاص داده شده به SOA را به خاطر دارید؟ اما حتی بیشتر به عقب برگرد. آیا SOA بسیار شبیه Enterprise Java Beans نیست؟2 آنها «فناوری آن» بودند که در سال‌های نه چندان دور، بیش از چند آهنگ کنفرانس را پر می‌کردند. حتی در آن زمان، صنعت ما همچنان بر روی شانه‌های آنچه که قبلاً آمده بود، ادامه داد. یک قدم دیگر به عقب و ممکن است شروع به دیدن خطوط کم رنگ CORBA کنید...
اما این بدان معنا نیست که اوضاع بهبود نیافته است. رایانش ابری بسیاری از محدودیت‌هایی را که ما را به سمت زیرساخت‌های مشترک سوق می‌دهد و همه پیامدهای آن حذف می‌کند. با این حال، مهم است که بدانیم فناوری امروز چگونه از گذشته خود مطلع شده است. گذشته آینده را شکل می‌دهد و با آن زمینه تاریخی، می‌توانید حدس‌های دقیقی در مورد اینکه یک فناوری معین به کجا می‌رود، بسازید.
وقتی بدانید صنعت ما از کجا آمده است، می توانید شروع به شناخت الگوها کنید. توجه به یک فناوری بازیافتی شما را قادر می سازد تا از چیزی که قبلاً شکست خورده بودید، بگذرید. همچنین می‌توانید ببینید که چرا چیزی که پنج سال پیش کار نمی‌کرد امروز می‌تواند کار کند. اما برای دیدن این الگوها باید گذشته ما را مطالعه کنید.
از گذشته یاد بگیر
گذشته را مطالعه کنید، اگر می خواهید آینده را خدایی کنید. – کنفوسیوس
برخلاف بسیاری از صنایع دیگر، صنعت ما کار خوبی برای یادگیری از گذشته خود انجام نمی دهد. هر رشته ای تاریخ خود را مطالعه می کند به جز رشته ما. یک برنامه درسی معمولی علوم کامپیوتر ممکن است شامل یک نیاز 'تاریخچه زبان های برنامه نویسی' باشد، اما به طور کلی به گذشته کوتاه می پردازیم. تمرکز همیشه زبان پیشرفته، آخرین چارچوب، داغ جدید است. اما بدون آن مواجهه با گذشته، نمی‌توانیم زمانی را که واقعاً در حال تکرار است، درک کنیم. نرم افزار یک صنعت نابالغ است. حقیقت این است که ما دوست نداریم در مورد اشتباهات خود صحبت کنیم. اما ما باید. من هرگز اول آگوست 2007 را فراموش نمی کنم.
آن شب، پل روی رودخانه می سی سی پی در ترافیک ساعات شلوغی فرو ریخت و 13 نفر کشته و 145 نفر دیگر زخمی شدند. من در همان اوایل آن هفته روی همان پل بودم. در پاییز آن سال، مهندسان شاغل (و همچنین دانشجویان مهندسی) در سراسر جهان آن فاجعه را مطالعه کردند. هنگامی که هیئت ملی ایمنی حمل و نقل گزارش تصادف خود را منتشر کرد، من تضمین می کنم که مهندسان شاغل (و همچنین دانشجویان مهندسی) در سراسر جهان آن را بخوانند. و (امیدوارم) نقص طراحی که در نهایت منجر به آن فاجعه شد، در طرح های بعدی پل تکرار نشود.
----
ادامه دارد ...
دارم به بخش های این کتاب فکر میکنم و بجای تفکر منفعل در سیلات تکنولوژی مدیریت استفاده از امکانات بنظرم خیلی مهم می باشد.
