Developer Advocate
رفتن به کانال در Telegram
1 035
مشترکین
اطلاعاتی وجود ندارد24 ساعت
اطلاعاتی وجود ندارد7 روز
-130 روز
آرشیو پست ها
1 035
Technology Strategy Patterns: Architecture as Strategy
کتاب: استراتژی فناوری برای معماران و مدیران فناوری
چگونه ایدههای خود را به زبان کسبوکار بیان کنیم؟
اغلب به متخصصان فناوری توصیه میشود که برای شنیده شدن، درک شدن، و تأمین بودجه ایدههایشان باید "به زبان کسبوکار صحبت کنند"، اما این زبان چیست؟ این کتاب به شما یک جعبه ابزار (Toolkit) ارائه میدهد تا با استفاده از الگوها و الگویهای عملی، زبان مشترکی برای ایجاد و انتقال استراتژیهای فناوری ایجاد کنید.
نویسنده و تجربهها
ابن هیویت (Eben Hewitt) این کتاب را بر اساس 39 الگو که طی یک دهه به عنوان CTO، CIO و معمار ارشد در شرکتهای فناوری جهانی توسعه داده است، نوشته است. این ابزارها به شما کمک میکنند تا اهداف، برنامهها و رویکردهای معماری خود را به گونهای تعریف و بیان کنید که برای مدیران اجرایی قابل درک، تأیید و اجرا باشد.
موارد کلیدی کتاب:
معماری و استراتژی
ذهنیتی استراتژیک برای معماری اتخاذ کنید تا تأثیر مادی و معناداری بر کسبوکار داشته باشید.
چگونگی ایجاد هماهنگی میان اهداف فنی و استراتژیهای تجاری.
ایجاد استراتژی
اجزای استراتژی فناوری را با استفاده از الگوهای اثباتشده تعریف کنید.
ابزارهایی برای شناسایی مشکلات و فرصتهای کلیدی در سیستمها.
ارتباط مؤثر با مدیران
نحوه انتقال استراتژی فناوری به شکلی جذاب و مؤثر برای مخاطبان مختلف از تیمهای فنی تا مدیران ارشد.
مهارتهای ضروری برای ارائه ایدهها در قالب قابل اجرا.
یکپارچهسازی الگوها
استفاده از الگوها به صورت جداگانه برای مسائل خاص یا ترکیب آنها برای دستیابی به یک چارچوب جامع.
راهنمایی برای طراحی استراتژیهایی که مدیریت تغییرات و مقیاسپذیری را ممکن میسازد.
این کتاب برای معماران نرمافزار، مدیران محصول، مدیران فناوری، و مدیران اجرایی طراحی شده است که به دنبال راهکارهای عملی برای ایجاد و انتقال استراتژیهای فناوری هستند. با مطالعه این اثر، زبان مشترکی میان تیمهای فنی و کسبوکار خواهید یافت که شما را به رهبر موفقیت در فناوری تبدیل میکند.
@DeveloperAdvocate 🥑
1 035
Practical Process Automation: Orchestration and Integration in Microservices and Cloud Native Architectures
اتوماتسازی فرایندهای پیچیده در معماریهای مدرن
در دنیای معماری IT امروزی، میکروسرویسها و فانکشنهای سرورلس (Serverless) نقش مهمی در اتوماتسازی فرایندها ایفا میکنند. اما سؤال اصلی اینجاست: چگونه میتوان راهکارهای تجاری جامع و متصل ایجاد کرد در حالی که اجزای سیستم بهصورت مستقل و بدون اتصال مستقیم طراحی شدهاند؟
این کتاب که برای توسعهدهندگان و معماران نرمافزار نوشته شده است، چارچوبی از طریق مثالها، توصیههای عملی، و موارد کاربردی (Use Cases) ارائه میدهد تا به طراحی و اتوماتسازی فرایندهای پیچیده کمک کند.
چالشهای سیستمهای توزیعشده
در سیستمهای مدرن که توزیعشده، غیرهمزمان (Asynchronous) و واکنشی (Reactive) هستند، اتوماتسازی فرایندها نیازمند مدیریت حالت (State Handling) برای تعاملات طولانیمدت است. برند روکر (Bernd Ruecker) نویسنده این کتاب، نشان میدهد که چگونه میتوانید از فناوریهای اتوماتسازی فرایند مانند موتورهای گردشکار (Workflow Engines) برای هماهنگسازی نرمافزار، انسانها، تصمیمات یا باتها استفاده کنید.
موارد کلیدی کتاب:
مقایسه اتوماتسازی فرایند مدرن با مدیریت فرایندهای تجاری (BPM)، معماری سرویسگرا (SOA)، پردازش دستهای (Batch Processing)، استریم رویدادها (Event Streaming)، و راهکارهای دادهای (Data Pipeline).
درک نحوه استفاده از موتورهای گردشکار و مدلهای فرایندی اجرایی با استفاده از BPMN.
شناخت تفاوت بین ارکستراسیون (Orchestration) و کوریوگرافی (Choreography) و یافتن تعادل میان این دو رویکرد.
این کتاب با ارائه ابزارها و رویکردهای جدید به شما کمک میکند تا سیستمهایی بسازید که با وجود استقلال اجزا، همچنان قابلیت اتصال و هماهنگی مؤثر را داشته باشند. اتوماتسازی فرایند را از طریق مطالعه این کتاب به یک مهارت قدرتمند در پروژههای خود تبدیل کنید.
@DeveloperAdvocate 🥑
1 035
Mastering API Architecture: Design, Operate, and Evolve API-Based Systems
طراحی و مدیریت پلتفرمهای API: راهنمای عملی برای معماران نرمافزار و توسعهدهندگان
در دنیای مدرن دیجیتال، APIها دریچهای برای ارتباط مشتریان با خدمات شرکتها هستند. بسیاری از سازمانها با داشتن حضور وب، به طراحی و مدیریت APIها میپردازند، چرا که این برنامههای حیاتی نه تنها توسعهدهندگان و معماران راهحل را تحت تأثیر قرار میدهند، بلکه تمامی افراد سازمان، از مهندسان گرفته تا مدیران اجرایی (C-suite) را نیز درگیر میکنند.
اما چالش اصلی برای توسعهدهندگان و معماران، ایجاد یک پلتفرم API از پایه است.
درباره کتاب:
این کتاب راهنمای عملی ارائه میدهد تا با استفاده از آن بتوانید APIهای REST را طراحی، پیادهسازی و تست کنید. همچنین نشان میدهد چگونه از دروازههای API (API Gateways) برای ترکیب سرویسها در سطح میکروسرویس استفاده کنید. نویسندگان کتاب (James Gough، Daniel Bryant، و Matthew Auburn) استراتژیهایی ارائه میدهند که به مهندسان و سازمانها کمک میکند به سمت کلود (Cloud) مهاجرت کنند و از فناوریهایی مانند مش سرویس (Service Mesh) برای اتصال سرویسهای داخلی استفاده نمایند.
نکات کلیدی کتاب:
آشنایی با اصول API و الگوهای معماری برای ایجاد پلتفرم API
درک نحوه طراحی، ساخت و تست سیستمهای مبتنی بر API از طریق مثالهای عملی
راهاندازی، مدیریت و پیکربندی اجزای کلیدی یک پلتفرم API
استفاده از دروازههای API و مشهای سرویس بر اساس مطالعات موردی
شناخت امنیت API و آسیبپذیریهای رایج در معماری API
محافظت از دادهها و APIها با استفاده از مدلسازی تهدید (Threat Modeling) و فناوریهایی مانند OAuth2 و TLS
یادگیری توسعه سیستمهای موجود به سمت معماریهای مبتنی بر API و کلود
این کتاب با ارائه مطالعات موردی و مثالهای واقعی به شما کمک میکند تا APIهای ایمن، کارآمد و قابل توسعه طراحی کرده و از آنها برای ساخت سیستمهای مدرن بهرهمند شوید.
@DeveloperAdvocate 🥑
1 035
Software Architecture Metrics: Case Studies to Improve the Quality of Your Architecture
معیارهای معماری نرمافزار: کلیدی برای نگهداری و کیفیت معماری پروژههای نرمافزاری
معیارهای معماری نرمافزار نقشی حیاتی در قابلیت نگهداری و کیفیت معماری پروژههای نرمافزاری ایفا میکنند و میتوانند در مراحل اولیه پروژه، شما را از تجمع خطرناک بدهیهای فنی و معماری آگاه کنند. این کتاب کاربردی، با ارائه مطالعات موردی توسط معماران برجسته نرمافزار، معیارهایی را معرفی میکند که هر معمار نرمافزاری باید با آنها آشنا باشد.
درباره کتاب:
این کتاب درباره تئوری نیست؛ بلکه بر عمل و پیادهسازی متمرکز است—چیزی که آزموده شده و نتیجه داده است. شناسایی زودهنگام مشکلات معماری نرمافزار برای موفقیت پروژه حیاتی است، چرا که خطر عملکرد ضعیف را کاهش میدهد و هزینه رفع این مشکلات را بهطور قابلتوجهی پایین میآورد.
این راهنما، که توسط متخصصان حرفهای برای معماران نرمافزار و توسعهدهندگانی نوشته شده که مشتاق کشف مطالعات موردی موفق هستند، به شما کمک میکند تا بیشتر درباره اثرگذاری تصمیمها و اثربخشی اندازهگیریها بیاموزید.
نکات کلیدی کتاب:
از طریق مشارکت 10 متخصص برجسته، این کتاب معیارهای کلیدی معماری نرمافزار را به اشتراک میگذارد تا به شما در تنظیم KPIs مناسب و اندازهگیری نتایج کمک کند. در این کتاب خواهید آموخت:
چگونه بررسی کنید که معماری نرمافزار شما چقدر به اهداف تعیینشده نزدیک است
انتخاب معیارهای مناسب برای پیگیری (و کنار گذاشتن معیارهای غیرضروری)
بهبود قابلیت مشاهده (Observability)، قابلیت تست (Testability) و قابلیت استقرار (Deployability)
اولویتبندی پروژههای معماری نرمافزار
ایجاد داشبوردهای مفید و مرتبط
این کتاب، راهنمایی عملی برای ایجاد معیارهایی است که نه تنها به بهبود معماری نرمافزار شما کمک میکند، بلکه تصمیمگیری بهتر و افزایش کیفیت کلی پروژههای نرمافزاری را ممکن میسازد.
@DeveloperAdvocate 🥑
1 035
Architecture Modernization: Socio-technical alignment of software, strategy, and structure
تکنیکها و اصول اثباتشده برای مدرنسازی سیستمهای قدیمی به معماریهای جدید که مزیت رقابتی جدی ارائه میدهند
برای اینکه یک کسبوکار رونق پیدا کند، نیاز به معماری نرمافزاری مدرنی دارد که با معماری سازمانی آن هماهنگ باشد. این کتاب روشهای عملی و ملموسی را ارائه میدهد که نرمافزار، محصول، استراتژی، پویایی تیم و روشهای کاری را همسو میکند. شما یاد میگیرید که معماری فنی و اجتماعی خود را همزمان تکامل دهید، وابستگیهای غیرضروری را کاهش دهید و جریان سریعتر نوآوری را در سازمان خود محقق کنید.
در کتاب مدرنسازی معماری: همترازی اجتماعی-فنی نرمافزار، استراتژی و ساختار چه میآموزید؟
شناسایی اهداف استراتژیک و چالشها از طریق تورهای گوش دادن و نقشهبرداری
بصریسازی چشمانداز کسبوکار و قابلیتهای کلیدی با استفاده از نقشهبرداری واردلی (Wardley Mapping)
ایجاد طبقهبندی محصول بهعنوان چارچوبی برای معماری
برگزاری کارگاههای بزرگ تصویرسازی (EventStorming) برای نقشهبرداری از دامنههای کسبوکار
استفاده از الگوهای توپولوژی تیمها (Team Topologies) برای شناسایی و بهبود جریان ارزش
طراحی معماریهای نرمافزاری شلکوپل (loosely coupled) و همسو با دامنه
ساخت پلتفرمهای توسعه داخلی برای تکامل سریع و قابلاعتماد
اجرای اصول و ابزارهای دادهمش (Data Mesh) برای انقلابی در مهندسی داده
ارائه نقشهراههای مدرنسازی جذاب با تمرکز بر ارائه ارزش مستمر
درباره کتاب:
مدرنسازی معماری: همترازی اجتماعی-فنی نرمافزار، استراتژی و ساختار به شما نشان میدهد که چگونه فرآیند معماری سیستمها را به یک فرآیند تحولآفرین برای کل شرکت تبدیل کنید. در هر فصل، دلایل و مزایای مدرنسازی را شناسایی میکنید، معماریای طراحی میکنید که برای کسبوکارتان مناسب باشد، و سپس رویکرد جدید خود را به روشی تدریجی و پایدار پیادهسازی میکنید.
هر تکنیک با مثالهای بینشآموز از صنعت و یک برد تعاملی Miro برای کاوش عمیقتر همراه است.
@DeveloperAdvocate 🥑
1 035
Balancing Coupling in Software Design: Universal Design Principles for Architecting Modular Software Systems (Addison-Wesley Signature Series (Vernon))
یاد بگیرید که چگونه کوپلینگ بر هر تصمیم طراحی نرمافزاری شما تأثیر میگذارد و چگونه میتوانید آن را کنترل کنید
اگر میخواهید سیستمهای نرمافزاری مدولار، قابل توسعه و پایدار طراحی کنید، باید کوپلینگ را درست مدیریت کنید. هر تصمیم طراحی شما بر کوپلینگ تأثیر میگذارد و این تأثیر بهنوبه خود گزینههای طراحی در دسترس شما را شکل میدهد. با وجود اهمیت آن، کوپلینگ اغلب آنطور که شایسته است مورد توجه قرار نمیگیرد—اما حالا زمان آن رسیده است.
از آغاز مهندسی نرمافزار، مشخص بود که مدیریت صحیح کوپلینگ برای طراحی سیستمهای نرمافزاری مدولار ضروری است. این موضوع طی سالها بهطور گستردهای مورد تحقیق قرار گرفته است، اما بخشی از این دانش فراموش شده و بخشی دیگر اعمال آن در عصر امروز چالشبرانگیز است. در کتاب متعادل کردن کوپلینگ در طراحی نرمافزار، نویسنده ولاد خنونوف مدلی ارائه میدهد که نهتنها از این دانش انباشته بهره میبرد، بلکه آن را با روشهای مدرن مهندسی نرمافزار تطبیق داده و دیدگاهی تازه برای طراحی نرمافزار مدولار ارائه میدهد.
با تکیه بر اصولی که در عمل ریشه دارند، ولاد به شما یاد میدهد که چگونه میتوانید هم پیچیدگی چندبعدی کوپلینگ را مدیریت کنید و هم از کوپلینگ بهعنوان ابزاری برای کنترل پیچیدگی و افزایش مدولاریت استفاده کنید. چهبسا این کتاب دیدگاه شما را نسبت به طراحی نرمافزار به کلی تغییر دهد.
نکات کلیدی کتاب:
تعریف مفهوم کوپلینگ و نقش آن در طراحی سیستمها و معماری نرمافزار.
توضیح اینکه کوپلینگ چگونه میتواند هم پیچیدگی سیستم را افزایش دهد و هم به مدولاریت کمک کند.
ارائه مدلی جامع که کوپلینگ را به ابزاری برای طراحی نرمافزار مدولار تبدیل میکند.
نشان دادن نحوه تکامل تصمیمات طراحی برای حمایت از رشد مداوم سیستمهای نرمافزاری.
ارائه مثالها و مطالعات موردی واقعی برای توضیح اصول مطرحشده.
نظر متخصص:
"کوپلینگ یکی از آن مفاهیمی است که زیاد درباره آن صحبت میشود اما کمتر کسی آن را به درستی درک میکند. ولاد ما را از شعارهای سادهگرایانه مانند «همیشه اجزا را از هم جدا کنید» به بحثی عمیق درباره کوپلینگ در زمینه پیچیدگی و تکامل نرمافزار هدایت میکند. اگر نرمافزار مدرن طراحی میکنید، این کتاب را حتماً بخوانید!"
--گرگور هوپ، نویسنده کتاب آسانسور معمار نرمافزار
1 035
کتاب «Logs and Telemetry» راهنمایی کاملاً عملی برای مانیتورینگ محیطهای ابری بومی و سنتی با استفاده از ابزار نظارتی Fluent Bit است. این کتاب شما را از مبانی جمعآوری لاگهای اپلیکیشن تا فیلتر کردن، مسیریابی، غنیسازی و تبدیل لاگها، متریکها و تریسها همراهی میکند.
مطالبی که در این کتاب خواهید آموخت:
پیادهسازی Fluent Bit برای جمعآوری تلهمتری (لاگها، متریکها و تریسها)
پیکربندی پایپلاینها برای فیلتر کردن، مسیریابی و تبدیل دادهها
ادغام Fluent Bit با کانتینرها و کوبرنتیز
پیکربندی Fluent Bit برای کار با ابزارهای متنباز مانند OpenTelemetry و Prometheus
مانیتورینگ اپلیکیشنها در مقیاس بزرگ با حداقل استفاده از منابع
رفع چالشها در اکوسیستمهای مبتنی بر کوبرنتیز با استفاده از Fluent Bit
استفاده از Fluent Bit برای تحلیل رویدادهای بلادرنگ و استخراج متریکها و بینشهای جدید
توسعه فیلترها، ورودیها و خروجیهای سفارشی برای استفادههای خاص یا قابلاستفاده مجدد
این کتاب با بهرهگیری از تجربیات نویسنده، فیل ویلکینز، و مشارکت اعضای کلیدی تیم توسعه Fluent Bit، به شما نشان میدهد چگونه این ابزار را در موارد استفاده متنوع از جمله کوبرنتیز و محیطهای سنتی به کار بگیرید. همچنین یاد خواهید گرفت که Fluent Bit را با ابزارهایی نظیر Prometheus، OpenTelemetry و FluentD ادغام کنید.
درباره Fluent Bit
Fluent Bit یک ابزار نظارتی سبک و بسیار سریع است که برای کوبرنتیز، کانتینرها و حتی محیطهای سنتی IT مناسب است. این ابزار به شما امکان میدهد دادههای لاگ، تریس و متریکهای عملکردی تولیدشده توسط اپلیکیشنها و زیرساختهای خود را تحلیل و به ابزارهای مانیتورینگ مانند Prometheus و Grafana ارسال کنید.
مطالب کتاب:
معرفی Fluent Bit
جمعآوری دادههای ورودی از کانتینرها و کوبرنتیز
ارسال رویدادها به خروجی
فیلتر کردن و تبدیل رویدادها
استفاده از پردازندههای جریانی برای محاسبات سریهای زمانی
ساخت پلاگینهای سفارشی و توسعه قابلیتهای Fluent Bit
پیادهسازی موارد استفاده در سطح سازمانی
مخاطبان:
توسعهدهندگان، مهندسان DevOps و SREهایی که در حوزه نظارت و پایش سیستم فعالیت دارند.
درباره نویسنده:
فیل ویلکینز، نویسنده کتاب «Logging in Action»، بیش از 25 سال تجربه در صنعت نرمافزار دارد و در شرکتهای چندملیتی و استارتاپها فعالیت کرده است.
فهرست مطالب:
بخش 1: مقدمه
معرفی Fluent Bit
اولین گامها (Hello, World)
بخش 2: مبانی
3. جمعآوری ورودیها
4. دریافت ورودی از کانتینرها و کوبرنتیز
5. ارسال رویدادها به خروجی
6. استخراج معانی بیشتر با پردازش لاگها
7. فیلتر کردن و تبدیل رویدادها
بخش 3: پیشرفته
8. استفاده از پردازندههای جریانی برای محاسبات و فیلتر کردن
9. ساخت پردازندهها و گزینههای گسترش Fluent Bit
10. توسعه پلاگینهای سفارشی
11. استفاده عملی از Fluent Bit در یک مورد استفاده سازمانی
1 035
بلاک نکنید وقتی کامنت میدیم برای بهتر شدن 👾
کامیونیتی نرمافزار خیلی کوچیکه و هممون در یه دنیای مشابه داریم فعالیت میکنیم. به جای بلاک کردن ، بهتره از نقدهای سازنده استفاده کنیم و همدیگه رو در مسیر یادگیری و پیشرفت حمایت کنیم. اینطور میتونیم محیطی بهتر و دوستانهتر بسازیم.
https://www.linkedin.com/posts/melad-kamari-70a65b120_%D8%AF%D9%88%D8%B1%D9%87-%D8%B1%D8%A7%DB%8C%DA%AF%D8%A7%D9%86-cqrs-%D9%82%D8%B3%D9%85%D8%AA-%D8%A2%D8%AE%D8%B1-%D8%AA%D8%AD%D9%85%D9%84-%D9%BE%D8%B0%DB%8C%D8%B1%DB%8C-activity-7278452781827444737-_nuj?utm_source=share&utm_medium=member_desktop
@DeveloperAdvocate 🥑
1 035
Repost from Learning With M
همونطور که احتمالا در جریان هستید، تیم .Net به دلیل اینکه
Swashbuckle به درستی آپدیت نمی شد و مشکلاتش رفع نمی شد، از .Net 9 این لایبرری رو حذف کردند.
این یعنی اگر شما پروژه جدید با .Net 9 بسازید و پروژه رو اجرا کنید، به جای صفحه Swagger با 404 رو برو می شید. در عوض تیم .Net، پیاده سازی OpenAPI رو اضافه کردن. برای همینه که توی program.cs شما فقط کد های زیر رو می بینید :
builder.Services.AddOpenApi()
app.MapOpenApi();
و این یعنی اگر صفحه openapi/v1.json رو باز کنید با یک فایل json مواجه میشید که وظیفه تولید مستندات OpenAPI رو داره.
💎 خب،از اونجایی که برای ارتباط بهتر استفاده کنندهای API های ما یا تست خودمون، اگر یک UI مثل Swagger داشته باشیم خیلی راحت تریم باید به فکر جایگزین باشیم.
شما هنوز می تونید به صورت دستی Swashbuckle رو اضافه کنید و کانفیگش کنید، ولی از اونجایی که بعضی وقت ها : عدو شود سبب خیر من یکم گشتم و گشتم تا یک جایگزین خوب پیدا کنم.
این شما و این Scalar.
این جناب Scalar یک پروژه اوپن سورس هست که خیلی کلاینت های مختلفی از جمله .Net داره که به شما کمک میکنه یک کلاینت تر و تمیز و با قابلیت هایی به مراتب بهتر از Swashbuckle برای کار با API های خودتون داشته باشید.
پیاده سازی و نصب راحتی داره، فقط کافیه که اول به پروژه اضافش کنید :
dotnet add package Scalar.AspNetCore
و بعد به دستور زیر پیکر بندیش کنید :
app.MapScalarApiReference();
هممون هم حواسمون هست که ابزار ها فقط برای محیط های Development و Staging هستند و نباید برن روی Production !
شما از چه ابزاری روی .Net 9 دارید استفاده می کنید ؟ چالش چی تو دست و بالتون دارید ؟ 😂1 035
"Looks Good To Me": Constructive code reviews
کتاب «Looks Good to Me» راهنمایی جامع برای انجام بازبینیهای کدی است که نه تنها به بهبود کیفیت کد کمک میکند، بلکه تیم شما را نیز تقویت میکند. این کتاب روشهای معمول و پرتنش بازبینی کد را کنار گذاشته و به شما یاد میدهد چگونه بازبینیها را به فرصتی سازنده و مثبت تبدیل کنید.
درباره کتاب
کتاب «Looks Good to Me» نوشته Adrienne Braganza شما را با فرآیند بازبینی کد آشنا میکند و نشان میدهد چگونه میتوانید از اولین کامیت تا استقرار نهایی، بازبینیهایی مؤثر و بینقص انجام دهید. این کتاب شامل ابزارها، فرآیندها و تکنیکهایی است که میتواند هر تیمی را به سمت بازبینیهای بهتر هدایت کند.
مطالبی که یاد خواهید گرفت
درک مزایای بازبینی کد و جلوگیری از مشکلات و گلوگاههای احتمالی
طراحی یک سیستم بازبینی کد عینی و موثر
مشخص کردن نقشهای افراد: نویسنده کد، بازبین، مدیر و تیم
تنظیم دستورالعملها و پروتکلهای قابل اجرا
مستندسازی قوانین و خطمشیهای تیم
خودکارسازی کیفیت کد با ابزارهایی مانند linting، فرمتدهی، آنالیز استاتیک و تست خودکار
نوشتن نظرات موثر برای هر موقعیتی
ترکیب بازبینی کد با برنامهنویسی دوتایی (Pair Programming) یا گروهی (Mob Programming)
استفاده از هوش مصنوعی برای بازبینی کد
ویژگیهای کتاب
این کتاب علاوه بر پوشش جامع هر بخش از فرآیند بازبینی کد، به شما کمک میکند تا چالشهای معمول مانند اختلافنظرها، نکتهگیریهای بیمورد و تاخیرهای غیرضروری را مدیریت کنید. با ترکیب ابزارها و شیوههای عملی با حس همدلی، بازبینیهای شما به تجربهای مثبت برای همه اعضای تیم تبدیل خواهد شد.
درباره نویسنده
Adrienne Braganza یک مهندس، سخنران و نویسنده کتاب پرفروش «Coding for Kids: Python» است که در زمینه آموزش و توسعه نرمافزار تخصص دارد.
برای چه کسانی مناسب است؟
این کتاب برای تمام اعضای تیم، از توسعهدهندگان تا رهبران تیم، مناسب است.
مطالب داخل کتاب
چرا بازبینی کد انجام میدهیم؟
خودکارسازی فرآیندهای مربوط به کیفیت کد
نوشتن نظرات مؤثر
فهرست مطالب
بخش اول
اهمیت بازبینی کد
بررسی دقیق بازبینی کد
ایجاد فرآیند اولیه بازبینی کد
بخش دوم
4. توافقنامه کاری تیم
5. مزایای خودکارسازی
6. نوشتن نظرات مؤثر برای بازبینی کد
بخش سوم
7. چرا بازبینی کد میتواند آزاردهنده باشد
8. کاهش تأخیر در بازبینی کد
9. حذف خلأهای فرآیند
10. کتابچه راهنمای اضطراری
بخش چهارم
11. بازبینی کد و برنامهنویسی دوتایی
12. بازبینی کد و برنامهنویسی گروهی
13. بازبینی کد و هوش مصنوعی
پیوستها
قالب اولیه توافقنامه کاری تیم
قالب اولیه کتابچه راهنمای اضطراری
قالبهای درخواست ادغام (PR)
فهرست منابع
درباره تکنولوژی
این کتاب نشان میدهد چگونه میتوانید بازبینی کد را از یک فرآیند بحثبرانگیز و گاه ناامیدکننده به تجربهای سازنده و هدفمند تبدیل کنید.
@DeveloperAdvocate 🥑
1 035
Repost from Syntax | سینتکس
آشنایی با File and Directory Permissions در لینوکس یکبار برای همیشه
در لینوکس، هر فایل و دایرکتوری دارای سطوح دسترسی (Permissions) است که مشخص میکند چه کسی میتواند به فایل یا دایرکتوری دسترسی داشته باشد و چه کاری با آن انجام دهد. این سطوح دسترسی برای سه دسته اصلی تعریف میشوند:
1. Owner (مالک فایل یا دایرکتوری)
2. Group (گروهی که فایل یا دایرکتوری به آن تعلق دارد)
3. Others (سایر کاربران سیستم)
ساختار دسترسیها
در ابتدای هر فایل یا دایرکتوری در خروجی دستور
ls -l، سطح دسترسی آن به صورت زیر نمایش داده میشود:
drwxrwxrwxاین سطح دسترسی از 10 کاراکتر تشکیل شده است: 1. اولین کاراکتر: نوع فایل را مشخص میکند: -
- : فایل معمولی
- d : دایرکتوری
- l : لینک سمبلیک
2. 9 کاراکتر بعدی (سه گروه سهتایی): سطح دسترسی برای مالک، گروه و سایرین را نشان میدهد:
- r : اجازه خواندن (Read)
- w : اجازه نوشتن (Write)
- x : اجازه اجرا (Execute)
جدول باینری و مقادیر اعداد
هر سطح دسترسی را میتوان به یک عدد باینری و سپس یک مقدار عددی تبدیل کرد. جدول زیر این مفهوم را نشان میدهد:
| مقدار عددی | سطح دسترسی | باینری |
|------------|------------|---------|
| 7 | rwx | 111 |
| 6 | rw- | 110 |
| 5 | r-x | 101 |
| 4 | r-- | 100 |
| 3 | -wx | 011 |
| 2 | -w- | 010 |
| 1 | --x | 001 |
| 0 | --- | 000
مثال: chmod 777
دستور chmod برای تغییر سطح دسترسی فایلها و دایرکتوریها استفاده میشود. در مثال chmod 777:
- اولین عدد 7: سطح دسترسی مالک (Owner) است.
- دومین عدد 7: سطح دسترسی گروه (Group) است.
- سومین عدد 7: سطح دسترسی سایرین (Others) است.
سطح دسترسی هر عدد به صورت زیر تعریف میشود:
rwx | rwx | rwxاین به این معناست که: - مالک: میتواند بخواند، بنویسد و اجرا کند. - گروه: میتواند بخواند، بنویسد و اجرا کند. - سایرین: میتوانند بخوانند، بنویسند و اجرا کنند. دسترسیهای محدودتر حال اگر بخواهیم دسترسی محدودتری تعریف کنیم، میتوانیم از مقادیر پایینتر استفاده کنیم: -
chmod 644:
- مالک: rw- (خواندن و نوشتن)
- گروه: r-- (فقط خواندن)
- سایرین: r-- (فقط خواندن)
- chmod 755:
- مالک: rwx (خواندن، نوشتن و اجرا)
- گروه: r-x (خواندن و اجرا)
- سایرین: r-x (خواندن و اجرا)
نکته درباره دایرکتوریها
برای دایرکتوریها:
- r:
به کاربر اجازه میدهد محتویات دایرکتوری را مشاهده کند.
- w:
به کاربر اجازه میدهد فایلها را حذف یا اضافه کند.
- x:
اجازه ورود به دایرکتوری را میدهد.
#file_and_directory_permission
@Syntax_fa1 035
Repost from Iran Agile
مدل ذهنی Probabilistic Thinking
به عنوان یک رهبر فنی، یکی از متداولترین (و شاید ناخوشایندترین) سوالاتی که با آن مواجه میشوید: «این کار کی تمام میشود؟» مشتریان، ذینفعان و حتی اعضای تیم خودتان به دنبال قطعیت در حوزه ای ذاتا نامطمئن هستند. در حالی که ارائه تاریخهای دقیق تحویل غیرممکن است، در اینجا میتوانیم از مدل ذهنی Probabilistic Thinking برای ارائه تخمینهای واقعبینانهتر و ارزشمندتر استفاده کنیم.
توسعه نرمافزار یک امر پیچیده است. چالشهای غیرمنتظره، تغییر نیازمندیها و خلاقیت ذاتی درگیر در آن، پیشبینی تکمیل با قطعیت مطلق را غیرممکن میسازد. برخورد با تخمینها به عنوان ضربالاجلهای ثابت، انتظارات غیرواقعی ایجاد میکند و میتواند منجر به موارد زیر شود:
- سندرم فرسودگی شغلی: توسعهدهندگان تحت فشار قرار میگیرند تا ضربالاجلها را رعایت کنند که منجر به استرس و کاهش بهرهوری در بلند مدت میشود.
-کاهش کیفیت: برای رعایت ضربالاجلها، ممکن است از برخی مراحل صرفنظر شود که منجر به نرمافزار دارای باگ و افزایش بدهی فنی شود.
- از دست دادن اعتماد: عدم رعایت مکرر ضربالاجلها، اعتماد بین تیم توسعه و ذینفعان را از بین میبرد.
به جای تاریخهای ثابت، بیایید عدم قطعیت را بپذیریم. در اینجا نحوه کمک Probabilistic Thinking آورده شده است:
شناسایی عدم قطعیتهای کلیدی:
پیچیدگی: پیچیدگی کار چقدر است؟ آیا ناشناختهها یا وابستگیهایی وجود دارد؟
تغییر دامنه: احتمال تغییر نیازمندیها چقدر است؟
تجربه توسعهدهندگان: تجربه تیم در زمینه فناوری و حوزه مسئله چیست؟
عوامل خارجی: آیا عوامل خارجی احتمالی وجود دارد که میتواند بر پروژه تأثیر بگذارد (مانند مشکلات زنجیره تامین، تاخیرهای غیرمنتظره)؟
تخصیص احتمالات:
بر اساس ارزیابی شما از این عدم قطعیتها، احتمالات را به سناریوهای مختلف اختصاص دهید.
به عنوان مثال، «۷۰٪ احتمال تکمیل شدن در عرض دو هفته، ۲۰٪ احتمال تکمیل در عرض سه هفته و ۱۰٪ احتمال مواجهه با تاخیرهای غیرمنتظره وجود دارد.»
ارتباط شفاف:
- به جای وعده دادن یک تاریخ مشخص، طیف وسیعی از نتایج احتمالی مرتبط با آنها را ارائه دهید.
- عواملی را که به عدم قطعیت کمک میکنند توضیح دهید.
- در مورد احتمال تاخیرها و اقداماتی که برای کاهش آنها انجام خواهید داد، صریح باشید.
ارزیابی مجدد مداوم:
- با پیشرفت پروژه، بازخورد جمعآوری کنید، پیشرفت را کنترل کرده و تخمینهای خود را متناسباً تنظیم کنید.
- این بهروزرسانیها را به طور منظم با ذینفعان در میان بگذارید تا شفافیت و اعتماد را حفظ کنید.
مثال:
درخواست ویژگی ظاهراً سادهای میرسد: «دکمهای به پروفایل کاربر اضافه کنید.»
پیچیدگی: در حالی که این کار ظاهراً ساده است، ممکن است وابستگیهایی به سایر بخشهای سیستم یا موارد حاشیهای غیرمنتظره وجود داشته باشد.
تغییر دامنه: مشتری ممکن است پس از مشاهده اجرای اولیه، درخواست اضافی کند.
ارتباط: به جای گفتن «تا جمعه انجام خواهد شد»، تیم لید ممکن است بگوید: «بر اساس ارزیابی اولیه، ۸۰٪ احتمال تکمیل این کار تا جمعه وجود دارد، اما ۲۰٪ احتمال وجود دارد که با چالشهای غیرمنتظرهای مواجه شویم که میتواند جدول زمانی را تمدید کند.»
ایجاد اعتماد از طریق شفافیت
با پذیرش Probabilistic Thinking و ارتباط صادقانه و شفاف، رهبران فنی یا مدیران پروژه میتوانند اعتماد را با ذینفعان ایجاد کنند. این رویکرد نه تنها منجر به انتظارات واقعبینانهتر میشود، بلکه فرهنگ همکاری و بهبود مستمر را نیز تقویت میکند.
