Я составляю правила программирования для моей команды: каковы ваши? - PullRequest
44 голосов
/ 05 февраля 2009

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

Для этого я хотел создать список вещей, которые:

  • лучшая практика,
  • лучшая мысль,
  • лучший подход ...

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

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

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

Начну с первого.

СУХОЙ - Не повторяйся - В коде, комментариях или документации.

Ответы [ 65 ]

2 голосов
/ 05 февраля 2009

YAGNI

Вам это не нужно

Будьте критичны в том, что вы делаете, АКА думает!

2 голосов
/ 05 февраля 2009

Шаблоны дизайна ваших друзей

Обязательно храните копию книги Gang Of Four где-нибудь в качестве справки.

2 голосов
/ 06 февраля 2009

Количество всегда превосходит качество

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

1 голос
/ 05 февраля 2009

Это никогда не так просто, как вы думаете

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

1 голос
/ 05 февраля 2009

Это от Стива Макконнелла

«Каждая новая строка кода должна проходить через отладчик по одному шагу»

1 голос
/ 05 февраля 2009

Объявите все. Никогда не вкладывайте 15 функций в 1 переменную.

1 голос
/ 05 февраля 2009

Красный, Зеленый, Refactor!

TDD или Разработка на основе тестирования .

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

  2. Введите наименьшее количество кода, необходимое для прохождения теста.

  3. Рефакторинг по мере необходимости для таких вещей, как эффективность или ясность.

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

1 голос
/ 05 февраля 2009

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

1 голос
/ 06 февраля 2009

Раннее обнаружение ошибок:

  • Используйте статически типизированный язык, чтобы компилятор и статический анализ могли вам помочь.
  • Модульный тест (первый или последний)
  • Отзыв о коде
  • Непрерывная интеграция
  • Наконец, самое важное - непрерывное обучение.
1 голос
/ 05 февраля 2009

Для баз данных ...

Нормализуй как можно дальше. Затем нормализуйте снова.

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

...