Я считаю вы путаете понятия. Выработанные требования практически всегда имеют изъяны. Это болезнь нашей индустрии.
А мое проектирование по требованиям достаточно хорошо, вот только требования могут измениться в любой момент и к этому стоит быть готовым.
И помните — выпустить что-то отстойное на 100% лучше, чем не выпустить вообще ничего.
Это похоже на «Лучше сделать и жалеть, чем не сделать и жалеть». Оба выражения лишь утешения для людей, которые ошиблись. Не стоит обманывать себя и злоупотреблять ими.
Особые случаи не настолько особые, чтобы нарушать правила.
При этом практичность важнее безупречности.
дзен питона
Мне кажется зря обобщили с программистами. Программистам чаще приходится соблюдать правила, нежели нарушать их. Например синтаксис, стиль кода, паттерны, стандартные алгоритмы и тд. При этом стандартные решения предпочтительнее необычных, иначе коллеги вас не поймут.
Но иногда приходится кое-что выдумывать, порой самому так хочется, а порой мир от нас этого требует.
Цените легкость чтения кода выше, чем удобство его написания Даже во время первоначальной разработки программы код приходится читать гораздо чаще, чем писать. Выгода от подхода, повышающего удобство написания кода за счет легкости его чтения, обманчива.
А зачем их дублировать?
Создали base_settings, там все что дублируется записали или прописали настройки по умолчанию
Потом создали production_settings:
и debug_settings:
Если я не ошибаюсь такой же путь рекомендуют в Django Two Scope(Там про это точно есть отдельная глава)
Я не совсем уверен кто не прав. В Макконнеле(связность зацепление) эти понятия используются наоборот.
То есть минимальное сопряжение между модулями и максимальная связность внутри модуля.
А мое проектирование по требованиям достаточно хорошо, вот только требования могут измениться в любой момент и к этому стоит быть готовым.
Это похоже на «Лучше сделать и жалеть, чем не сделать и жалеть». Оба выражения лишь утешения для людей, которые ошиблись. Не стоит обманывать себя и злоупотреблять ими.
дзен питона
Мне кажется зря обобщили с программистами. Программистам чаще приходится соблюдать правила, нежели нарушать их. Например синтаксис, стиль кода, паттерны, стандартные алгоритмы и тд. При этом стандартные решения предпочтительнее необычных, иначе коллеги вас не поймут.
Но иногда приходится кое-что выдумывать, порой самому так хочется, а порой мир от нас этого требует.
Макконнелл
Еще можно вместо словаря использовать именованный кортеж, он, вроде, тоже чуть-чуть быстрее.
Из экстремальных оптимизаций — можно вынести все обращения к атрибутам из цикла, например:
stack_pop = stack.pop
но это уже не питоник решение
К тому же они работают чуть быстрее, так как убирают лишний вызов функции.
Написано, что Go помогает писать код с которым будет меньше проблем в будущем.
JetBrains меняет лицензирование, но я такой новости в списке не вижу.
wget google.com | /bin/sh в песочнице
или на приложения для androind || iOS?
Почему сразу не пойти по этому пути?
У меня последний PyCharm, такого больше не наблюдаю
может хватит мучиться?
переходите уже на Notepad++ или что-нибудь попроще, vim например(только без плагинов)
На другой машине у меня еще SSD есть, там быстрее работает
Но и без SSD не тормоит