Почему программисты не любят работать с чужим кодом
Есть причина, по которой программисты всегда хотят выкинуть старый код и написать новый: они думают что старый код — плохой. Возможно они неправы. Причина, по которой они думают что старый код — плохой, из-за кардинального, фундаментального закона программирования: тяжелее читать код, чем его писать.
Джоэль Спольски.
http://lurkmore.to/Фатальный_недостаток
А Джоэлю надо было просто вступление, чтобы перейти к теме.
Эти люди не знают что такое рефакторинг
Переписывать код заново — антипаттерн. Там скрыто куча информации, его нужно только рефакторить.
Однако у нормального программиста новый код всегда должен быть лучше чем старый, иначе его надлежит уволить.
Еще раз, старый код не нужно выкидывать, его нужно рефакторить.
(0) Ну. Сказал этот чувак это. И чьто? Чьто-чьто. Да ничьто! (с) фильм «Ликвидация».
_Свои_ мысли как-то надо выражать. Если есть, конечно. Чья-то цитата — не Ваша мысль и не аргумент и тем более не аксиома.
Работает — не трогай.
(5) >> новый код всегда должен быть лучше чем старый
Озвучьте критерии этого «лучше».
(0) Здесь важна не только парадигма «старый» – «новый», но и «свой» – «чужой». Однако если чужой код хорошо работает, то зачем его менять? Даже если в нем трудно разобраться. В этом случае просто больше стимула разбираться. Но вот если код работает плохо, то уже не важно, чей он, свой или чужой. Действительно иногда легче переписать даже свой код, чем рефакторить его. Чего уж там говорить про чужой.
Люди все разные и всех свои собственные представления, что такое «хорошо» и «красиво». Одному нравиться лепить в кучу все операторы и игнорировать разделители, отступы и пустые сроки. А другого это жутко раздражает и пока он не «причешет» чужой код под свои предпочтения, он не способен вникать в него по существу.
Главное, думаю, не «фундаментальный закон программирования», который, скорее всего, высосан из пальца, а вечно стремление человека к совершенству. По принципу, это программа плохая (моя, твоя – не важно), напиши лучшую. И вообще «лучшее – враг хорошего».
(9) > Озвучьте критерии этого «лучше».
По-моему, это очевидно. Лучше, в данном контексте, значит, что новая программа (версия) является гибче, приятней (комфортней, дружелюбней), эффективней, более быстрой, с большим функционалом и возможностями, менее объемной и ресурсоемкой и т.д. и т.п., чем старая.
(10) Лучше, в данном контексте, значит, что новая программа (версия) является гибче, приятней (комфортней, дружелюбней), эффективней, более быстрой, с большим функционалом и возможностями, менее объемной и ресурсоемкой и т.д. и т.п., чем старая.
И для этого её надо переписать на ассемблере с разворотом циклов и прочими прыжками.
Как думаешь. Код. Улучшится?
(0) Не нужно г..внокодить.
Я свой код не переписываю, даже 10 летней давности.
Открываю, он написан по стандартам 1с (похож на код из типовых). Легко читаем, есть коменты. Зачем переписывать?
Хохлы учат русских как писать чистый код. Лекция. Осторожно, укросми
(0) Все подряд переписывать не нужно. А вот кривые и неоптимальные куски кода — нужно. «Кайдзен в бизнесе» должен плавно переходить в «Кайдзен в разработке ПО».
Для тех, кто не в курсе: Кайдзен — это процесс непрерывного усовершенствования.
Свои коды трогать не надо. А вот чужие, кои присутствуют в модулях, надо править, при этом очень ругаться и эту ругань доносить до руководства.
А также постить на мисте.
(0) Не всегда хотят выкинуть старый код.
Вот мне хочется всегда выкинуть говно код, реализованный по принципу «А копирну я одно и тоже раз 200, так же быстро» 🙂
(11) > И для этого её надо переписать на ассемблере с разворотом циклов и прочими прыжками.
Как думаешь. Код. Улучшится?
Чтобы улучшить работу, скажем, учетной программы, совсем необязательно переписывать ее на ассемблере. Хотя бы потому, что с этой задачей можно не справиться физически. Тем не менее, в свое время целые игры писали на голом ассемблере, а у нас в университете учился сириец, который даже собственную операционную систему наваял на ассемблере (что-то типа примитивного ДОСа).
А вот улучшить бизнес-логику программы, поменять медленные алгоритмы на быстрые, увеличить гибкость программы и ее дружелюбность, так структурировать код, чтобы не потерять над ним контроль, даже через несколько лет, для всего этого вполне можно обойтись штатными средствами. Исходя из направленности нашего форума это может быть конфигуратор 1С или, для экстремалов, С++ ради написания ВК под 1С.
+ А потом ковыряешь все 200 процедур и запросов, что бы все это не расплылось в итоге, тратя на это кучу времени 🙂
(0) Как вариант, бывают ситуации когда руководство просит отчеты по отработанному времени и тогда программист разбор такого кода аргументирует как «Переписать код старого программиста».
(15) Такой код как раз и шифруют и пароли ставят 🙂
(0) Все просто — предыдущий программист не оставил документации, либо требования к ПО поменялись, и старый код не удовлетворяет новым запросам.
(12) ЛПиП. Код типовых — не пример для подражания, и второе — за 10 лет изменился достаточно сильно.
(17) + Еще очень важное значение имеет структура данных. Это вообще отдельная песня. Можно быть сколь угодно прекрасным кодировщиком, но легко делать структурные ошибки в данных. Которые как бы и не ошибки, но жизнь пользователей и даже обслуживающих программистов усложняют.
. Часто и свой код легче переписать заново!
А, вообще, зависит от поставленной задачи. Если функционал добавить, иногда лучше старый. А если ошибку найти, то иногда лучше переписать..
(0)Это не всегда оправдано, но всегда полезно. Потому что в процессе написания своего кода после того как наступишь на все грабли и споткнешься обо все подводные камни- ты будешь в теме на все 100% и точно знать как вся эта кухня работает.
«код» в 1с — это слишком громко сказано
(0) Мысль правильная, но изложение.
Человек растет и совершенствуется. Поэтому нередко код, который написан вчера, сегодня уже был бы написан по-другому.
Хорошие программисты рано или поздно приходят к тому, что перестают переписывать. Потому что практически нет нареканий.
(25) Сдавайся :)))))
(15) Ну, когда изменение пары строчек в чужом запросе ускоряет его работу на 2-3 порядка, и таких запросов десятки — сдержаться тяжело.
(0) Во фразе «Есть причина, по которой программисты всегда хотят выкинуть старый код» допущена гипербола. Слово «всегда» — лишнее. Да и вообще, это «не та» цитата Джоэла, которую стоило бы озвучивать на форуме программистов 1С, где платформы и конфигурации меняются как перчатки шесть раз на дню.
PS: и не «Джоэль», а «Джоэл» — пишется не так, как произносится.
(5) ERP хуже УПП. Там даже нормальных отборов нет. Вывод — в 1С ненормальные программисты 🙂
(29) «Вывод — в 1С ненормальные программисты »
Открыл Австралию.
(10) Обычно каждая новая версия программы тормознее и глючнее 🙂
(17) Гибкость и дружелюбность — обычно несовместимы. Чем гибче программа — тем адовее она для пользователей.
Окостылил говнокод?
Ляг, поспи и все пройдет.
Встал, покодил, все равно
Получается говно.
Как не патчил много лет,
Как не фиксил баги,
Все-равно велосипед
На костыльной тяге.
Что б совсем без костылей,
Великов и багов
Нанимайте, говорю,
Нанимайте магов!
(25) Во-во, нет кода кроме машинного.
(30) Не, я просто обосновал эмпирический выводы 🙂
(36) Угу, добавление движений при проведении в чужой документ — это вообще как через задний проход гланды удалять.
каждый раз когда возникает желание переписать чужой код, задайте себе вопрос «а кто за это заплатит?» и желание сразу отпадет
(39) если на окладе, то все оплачено уже
(0) Это психология.
Профессия программист в соответствии с эволюционными законами и естественным отбором, отбирает людей склонных к интровертности и перфикционизму.
Поэтому когда смотришь на свой код пятилетней давности, то приходишь в ужас и руки тянуться все переписать правильно. Хотя пять лет назад этот код казался гениальным решением.
(32) > Гибкость и дружелюбность — обычно несовместимы. Чем гибче программа — тем адовее она для пользователей.
Как по мне, то многое зависит от дружелюбности самого программиста. Есть программисты, которые любят пользователей, часто ставят себя на их место, и есть, которые не любят и получают садистское удовольствие от их мучений. Таких нужно в принудительном порядке заставлять работать определенное время на собственных программах, без возможности их модификации. Тогда будут думать, прежде чем вводить избыточные ограничения.
Возьмем, скажем, дополнительные настройки. Не обязательно, чтобы они мозолили глаза пользователю, главное, чтобы они были. Например, в «семерке» нет возможности штатно установить точные размеры формы, только «на глаз». Нет возможности задать центровку всех окон – они обязательно должны скакать по монитору, потому что такой стандарт придумал де Билл (который Гейтс). Настройки эти пользователю не дали, типа упростили ему жизнь, поэтому народ изголяется, как может, придумал FormEx, 1C++ и т.п. Вплоть до того, что декомпилирует md-файлы и правит там формы вручную.
Второй пример, жесткая заточенность на законодательство. Типа, если пользователю разрешить отключать механизм вытеснения в «зарплате», то он обязательно одновременно насчитает себе и другим оплату по окладу, отпуск, больничные и командировку в один и тот же период. Но иногда наложение разных графиков либо отклонений все же необходимо, почему бы не позволить это делать под ответственность самого пользователя?
В идеале, допустим, «зарплата» созданная под российское законодательство должна быть теоретически способна быть перенастроенной под законодательство другой страны, например, ЛНР / ДНР или даже какой-нибудь Белоруссии с Казахстаном. Вот это я понимаю – гибкость. А так нынешний ЗУП это идеальный образец жёсткости.
выбросьте слово «всегда» из формулировки.
или добавьте «неопытные».
а то получается безапелляционное и неверное утверждение, которое выносится в заголовок и подразумевается истинным, а обсуждать начинают уже комментарии к нему.
это старый и грязный прием софистов.
Почему программисты ненавидят работать с чужим кодом?
Многие люди, далекие от программирования, часто не понимают, почему программисты ненавидят работать с чужим кодом? Что их так раздражает? Многим кажется, что программисты просто слишком гордые или же им просто не нравится как именно все написано.
Некоторые даже считают, что программисты попросту ленивые люди, которые не очень хотят и умеют работать с тем, что писали не сами. Например, некоторые специалисты говорят о том, что, в целом, можно за 1-2 дня разобраться в любом коде на любом языке, узнать проект и улучшить его. И, в большинстве случаев, намного легче доработать то, что уже есть чем начинать с нуля. Потому что на продумывание архитектуры, структуры базы всегда уходит намного больше времени, чем человек планирует. Даже матерый программист, который работает уже несколько лет и отлично кодит, все равно в какой-то момент начинает “буксовать”. И это приводит к большим временным и финансовым затратам. Но, при этом, люди все равно не хотят работать с чужим кодом.
Легаси-коди спагетти-код
Легаси-кодом называют коды, написанные на устаревших языках. А спагетти-кодом те, которые имеют очень сложную и запутанную структуру. С такими кодами программисты очень не любят работать, поскольку на то, чтобы в них нормально разобраться, уходит очень много времени.
Как проходит код-ревью?
Также часто программисты не любят работать с кодом-ревью. В идеале специалист отправляет свою работу другому специалисту. Тот смотрит, формирует фидбек, отправляет автору. Автор может задавать уточняющие вопросы, узнать, почему именно рекомендованы те или иные изменения. После этого он снова отправляет код на проверку. Все вроде бы выглядит очень просто. Но здесь мы сталкиваемся с человеческим фактором. Часто автор просто не готов принимать критику и адекватно на нее реагировать. Вместо того чтобы прислушаться к рекомендациям, программисты начинают спорить, переходить на личности. Тем самым они тратят уйму времени, нервов, как своих, так и чужих. И, в итоге, так и не приходят к консенсусу.
Почему программисты ненавидят работать с чужими кодами?
Самая банальная причина – код написан настолько плохо, что глядя в него, человек понимает – легче все переписать заново, чем пытаться это исправить. Особенно плохо дело обстоит в той ситуации, когда программист получает код, видит, что все очень плохо, связывается с человеком, который уже написал код. И вместо адекватного объяснения получает либо молчание, либо возмущение. В такой ситуации очень сложно начать работу. Потому что непонятно, где были допущены ошибки, чего именно человек хотел добиться, создавая именно такой код.
Вот это, пожалуй, и есть самые простые и самые реальные причины того, что программисты не хотят работать с чужим кодом.
Как читать чужой код: 6 правил, которые стоит помнить разработчику
Каждому программисту рано или поздно предстоит разобраться в чужом коде, однако не все это делают правильно. Мы перевели статью разработчика Уильяма Шона и узнали, как читать чужой код так, чтобы понимать его и выносить из этой практики что-то новое.
Вы читаете обновленную и улучшенную версию нашей старой статьи
Почему разработчики не любят разбираться в чужом коде
«Ненавижу читать чужой код», — такую фразу можно часто услышать от программистов. Причина их ненависти в том, чужой код пишут не они. Это не значит, что каждый разработчик страдает манией величия, все гораздо проще: читатель никогда не испытает того потокового состояния, в котором находился программист, когда создавал свой код. Поэтому пассивное чтение иногда бывает скучным.
Читатель может не осознавать, что видит на экране труд нескольких разработчиков. Возможно, они спорили во время кодинга, и он дался им нелегко. Возможно, разработчикам потребовались недели, чтобы выдать код, который обходит недокументированные ограничения. Читатель имеет дело с законченным продуктом и даже не догадывается, что стоит за многократно выверенными строками кода.
Рано или поздно у разработчика наступает момент, когда ему предстоит читать чужой код. Например, когда программисту нужно изменить или обновить существующий код, провести код-ревью, разобраться в работе программного интерфейса. Для этого нужно знать, как читать и понимать чужой код. Это умение полезно и тем, кому только предстоит освоиться в кодовой базе. Разберемся, на что обратить внимание при чтении чужого кода, чтобы понять его и, возможно, чему-то научиться.
Как правильно читать код
Научитесь проводить «раскопки» в коде
При первом знакомстве с серьезной кодовой базой вы будете ощущать себя не разработчиком, а археологом, частным сыщиком или исследователем религиозных книг. Вам придется проводить «раскопки» в чужом коде, чтобы понять, как он создавался.
Если вы работаете над кодовой базой, в которой разработчики использовали контроль версий, то у вас есть доступ к метаданным. Изучите следующие команды для Git, чтобы узнать, как изменялся код (они подойдут и для SVN):
git blame
С помощью этой команды вы узнаете имя автора кода, дату последних изменений и хэш коммита (зафиксированного изменения в коде) для каждой строки. Так можно найти историю кода и понять, какой именно код был внесен в репозиторий, как это было сделано и по какой причине. Если это возможно, познакомьтесь с авторами кода: они постараются ответить на ваши вопросы.
Читая код, убедитесь, что вы понимаете, где он начинает выполняться и что происходит в процессе его запуска. Посмотрите, какие файлы подключаются, какие классы используются, какие опции конфига устанавливаются. Скорее всего, вы будете постоянно сталкиваться с ними во всей кодовой базе.
Некоторые модули могут выделяться из остального кода и иметь очень общее назначение. Выполните git blame и посмотрите, какие части основного файла недавно изменяли. Так вы узнаете проблемы, которые решала команда в последнее время. Возможно, разработчики долго пытались наладить библиотеку, которая не слишком хорошо работала. Может, там просто шаблонный код, который нужно регулярно обновлять.
Попробуйте найти примеры таких выделяющихся модулей в других частях кода, чтобы узнать, как и когда они используются. Это поможет вам понять место и роль модулей в основном приложении.
git log и git grep
Используйте команду git log , чтобы увидеть историю коммитов по всему репозиторию. Команда git grep поможет вам найти в коммитах конкретный текст, например, название функции someFunction: git log | grep someFunction -C 3 . Последние флаги покажут вам найденные выражения с тремя строками окружающего контекста.
Также git log может показать вам историю отдельного файла. Чтобы ее посмотреть, используйте флаг -p: git log -p index.js . Обращайте внимание на имена авторов коммитов, чтобы знать, кому в будущем адресовать вопросы.
Переключайтесь между коммитами и изучайте историю кода
Вы можете переключиться на любой коммит и запустить проект так, будто этот коммит был последним. Как правило, это делают для того, чтобы выявить сложно отслеживаемую проблему. Также коммиты переключают, чтобы увидеть историю кода.
Если проект хранится на GitHub или подобном сервисе, вы можете узнать много нового, читая пулл-реквесты и код-ревью. Обращайте внимание на тикеты — карточки-задачи для отслеживания работы над багами, внедрения функций. Читайте обсуждения в тикетах: там могут быть «болевые точки», с которыми вы можете столкнуться в будущем, поэтому лучше иметь представление о них заранее.
Читайте спецификации
Specs или спецификации — это новые комментарии к коду. Читайте unit specs, чтобы выяснить предназначение функций, модулей и возможные пограничные случаи (edge-cases), которые они обрабатывают.
Также читайте интеграционные спецификации, чтобы понять, как пользователи будут взаимодействовать с вашим приложением и какие процессы оно поддерживает.
Воспринимайте комментарии как подсказки
Если в процессе изучения кода вы наткнулись на непонятную функцию и прочли комментарий к ней, который еще больше вас запутал — возможно, он просто устарел. Держите это в голове: если комментарий к функции давно не обновлялся, вероятно, она исчезла уже много месяцев назад, и кроме вас это никто не заметил.
Обращайте внимание на стиль написания кода
Читая чужой код, посмотрите, соблюдены ли стандарты его оформления, есть ли именования, пробелы, скобки. Обратите внимание на общий уровень абстракции кода. Если у него много уровней абстракции, то вам следует их использовать и в своем коде.
Если вы хорошо провели «раскопки», то нашли момент, когда один из разработчиков решил абстрагировать часть кода. Вспомните, как код выглядел до этого изменения и задумайтесь, что с ним стало после выноса на новый уровень абстракции.
Работая над проектом, посмотрите, какие конструкции используют разработчики из вашей команды. Если они отдают предпочтение циклам, а не функции map , то и вам следует их использовать. Если вам не нравится стиль оформления кода в проекте, обсудите это с командой — это лучше, чем смешивать разные стили в одном файле. Хороший код выглядит так, будто он написан одним человеком.
Избавляйтесь от «мусора» в коде
Пока вы читаете код, вам могут встретиться функции и целые файлы, которые разработчики никогда не используют, и комментарии, на которые никто не отвечал несколько лет. Не тратьте на разбор всего этого много времени — избавьтесь от «мусора». Если этот код все еще нужен, кто-нибудь отметит это на код-ревью. Удалив ненужное, вы сбережете силы и время того, кто будет читать этот код после вас.
Итог
Не падайте духом, если чувствуете, что вы совсем запутались в чужом коде. Изучение кода — это не линейный процесс. Не ждите, что сразу поймете все на 100%. Обращайте внимание на важные детали, проводите «раскопки», чтобы найти ответы на вопросы, и, надеемся, все станет понятнее.
Никогда не останавливайтесь: В программировании говорят, что нужно постоянно учиться даже для того, чтобы просто находиться на месте. Развивайтесь с нами — на Хекслете есть сотни курсов по разработке на разных языках и технологиях
Чужой код. Порвало). Я просто положу это здесь
Меня недавно спросили, почему программисты ненавидят работать с чужим кодом. Долго думал, как донести до обычного пользователя всю суть пиздеца.
Решил привести небольшую аналогию:
Вот представь, что тебе доверили достроить за другим прорабом лабораторию на острове. Ты приходишь на объект, а там кроме недостроенного здания: огромный вентилятор (размером со здание), большой воздушный шар и комната набитая швабрами. Почесав голову, ты разбираешь этот хлам и доделываешь лабораторию. Сдаешь объект ученным, но через 5 минут они выбегают с криком: «УТЕЧКА ЯДОВИТОГО ГАЗА. «.
— Как так–то, блять! Должно же работать! — в отчаянии кричишь ты и звонишь прошлому прорабу:
— Вася, у нас ядовитый газ потёк! В чем проблема?
— Не знаю, должно было все работать. Что–то в проекте менял?
— Немного, швабры вынес.
— Швабры потолок держали!
— Что. Что, блять, извините.
— Говорю, швабры потолок держали. Над ними цистерны с газом были. Очень тяжелые, пришлось в комнату снизу швабры напихать.
— Ты хотя бы записку на двери повесил бы, что швабры для держания потолка! У нас тут ядовитый газ течет! Что нам делать?
— Включай вентилятор. Он сдует газ с острова.
— Я его, блять, демонтировал сразу же!
— Зачем?
— Зачем ты построил 120 тонный вентилятор? Ты не мог положить ящик блядских ПРОТИВОГАЗОВ?
— Ящик противогазов искать нужно, а вентилятор у меня с прошлого заказа оставался.
— Вася, я убрал твой вентилятор! Мы тут задыхаемся!
— Херли вы тогда там делаете? Садитесь на воздушный шар и уебывайте!