Сосать меньше каждый год? [закрыто]

10

Сосет меньше каждый год -Джефф Этвуд

Я наткнулся на эту проницательную статью. Цитата прямо из поста

Я часто думал, что с каждым годом меньше сосать - это то, как улучшаются скромные программисты. Вы должны быть недовольны кодом, который вы написали год назад. Если нет, это означает, что либо А) вы ничего не узнали за год, Б) ваш код не может быть улучшен, либо С) вы никогда не пересматриваете старый код. Все это поцелуй смерти для разработчиков программного обеспечения.

  1. Как часто это случается или не случается с вами?
  2. Как долго, прежде чем вы увидите реальное улучшение вашего кодирования? месяц год?
  3. Вы когда-нибудь пересматривали свой старый код?
  4. Как часто ваш старый кодекс изводит вас? или как часто вам приходится иметь дело с вашим техническим долгом.

Определенно очень больно исправлять старые ошибки и грязный код, который мы, возможно, сделали, чтобы быстро уложиться в сроки, и те быстрые исправления, в некоторых случаях нам может потребоваться переписать большую часть приложения / кода. Никаких аргументов по этому поводу.

Некоторые разработчики, с которыми я сталкивался, утверждали, что они уже находились на стадии развития, когда их кодирование не нуждается в улучшении или не может быть улучшено больше.

  • Это происходит?
  • Если так, сколько лет в кодировании на определенном языке можно ожидать, что это произойдет?

Связанные с:

Ты когда-нибудь оглядывался назад на свой старый код и с гримасой боли?

Звездные войны Момент в коде "Люк! Я твой код!" "Нет! Невозможно! Этого не может быть!"

Адитья П
источник
3
ИМХО, люди, которые думают, что они совершенны и думают, что им не нужно совершенствоваться, правы. Они не могут улучшиться. Любой здравомыслящий человек знает, что он никогда не может быть идеальным, всегда есть место для улучшения / изучения новых вещей. Я был бы в ужасе, если бы узнал, что я не могу улучшить себя - я не хочу думать, что у меня есть потолок.
МАК
Мне нравится возвращаться к проектам, которые я делал, когда я был совсем новым, и смотреть на код, который мне было так сложно писать. Много раз код ооочень прост. Это заставляет меня смеяться.
Маффин Ман

Ответы:

6
  > Sucking Less Every Year ?

Нет, но сосать разные каждый год :-)

После моих первых обзоров много лет назад я переживал из-за отсутствия соглашений об именах.

Затем я почувствовал, что мой код (ненужный) реализован настолько универсально, насколько это возможно, но это затрудняет понимание и поддержку кода.

Затем я приступил к разработке на основе тестов, InversionOfControl, какие дот нету дженерики, где и многое другое.

вывод

страдания от старых вредных привычек уменьшились, но были компенсированы новыми страданиями, которые я получил, потому что узнал больше.

k3b
источник
19

Интересно, что все программисты «рок-звезды», с которыми я когда-либо работал, были чрезвычайно скромны, стремились учиться и были готовы признать, что они не знают всего. Черт возьми, многие на самом деле были просто самоуничижительными, по крайней мере, в беззаботных моментах.

Я не думаю, что когда-либо встречал разработчика, который думает, что их кодирование «не может быть улучшено», но что-то подсказывает мне, что эти парни были бы настолько далеки от рок-звезды, насколько вы можете - мягко говоря.

Бобби Столы
источник
2
Я согласен на 100%. Они тихие убийцы! Ох, и классное имя пользователя, xkcd? :)
jamiebarrow
@jamiebarrow: Конечно. :)
Бобби Столы
Другой случай неудачи - это тот, кто говорит: «Все программное обеспечение плохое, все его взломы, ваши идеи по улучшению не имеют значения». Вид удручает работу с этими типами.
Даг Т.
13

