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

Question

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

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

Answer 1

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

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

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

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

Answer 2

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

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

Answer 3

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

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

Answer 4

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

Answer 5

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

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

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

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

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

Answer 6

[вставить шаблон, не относящийся к ООП, здесь!]

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

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

• Действительно думать об «есть» и «есть». Понимание этого с первого раза очень важно.

Answer 7

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

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

Взломы обычно бывают запутанными и не интуитивными, поэтому необходимо хорошее комментирование.

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

С уважением,

Docta

Answer 8

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

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

Answer 9

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