واژگان دقیق فنی و حرفهای
چگونه سیستمها، تصمیمها و مصالحهها را دقیق توصیف کنیم — واژگانی که انگلیسی فنی را قانعکننده میکند.
انگلیسی فنی نه به خاطر دستور زبان که به خاطر فعلهای مبهم شکست میخورد. «We made the system better» و «we reduced query latency by 40%» یک کار را با قانعکنندگی کاملاً متفاوتی توصیف میکنند.
فعلهایی با وزن فنی
| مبهم | دقیق |
|---|---|
| make faster | optimise, accelerate, streamline |
| make smaller | reduce, compress, consolidate |
| fix | resolve, patch, mitigate |
| change | refactor, migrate, restructure |
| check | validate, verify, audit |
| set up | configure, provision, deploy |
| join together | integrate, consolidate, merge |
| find the cause | diagnose, trace, isolate |
We isolated the bottleneck and refactored the query layer.
چگونه رابطهٔ بخشها را توصیف کنیم
برای توضیح معماری با صدای بلند مجموعهٔ کوچکی از فعلهای رابطه لازم است، و ابهام اینجاست که توضیح خوب را نامفهوم میکند:
- The API sits behind a load balancer.
- The service depends on the auth layer. · Nothing else relies on it.
- It talks to the database directly. (محاورهای ولی استاندارد)
- The queue decouples ingestion from processing.
- Sessions are backed by Redis.
- That module is responsible for validation.
توجه کنید: depend on و rely on هر دو با on میآیند و consist of با of. سه حرف اضافهٔ ثابت که در آنها زیاد اشتباه میشود.
توصیف مصالحهها
بحث فنی بخش بزرگیاش مصالحه است و انگلیسی برای آنها زبان آماده دارد:
- There's a trade-off between speed and accuracy.
- We prioritised reliability over raw performance.
- That approach scales better, but at the cost of complexity.
- It's a reasonable compromise given the constraints.
- The downside is that it adds a dependency.
نرم کردن ادعاهای فنی
اغراق اعتماد مخاطب فنی را از بین میبرد. دقت دقت در میزان اطمینان را هم شامل میشود.
- This should reduce load significantly. (انتظار میرود)
- It appears to be a race condition. (محتمل ولی تأییدنشده)
- We suspect the issue originates in the cache layer.
- As far as we can tell, the data is consistent.
مقایسه کنید با اغراق: This will definitely fix it. این بهندرت موجه است و اگر اشتباه باشد گران تمام میشود.
توضیح علت
- The failure stems from an unhandled edge case.
- This was triggered by a schema change.
- The root cause turned out to be a timeout setting.
- These issues are symptomatic of a deeper design problem.
وقتی چیزی خراب میشود
زبان حادثه بسیار قراردادی است و واژهٔ نادرست یا اغراق میکند یا کمنمایی:
| اصطلاح | معنا |
|---|---|
| outage | کاملاً از کار افتاده |
| degradation | کار میکند ولی کند یا ناقص |
| intermittent | گاهبهگاه خراب میشود |
| regression | چیزی که قبلاً کار میکرد خراب شد |
| workaround | راه دور زدن موقت |
| mitigation | پیامد را کم میکند ولی علت را برطرف نمیکند |
| rollback | بازگشت به نسخهٔ قبلی |
| postmortem | بررسی پس از رخداد |
We've mitigated the impact with a workaround; the root cause is still open. — این جمله دقیقاً به مدیر میگوید کجا هستید.
برآورد حجم و زمان
- That's out of scope for this release.
- Roughly — ballpark — two weeks.
- We're seeing some scope creep.
- I'd want to spike on it before committing to an estimate.
- It's blocked on the API change.
ارزیابی کمّی
برآوردهای مبهم انگلیسی فنی را که غیر از آن خوب است بیارزش میکنند.
- ❌ It got a lot faster.
- ✅ Latency dropped from 800 ms to roughly 200 ms.
- ✅ That's an improvement of around 75%.
- ✅ Error rates fell by an order of magnitude.
دقت و اطمینان دو دستگیرهٔ جدا هستند. We reduced p99 latency by roughly 60%, though we haven't confirmed why هم دقیق است هم بهجا نامطمئن. مخاطب فنی به همین ترکیب اعتماد میکند و به عکسش — ادعای مطمئن بدون یک عدد — اعتماد ندارد.
بررسی حادثه
A: What are we seeing?
B: Intermittent 500s on checkout since about nine. It's degradation, not a full outage.
A: Do we know why?
B: Not yet. It appears to be connection-pool exhaustion, but that's a guess. We've rolled back the deploy as a mitigation and errors dropped by around 90%.
A: Good. Root cause can wait for the postmortem.
هر ادعا با درجهٔ اطمینان مشخص، یک عدد و واژهٔ درست در هر جایگاه.
خودتان را بسنجید
در آزمون زیر دقت و نرمکردن بهجا برنده است، نه ابهام جلوهگر.