Следующие пункты - это не советы, а личный журнал:

  • используя меньше глобальных переменных
  • не используйте аббревиатуру для переменных или имен функций
  • написать [несколько] тестовых кодов
  • не оценивайте код как медленный (или быстрый) без бенчмаркинга
  • узнайте, как загрузить приложение
  • не чини, если не сломал
  • использовать инструмент управления исходным кодом (git / hg)
  • рефакторинг - это круто, не стоит недооценивать стоимость тестирования
  • безопасность очень сложна, поэтому остерегайтесь этого как можно раньше
  • исправить некоторые ошибки проекта с открытым исходным кодом
  • блог что-то новое
  • юзабилити не может быть запросом функции, но это важно

Я не выучил все за год, все требует времени ...

ohho
источник
Мне нравится, как вы упоминаете «написать [некоторые] тестовые коды». Я верю, что никто никогда не достигнет совершенства, когда они никогда не ошибутся как программисты - мы все люди, и мы время от времени совершаем ошибки. Модульные тесты и интеграционные тесты могут уменьшить наши ошибки. И я заметил, что вы говорите «некоторые» тесты, что важно, потому что иногда я увлекаюсь написанием тестов, которые не очень полезны.
jamiebarrow
На самом деле, я думаю, что под «не исправить это, если оно не сломано», я бы добавил «Если оно сломано, и это сложно, воспроизведите и исправьте ошибку с помощью тестового кода»
jamiebarrow
2
Могу ли я добавить несколько? Если это API, не раскрывайте больше внутренних деталей, чем нужно, если вы его скрываете, вы можете изменить его позже. Всегда используйте константы вместо магических чисел, потому что их легче документировать и изменять. Неизменность очень полезна, особенно когда речь идет о параллелизме. Работайте над чужой кодовой базой, это бесконечно ценный процесс, чтобы судить о вашем собственном стиле кодирования, когда вам нужно оправдать его для кого-то другого. Заморозьте спецификацию (если это возможно), потому что попасть в движущуюся цель труднее.
Эван Плейс
Если вы работаете на месте или рядом с клиентами, возьмите с собой карты без полномочий и с большей мощностью. Если они попросят вас что-то изменить за пределами спецификации, потяните (у меня) карточку без полномочий, а затем (ссылку на) карточку с более высокой мощностью (предпочтительно сторонний администратор PM, который может принимать запросы). В лучшем случае это позволит вам сосредоточиться на разработке; в худшем случае это сократит количество обращений к функциям. (спорно) Возвращение рано и возвращение часто, если возвращение должно было произойти в конце блока кода не было бы ключевое слово для этого. Надеюсь, я продолжаю сосать меньше с каждым годом.
Эван Плейс,
4

Часто люди думают, что хороший код внезапно появляется, но для большинства из нас, простых смертных, хороший код растет в нашей кодовой базе. Я имею в виду, что с самого начала очень сложно написать идеальный программный продукт, поскольку требования постоянно меняются, и мы не идеальные программисты, и поэтому не всегда принимаются глупые решения от менеджеров и программистов. Затем я вижу, что каждое требование меняет хорошую возможность реорганизовать часть старого кода в более качественный код (и получать за это плату!) И погасить небольшую техническую задолженность. Как говорится: «каждый раз, когда вы делаете код, оставляйте репозиторий кода немного лучше». Тогда ваша система превратится в систему, близкую к идеальной.

Я не знаю абсолютно никакого программиста, который гордится своим программным обеспечением, но это хорошо. Это означает, что программист научился в процессе.

Также, если вы прочитаете книгу «Чистый код», вы увеличите свой собственный код «фактор всасывания» в несколько раз. : D

Рафа де Кастро
источник
1
Я не согласен с вами по одному вопросу, я полагаю, какой-то код, которым вы можете гордиться. Ирония в том, что вы можете сделать один проект очень успешным и гордиться им, возможно, с небольшими неприятностями. Тогда в следующем проекте ваши WTF в час высоки ... для вашего собственного кода! : D
jamiebarrow
1
Может быть, зависит от того, какой шаг вы сейчас делаете. Теперь я нахожу код, который написал год назад, и даже мне трудно понять некоторые имена или назначение некоторых методов. Также я нахожу код, открытый тестами и тому подобное. По мере того, как я продолжаю совершенствоваться, подобные вещи, как правило, являются скорее исключением, чем нормой, и я начинаю смущаться проблемами, которые раньше казались неважными ...
Рафа де Кастро
+1 за Чистый код, хотя сравнение всегда с вами.
Aditya P
4

