Я составляю правила программирования для моей команды: каковы ваши?

Question

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

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

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

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

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

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

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

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

Answer 1

Следуйте ТВЕРДЫМ принципам :

Принцип единой ответственности (SRP)

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

Принцип открытого доступа (OCP)

Программные объекты (классы, модули, функции и т. Д.) должен быть открыт для расширения, но закрыт для модификация.

Принцип замещения Лискова (LSP)

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

Принцип разделения интерфейса (ISP)

Клиенты не должны зависеть от интерфейсов что они не используют.

Принцип обращения зависимостей (DIP)

A. Модули высокого уровня не должны зависеть от низкого модули уровня. Оба должны зависеть от абстракций.

B. Абстракции не должны зависеть от деталей. подробности должно зависеть от абстракций.

Answer 2

Лучшая практика: Используйте свой мозг
Не следуйте какой-либо тенденции / принципу / образцу, не думая об этом

Answer 3

Я думаю, что почти все, что перечислено в разделе «Дзен Python», применимо для каждого списка «Правила программирования мышления». Начните с 'python -c' import this '':

Дзен Питона, Тим Питерс

• Красиво лучше, чем безобразно.
• Явное лучше, чем неявное.
• Простое лучше, чем сложное.
• Комплекс лучше, чем сложный.
• Квартира лучше вложенной.
• Разреженный лучше, чем плотный.
• Читаемость имеет значение.
• Особых случаев недостаточно, чтобы нарушать правила.
• Хотя практичность побеждает чистоту.
• Ошибки никогда не должны проходить молча.
• Если не указано явное молчание.
• Перед лицом двусмысленности откажитесь от искушения угадать.
• Должен быть один - и желательно только один - очевидный способ сделать это.
• Хотя вначале этот путь может быть неочевиден, если вы не голландец.
• Теперь лучше, чем никогда.
• Хотя никогда не бывает лучше, чем прямо сейчас.
• Если реализацию сложно объяснить, это плохая идея.
• Если реализацию легко объяснить, это может быть хорошей идеей.
• Пространства имен - одна из замечательных идей - давайте сделаем больше таких!

Answer 4

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

Answer 5

Test Driven Development (TDD) заставляет кодеров лучше спать ночью

Просто чтобы прояснить: некоторые люди думают, что TDD - это просто некомпетентный способ кодера хромать от А до В, не затрачивая слишком много времени, и что если вы знаете, что делаете, это означает, что вам не нужно (модульные) методики тестирования. Это полностью упускает из виду разработку через тестирование. TDD - это три (обновление: очевидно, четыре):

1. Рефакторинг магии . Наличие полного набора тестов означает, что вы можете совершать безумные трюки с рефакторингом, манипулируя всей структурой вашего приложения, не пропуская даже одного из двухсот сумасшедших тонких побочных эффектов, которые возникают в результате. Даже лучшие программисты неохотно реорганизуют свои базовые классы и интерфейсы без хорошего (модульного) тестирования, потому что почти невозможно отследить все маленькие «волновые эффекты», которые они вызывают без них.

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

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

4. Заставляет вас писать лучший код . Поскольку TDD вынуждает весь код быть тестируемым (вы не пишете код до его тестирования), он требует, чтобы вы писали более разъединенный код, чтобы вы могли тестировать компоненты изолированно. Так что TDD заставляет вас писать лучший код. ( Спасибо, Эско )

Answer 6

Меньше кода лучше, чем больше, если он имеет больше смысла, чем много кода.

Answer 7

Привычки ленивого кодера

В первый раз, когда вас просят что-то сделать, сделайте это (справа).

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

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

(не следует воспринимать слишком серьезно)

Answer 8

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

Answer 9

Будьте катализатором перемен

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

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

Answer 10

Не паникуйте при отладке

Сделай глубокий вдох и ДУМАЙ! о том, что может быть причиной ошибки.

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