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

Ответ 1

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

Ответ 2

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

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

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

Ответ 3

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

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

Ответ 4

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

Ответ 5

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

Ответ 6

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

Ответ 7

нет открытого класса с изменяемыми переменными public (struct-like).

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

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

Ответ 8

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

Ответ 9

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

• Unit test, unit test, unit test. Определенные модульные тесты имеют привычку держать людей в задаче, а не "блуждать" бесцельно между объектами.
• Перед записью производственного кода определите и документируйте всю иерархическую информацию (пространства имен, пакеты, структуры папок и т.д.). Это помогает выявить объектные отношения и выявить недостатки в предположениях, связанных с отношениями объектов.
• Определить и документировать все применимые интерфейсы до написания производственного кода. Если это будет сделано руководителем или архитектором, эта практика может дополнительно помочь держать разработчиков на уровне младшего уровня в задаче.

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

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

Ответ 10

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

Ответ 11

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

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

• Используйте контроль источника и на самом деле записывайте комментарии коммита. Таким образом, у вас есть небольшая часть документации, если вы когда-нибудь задумывались о том, "что, черт возьми, я думал, когда писал это?"
• Напишите чистый код или документ. Чистый хорошо написанный код должен содержать небольшую документацию, поскольку это значение можно понять, прочитав его. Хаки много разные. Напишите, почему вы это сделали, что вы делаете и что хотите делать, если у вас есть время/знания/мотивация/... чтобы сделать это правильно.
• Unit Test. Да, это на третьем. Не потому, что это неважно, а потому, что это бесполезно, если у вас нет других двух, по крайней мере, на полпути. Написание единиц измерения - это еще один уровень документации, который должен выполнять код (среди прочих).
• Рефакторинг перед тем, как добавить что-то. Это может показаться типичным "но у нас нет времени для этого". Но, как и во многих из этих пунктов, обычно это экономит больше времени, чем стоит. По крайней мере, если у вас есть хоть какой-то опыт работы с ним.

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

Ответ 12

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

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

Обычно хаки, как правило, свернуты и не интуитивно понятны, поэтому необходимы некоторые хорошие комментарии.

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

Привет,

Docta​​p >

Ответ 13

[вставить здесь специальную оговорку о несобственном ООП]

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

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

• На самом деле думать о is-a и has-a's. Получение этого права в первый раз настолько важно.

Ответ 14

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

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

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

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

Само кодирование довольно быстро и просто, отлаживая хард, который кто-то писал, когда они были "под давлением", - это то, что занимает все время!

Ответ 15

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

Ответ 16

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

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

Ответ 17

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

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

Ответ 18

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

Ответ 19

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

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