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

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

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

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

Если этот день раньше даты вашего релиза, все становится еще сложнее.

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

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

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

Модульные тесты - помогают спать по ночам :-)

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

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

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

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

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

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

1. Модульный тест, модульный тест, модульный тест. У определенных модульных тестов есть привычка удерживать людей на задаче, а не бесцельно «блуждать» между объектами.
2. Определите и задокументируйте всю иерархическую информацию (пространства имен, пакеты, структуры папок и т. д.) До написания рабочего кода. Это помогает конкретизировать объектные отношения и выявить недостатки в предположениях, связанных с отношениями объектов.
3. Определите и задокументируйте все применимые интерфейсы до написания производственного кода. Если это выполняется ведущим специалистом или архитектором, эта практика может дополнительно помочь удержать больше разработчиков младшего уровня в работе.

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

Изменить в ответ на комментарий: Именно поэтому вам нужно делать это заранее. Все эти виды практики упрощают дальнейшее техническое обслуживание. Чем больше вы рискуете в начале проекта, тем больше вероятность того, что вы потратите все больше и больше времени на поддержку кода. Конечно, первоначальная стоимость выше, но строительство на прочном фундаменте окупается. Ваше препятствие: недостаток времени (например, необходимость поддерживать другие приложения) или решение вышестоящего уровня? Мне пришлось сражаться на обоих этих фронтах, чтобы принять такие практики, и это неприятная ситуация.

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

Как и все остальные, эти рекомендации не относятся к ООП:

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

Хаки обычно бывают запутанными и не интуитивно понятными, поэтому очень важно хорошо комментировать.

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

С уважением,

Докта

[вставьте здесь шаблонное предупреждение, не относящееся к ООП]

• Разделение проблем, модульные тесты и ощущение, что если что-то слишком сложное, это, вероятно, еще не совсем правильно концептуализировано.

• Создание эскизов UML: это прояснило и сэкономило столько усилий, потраченных впустую. Картинки классные, не правда ли? :)

• На самом деле думаю о том, что есть и что есть. Очень важно сделать это правильно с первого раза.

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

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

Я не могу вспомнить, чтобы когда-либо писал код и никогда не смотрел на него снова, я всегда делаю несколько проходов, чтобы проверить и отладить его, и даже в этих нескольких проходах такие практики, как рефакторинг, чтобы мой код оставался СУХИМ, документация (для некоторых степень), разделение забот и сплоченность, кажется, экономят время.

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

Само кодирование происходит довольно быстро и легко, отладка чуши, написанной кем-то, находясь «под давлением», занимает все время!

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

Научитесь «рефакторингу на ходу». В основном с точки зрения "метода извлечения". Когда вы начинаете писать блок последовательного кода, уделите несколько секунд тому, чтобы решить, может ли этот блок быть автономным в качестве метода многократного использования, и, если да, немедленно создайте этот метод. Я рекомендую его даже для одноразовых проектов (особенно, если вы можете вернуться позже и скомпилировать такие методы в свой личный API панели инструментов). Это не займет много времени, прежде чем вы сделаете это почти не задумываясь.

Надеюсь, вы это уже делаете, и я проповедую хору.

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

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

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

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

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

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

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

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