7 причин ненавидеть свой код | Participants
|
- Statistics
- Participants
- Translate into Russian
- Translation result
- Translation complete.
If you do not want to register an account, you can sign in with OpenID.
7 Reasons To Hate Your Code | ||
Incompetence is the cause of many ills in the software world, but increasingly I’m seeing a certain kind of competence as being just as destructive. You see, there are a lot of programmers who care deeply about their code. I did, but it turns out there are good reasons we shouldn’t do that; reasons why we should hate our code… | Некомпетентность — причина многих бед в мире программного обеспечения, но я всё чаще нахожу, что есть вид компетентности, столь же разрушительный. Видите ли, на свете полно программистов, которые горячо пекутся о своём коде. И я, в прошлом, — тоже, но оказалось, что есть веские причины избегать этого; причины, по которым нам стоит ненавидеть наш код... | |
Reason 1: It keeps you open to change | Причина 1: Благодаря этому вы не противитесь изменениям | — может все-таки "изменений"? — weblomaster — Да, пожалуй. Но тогда, наверное, не "открыты для", а "готовы к" или как-то ещё. — tms More 6 comments — «Вы не будете бояться сделать его лучше»? — S2im |
The most productive way to write software is to release early and iterate quickly with feedback from real users, right? It saves us from implementing the wrong features, that it helps build a community and so on. What’s people don’t talk about as often is the impact it has on our relationship with the code. Putting a program in front of users is terrifying because they might not like it. The more lovingly we craft and polish every class before release, the more carefully we plan our abstractions and structures, the more emotionally attached we are to the way we have made it. | Самый продуктивный способ создавать программное обеспечение — пораньше сделать релиз и часто выпускать новые версии, получая отзывы от реальных пользователей, верно? Это спасает нас от реализации ненужных функций, помогает создать сообщество, и так далее. Куда реже говорят о том влиянии, которое этот способ оказывает на наше отношение к коду. Необходимость познакомить пользователей со своей программой ужасает, ведь она может им не понравиться. И чем более любовно мы создаём и отшлифовываем каждый класс перед релизом, чем тщательнее мы продумываем свои абстракции и структуры, тем крепче мы привязываемся эмоционально к тому, как мы всё это сделали. | — feedback - можно перевести как "комментарии клиентов" http://multitran.ru/c/m.exe?l1=1&s=fe... — space_indus "ненужных" - здесь очень хорошо по смыслу подходит — space_indus — Iterate quickly with - это не только получать фидбэк, но и выполнять какую-то работу на его основе, как я понимаю. То есть, что-то вроде "итеративно работать над продуктом, отвечая на запросы пользователей" — tms |
The result is that we instinctively resist making significant changes to the code based on early feedback, even though this was the whole point. It’s an unconscious, emotional reaction that we rationalize away to ourselves by claiming the users just don’t understand the feature, or that it just needs a bit more polish when, seen objectively, the best thing to do might be to restructure it completely do do something rather different. | В результате мы инстинктивно сопротивляемся внесению существенных изменений в код на основе первых откликов от пользователей, хотя в этом-то и заключался весь смысл. Это бессознательная эмоциональная реакция, которую мы оправдываем себе, утверждая, что пользователи просто не разобрались с этой функцией, или что нужно только её еще немного подшлифовать, тогда как, если посмотреть объективно, возможно, самое дельное — это полностью переработать её, сделать что-то несколько иное. | |
In fact, the best way to remain responsive to your users is to hate your code. | По сути, лучший способ заботиться о своих пользователях — это ненавидеть свой код. | |
Reason 2: Jeff Atwood says that you should | ||
> You can tell a competent software developer from an incompetent one with a single interview question: “What’s the worst code you’ve seen recently?” | > Вы можете отличить компетентного разработчика от некомпетентного с помощью одного простого вопроса на интервью: „Какой самый худший код вы недавно видели?“ | |
> If their answer isn’t immediately and without any hesitation these two words: “My own,” then you should end the interview. | > Если в ответ вы не услышите немедленно и без колебаний два слова: „Мой собственный“, то можете на этом закончить интервью. | |
– Jeff Atwood | ||
Every now and again people attack Jeff for his assertion that we write bad code, for his arms-wide-open group humility. I think people misunderstand him. The message is not you are a bad programmer, it’s that part of being – of becoming – a great programmer is writing code that you’re ashamed of. If you think all the code you write is wonderful, you’re probably not learning anything. | Джефф время от времени подвергается нападкам за это утверждение, что мы пишем плохой код, за его готовность смириться с этим. Я считаю, что люди неверно его понимают. Смысл не в том, что вы — плохой программист, а в том, что невозможно стать великим программистом, не создавая код, за который вам потом бывает стыдно. Если вы думаете, что весь написанный вами код прекрасен, то вы, похоже, ничему не учитесь. |
© http://coderoom.wordpress.com.
— Автор не всё чаще видит примеры излишней заботы, а всё лучше понимает, как она опасна — S2im
— Пожалуй. Примерно так? — tms