10 программистских поговорок, которые должен знать каждый разработчик | Participants
|
- Statistics
- Participants
- Translate into Russian
- Translation result
- Translated in draft, editing and proof-reading required. Completed: 3%.
If you do not want to register an account, you can sign in with OpenID.
10 Programming Proverbs Every Developer Should Know | 10 программистских поговорок, которые должен знать каждый разработчик | |
Proverbs are used to express universal truths or life lessons in a short and memorable fashion. I find that they are a great way to keep things in perspective, both in life and in work. Because of this, I have assembled 10 programming proverbs that every developer needs in their arsenal. | Пословицы используются для выражения универсальных истин или жизненных уроков в краткой и запоминающейся манере. Я считаю, что они представляют собой отличный способ удержать вещи в перспективе, как в жизни, так и в работе. Исходя их этого, я собрал 10 пословиц программирования, которые каждый разработчик должен иметь в своем арсенале. | — to keep things in perspective как-то по другому должно переводиться — ruguevara — почему ты так думаешь? — berkus — Потому что мне вообще не понятно, что значит "держать вещи в перспективе" — ruguevara — Вариант: Я считаю, они отлично подходят для того, чтобы иметь эти вещи в виду как вообще для жизни, так и для работы. — O90 |
1. There is no smoke without fire | ||
Relax. It's probably just another fire drill | Расслабьтесь. Похоже, это всего-лишь пожарные учения. | — Расслабьтесь. Наверное это просто еще один противопожарный инструктаж. — sim-sim |
Poorly designed code tends to manifest itself through some common tell-tale signs. Some examples of these are: | Плохо организованный код проявляет себя некоторыми общими предательскими признаками. Вот несколько примеров: | |
* Giant classes and/or functions | ||
* Large blocks of commented out code | ||
* Duplicated logic | ||
* Deeply nested if/else blocks | ||
Developers often refer to these as code smells, but personally, I think the term "code smoke" or "code fumes" is more appropriate as it implies a higher sense of urgency. If you don't address the underlying problem it will come back to burn you later on. | Разработчики часто называют такой код говнокодом, но лично я предпочитаю термин «дымящийся» или «коптящий» код, так как он обозначает гораздо большую серьезность проблемы. Если вы не соберётесь её исправить, рано или поздно она может и загореться. | — Нет, так у нас код никто не называет. Что это за выражение "дурно пахнущий"? Все разрабы называют такой код очень просто "говнокод". — BAZIL — думаю, что лучше все-таки "смердящий", чем "говнокод" — Dmitry-Leushin — именно говнокод, без вариантов — sim-sim |
2. An ounce of prevention is worth a pound of cure | Comment was deleted Comment was deleted | |
Ok, I'm convinced | — Как-то "Ок, убедили" - не по-русски. Лучше просто: "Хорошо, убедили" — Dmitry-Leushin — а еще лучше: "Ну ладно, уломали." — sim-sim | |
Toyota's assembly line of the 1980s was famously efficient due to its revolutionary approach towards defect prevention. Each member of the assembly line was given the ability to halt production when they noticed a problem in their sector. The idea was that it was better to halt production and fix the problem as early on as possible than to continue producing faulty units that would be tougher and more costly to fix/replace/recall later on. | Сборочный конвейер Тойоты 1980-х был известен своей эффективностью из-за революционного подхода к предотвращению дефектов. Каждый участник сборочной линии имел возможность остановить производство, если он замечал проблему в своем секторе. Идея была в том, что лучше остановить конвейер и исправить проблему раньше, чем продолжать производить неисправные детали, которые в дальнейшем будет сложнее и дороже исправить, заменить или отозвать. | |
Developers often make the faulty assumption that productivity = cranking out code quickly. Many programmers dive straight into coding without a second thought towards design. Unfortunately, this Leeroy Jenkins approach towards software development tends to lead to sloppy, fragile code that will need to be constantly monitored and patched -- perhaps even replaced altogether down the line. Ultimately, productivity must be measured not only in how much time is spent writing it, but also by how much time is spent debugging it. A short term gain may prove to be a long term loss if one isn't careful. | Разработчики часто ошибочно считают, что производительность = быстрый набор кода. Многие программисты сразу бросаются писать код без малейшего проектирования. К сожалению, такой подход Лироя Дженкинса приводит к неряшливому, слабому коду, за которым нужно всё время присматривать и латать — возможно, даже полностью заменить впоследствии. В конечном счете, продуктивность должна измеряться не только временем, ушедшим на написание кода, но и временем, затраченным на его отладку. Краткосрочный выигрыш по времени может оказаться серьезной потерей в дальнейшем, если не проявить осторожность. | — фигаченье - смеялся. Отличный перевод :)) честно — notalone |
— Десять поговорок программистов, которые должен знать каждый разработчик — notalone
— поговорки не катят, здесь приводятся именно ПОСЛОВИЦЫ! а поговорки это недлпословицы типа "лыка не вяжет" и т.д. см http://ru.wikipedia.org/wiki/%D0%9F%D... — sim-sim