У меня на самом деле есть обе стороны медали для этого.

С одной стороны, вы смотрите на старый код и видите, что он полон ошибок и сложных способов выполнения задач, которые просто достигаются за счет использования техник и языковых функций, о которых вы не знали в то время.

С другой стороны, вы замечаете особенно изящное решение проблемы, и вы не можете сдержать самодовольную усмешку о том, насколько умным вы тогда были.

А затем вы прокручиваете пару строк и в ужасе гримасничаете от того, что использовали GOTO в C.

Крис Браун
источник
3

Хм ... Меня часто приятно удивляет, насколько хорош мой старый код.

Если бы я делал это сегодня, я бы часто писал по-другому, но если бы мне пришлось жить с ограничениями времени, я не уверен , что сделал бы это. Когда вы можете рассчитывать на типичную машину, имеющую хотя бы пару гигабайт оперативной памяти, вы можете (и часто должны) писать свой код немного иначе, чем когда большой жесткий диск занимал 100 мегабайт.

Джерри Гроб
источник
3
  1. Как часто это случается или не случается с вами?

  2. Как долго, прежде чем вы увидите реальное улучшение вашего кодирования? месяц год?

  3. Вы когда-нибудь пересматривали свой старый код?

  4. Как часто ваш старый кодекс изводит вас? или как часто вам приходится иметь дело с вашим техническим долгом.

  1. Каждый раз я узнаю что-то новое, надеюсь, это каждый день.

  2. Если мне удастся реализовать то, чему я научился, то это сразу после того, как я это осуществлю.

  3. Да, только для (1) новых функций, (2) исправления ошибок, (3) ностальгии, (4) посмотрите, как я решил что-то, может быть полезно.

  4. Что касается 1., когда я узнаю, как сделать что-то лучше, я осознаю, что некоторые старые проекты «могли» быть выполнены лучше. Я оставляю их в покое. Просто убедитесь, что следующий проект сделан лучше. Я не волнуюсь, если это не фактическая ошибка.

Темная ночь
источник
3

В другом вопросе речь шла о способах оценки качества вашего собственного кода. Одним из моих предложений было пересмотреть его через несколько лет, когда ваш опыт намного выше, чем был при написании кода. Одна цитата из моего ответа на этот другой вопрос напрямую связана с вашим вопросом:

«В моем случае продолжительность жизни составляет один год: это означает, что я могу изменить код, который я написал шесть месяцев назад, но если код был написан два года назад, у него есть большие шансы быть брошенным, а затем полностью переписанным, так как это просто отстой ".

Так что да, на практике каждый кусок кода, который я написал, становится невыносимым с моей точки зрения через год. И я говорю не об одноразовом коде, а о коде, который я написал с учетом качества, удобства обслуживания и удобства чтения. На данный момент исключений не было.

Чтобы ответить на ваш второй вопрос о продолжительности жизни, он сильно варьируется. Срок действия одноразового кода составляет ноль секунд : он сосет сразу после того, как вы его написали, но это не имеет значения. Некоторые фрагменты кода, которые я написал, были терпимы через два года , но требовали некоторых косметических изменений: небольшой рефакторинг, применение правил StyleCop и т. Д. В среднем, в моем конкретном случае, продолжительность жизни варьируется от восьми месяцев до одного года для C # и от двух до шести месяцев для PHP.

Я повторно посещаю мой старый код? Да, конечно, как любой разработчик, если вы не заботитесь о СУХОЙ и изобретаете свое колесо снова и снова. Существуют также шансы очень часто просматривать и улучшать код, если у вас есть общая кодовая база, которую вы используете во многих проектах . Другой момент заключается в том, что если вы работаете над огромными проектами, некоторые из них могут занять несколько лет , поэтому вам придется пересмотреть старый код.

