Откуда вы знаете, что пишете хороший код? [Дубликат]

    

У этого вопроса уже есть ответ:

    

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

Что все сказано, я чувствую, что никогда не знаю, хороши ли мои программы. Конечно, они работают - но это код чистый, плотный, хорошо написанный материал, или другой кодер посмотрит на него и ударит меня по голове? Я вижу кое-что в Stack Overflow, которое просто сбивает меня с ума, и мои попытки кодирования кажутся полностью слабыми. Мои работодатели были довольны тем, что я сделал, но без экспертной оценки, я в темноте в противном случае.

Я просмотрел обзор однорангового кода, но многие вещи не могут быть опубликованы из-за NDAs или вопросы конфиденциальности. Многие из вас, профессионалы, могут иметь товарищей по команде, чтобы смотреть на вещи через плечо или подпрыгивать вокруг, но как насчет независимых и сольных парней, таких как я? Как вы узнаете лучшие практики и убедитесь, что ваш код до табака?

Или не имеет значения, является ли это «лучшим», если он работает так, как ожидалось, и обеспечивает хороший пользовательский интерфейс?

265 голосов | спросил 6 revs, 5 users 50%
Jim
1 Jam1000000amThu, 01 Jan 1970 03:00:00 +030070 1970, 03:00:00

25 ответов


325

Самый большой ключ для меня:

Когда вам нужно вернуться и добавить /изменить функцию, сложно? Вы постоянно нарушаете существующую функциональность при внесении изменений?

Если ответ на это «да», вы, вероятно, имеете плохой общий дизайн.

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

ответил 19 PM00000060000001231 2011, 18:27:12
176

Это, безусловно, довольно стандартная мера, в которой я работаю.

Code Quality = WTFs /minute

  

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

(Robert C Martin, Очистить код - книга, которая открывается с изображением выше)

ответил 19 PM00000060000001231 2011, 18:27:12
103

Вы знаете, что пишете хороший код, когда:

  • Все умны, но не слишком умны.
  • Алгоритмы оптимальны как по скорости, так и по читабельности
  • Классы, переменные и функции хорошо названы и имеют смысл, не думая слишком много.
  • Вы возвращаетесь к нему после выходных, и вы можете прыгать прямо в
  • Вещи, которые будут повторно использоваться, могут повторно использоваться
  • Модульные тесты легко писать
ответил 19 PM00000060000001231 2011, 18:27:12
59

Хотя вы сказали, что у вас нет других кодеров, чтобы сделать это, я включу это ради других.

Тест качества кода: У другого программиста, который никогда не видел код, прочитайте его, объясните, что каждый модуль делает с вами, пока вы смотрите через плечо. Чем сильнее ваше желание вскочить и объяснить что-то, тем хуже код. Если вы можете спокойно сидеть там, закрыв рот, и им не нужно задавать много вопросов, вы, вероятно, хороши.

В ваших интересах, вот некоторые общие рекомендации, когда у вас нет подходящего партнера. Они не абсолюты, просто «пахнут».

Хорошие знаки

  • Методы, как правило, очень короткие, что идеально выполняет одну задачу.
  • У вас достаточно информации для вызова методов, не глядя на их тело.
  • Модульные тесты легко писать.

Плохие знаки

  • Длинные методы, состоящие из 2-3 подзадач, которые не разбиваются на другие методы.
  • Способы обмениваются данными с помощью некоторых средств, отличных от их интерфейса.
  • Если вы изменяете реализацию одного метода (но не интерфейса), вам нужно изменить реализацию других методов.
  • Много комментариев, особенно длинных комментариев.
  • У вас есть код, который никогда не запускается в вашем приложении, чтобы обеспечить «будущую гибкость».
  • Большие блоки try /catch
  • Вам трудно найти подходящие имена методов или они содержат слова «OR» и «AND» (например, GetInvoiceOrCustomer).
  • Идентичные или почти идентичные блоки кода.

Вот более длинный список запахов кода , который также должен быть полезен.

ответил 19 PM00000060000001231 2011, 18:27:12
27

