Военные уставы Huawei по разработке Java и программированию, кто их нарушит, тот пойдет

Java
Военные уставы Huawei по разработке Java и программированию, кто их нарушит, тот пойдет

1. Введение

Этот стандарт предназначен для измерения дефектов самого кода, а также для измерения ценности разработчика. В глобальной ИТ-компании Huawei работает более 100 000 сотрудников. Будь то управление персоналом или управление кодом, это непростая задача. Без нормативных ограничений об этом страшно думать. Вот некоторые спецификации программирования, которые распространяются в Интернете. Давайте учиться вместе. Следующее содержание не включает в себя базовые спецификации грамматики (см. Ссылку), но фокусируется на некоторых навыках программирования, на том, как повысить надежность и удобство обслуживания программы и т. д. (PS: следующий контент не был официально проверен. Если читателю неудобно, пожалуйста, немедленно закройте эту страницу -_-||| )

2. Введение в воинские уставы

Военная инструкция 1: [Избегайте использования дьявольских чисел в программе, они должны обозначаться осмысленными константами. 】

Военный устав 2: [Уточните функцию метода, а метод выполняет только одну функцию. 】

Военный устав 3: [Параметры метода не могут превышать 5]

Военные правила 4: [Вызов метода должен стараться не возвращать значение null, вместо этого выдавать исключение или возвращать объект особого случая (объект SPECIAL CASE, SPECIAL CASE PATTERN); для методов, которые используют тип коллекции или массива в качестве возвращаемого значения, замените его пустой коллекцией или массивом нулевой длины. 】

Военный регламент 5: [При выполнении операций с базой данных или операций ввода-вывода вы должны убедиться, что ресурсы высвобождаются после использования, и вы должны убедиться, что операция высвобождения выполняется в конце. 】

Военный регламент 6: [Не перехватывать исключения (исключение ex) напрямую и обрабатывать исключения в подразделениях. 】

Военное правило 7: [Для условного суждения if «else if» (их может быть несколько else if ...), в конце должна быть включена ветвь else, чтобы избежать ошибок, вызванных пропуском ветвей; каждый оператор switch-case должен Гарантировано значение по умолчанию, чтобы избежать пропуска ветвей и возникновения ошибок. 】

Военные правила 8: [При переопределении метода equals() объекта метод hashCode() должен быть переопределен одновременно. 】

Военный регламент IX: [Запрещено создавать новые потоки в цикле и пытаться максимально использовать пул потоков. 】

Военное постановление 10: [Избегайте использования float и double при выполнении точных вычислений (например, при расчете валюты). Вычисления с плавающей запятой являются неточными и должны использовать BigDecimal или преобразовывать операции с плавающей запятой в операции с целыми числами. 】

3. Воинские уставы

Военная инструкция 1: [Избегайте использования дьявольских чисел в программе, они должны обозначаться осмысленными константами. ] Примечание. Является ли это числом дьявола, должно основываться на принципах легкости чтения и глобальной замены. Когда 0 и 1 являются перечисляемыми значениями физических величин в определенной профессиональной области, константы должны быть определены, а «дьявольские константы» вроде NUMBER_ZERO категорически запрещены.

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

Военное постановление 3: [Параметры метода не могут превышать 5] Описание: Слишком много параметров повлияет на чтение и использование кода. Чтобы уменьшить параметры, в первую очередь необходимо учитывать рациональность этих параметров, функция метода должна быть единственной. , и дизайн метода должен быть оптимизирован.Если параметры не могут быть уменьшены , вы можете инкапсулировать несколько параметров в класс (объект) и рассмотреть возможность добавления соответствующих поведений в новый класс (объект), чтобы больше соответствовать ООП .

Военные правила 4: [Вызов метода должен стараться не возвращать значение null, вместо этого выдавать исключение или возвращать объект особого случая (объект SPECIAL CASE, SPECIAL CASE PATTERN); для методов, которые используют тип коллекции или массива в качестве возвращаемого значения, замените его пустой коллекцией или массивом нулевой длины. ] Примечание. Возврат нулевого значения приведет к увеличению количества ненужных суждений об нулевом указателе, а пропуск суждений также приведет к серьезным ошибкам NullPointerException.

Военный регламент 5: [При выполнении операций с базой данных или операций ввода-вывода вы должны убедиться, что ресурсы высвобождаются после использования, и вы должны убедиться, что операция высвобождения выполняется в конце. ] Примечание: Объекты, которые необходимо закрыть для операций с базой данных, операций ввода-вывода и т. д., должны быть закрыты() в конце команды try-catch-finally.Если необходимо закрыть несколько объектов ввода-вывода, попробуйте закрыть () метод каждого объекта отдельно. , чтобы объект ввода-вывода не закрывался, а другие объекты ввода-вывода не закрывались.

Военный регламент 6: [Не ловить (исключение ex) напрямую для захвата исключений и обрабатывать исключения в подразделениях. ] Описание: Результатом catch (Exception ex) будет захват исключения RuntimeException.RuntimeException — это исключение времени выполнения, исключение, созданное самой программой без тщательного рассмотрения, и ошибка программы, такая как недопустимые параметры, массив вне -границы, деление на ноль и т.д., программа. Необходимо гарантировать, что исключение RuntimeException не может быть сгенерировано, а явный захват исключения RuntimeException не разрешен для облегчения обнаружения проблем программы во время тестирования.

Военное правило 7: [Для условного суждения if «else if» (может быть несколько elseif...), в конце должна быть включена ветвь else, чтобы избежать ошибок, вызванных пропуском ветвей; каждый оператор switch-case должен обеспечивать что существует по умолчанию, чтобы избежать пропусков ветвей и вызвать ошибки. 】

Военные правила 8: [При переопределении метода equals() объекта метод hashCode() должен быть переопределен одновременно. ] Описание: Методы equals и hashCode являются основой для эффективной работы объектов в хеш-контейнере. Правильное переопределение этих двух методов может обеспечить корректность поиска объектов в хэш-контейнере. повысить эффективность хеш-контейнера.

Военный регламент IX: [Запрещено создавать новые потоки в цикле и пытаться максимально использовать пул потоков. 】

Военное постановление 10: [Избегайте использования float и double при выполнении точных вычислений (например, при расчете валюты). Вычисления с плавающей запятой являются неточными и должны использовать BigDecimal или преобразовывать операции с плавающей запятой в операции с целыми числами. ] Примечание. Арифметика с плавающей запятой обеспечивает хорошее приближение в широком диапазоне значений, но не дает точных результатов. Двоичные числа с плавающей запятой очень непригодны для точных вычислений, потому что невозможно точно представить 0,1 — или любую другую отрицательную степень числа 10 — в виде двоичной дроби конечной длины.

Конкретные случаи см. в разделе: Проблемы, вызванные добавлением чисел с плавающей запятой: двоичное представление чисел с плавающей запятой
№ OSCHINA.net/Lee Jun 2005/…

4. Предложения и опыт по эффективности разработки и сотрудничеству

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

1. Небольшая подача:

Разделите большие задачи на несколько независимых небольших задач.После выполнения небольших задач, чтобы убедиться в отсутствии ошибок, их можно отправить и объединить в основную ветку или даже выпустить; частая отправка выгодна для контроля за ходом проекта, снижения рисков, сотрудничать с другими и проверять код; слияние можно отправлять несколько раз в день. Каждая маленькая задача имеет гранулярность 1-2 часа, которую можно выполнить, а самую большую можно выполнить за один день. При параллельном выполнении нескольких задач отдавайте приоритет задачам, которые могут быть реализованы в кратчайшие сроки.

2. Соглашение об именах:

Старайтесь избегать бессмысленных символов в качестве переменных, таких как a, b, t. Его можно улучшать постепенно, вы можете обратиться к:Дорого в стиле Google. Google code.com/SVN/trunk/ просто…

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

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

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

6. Избегайте больших функций, которые невозможно отобразить на одном экране.

7. Добавьте необходимые лаконичные комментарии:

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

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

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

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

Источник: blog.csdn.net/chenleixing/article/details/44173985.