Каким методам кодирования ООП следует всегда уделять время?

Question

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

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

Answer 1

Не ООП, но практика, которая помогает как в краткосрочной, так и в долгосрочной перспективе, является СУХОЙ, не повторяйте себя. Не используйте копирование / вставку наследования.

Answer 2

Не ООП практика, а здравый смысл; -).

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

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

Answer 3

Использовать контроль источника .

Независимо от того, сколько времени потребуется на настройку (секунды ...), это всегда сделает вашу жизнь проще! (все же это не связано с ООП).

Answer 4

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

Answer 5

Юнит-тесты - помогает вам спать по ночам: -)

Answer 6

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

Answer 7

нет открытого класса с изменяемыми общедоступными переменными (по типу структуры).

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

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

Answer 8

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

Answer 9

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

Мой личный рейтинг такой:

1. Используйте контроль исходного кода и фактически пишите комментарии коммита. Таким образом, у вас есть немного документации, если вы когда-нибудь задумывались: «Какого черта я думал, когда писал это?»
2. Введите чистый код или документ. Чистый хорошо написанный код должен требовать небольшого количества документации, так как его значение можно понять, прочитав его. Хаки очень разные. Напишите, почему вы это сделали, что вы делаете и что вы хотели бы делать, если у вас было время / знания / мотивация / ... чтобы сделать это правильно
3. Модульный тест. Да, это номер три. Не потому что это неважно, а потому что это бесполезно, если у вас нет двух других, по крайней мере, наполовину завершенных. Написание модульных тестов - это еще один уровень документации, которым должен заниматься ваш код (среди прочего).
4. Рефакторинг, прежде чем что-то добавить. Это может звучать как типичный пункт «но у нас нет времени на это». Но, как и во многих из этих пунктов, это обычно экономит больше времени, чем стоит. По крайней мере, если у вас есть хоть какой-то опыт.

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

Answer 10

Применение единого принципала ответственности. Эффективное применение этого принципа порождает много положительных внешних эффектов.