В этой статье описаны десять основных заповедей, которые необходимо знать Java-разработчикам. Поделитесь им со всеми для справки, подробности следующие:
Как Java-разработчик, я постоянно думаю об улучшении качества и удобства сопровождения собственного кода. Я увидел эту статью в Интернете и использовал ее, чтобы подбодрить себя.
Существует множество стандартов и лучших практик для разработчиков Java. В этой статье перечислены десять основных правил, которым должен следовать каждый разработчик; если есть правила, которым можно следовать, но не следовать, это приведет к очень трагическому финалу.
1. Добавьте комментарии к вашему коду
Все это знают, но почему-то забывают следовать этому. Посчитайте, сколько раз вы «забыли» добавить аннотацию? Это правда: комментарии не вносят существенного вклада в функциональность программы. Однако вам нужно возвращаться к коду, который вы написали две недели назад, снова и снова, может быть, на всю жизнь, и вы не должны помнить, почему код ведет себя именно так. Если эти коды ваши, вам относительно повезло. Потому что это может вернуть воспоминания. Но, к сожалению, в большинстве случаев код принадлежит кому-то другому, и есть большая вероятность, что он покинул компанию.
2. Не усложняйте вещи
Я делал это раньше, и я уверен, что все это делали. Разработчики часто находят решение простой проблемы. Мы представили EJB для приложения всего с пятью пользователями. Мы используем фреймворк для приложения, которому он даже не нужен. Мы добавили в приложение файлы свойств, объектно-ориентированные решения и потоки, но они ему вообще не понадобились. Почему мы это делаем? Некоторые из нас делают это потому, что не знают, как это сделать лучше, а некоторые из нас делают это, чтобы освоить новые знания и сделать приложение более интересным для себя.
3． Помните: «лучше меньше, да лучше» не всегда хорошо.
Эффективность кода — это здорово, но во многих случаях написание меньшего количества строк кода не делает этот код более эффективным. Пожалуйста, позвольте мне показать вам простой пример.
if(newStatusCode.equals("SD") && (sellOffDate == null || TodayDate.compareTo(sellOffDate)<0 || (lastUsedDate != null && TodayDate.compareTo(lastUsedDate)>0)) || (newStatusCode.equals ("OBS") && (OBSDate == null || TodayDate.compareTo(OBSDate)<0))){ newStatusCode = "NYP";} Я хочу спросить: легко ли определить, что хочет сделать условие if приведенного выше кода? Теперь предположим, что тот, кто написал этот код, не выполнил правило номер один — добавляйте комментарии в свой код.
Не проще ли было бы разделить это условие на два отдельных оператора if? Теперь рассмотрим следующий исправленный код:
if(newStatusCode.equals("SD") && (sellOffDate == null || TodayDate.compareTo(sellOffDate)<0 || (lastUsedDate != null && TodayDate.compareTo(lastUsedDate)>0))){ newStatusCode = "NYP ";}иначе if(newStatusCode.equals("OBS") && (OBSDate == null || TodayDate.compareTo(OBSDate)<0)){ newStatusCode = "NYP";}Не лучше ли было бы читать? Да, мы повторили условие утверждения. Да, у нас есть лишний «ЕСЛИ» и две дополнительные пары круглых скобок. Но код лучше читается и понятен.
4. Пожалуйста, без жесткого кода
Разработчики часто сознательно забывают или игнорируют это правило, потому что мы, как обычно, спешим. Если мы будем следовать этому правилу, мы можем отстать от графика. Возможно, мы не сможем положить конец нашему нынешнему состоянию. Но сколько времени нам понадобится, чтобы написать дополнительную строку кода, определяющую статические константы?
Вот пример.
общественный класс A {общественная статическая окончательная строка S_CONSTANT_ABC = "ABC"; общественный логический методA (String sParam1) { if (AS_CONSTANT_ABC.equalsIgnoreCase (sParam1)) { return true } return false;Теперь каждый раз, когда нам нужно сравнить строку «ABC» с какой-либо переменной, нам нужно только ссылаться на S_CONSTANT_ABC вместо того, чтобы запоминать фактический код. Преимущество этого метода также заключается в том, что его проще изменять в одном месте, а не искать его во всем коде.
5. Не изобретайте свои собственные рамки
Были запущены тысячи фреймворков, и большинство из них имеют открытый исходный код. Многие из этих фреймворков являются отличными решениями и используются в тысячах приложений. Вам нужно идти в ногу с этими новыми рамками, по крайней мере поверхностно. Среди этих превосходных и широко используемых фреймворков одним из лучших и наиболее ярких примеров является Struts. Из всех фреймворков, которые вы только можете себе представить, этот веб-фреймворк с открытым исходным кодом является идеальным кандидатом для веб-приложений. Но вы должны помнить второе правило – не усложняйте. Если вы разрабатываете приложение всего из трёх страниц — не используйте Struts. В таком приложении нечем «контролировать» запросы.
6. Не печатайте строки и не добавляйте строки
Я знаю, что в целях отладки разработчики любят добавлять System.out.println везде, где считают нужным, и говорим себе, что удалим этот код позже. Но мы часто забываем удалить эти строки кода или просто не хотим их удалять. Мы используем System.out.println для тестирования. Почему после завершения теста мы все еще можем получить к ним доступ? Мы можем удалить строку кода, которая нам действительно нужна, просто потому, что вы недооценили ущерб, причиненный System.out.println. Рассмотрим следующий код:
общественный класс BadCode {общественный статический недействительный расчетWithPrint () {двойной someValue = 0D; для (int я = 0; я <10000; я ++) { System.out.println (someValue = someValue + i } } Public статический недействительный расчет с OutPrint (); ){ double someValue = 0D; for (int i = 0; i < 10000; i++) { someValue = someValue + я; } } public static void main(String [] n) { BadCode.calculationWithPrint(); BadCode.calculationWithOutPrint();В таблице ниже вы можете видеть, что выполнение метода AssessmentWithOutPrint() заняло 0,001204 секунды. Для сравнения, запуск метода CalculationWithPrint() занял целых 10,52 секунды.
(Если вы не знаете, как получить такую таблицу, прочтите мою статью «Профилирование Java с помощью WSAD» Профилирование Java с помощью WSAD)
Лучший способ избежать такой траты ЦП — ввести метод-оболочку, как показано ниже.
общественный класс BadCode {общественный статический окончательный интервал DEBUG_MODE = 1; общественный статический окончательный интервал PRODUCTION_MODE = 2; общественный статический недействительный расчет (int logMode) {двойной someValue = 0D; for (int я = 0; я <10000; я ++) {someValue = someValue + я myPrintMethod (logMode, someValue}} Public static void); myPrintMethod(int logMode, двойное значение) { if (logMode > BadCode.DEBUG_MODE) { return } System.out.println(value); } public static void main(String [] n) { BadCode.calculationWithPrint(BadCode.PRODUCTION_MODE) ; }}На рисунке ниже вы увидите, что выполнение метода, использующего StringBuffer, заняло всего 0,01 секунды, а выполнение метода, использующего сложение строк, заняло 0,08 секунды. Выбор очевиден.
7． Следуйте графическому интерфейсу
Как бы нелепо это ни звучало, я повторяю это снова и снова: графический интерфейс так же важен для бизнес-клиентов, как функциональность и производительность. Графический интерфейс является важной частью успешной системы. (Однако ИТ-журналы часто склонны игнорировать важность графических интерфейсов. Многие организации экономят деньги, не нанимая дизайнеров, имеющих большой опыт разработки «удобных» графических интерфейсов. Разработчикам Java приходится полагаться на собственные знания HTML, но их знания в этой области весьма ограничены. Я видел много подобных приложений: они «дружественны к компьютеру», а не «удобны для пользователя». Я редко вижу разработчика, который обладает опытом как в разработке программного обеспечения, так и в разработке графического интерфейса. Если вы неудачливый разработчик, которому поручено разработать пользовательский интерфейс, вам следует следовать этим трем принципам:
1. Не изобретайте велосипед. Найдите существующие системы со схожими требованиями к пользовательскому интерфейсу.
2. Сначала создайте прототип. Это очень важный шаг. Клиентам нравится видеть, что они получат. Это также здорово для вас, потому что вы получаете их отзывы, прежде чем приложите все усилия и создадите пользовательский интерфейс, который их разозлит.
3. Наденьте шляпу пользователя. Другими словами, изучите требования приложения с точки зрения пользователя. Например, следует ли разбивать страницу сводки на страницы. Как разработчик программного обеспечения, вы склонны игнорировать нумерацию страниц в системе, поскольку она усложняет разработку. Однако это не лучшее решение с точки зрения пользователя, поскольку суммированные данные будут содержать сотни или тысячи строк.
8. Всегда готовьте документированные требования
Любое бизнес-требование должно быть документировано. Это может быть правдой в некоторых сказках, но в реальном мире это невозможно. Независимо от того, насколько сжаты сроки вашей разработки или скоро ли наступит дата поставки, вы всегда должны знать, что каждое бизнес-требование документировано.
9. Модульное тестирование, модульное тестирование, модульное тестирование
Я не буду вдаваться в подробности того, как лучше всего провести модульное тестирование вашего кода. Я хочу сказать, что необходимо провести модульное тестирование. Это самое основное правило программирования. Это самый важный из всех вышеперечисленных законов, который нельзя игнорировать. Лучше всего, если у вас есть коллеги, которые смогут создавать и тестировать модульные тесты для вашего кода. Но если за вас это никто не делает, то вам придется сделать это самому. При создании плана модульного тестирования следуйте следующим правилам:
1. Пишите модульные тесты перед написанием кода.
2. Пишите комментарии в юнит-тестах.
3. Протестируйте все общедоступные методы, выполняющие «интересные» функции («интересные» означают методы, которые не являются сеттерами или геттерами, если только они не выполняют методы set и get особым образом).
10． Помните – качество, а не количество.
Не задерживайтесь в офисе допоздна (когда в этом нет необходимости). Я понимаю, что иногда проблемы с продуктом, сжатые сроки и непредвиденные события могут помешать нам уйти с работы вовремя. Однако в обычных обстоятельствах руководитель не будет ценить и вознаграждать сотрудников, уходящих с работы слишком поздно. Он ценит их из-за качества производимой ими продукции. Если вы будете следовать правилам, которые я дал выше, вы обнаружите, что в вашем коде меньше ошибок и его легче поддерживать. И это самая важная часть вашей работы.
Подвести итог
В этой статье я привожу десять важных правил для Java-разработчиков. Важно не только знать эти правила, но и следовать им в процессе кодирования. Надеемся, эти правила помогут нам стать лучшими программистами и профессионалами.
Я надеюсь, что эта статья будет полезна всем, кто занимается программированием на Java.