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

Ответ 1

Всегда оставляйте код немного лучше, чем когда вы его нашли.

Ответ 2

Код не существует до тех пор, пока не будет введен в систему управления версиями .

Ответ 3

Не бойтесь признать "я не знаю" и спросить.

10 минут просят кого-то спасти день, вытаскивая ваши волосы!

Ответ 4

Не изобретать велосипед

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

Ответ 5

KISS - Держите его простым, глупым.
Выберите простейшее решение, которое работает.
Не делайте вещи (слишком) сложными, прежде чем они должны быть.
Просто потому, что все остальные используют сложную структуру для решения своей проблемы, не означает, что вам нужно.

Ответ 6

Полезная важна.

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

Ответ 7

Кто-то другой не исправит его.

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

Ответ 8

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

"Мы должны забыть о небольшой эффективности, скажем, около 97% времени: преждевременная оптимизация - это корень всего зла".
    - Дональд Кнут

Ответ 9

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

Ответ 10

Не собирайте требования - Dig for them

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

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

Ответ 11

Следуйте принципам SOLID:

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

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

Принцип открытого закрывания (OCP)

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

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

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

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

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

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

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

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

Ответ 12

Я думаю, что почти все, что указано в разделе "The Zen of Python", применяется для каждого списка "Rules of Mindset". Начните с "python -c" импортируйте это ":

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

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

Ответ 13

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

Ответ 14

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

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

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

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

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

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

Ответ 15

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

Ответ 16

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

Ответ 17

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

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

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

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

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

Ответ 18

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

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

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

Ответ 19

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

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

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

Ответ 20

Вы можете скопировать и вставить, чтобы заставить его работать, но вы не можете его оставить.

Дублированный код - это промежуточный шаг, а не конечный продукт.

Ответ 21

Это как то, что вы говорите, так и то, как вы это говорите

Нет смысла иметь отличные идеи, если вы не сообщаете их эффективно.

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

Ответ 22

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

От: код ужас

Ответ 23

Опубликовать раннее, часто публиковать

Ответ 24

Построить брелок для обеда

Ответ 25

Сначала постройте его правильно. Сделайте его вторым.

Ответ 26

Часто проводить обзоры кода

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

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

Ответ 27

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

Ответ 28

Конвенция по конфигурации

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

Ответ 29

Участвуйте в разработке с открытым исходным кодом

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

Ответ 30

Понимать инструменты, которые вы используете

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