Для меня лично я думаю, что это когда я забываю о коде. Другими словами:

  • Ошибки редко встречаются
  • Когда они происходят, другие люди разрешают их, не спрашивая меня.
  • Еще важнее, никто никогда не спрашивает меня о моем коде.
  • У людей нет высокой скорости WTF /min при чтении.
  • Многие новые классы в системе начинают использовать мой класс ( high fan-in , как это назвал Стив Макконнелл)
  • Код легко модифицировать и /или рефакторировать при необходимости, без проклятия (даже если это я - проклинаю себя!)
  • Мне также нравится, когда я предполагаю, что только нужная сумма абстракции, которая, кажется, подходит всем в команде.

Это приятное чувство, когда вы открываете файл, который вы написали год назад, и видите все приятные дополнения для класса, но очень мало модификаций , и - очень высокий уровень вентилятора! :)

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

ответил 19 PM00000060000001231 2011, 18:27:12
20

У меня есть три золотых правила:

  1. Если я чувствую себя вынужденным копировать /вставлять блоки кода, я делаю что-то неправильно
  2. Если я не могу взять весь код в голове, я делаю что-то неправильно
  3. Если кто-то прыгает и теряется в моем коде, я делаю что-то неправильно

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

ответил 19 PM00000060000001231 2011, 18:27:12
11

Это отличный вопрос, и я приветствую вас за то, что вы даже просили.

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

Теперь, откуда вы знаете, когда пишете хороший код?

  • Когда ваши классы обслуживают одну, очень четко определенную цель, отделены от других классов другими четко определенными целями.
  • Когда ваши методы короткие - в идеале менее 50 строк и, конечно, менее 100 - и их имена четко определяют, что они делают именно . Метод не должен делать ничего, кроме того, что подразумевает его название. Если вы переходите более 100 строк или закладываете очень далеко, вы, возможно, можете что-то вытащить в свою собственную функцию.
  • Когда ваш код предоставляет один способ сделать что-то - когда он не предоставляет возможность зигзагообразного или zag, но вместо этого предоставляет один линейный путь для каждого возможного курса действий, пользователь может его отправить.
  • Когда вы сделали все, что разумно, можете уменьшить связь между классами; так что, если класс А зависит от класса B, а класс B удаляется, а класс C помещается в его место, незначительные изменения не должны быть внесены в класс A. Класс A должен быть настолько слепым, насколько это возможно, к тому, что происходит в внешний мир.
  • Когда ваши имена классов, методов и переменных могут быть прочитаны и немедленно поняты всем, кто встречает код, нет необходимости в «pktSize», когда «packetSize» читает гораздо более easliy.

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

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

ответил 19 PM00000060000001231 2011, 18:27:12
7

Я бы сказал, что мои основные моменты:

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

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

Хорошая статья MSDN по этой теме: Что хорошего кода хорошего?

ответил 19 PM00000060000001231 2011, 18:27:12
6

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

Например, sendmail - это какое-то место, чтобы посмотреть, записываете ли вы код спагетти . На самом деле это не ошибка sendmail; ему всего 20 лет, поэтому в нем много крутизны. Поэтому, если ваш код выглядит как код sendmail, вы, вероятно, ошибетесь.

Я не смотрел на Postfix в последнее время сам, хотя, и это вероятно, очень хорошо спроектирован. Поэтому, если ваш материал больше похож на постфикс, вы на правильном пути.

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

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

ответил 19 PM00000060000001231 2011, 18:27:12
6

