Написание чистого кода без знания запрограммированной темы

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


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

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

В итоге наша программа начинает работать. Мы снова смотрим на наш код, и это выглядит неприятным - одна большая процедура, полная «временных» решений, которые мы применяли, пытаясь заставить ее работать. У нас есть два варианта: переписать все с нуля, надеясь, что реорганизованный код будет работать, или оставить его как есть, так как он работает. В большинстве компаний используется второй подход, по крайней мере, до тех пор, пока не выпустятся дополнительные учебники для библиотеки.

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

6 голосов | спросил JoshThunar 8 Maypm17 2017, 20:33:04

3 ответа


15

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

Вместо этого напишите аналитические тесты , чтобы узнать, как работает lib, и когда вы достаточно уверены, что поняли, что происходит, тогда напишите свой производственный код. Это заставляет вас хранить ваши «временные» решения в тестах и ​​помогает вам сохранить производственный код в чистоте. Кроме того, попробуйте дать своим методам тестирования хорошие имена и некоторое описание того, что они тестируют, тогда ваши тесты станут недостающей документацией в виде примеров.

Кроме того, я думаю, что ответ @ DaveGauer содержит много хороших советов. Вы должны попытаться развить отношение к очистке вещей сразу, прежде чем они выйдут из-под контроля. Разделение вашего «экспериментального кода» из вашего производственного кода может помочь вам в этом.

ответил Doc Brown 9 Mayam17 2017, 00:39:29
20

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

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

  

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

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

Технический долг может быть ужасно деморализующим. Я знаю.

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

ответил DaveGauer 8 Maypm17 2017, 21:42:33
-3

Есть два аспекта, которые вы можете улучшить без каких-либо знаний о цели кода:

  • применить зависимость /инверсия управления (DI)
  • уменьшить дублирование кода.

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

Вам следует начать с DI, а затем добавить UnitTests в ваше приложение, которое поможет вам понять бизнес-правила в коде и избавит вас от нежелательного изменения логики при уменьшении дублирования кода.


  

DI не имеет значения сам по себе; - Фрэнк Хилема

Он имеет такое же «значение и само по себе», как и любой другой принцип OO, за которым мы следуем. То, что вы не видите его «значение», не означает, что его нет.


  

он полезен только тогда, когда вам это нужно. - Фрэнк Хилема

DI /IoC значительно улучшает (повторно) удобство использования.

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

Применение DI /IoC снижает сложность модульных тестов, поскольку позволяет заменять зависимости на test double .

Также для применения DI /IoC вы можете следовать формальному алгоритму. Единственное, что вам нужно знать, - это то, что из invokation оператора new создает зависимость скорее, чем объект Value / DTO .

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

  • Применить DI /IoC
  • напишите единичный тест, чтобы проверить /понять, что делает код.
  • применяйте другие рефакторинги, такие как метод извлечения , переименовать идентификаторы , извлечь класс и другие saveguardes модульными тестами, написанными на предыдущем шаге.
ответил Timothy Truckle 8 Maypm17 2017, 21:37:33

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132