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

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

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

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

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

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

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

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

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

Ответы [ 65 ]

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

Сделайте шаг назад и посмотрите на всю картину

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

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

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

Думайте о своей работе как о ремесле, а не как о долге.

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

Подумайте! О вашей работе

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

через Прагматичный программист

3 голосов
/ 08 февраля 2009

Никогда не говори бизнесу все!

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

3 голосов
/ 05 февраля 2009
  1. Аудитория - все, что мы создаем, предназначено для аудитории, будет использоваться как конечными пользователями, так и другими программистами. Убедитесь, что он может использоваться обоими.

  2. Простота - если вы реализуете что-то сложное и запутанное, вы, вероятно, упускаете более эффективное и простое решение.

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

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

План первый, второй дизайн, третий код, тест всегда.

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

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

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

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

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

Это не должно быть искусством, но это должно быть вовремя

Старое правило журналистики, которое мне пришлось выучить трудным путем.

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