сентиментальный код [закрыто]
https://stackoverflow.com/questions/1414969
-
06-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Я наткнулся на статью, в которой обсуждается проблема «восхищения кодом».По сути, автор говорит о том, что разработчикам следует более скептически относиться к коду, который они пишут.Как мы можем слишком сильно «восхищаться» нашим кодом, привязываться к нему, делая нас более уязвимыми для ошибок и других неудач, которые могут нас ждать.
Как вы относитесь к этому вопросу?Есть ли у вас еще советы о том, как избежать этой проблемы или быть более осведомленным об этой проблеме?
Решение
Несколько лет назад я работал с другим над небольшим "хобби" проект, и я понял, что мы должны переоценить вещи. Мы написали много кода, но не все было хорошо.
На самом деле мы не хотели "выбрасывать" всю работу, которую мы проделали. Но я кое-что понял: больше всего было важно, сколько работы нам нужно будет выполнить в с этого момента .
Мы не могли изменить тот факт, что мы уже вложили так много работы в проект, поэтому единственный способ минимизировать общий объем работы, который потребуется проекту, - это минимизировать объем работы, которую мы еще не сделали .
С того дня я перестал привязываться к своему коду. Если я уверен, что выбрасывать его и начинать с нуля означает меньше работы, чем хранить его и адаптировать к моим потребностям, тогда я его выброшу.
Другие советы
Мой учитель рисования в средней школе побуждал нас брать то, что мы считали нашими лучшими рисунками, и рвать их; он назвал это «очищением души». Он рассуждал о том, что, будучи художниками, мы были вынуждены создавать произведения искусства, и каждый раз, когда мы создавали что-то, что нам нравилось и приносило нам удовлетворение, наша мотивация продолжать создавать уменьшалась.
Поэтому я последовал его совету и порвал свои лучшие вещи, и это сработало. Вместо того, чтобы тратить время на восхищение моей старой работой, я создавал новые вещи и постоянно поправлялся. Я пытался следовать тому же принципу в своем коде, но на самом деле он не работает: у моего компьютера жесткая пластиковая оболочка, которую почти невозможно пробить.
Я публикую фрагмент из блога Джеффа Этвуда, Сосать меньше каждый год и я согласен на 100%.
Я часто думал, что сосать меньше каждый год как скромные программисты улучшить. Вы должны быть недовольны код, который вы написали год назад. если ты не, это означает либо А) вы ничему не научился за год, б) ваш код не может быть улучшен, или C) вы никогда не пересматривать старый код. Все из этого поцелуй смерти для программного обеспечения разработчики.
Нам, конечно, нравится восхищаться нашим красивым кодом, но не всегда легко понять, чем восхищаться.Сложный и продуманный код иногда ошибочно принимают за достойный восхищения код, тогда как к элегантности и простоте следует стремиться.
На ум приходят две цитаты:
«Отладка в два раза сложнее, чем написание код в первую очередь.Поэтому, если вы напишете код как как можно умнее, вы, определение, недостаточно умное для отладки это.
-- Брайан Керниган
и
«Сделайте все так же просто, как возможно, но не проще».
-- Альберт Эйнштейн
Джонатан Эдвардс написал поразительно красивое эссе на эту тему, вызванная работой над книгой О'Рейли Красивый код . Вот последний абзац, но остальная часть эссе также стоит прочитать.
Еще один урок, который я усвоил, - не доверять красоте . Кажется, что увлечение дизайном неизбежно приводит к душераздирающему, поскольку пропускаются отвратительные реалии. Любовь слепа, но компьютеры - это не так. Долгосрочные отношения & # 8211; поддержание системы в течение многих лет & # 8211; учит ценить больше внутренних достоинств, таких как прямолинейность и условность. Красота - это идеалистическая фантазия: что действительно важно, так это качество бесконечного разговора между программистом и кодом, когда каждый учится у другого и адаптируется к нему. Красота не является достаточным основанием для счастливого брака.
Другие версии этой же мудрости существуют в других областях. Сэмюэль Джонсон, о написании:
Прочитайте свои сочинения, и, где бы вы ни встретились с отрывком, который, по вашему мнению, особенно хорош, вычеркните его.
Версия Уильяма Фолкнера была гораздо более краткой: & # 8220; Убей своих любимых. & # 8221;
Мой тесть работает в качестве редактора фильмов, и он старательно избегает съемок фильма. Когда он должен посетить, он прикрывает глаза столько, сколько он может. Это потому, что когда он решает, включать сцену в финальный фильм или нет, он не хочет зависеть от того, сколько усилий потребовалось, чтобы снять сцену. Важно то, насколько хорошо сцена работает в финальном фильме.
Мое эссе, "Моя эволюция как программист" (на который я хотел бы сослаться, если бы я не был новым пользователем), он в основном посвящен изучению скептицизма в отношении написанного мною кода: работает ли он, полезен ли он, понятен ли он (парное программирование было настоящим вызовом для пробуждения) Вот). Это сложно!
Я никогда не восхищаюсь своим кодом. Я восхищаюсь кодексом других людей, который я заимствую. и пытаюсь подражать им или лучше их, и я нахожу, что чем больше я знаю, особенно о кодировании, тем больше я нахожу, что не знаю. Единственное, что может стоить того, чтобы равные программисты восхищались моим кодом и заимствовали его.
Я думаю, что у него есть хорошая точка зрения.Очень неприятно работать с людьми, у которых этого слишком много, поскольку это действительно мешает командной работе и поиску наилучшего решения проблемы.
Поскольку я могу немного заблуждаться, я стараюсь применять практики, которые помогут мне оставаться в реальности.Для кода,
модульные тесты:Это заставляет меня больше сосредоточиться на том, что должен делать код, а не на абстрактной «красоте».
владение общим кодом:Здесь есть два лагеря:дайте людям больше ответственности за свой код и надейтесь, что гордость возьмет верх, или дайте им меньше и позвольте вступить в игру давлению со стороны коллег.Я считаю, что предоставление людям большей ответственности может привести к восхищению этим кодом.Мы практикуем совместное владение кодом, поэтому мне постоянно приходится видеть, как кто-то переписывает мой идеальный код, чтобы сделать его лучше (по их мнению).Я быстро понял, что слишком сильно восхищаться им — пустая трата времени и эмоционально трудная трата времени.
парное программирование:Работая бок о бок с кем-то, вы сохраните реалистичность.
другой отзыв:Это все петли обратной связи, но есть и другие.Нет лучшего способа проверить, работает ли что-то, чем наблюдать, как кто-то (пытается) это использовать.Покажите свою работу как можно большему количеству людей.Проведите обзоры кода.Читать чужой код.Бегать статический анализ кода инструменты.
Я работаю с PurplePilot - я не восхищаюсь своим собственным кодом, и поэтому я постоянно ищу новые, более эффективные (черт возьми, более простые) способы сделать то же самое. Мне нравится книга Effective c #, я получил много полезного кода, которым я восхищаюсь.
У меня не было бы сомнений в том, что нужно выбросить код и начать заново, но не обязательно с нуля, то есть, написав некоторый код для конкретного сценария и затем выбросив его, вы, вероятно, лучше поймете сценарий. Другими словами, это «злая проблема», или вы нашли другой способ, который не работает, как Эдисон.
Возникает более широкий вопрос: если код не выбрасывается или, по крайней мере, пересматривается, развивается на библиотеках, которые становятся стагнацией, хорошо?
Нет ничего плохого в том, чтобы восхищаться вашим кодом ... это часть процесса позитивного подкрепления, который побудит вас писать больше и лучше кода в будущем.
Однако восхищение неуместным или злоупотреблением может быть проблемой. Если код на самом деле не очень хорош, или содержит ошибки, которые не были обнаружены модульным или другим тестированием, или нуждается в рефакторинге / редизайне / замене, тогда это неуместное адмиратоин является проблемой. И использование восхищения в качестве предлога для пропуска части процесса - например, проверки кода или отсутствия скептического отношения к коду - является злоупотреблением восхищением.
Как и все хорошее, восхищение кодом может быть неуместным или неправильным - это не значит, что это само по себе плохо. Это все равно что сказать «религия - это плохо, потому что она вызывает конфликты и войны между людьми».
Два слова: проверка кода.
Соберите двух или более коллег-разработчиков и предложите им просмотреть / критиковать / прокомментировать ваш код. 'Твил пролил немного (по общему признанию резкого) света на ваш код.
Возможно, лучше иметь более здоровую перспективу - мы не ракетостроители и не лечим рак - это просто работа.
(Да, разумно гордиться целым зданием, которое вы помогли построить, если вы архитектор, но действительно ли у них много самооценки, заключенной в индивидуальный проект или шкаф на 3 этаже? они разработали сами?).