Некоторые разработчики, с которыми я сталкивался, утверждали, что они уже находились на стадии развития, когда их кодирование не нуждается в улучшении или не может быть улучшено больше.

Когда человек говорит, что она настолько совершенна, что ей не нужно ничего учить, это означает, что она даже не способна понять, насколько она глупа.

Даже если у вас есть двадцатилетний опыт работы в области компьютеров / программирования, все меняется слишком быстро, поэтому всегда есть что изучать и новые методы для улучшения кода. Например, код на C #, написанный, когда не было .NET Framework 3.0, вполне может быть сделан более читабельным и лучше с новыми вещами, которые мы имеем сегодня (включая Linq, контракты Code и т. Д.), И это, даже если старый код был написан самым умным разработчиком.

Арсений Мурзенко
источник
Это больше похоже на то, что если вы спросите это, вы рискуете оказаться похожим на того, кто не знает, как написать хороший код.
Адитья Р
@AdityaGameProgrammer: есть разница между ошибкой, уродливым кодом и хорошим кодом, который через год или меньше может быть написан более элегантным способом. (1.) Никто не может написать идеальный код, который останется идеальным навсегда, поэтому мы должны признать, что наш код со временем может быть улучшен. (2.) Мы приобретаем опыт и знания с течением времени, что также является источником для улучшения старого кода.
Арсений Мурзенко
1

Это происходит довольно регулярно, когда я смотрю на код и задаюсь вопросом: «О чем я думал, когда писал это?»

Обычно все время происходят улучшения, так как иногда мне приходит новая идея для организации кода, стилизации кода или чего-то еще, и хотя это может и не быть большим улучшением, может помочь любая мелочь, которую стоит сделать.

В зависимости от рабочей среды, я могу видеть код несколько лет назад, поскольку я продолжаю работать в той же кодовой базе и хорошо знаком с тем, что там есть и чем можно управлять.

Старый код почти всегда мучает меня, так как обычно я либо меняю существующую систему, либо заменяю систему. В любом случае, я должен знать причуды существующей системы, чтобы убедиться, что они есть в новой.

Хотя я уверен, что есть такие, как Джон Скит, которые могут просто придумать идеальный код, большинство других людей, которые говорят, что их код не может быть улучшен, говорят, что с точки зрения эго это может быть непривлекательным. В то же время, с точки зрения поиска значительного улучшения каждый раз, это не всегда будет иметь место.

JB King
источник
1

1. Как часто это случается или не случается с вами?

Как часто я недоволен своим старым кодом? Почти всегда. Есть редкие исключения, когда у меня есть код, которым я действительно горжусь ... но, опять же, они редки. Мне сказали, что код, который я написал пару лет назад, был хорош ... Я съежился и подумал: «Бедный бедняк, который видел хуже, чем мусор, который я написал».

2.Как задолго до того, как вы увидите реальное улучшение своего кодирования? месяц год?

Обычно это происходит поэтапно ... Я действительно разбираюсь в стиле или методологии (возьмем, например, беглые интерфейсы ... так как это был последний стиль, для которого у меня был огромный мокрый стиль), и вырезал все, что я пишу, за месяц или четыре , Тогда это начинает выглядеть лучше.

3. Вы когда-нибудь посещали свой старый код?

Не так часто, как хотелось бы. Большая часть моего старого кода принадлежит предыдущим работодателям. Личный код слишком часто стирается.

4. Как часто ваш старый кодекс мучает вас? или как часто вам приходится иметь дело с вашим техническим долгом.

Поскольку у предыдущих работодателей большая часть моего старого кода была, а я стираю большую часть своего личного кода ... совсем не часто.

Стивен Эверс
источник
белая стирка = перефакторинг? Вы имеете в виду код проекта или вашу личную кодовую базу.
Адитья Р
1
@AdityaGameProgrammer: White wash = выбросить все и переписать с самого начала. Я говорю о моем личном коде.
Стивен Эверс