Это был мой опыт с момента перехода из мира колледжа программирования в отрасль за последние пять месяцев:

  • Простота использования настолько важна, что мы платим людям только за разработку пользовательских интерфейсов. Кодеры часто втягиваются в дизайн пользовательского интерфейса.
  • Вы обнаружите, что получить его на работу недостаточно [/li>
  • Оптимизации становятся более критичными в реальных сценариях.
  • Есть тысячи способов подойти к проблеме. Тем не менее, часто, когда подход не учитывает несколько менее известных факторов, которые могут негативно повлиять на эффективность вашего подхода, например, аутентификацию базы данных, транзакции, файл модульного тестирования (это, по общему признанию, от компании к компании)

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

ответил 19 PM00000060000001231 2011, 18:27:12
2

Когда вы можете прочитать это как прозу.

ответил 19 PM00000060000001231 2011, 18:27:12
2

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

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

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

  • Требования были нарушены.
  • Код не работает
  • Приложение не интуитивно понятное
  • Разработчик не понял потребности пользователя
  • Кто-то нажал на дату доставки по качеству
  • Кто-то плохо тестировал или не знал, что тестировать для
ответил 19 PM00000060000001231 2011, 18:27:12
2

Прочтите хороший код и выясните, почему это хорошо. Прочитайте плохой код и выясните, почему это плохо. Прочтите посредственный код и выясните, какие части хороши, что плохо, и что хорошо. Прочтите свой собственный код и сделайте то же самое. Возьмите пару (хорошо расцененных) учебников специально для того, чтобы взглянуть на примеры и понять, почему они написали их так, как они это делали. В основном, прочитайте код, пока не сможете определить разницу между плохим и хорошим, и можете сделать свой собственный «Wtf?». тесты.

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

(«Прочитать код других людей» появилось в нескольких комментариях по этой теме, но я подумал, что это заслуживает его собственного сообщения)

ответил 19 PM00000060000001231 2011, 18:27:12
2

Попросите кого-нибудь еще взять на себя работу в течение одного дня и проверить, насколько он стеснен в конце дня; -)

Я плохо документирую и очищаю вещи - так вот как я это проверяю.

ответил 19 PM00000060000001231 2011, 18:27:12
1
  

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

Рассматривали ли вы запрос другого кодера, что они думают о вашем коде?

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

ответил 19 PM00000060000001231 2011, 18:27:12
1

ИМХО, нет «хорошего кода» как такового, но есть «хороший кусок программного обеспечения».

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

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

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

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

ответил 19 PM00000060000001231 2011, 18:27:12
1

Хороший код субъективен человеку. Профессиональный кодер, который прочитал много книг и был на семинарах и использовал различные методы кодирования, вероятно, разорвал бы ваш код на клочки ... Однако я обнаружил, что код действительно свидетельствует о том, где уровень опыта кодировщиков. Для меня это читается как книга истории или автобиография. Это то, что знал кодер в то время или какие инструменты он ограничивал.

Спросите себя об этом ... Почему Microsoft использует 3 версии программного обеспечения, чтобы что-то сделать правильно? Потому что они постоянно исправляют ошибки, допущенные ими в предыдущих версиях. Я знаю, что мой код всегда становится лучше и лучше после пересмотра. Конечно, здесь будут люди, которые говорят, что я пишу код в первый раз. Если вы считаете, что тогда у меня есть болотная земля, чтобы продать вас ...

Как вы понимаете, все становится проще. Для меня начало изучения чего-то нового - «могу ли я заставить его работать?», То следующий шаг: «Интересно, могу ли я сделать это таким образом ...», тогда обычно, когда я прибивал его, я спрашиваю «как я могу сделать это быстрее» ...

Если вы хотите быть программистом, тогда вам нужно погрузиться в него и просто сделать это. Это требует много работы, и, честно говоря, это похоже на произведение искусства, которое никогда не может быть закончено. Однако, если вы хотите быть просто случайным любителем, тогда, если он работает, не беспокойтесь об этом. Вы должны приспособиться к своему окружению. Если у вас нет способа делать обзоры кода, то невежество - это блаженство =)

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

ответил 19 PM00000060000001231 2011, 18:27:12
1

Для конкретного фрагмента кода:

Если он работает и поддерживается (выберите подходящую практику), это хороший код.

Для вас как разработчика с течением времени:

Хорошее - относительный и динамичный термин, к языковой области, проблемной области, текущим тенденциям и, самое главное, вашему опыту. «ХОРОШИЙ» кислотный тест для этого континуума мог бы просто оглянуться на вашу предыдущую работу, и если вы скажете « sigh , я действительно решил это так?» то, скорее всего, вы все еще растете и, вероятно, продолжаете писать хороший код.

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

