Сосет меньше каждый год -Джефф Этвуд
Я наткнулся на эту проницательную статью. Цитата прямо из поста
Я часто думал, что с каждым годом меньше сосать - это то, как улучшаются скромные программисты. Вы должны быть недовольны кодом, который вы написали год назад. Если нет, это означает, что либо А) вы ничего не узнали за год, Б) ваш код не может быть улучшен, либо С) вы никогда не пересматриваете старый код. Все это поцелуй смерти для разработчиков программного обеспечения.
- Как часто это случается или не случается с вами?
- Как долго, прежде чем вы увидите реальное улучшение вашего кодирования? месяц год?
- Вы когда-нибудь пересматривали свой старый код?
- Как часто ваш старый кодекс изводит вас? или как часто вам приходится иметь дело с вашим техническим долгом.
Определенно очень больно исправлять старые ошибки и грязный код, который мы, возможно, сделали, чтобы быстро уложиться в сроки, и те быстрые исправления, в некоторых случаях нам может потребоваться переписать большую часть приложения / кода. Никаких аргументов по этому поводу.
Некоторые разработчики, с которыми я сталкивался, утверждали, что они уже находились на стадии развития, когда их кодирование не нуждается в улучшении или не может быть улучшено больше.
- Это происходит?
- Если так, сколько лет в кодировании на определенном языке можно ожидать, что это произойдет?
Связанные с:
Ты когда-нибудь оглядывался назад на свой старый код и с гримасой боли?
Звездные войны Момент в коде "Люк! Я твой код!" "Нет! Невозможно! Этого не может быть!"
источник
Ответы:
Нет, но сосать разные каждый год :-)
После моих первых обзоров много лет назад я переживал из-за отсутствия соглашений об именах.
Затем я почувствовал, что мой код (ненужный) реализован настолько универсально, насколько это возможно, но это затрудняет понимание и поддержку кода.
Затем я приступил к разработке на основе тестов, InversionOfControl, какие дот нету дженерики, где и многое другое.
вывод
страдания от старых вредных привычек уменьшились, но были компенсированы новыми страданиями, которые я получил, потому что узнал больше.
источник
Интересно, что все программисты «рок-звезды», с которыми я когда-либо работал, были чрезвычайно скромны, стремились учиться и были готовы признать, что они не знают всего. Черт возьми, многие на самом деле были просто самоуничижительными, по крайней мере, в беззаботных моментах.
Я не думаю, что когда-либо встречал разработчика, который думает, что их кодирование «не может быть улучшено», но что-то подсказывает мне, что эти парни были бы настолько далеки от рок-звезды, насколько вы можете - мягко говоря.
источник
Следующие пункты - это не советы, а личный журнал:
Я не выучил все за год, все требует времени ...
источник
Часто люди думают, что хороший код внезапно появляется, но для большинства из нас, простых смертных, хороший код растет в нашей кодовой базе. Я имею в виду, что с самого начала очень сложно написать идеальный программный продукт, поскольку требования постоянно меняются, и мы не идеальные программисты, и поэтому не всегда принимаются глупые решения от менеджеров и программистов. Затем я вижу, что каждое требование меняет хорошую возможность реорганизовать часть старого кода в более качественный код (и получать за это плату!) И погасить небольшую техническую задолженность. Как говорится: «каждый раз, когда вы делаете код, оставляйте репозиторий кода немного лучше». Тогда ваша система превратится в систему, близкую к идеальной.
Я не знаю абсолютно никакого программиста, который гордится своим программным обеспечением, но это хорошо. Это означает, что программист научился в процессе.
Также, если вы прочитаете книгу «Чистый код», вы увеличите свой собственный код «фактор всасывания» в несколько раз. : D
источник
У меня на самом деле есть обе стороны медали для этого.
С одной стороны, вы смотрите на старый код и видите, что он полон ошибок и сложных способов выполнения задач, которые просто достигаются за счет использования техник и языковых функций, о которых вы не знали в то время.
С другой стороны, вы замечаете особенно изящное решение проблемы, и вы не можете сдержать самодовольную усмешку о том, насколько умным вы тогда были.
А затем вы прокручиваете пару строк и в ужасе гримасничаете от того, что использовали GOTO в C.
источник
Хм ... Меня часто приятно удивляет, насколько хорош мой старый код.
Если бы я делал это сегодня, я бы часто писал по-другому, но если бы мне пришлось жить с ограничениями времени, я не уверен , что сделал бы это. Когда вы можете рассчитывать на типичную машину, имеющую хотя бы пару гигабайт оперативной памяти, вы можете (и часто должны) писать свой код немного иначе, чем когда большой жесткий диск занимал 100 мегабайт.
источник
Каждый раз я узнаю что-то новое, надеюсь, это каждый день.
Если мне удастся реализовать то, чему я научился, то это сразу после того, как я это осуществлю.
Да, только для (1) новых функций, (2) исправления ошибок, (3) ностальгии, (4) посмотрите, как я решил что-то, может быть полезно.
Что касается 1., когда я узнаю, как сделать что-то лучше, я осознаю, что некоторые старые проекты «могли» быть выполнены лучше. Я оставляю их в покое. Просто убедитесь, что следующий проект сделан лучше. Я не волнуюсь, если это не фактическая ошибка.
источник
В другом вопросе речь шла о способах оценки качества вашего собственного кода. Одним из моих предложений было пересмотреть его через несколько лет, когда ваш опыт намного выше, чем был при написании кода. Одна цитата из моего ответа на этот другой вопрос напрямую связана с вашим вопросом:
Так что да, на практике каждый кусок кода, который я написал, становится невыносимым с моей точки зрения через год. И я говорю не об одноразовом коде, а о коде, который я написал с учетом качества, удобства обслуживания и удобства чтения. На данный момент исключений не было.
Чтобы ответить на ваш второй вопрос о продолжительности жизни, он сильно варьируется. Срок действия одноразового кода составляет ноль секунд : он сосет сразу после того, как вы его написали, но это не имеет значения. Некоторые фрагменты кода, которые я написал, были терпимы через два года , но требовали некоторых косметических изменений: небольшой рефакторинг, применение правил StyleCop и т. Д. В среднем, в моем конкретном случае, продолжительность жизни варьируется от восьми месяцев до одного года для C # и от двух до шести месяцев для PHP.
Я повторно посещаю мой старый код? Да, конечно, как любой разработчик, если вы не заботитесь о СУХОЙ и изобретаете свое колесо снова и снова. Существуют также шансы очень часто просматривать и улучшать код, если у вас есть общая кодовая база, которую вы используете во многих проектах . Другой момент заключается в том, что если вы работаете над огромными проектами, некоторые из них могут занять несколько лет , поэтому вам придется пересмотреть старый код.
Когда человек говорит, что она настолько совершенна, что ей не нужно ничего учить, это означает, что она даже не способна понять, насколько она глупа.
Даже если у вас есть двадцатилетний опыт работы в области компьютеров / программирования, все меняется слишком быстро, поэтому всегда есть что изучать и новые методы для улучшения кода. Например, код на C #, написанный, когда не было .NET Framework 3.0, вполне может быть сделан более читабельным и лучше с новыми вещами, которые мы имеем сегодня (включая Linq, контракты Code и т. Д.), И это, даже если старый код был написан самым умным разработчиком.
источник
Это происходит довольно регулярно, когда я смотрю на код и задаюсь вопросом: «О чем я думал, когда писал это?»
Обычно все время происходят улучшения, так как иногда мне приходит новая идея для организации кода, стилизации кода или чего-то еще, и хотя это может и не быть большим улучшением, может помочь любая мелочь, которую стоит сделать.
В зависимости от рабочей среды, я могу видеть код несколько лет назад, поскольку я продолжаю работать в той же кодовой базе и хорошо знаком с тем, что там есть и чем можно управлять.
Старый код почти всегда мучает меня, так как обычно я либо меняю существующую систему, либо заменяю систему. В любом случае, я должен знать причуды существующей системы, чтобы убедиться, что они есть в новой.
Хотя я уверен, что есть такие, как Джон Скит, которые могут просто придумать идеальный код, большинство других людей, которые говорят, что их код не может быть улучшен, говорят, что с точки зрения эго это может быть непривлекательным. В то же время, с точки зрения поиска значительного улучшения каждый раз, это не всегда будет иметь место.
источник
1. Как часто это случается или не случается с вами?
Как часто я недоволен своим старым кодом? Почти всегда. Есть редкие исключения, когда у меня есть код, которым я действительно горжусь ... но, опять же, они редки. Мне сказали, что код, который я написал пару лет назад, был хорош ... Я съежился и подумал: «Бедный бедняк, который видел хуже, чем мусор, который я написал».
2.Как задолго до того, как вы увидите реальное улучшение своего кодирования? месяц год?
Обычно это происходит поэтапно ... Я действительно разбираюсь в стиле или методологии (возьмем, например, беглые интерфейсы ... так как это был последний стиль, для которого у меня был огромный мокрый стиль), и вырезал все, что я пишу, за месяц или четыре , Тогда это начинает выглядеть лучше.
3. Вы когда-нибудь посещали свой старый код?
Не так часто, как хотелось бы. Большая часть моего старого кода принадлежит предыдущим работодателям. Личный код слишком часто стирается.
4. Как часто ваш старый кодекс мучает вас? или как часто вам приходится иметь дело с вашим техническим долгом.
Поскольку у предыдущих работодателей большая часть моего старого кода была, а я стираю большую часть своего личного кода ... совсем не часто.
источник