Искусство написания не поддерживаемого кода: руководство к долголетию

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

Соглашения об именах: путь клингона

Когда дело доходит до именования переменных и методов, ясность — ваш враг. Используйте непонятные имена, которые противоречат логике и соглашениям. Например, вместо userFirstName используйте xqjklm или a_crszkvc30LastNameCol, если вы особенно креативны.

classDiagram class Variable { - xqjklm: string - a_crszkvc30LastNameCol: string } note "Избегайте описательных имён" Variable: - xqjklm Variable: - a_crszkvc30LastNameCol

Комментарии: отвлекающий манёвр

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

sequenceDiagram participant Developer participant Code participant Comment Developer->>Code: Write code Developer->>Comment: Generate meaningless comment Code->>Comment: Вводит в заблуждение будущих разработчиков

Модульные тесты: иллюзия покрытия

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

graph TD A("Write unit tests") --> B("No asserts") A --> C("Test only positive cases") A --> D("Never test business logic") A --> E("Mock useless exceptions") A --> B("Never do integration tests")

Циклические зависимости: паутина путаницы

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

graph TD A("Class A") --> B("Class B") B --> C("Class C") C --> A note "Циклические зависимости"

Копии кода: наследие копипасты

Копии кода увеличивают размер вашего программного обеспечения и приводят к непоследовательным изменениям и исправлениям ошибок. Эта путаница является золотом, когда речь идёт о написании не поддерживаемого кода. Чем больше копий, тем лучше.

classDiagram class CodeA { + method1() + method2() } class CodeB { + method1() + method2() } note "Копии кода" CodeA: + method1() CodeA: + method2() CodeB: + method1() CodeB: + method2()

Грязные обходные пути: искусство угадывания

При работе с нестабильным кодом, таким как тесты Selenium GUI, используйте обходные пути, которые иногда работают. Например, используйте Thread.sleep() с магическими числами, чтобы ваши тесты проходили время от времени. Это гарантирует, что некоторые тесты будут случайным образом давать сбой, держа будущих разработчиков в напряжении.

sequenceDiagram participant Developer participant Test participant Thread Developer->>Test: Write test with Thread.sleep() Test->>Thread: Sleep for magic number Thread->>Test: Иногда проходит, иногда нет

Глобальные переменные: хаос области видимости

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

classDiagram class GlobalVariables { - var1: int - var2: string } class FunctionA { + method1() } class FunctionB { + method2() } GlobalVariables --* FunctionA GlobalVariables --* FunctionB note "Глобальные переменные"

Обманчивые имена и венгерская нотация

Убедитесь, что каждый метод делает немного больше (или меньше), чем предполагает его имя. Например, метод с именем isValid(x) должен иметь побочный эффект преобразования x в двоичный формат и сохранения его в базе данных. Венгерская нотация — ещё один отличный инструмент; используйте её для создания имён переменных, которые сбивают с толку.

classDiagram class Method { + isValid(x) } note "Побочный эффект: преобразование x в двоичное и сохранение в базе данных" Method: + isValid(x)

Проверка на стороне клиента: скрытая ловушка

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

sequenceDiagram participant Client participant Server participant Attacker Client->>Server: Send request with client-side validation Server->>Client: Accept request without server-side validation Attacker->>Server: Exploit vulnerability

Try-catch-проглотить: тихий убийца

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

graph TD A("Code") --> B("Try") B --> C("Catch") C --> D("Проглатывание ошибки") note "Тихий убийца"

Заключение

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