Ответ 1

модульные тесты!!! если у вас есть модульные тесты, это, по-видимому, заставляет модульность, потому что, чтобы иметь возможность писать (хорошо) unit test, вам нужно иметь небольшие компоненты, которые легко тестировать, в противном случае эти модульные тесты никогда не будут записаны =)

Ответ 2

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

Используйте много белого пространства. Я помещаю все вокруг. Ничто не беспокоит меня больше, чем чтение кода, где какой-то "умный" программист упаковал все операторы в уравнение вместе без пробелов. С кем он, по его мнению, помогает? Компилятор?

Сохраняйте методы короткими. Если метод приближается к экрану, заполненному текстом, разбейте его на более мелкие методы.

Рефакторинг постоянно. Идет, не говоря, и держать ваши методы короткими является частью этого.

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

Ответ 3

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

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

Ответ 4

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

Ответ 5

Рефакторинг Triage

Недавно я участвовал в реорганизации довольно крупного проекта в относительно короткий период времени. Это требовало, чтобы мы выполняли сортировку рефакторинга. Цели, которые мы выбрали для обеспечения удобства и удобочитаемости, были следующими:

Удалить неиспользуемый код

Любой код, который не вызывается, не должен быть частью проекта.

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

Очистка комментариев

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

Но если код непонятен, вы, вероятно, должны его переписать.

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

Иерархии иерархии сглаживания

Используйте наследование для выражения отношений "есть".

Наследование полезно для полиморфизма (например, мы используем интерфейс для).

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

Следуйте последовательно действующим стандартам кодирования

Соглашения об именах

Структура файла

Избегайте "магических чисел", вместо этого используйте именованные константы

Ответ 6

Следование за мной было довольно простым:

• Изучите код, который вы считаете хорошим.
• Решите, какие аспекты кода, который вы изучаете, лучше, чем в вашем коде.
• Улучшите свой код, пока вы не удовлетворены тем, как он читает

Позже я прочитал книгу Рефакторинг: улучшение дизайна существующего кода (ссылка Amason). Он содержит конкретные советы do-s и dont-s для чистого и красивого кода с примерами Java и Python.

Ответ 7

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

Не обязательно в этом порядке приоритета.

Ответ 8

Чтение кода завершено. Это конечная ссылка на хорошие методы кодирования.

И опыт в сохранении вашего собственного грязного кода научит вас;)

Ответ 9

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

Ответ 10

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

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

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

Ответ 11

Чтобы перефразировать @jxie: Test-Driven Development требует и создает развязанный код.

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

Получение кода чистым и понятным. Много. Хорошо, что вы думаете об этом.

Ответ 12

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

Итак, чтобы ответить на ваш вопрос, я скажу, что вам нужно добавить TDD и Refactoring в свой инструментарий.

Ответ 13

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

Я также загрузил StyleCop. Это очень помогает!!!

Ответ 14

Я сильный сторонник обучения, выполняя мантру. Чем больше вы код, тем больше вы работаете над другим кодом разработчика, и чем больше вы читаете о развитии, тем лучше будет ваш код. В учебниках часто используются плохие методы и плохая форма, потому что они пытаются учить общие понятия. Реальный, код уровня производства - это то, над чем вы хотите работать, погружаться и дышать. Не каждая работа у вас будет иметь совершенный код, но чем больше вы видите и учитесь на этом коде, тем лучше разработчик вы будете. Будьте увлечены улучшением вашей работы и действуйте по этому поводу. Прочитайте код, который вы никогда раньше не видели, ознакомьтесь с статьями о безопасности, фреймворках и времени выполнения. Примените это знание, и скоро все это будет просачиваться в вашу работу.

Ответ 15

Поскольку тема refactoring появилась, я бы предложил использовать среду IDE, которая имеет хорошие инструменты рефакторинга, такие как Eclipse.

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

Поскольку вы сказали, что используете Java и С++, Eclipse может быть хорошим выбором, поскольку он поддерживает оба языка. (Через Инструменты разработки Java и C/С++ Development Tooling, соответственно.)

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

Ответ 16

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

Ответ 17

Прочитайте тонны кода и тонны книг. Например, посетите www.koders.com

Ответ 18

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

Ответ 19

Ответ работает с интерфейсами, которые обеспечивают уровень абстракции, который поможет вам позже.

Мой метод для разработки: 1. Прочтите требование 2. сделайте дизайн высокого уровня в UML 3. писать интерфейсы - это дизайн детали, для почти любого класса вы должны иметь интерфейс и использовать только ссылки интерфейса, поэтому класс без интерфейса является частным классом. 4. напишите unit test для каждого класса 5. Внедрить код.

Кроме того, не создавайте функцию размером более 20 строк. не создавайте класс более 200 строк.

модуль вашего кода