Я видел несколько интересных цитат инженеров, но у меня не было репозитория, чтобы собрать их в кучу. Некоторые исчезли, забылись. Так что с этого момента в этом посте я буду копипастить все эти субъективно интересные цитаты и афоризмы до того дня, когда я перестану называть себя инженером. Ржу не могу.

Этот пост будет расти в природе.

Начнем с прекрасно написанного Дзен Питона. Я никогда не использовал Python профессионально, но this имеет смысл.

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

О программном обеспечении

«Лучшие программы — это те, которые написаны, когда программист должен работать над чем-то другим». — Мелинда Вариан

На уроке

Класс должен делать наименьшую возможную полезную вещь

У класса должна быть одна и только одна причина для изменения. - Роберт С. Мартин

Принцип единой ответственности: замена сложности на большее количество функций, классов и/или модулей. Разделение обязанностей.

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

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

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

Клиентов не следует заставлять зависеть от методов, которые они не используют.

Никто не любит раздутые классы! Чем больше ответственности у объекта, тем больше вероятность, что он захочет измениться

Клиентов не следует заставлять зависеть от методов, которые они не используют.

Речь идет о принципе разделения интерфейсов (ISP). Что в основном рекомендует нам создавать детализированные интерфейсы, ориентированные на клиента.

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

Это принцип инверсии зависимостей, который побуждает нас отделять требования использования от реализаций. Например, если у нас есть два пакета: Person и Shoe, и Person нужен Shoe, мы можем иметь интерфейс Footwear в Person, а Shoe нужно его реализовать; вместо того, чтобы иметь Person, зависит от Shoe или его абстракции. Таким образом, у нас может быть много типов Shoe, будь то BrownShoes, LeatherShoes и так далее.

Об исходных кодах

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

Начните с простого — усложняйте только тогда, когда необходимо

О работе и совместной работе

Работа в команде делает мечту реальностью

Точный. Правильно? Мы не можем работать в одиночку.

Программирование — это думать, а не печатать

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

Кто-то моложе душой должен заменить вас, и это должны быть вы. — Георгиевская церковь

Оставайся голоден, оставайся в дураках!?