Обратите внимание на общедоступный номер: технический круг xy
Эта статья в основном суммирует размышления о некоторых проблемах, возникающих при обычном кодировании. Во многих случаях дизайн кода трудно сделать идеальным, и мы часто сталкиваемся с вопросами с несколькими вариантами ответов.Как сбалансировать несколько вариантов — непростая задача.
производительность и читабельность
«Производительность» — это момент, на который обращает внимание хороший программист. При написании кода мы часто надеемся, что сможем написать программы, отвечающие нашим потребностям, с оптимальной производительностью. Но иногда слепо высокая производительность может снизить читабельность кода.
Например, когда поле базы данных разработано, есть поле «год». Мы все знаем, что год обычно состоит из 4 цифр, поэтому мы используемSMALLINTбыть типом этого поля. Сопоставление с Java с использованием ORMshortтипа тоже.
Студенты, знакомые с языком Java, должны знать, что когда язык Java разрабатывает числовые операции, он неявно преобразует их вintтип, покаintТипы должны быть явно приведены кshort, поэтому их много(short)Принудительное вращение следующим образом:
short year = repository.getYearById(id);
short nextYear = (short)(year + 1);
Такое принудительное преобразование на самом деле не имеет большого смысла, хотя и снижает читабельность, но не дает большого прироста производительности.
Поэтому, когда мы пишем программы, иногда нам нужноВ погоне за производительностью и читабельностью кодаостаток средств,Сделайте код максимально читабельным с приемлемой производительностью.
Общий и переработанный
Если одна и та же логика используется в нескольких местах, мы можем рассмотреть возможность ее извлечения и инкапсуляции в частный метод или даже в класс. Мы называем этот извлеченный код «универсальным», также известным как «многоразовый».
Мы все более или менее знаем некоторые шаблоны проектирования.На самом деле проблема, которую решают многие шаблоны проектирования, заключается в «повторном использовании» кода. Возможность повторного использования кода важна, но иногда это может привести к увеличению сложности. Особенно после извлечения некоторых дополнительных классов в вашем коде будет намного больше xxBuilder, xxFactory, xxProxy и им подобных. Более того, это непосредственно xxUtils, xxHelper и другие классы с неизвестными обязанностями, и в нем много беспорядочных методов.
Еще одна проблема, связанная с общедоступными методами и классами, заключается в том, что если два бизнеса используют этот фрагмент кода одновременно, а требования меняются позже, логика одного бизнеса должна претерпеть небольшие изменения в этом коде, то, если вы перейдете к разделу Изменение общедоступный код повлияет на другой бизнес.
Итак, каков компромисс между «общностью» и «сложностью»? Ответ: «простой дизайн», а не «чрезмерный дизайн».
При написании кода старайтесь, чтобы код был максимально простым, не извлекайте много методов и классов для повторного использования, а выполняйте необходимый рефакторинг для удобства чтения. Извлекайте общедоступные методы или классы только при необходимости.Например, несколько предприятий используют одну и ту же сложную логику, и существует высокая вероятность того, что никаких изменений не произойдет.
Код такой, как и интерфейс. Не перепроектируйте только потому, что вы думаете, что «может быть использовано в будущем», еще не поздно провести рефакторинг, когда эта функция будет достигнута.
Что касается того, как это реализовать? Я не думаю, что есть четкое указание: вам нужно писать больше кода, больше думать и больше разбираться в бизнесе, чтобы вы могли четко судить о необходимости извлечения.
Сколько тестов написать?
Автор обычно следует процессу TDD в проекте, поэтому тестов все же написано больше. В нашем проекте мы стараемся сначала писать юнит-тесты, а потом только нужные happy-paths для интеграционных тестов, некоторые простые классы могут даже не писать интеграционные тесты, например слой контроллера. Сначала напишите тест, затем напишите реализацию, а тест запускает код реализации.
В книге "Рефакторинг" упоминается, что написание тестов не должно быть фиксированным и жестким процессом разработки. Когда мы пишем тесты, мы должны писать только необходимые тесты, и писать тесты только для тех кодов, в которых у нас нет полной уверенности. . . .
Но это кажется немного по отношению к точке зрения «Test-First» TDD. Если мы сначала пишем тесты, как мы можем знать, как долго выглядит наш код реализации, и как мы можем знать, если у нас есть полная уверенность?
На самом деле, при реальной разработке проекта очень сложно протестировать 100% охват. Особенно в случае «белого списка» мы часто можем только проверить, подходят ли параметры из белого списка, но невозможно измерить все параметры за пределами белого списка, которые не подходят. Таким образом, вы можете выбрать только один или два для тестирования.
Иногда может быть сложно сначала написать тесты. Например, мы можем зависеть от других классов при реализации, поэтому мы можем имитировать этот класс при тестировании, но при написании кода реализации мы обнаружим, что этот класс не подходит, и вместо этого нам может понадобиться вызвать другой класс. В настоящее время кажется немного хлопотным вернуться и изменить тест. Так что иногда это не обязательно полный тест-сначала, а цикл тест-реализация-рефакторинг.
Суммировать
То, что я упомянул выше, является размышлениями автора о некоторых проблемах, возникающих в повседневной разработке. На самом деле, иногда это нужно рассматривать в соответствии с реальной ситуацией.При написании кода нужно учитывать множество вещей, таких как читабельность, ремонтопригодность, масштабируемость, производительность, тестирование и так далее.
Программирование — это проект, и для того, чтобы сделать этот проект хорошо, нам нужно освоить больше знаний. Узнайте больше о том, как другие люди пишут код, каковы их плюсы и минусы, больше читайте, обобщайте больше, и «опыт» придет сам собой.
Рекомендуемые книги:
- Реконструкция
- «Чистый код»
- «Эффективная Java»
- "Шаблоны проектирования"
- Внедрение дизайна, управляемого доменом
Внимательно пишите статьи и делитесь ими с душой.
Персональный сайт:yasinshaw.com
Общедоступный номер: технический круг xy