ответил 19 PM00000060000001231 2011, 18:27:12
0

Отпустите свой код, позвольте некоторым людям возиться с ним, чтобы убедиться, что он делает то, что он всегда должен. Или, если хотите, спроектируйте спецификацию и убедитесь, что она соответствует всем этим спецификациям. Если вы пройдете один или оба этих теста, тогда ваш код «хорош для прямо сейчас». Для большинства людей ваш код никогда не будет отличным, потому что вы вернетесь через год и скажете: «Почему я сделал , что , когда он работал бы намного лучше this путь? "

С большим опытом вы получаете лучший код. Но если вы постоянно практикуете одни и те же привычки, вы будете постоянно попадать в те же ловушки. Это простой пример старой поговорки «Практика делает постоянным ». Если вы постоянно делаете что-то правильно (например, проверяя свой код, чтобы он всегда работал над тем, что он должен делать), тогда вы поправляетесь. Если вы постоянно делаете неправильный путь (например, никогда не проверяя свой код для определенных ситуаций или не узнавая, где могут возникнуть ошибки), вы просто упрямете с вашим кодом.

ответил 19 PM00000060000001231 2011, 18:27:12
0

Ничто не сравнится с тем, что кто-то испытал ваш код, но есть некоторые ресурсы, которые помогут вам оценить и улучшить свой код самостоятельно. Взгляните на Рефакторинг (или сайт ). Sahter и Alexandrescu Стандарты кодирования C ++ хороши, если вы пишете на C ++. Многие рекомендации в этой области являются агностиками языка, но другие могут рекомендовать похожие книги для других языков. Разработка, основанная на тестах, может быть очень полезна для разработчиков соло, поскольку она обеспечивает качественную проверку, когда вы идете, и вы знаете, когда тесты становятся трудными для написания, что это означает, что ваш код, вероятно, может использовать реструктуризацию.

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

ответил 19 PM00000060000001231 2011, 18:27:12
0

Вы можете использовать инструмент анализа кода, например FindBugs , PMD . Это даст некоторую информацию о качестве вашего кода.

ответил 19 PM00000060000001231 2011, 18:27:12
0

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

После этого момента я поставил его на тест: найдите человека, который довольно не разбирается в компьютерах в целом, попробуйте объяснить некоторые основные шаблоны кода. Если они могут сортировать-прочесть его, ничего себе. Хорошая работа.

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

ответил 19 PM00000060000001231 2011, 18:27:12
0

Никогда.

«Хороший код» - это только код, для которого еще не найден какой-либо способ улучшения. Как Джефф Этвуд сказал :

  

Есть несколько программистов в   мир, способный производить   блестящий, идеальный код. Все остальные   из нас может сделать, это сделать наше   программное обеспечение менее дерьмовое с течением времени - a   процесс непрерывного совершенствования

И, кстати, вам не нужно достигать совершенства, потому что иногда «

ответил 19 PM00000060000001231 2011, 18:27:12
-1

Я использую 5 баллов, чтобы узнать, хорош ли код или нет:

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

Для меня GetCustIDFromDB (var & ast, DB, char & ast; customer) лучше, чем getcid (var & ast; DB, char & ast; c) потому что он говорит мне, на что я смотрю. Но * DBLookupCIDByName (var & ast; DB, char & ast; customer) тоже работает.

Я часто проверяю, действительно ли я все еще использую все мои #includes ... Если я смогу удалить его, отлично. Иногда можно просмотреть ваши включенные заголовки и посмотреть, действительно ли необходимые функции находятся в том, что заголовок включает в себя через #include, но ... но я делал это редко, и это также экономит немного места, это может сделать процесс добавления новых функций намного сложнее.

ответил 19 PM00000060000001231 2011, 18:27:12
-1

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

http://xkcd.com/844/

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

ответил 19 PM00000060000001231 2011, 18:27:12

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132