Проектирование программного комплекса представляет собой написание технического задания на разработку и создание модели документооборота.
Срок выполнения этапа: от полутора недель (в зависимости от задачи автоматизации).
Этап 2. Разработка программного комплекса.
15 правил написания качественного кода
Есть мириады способов написать плохой код. К счастью, чтобы подняться до уровня качественного кода, достаточно следовать 15 правилам. Их соблюдение не сделает из вас мастера, но позволит убедительно имитировать его.
Правило 1. Следуйте стандартам оформления кода.
У каждого языка программирования есть свой стандарт оформления кода, который говорит, как надо делать отступы, где ставить пробелы и скобки, как называть объекты, как комментировать код и т.д.
7 частых ошибок начинающих сценаристов
Например, в этом куске кода в соответствии со стандартом есть 12 ошибок:
for(i=0 ;i
Изучайте стандарт внимательно, учите основы наизусть, следуйте правилам как заповедям, и ваши программы станут лучше, чем большинство, написанные выпускниками вузов.
Многие организации подстраивают стандарты под свои специфические нужды. Например, Google разработал стандарты для более чем 12 языков программирования. Они хорошо продуманы, так что изучите их, если вам нужна помощь в программировании под Google. Стандарты даже включают в себя настройки редактора, которые помогут вам соблюдать стиль, и специальные инструменты, верифицирующие ваш код на соответствию этому стилю. Используйте их.
Правило 2. Давайте наглядные имена.
Ограниченные медленными, неуклюжими телетайпами, программисты в древности использовали контракты для имён переменных и процедур, чтобы сэкономить время, стуки по клавишам, чернила и бумагу. Эта культура присутствует в некоторых сообществах ради сохранения обратной совместимости. Возьмите, например, ломающую язык функцию C wcscspn (wide character string complement span). Но такой подход неприменим в современном коде.
Используйте длинные наглядные имена наподобие complementSpanLength, чтобы помочь себе и коллегам понять свой код в будущем. Исключения составляют несколько важных переменных, используемых в теле метода, наподобие итераторов циклов, параметров, временных значений или результатов исполнения.
Гораздо важнее, чтобы вы долго и хорошо думали перед тем, как что-то назвать. Является ли имя точным? Имели ли вы в виду highestPrice или bestPrice? Достаточно ли специфично имя, дабы избежать его использования в других контекстах для схожих по смыслу объектов? Не лучше ли назвать метод getBestPrice заместо getBest? Подходит ли оно лучше других схожих имён?
Если у вас есть метод ReadEventLog, вам не стоит называть другой NetErrorLogRead. Если вы называете функцию, описывает ли её название возвращаемое значение?
💩10 обязательных правил для начинающего программиста или как писать код, за который не стыдно?
В заключение, несколько простых правил именования. Имена классов и типов должны быть существительными. Название метода должно содержать глагол. Если метод определяет, является ли какая-то информация об объекте истинной или ложной, его имя должно начинаться с «is». Методы, которые возвращают свойства объектов, должны начинаться с «get», а устанавливающие значения свойств — «set».
Правило 3. Комментируйте и документируйте.
Начинайте каждый метод и процедуру с описания в комментарии того, что данный метод или процедура делает, параметров, возвращаемого значения и возможных ошибок и исключений. Опишите в комментариях роль каждого файла и класса, содержимое каждого поля класса и основные шаги сложного кода. Пишите комментарии по мере разработки кода. Если вы полагаете, что напишете их потом, то обманываете самого себя.
Вдобавок, убедитесь, что для вашего приложения или библиотеки есть руководство, объясняющее, что ваш код делает, определяющий его зависимости и предоставляющий инструкции для сборки, тестирования, установки и использования. Документ должен быть коротким и удобным; просто README-файла часто достаточно.
Правило 4. Не повторяйтесь.
Никогда не копируйте и не вставляйте код. Вместо этого выделите общую часть в метод или класс (или макрос, если нужно), и используйте его с соответствующими параметрами. Избегайте использования похожих данных и кусков кода. Также используйте следующие техники:
- Создание справочников API из комментариев, используя Javadoc и Doxygen.
- Автоматическая генерация Unit-тестов на основе аннотаций или соглашений об именовании.
- Генерация PDF и HTML из одного размеченного источника.
- Получение структуры классов из базы данных (или наоборот).
Правило 5. Проверяйте на ошибки и реагируйте на них.
Методы могут возвращать признаки ошибки или генерировать исключения. Обрабатывайте их. Не полагайтесь на то, что диск никогда не заполнится, ваш конфигурационный файл всегда будет на месте, ваше приложение будет запущено со всеми нужными правами, запросы на выделение памяти всегда будут успешно исполнены, или что соединение никогда не оборвётся. Да, хорошую обработку ошибок тяжело написать, и она делает код длиннее и труднее для чтения. Но игнорирование ошибок просто заметает проблему под ковёр, где ничего не подозревающий пользователь однажды её обнаружит.
Правило 6. Разделяйте код на короткие, обособленные части.
Каждый метод, функция или блок кода должн умещаться в обычном экранном окне (25-50 строк). Если получилось длиннее, разделите на более короткие куски. Даже внутри метода разделяйте длинный код на блоки, суть которых вы можете описать в комментарии в начале каждого блока.
Более того, каждый класс, модуль, файл или процесс должен выполнять определённый род задач. Если часть кода выполняет совершенно разнородные задачи, то разделите его соответственно.
Правило 7. Используйте API фреймворков и сторонние библиотеки.
Изучите, какие функции доступны с помощью API вашего фреймворка. а также что могут делать развитые сторонние библиотеки. Если библиотеки поддерживаются вашим системным менеджером пакетов, то они скорее всего окажутся хорошим выбором. Используйте код, удерживающий от желания изобретать колесо (при том бесполезной квадратной формы).
Правило 8. Не переусердствуйте с проектированием.
Проектируйте только то, что актуально сейчас. Ваш код можно делать довольно обобщённым, чтобы он поддерживал дальнейшее развитие, но только в том случае, если он не становится от этого слишком сложным. Не создавайте параметризованные классы, фабрики, глубокие иерархии и скрытые интерфейсы для решения проблем, которых даже не существует — вы не можете угадать, что случится завтра. С другой стороны, когда структура кода не подходит под задачу, не стесняйтесь рефакторить его.
Правило 9. Будьте последовательны.
Делайте одинаковые вещи одинаковым образом. Если вы разрабатываете метод, функциональность которого похожа на функциональность уже существующего, то используйте похожее имя, похожий порядок параметров и схожую структура тела. То же самое относится и к классам. Создавайте похожие поля и методы, делайте им похожие интерфейсы, и сопоставляйте новые имена уже существующим в похожих классах.
Ваш код должен соответствовать соглашениям вашего фреймворка. Например, хорошей практикой является делать диапазоны полуоткрытыми: закрытыми (включающими) слева (в начале диапазона) и открытыми (исключающими) справа (в конце). Если для конкретного случая нет соглашений, то сделайте выбор и фанатично придерживайтесь его.
Правило 10. Избегайте проблем с безопасностью.
Современный код редко работает изолированно. У него есть неизбежный риск стать мишенью атак. Они необязательно должны приходить из интернета; атака может происходить через входные данные вашего приложения.
В зависимости от вашего языка программирования и предметной области, вам возможно стоит побеспокоиться о переполнении буфера, кросс-сайтовых сценариях, SQL-инъекциях и прочих подобных проблемах. Изучите эти проблемы, и избегайте их в коде. Это не сложно.
Правило 11. Используйте эффективные структуры данных и алгоритмы.
Простой код часто легче сопровождать, чем такой же, но изменённый ради эффективности. К счастью, вы можете совмещать сопровождаемость и эффективность, используя структуры данных и алгоритмы, которые даёт ваш фреймворк. Используйте map, set, vector и алгоритмы, которые работают с ними. Благодаря этому ваш код станет чище, быстрее, более масштабируемым и более экономным с памятью. Например, если вы сохраните тысячу значений в отсортированном множестве, то операция пересечения найдёт общие элементы с другим множеством за такое же число операций, а не за миллион сравнений.
Правило 12. Используйте Unit-тесты.
Сложность современного ПО делает его установку дороже, а тестирование труднее. Продуктивным подходом будет сопровождение каждого куска кода тестами, которые проверяют корректность его работы. Этот подход упрощает отладку, т.к. он позволяет обнаружить ошибки раньше.
Unit-тестирование необходимо, когда вы программируете на языках с динамической типизацией, как Python и JavaScript, потому что они отлавливают любые ошибки только на этапе исполнения, в то время как языки со статической типизацией наподобие Java, C# и C++ могут поймать часть из них во время компиляции. Unit-тестирование также позволяет рефакторить код уверенно. Вы можете использовать XUnit для упрощения написания тестов и автоматизации их запуска.
Правило 13. Сохраняйте код портируемым.
Если у вас нет особой причины, не используйте функциональность, доступную только на определённой платформе. Не полагайтесь на то, что определённые типы данных (как integer, указатели и временные метки) будут иметь конкретную длину (например, 32 бита), потому что этот параметр отличается на разных платформах. Храните сообщения программы отдельно от кода и на зашивайте параметры, соответствующие определённой культуре (например, разделители дробной и целой части или формат даты). Соглашения нужны для того, чтобы код мог запускаться в разных странах, так что сделайте локализацию настолько безболезненной, насколько это возможно.
Правило 14. Делайте свой код собираемым.
Простая команда должна собирать ваш код в форму, готовую к распространению. Команда должна позволять вам быстро выполнять сборку и запускать необходимые тесты. Для достижения этой цели используйте средства автоматической сборки наподобие Make, Apache Maven, или Ant. В идеале, вы должны установить интеграционную систему, которая будет проверять, собирать и тестировать ваш код при любом изменении.
Правило 15. Размещайте всё в системе контроля версий.
Все ваши элементы — код, документация, исходники инструментов, сборочные скрипты, тестовые данные — должны быть в системе контроля версий. Git и GitHub делают эту задачу дешёвой и беспроблемной. Но вам также доступны и многие другие мощные инструменты и сервисы. Вы должны быть способны собрать и протестировать вашу программу на сконфигурированной системе, просто скачав её с репозитория.
Заключение.
Сделав эти 15 правил частью вашей ежедневной практики, вы в конце концов создадите код, который легче читать, который хорошо протестирован, с большей вероятностью запустится корректно и который будет гораздо проще изменить, когда придёт время. Вы также убережёте себя и ваших пользователей от большого числа головных болей.
Перевод статьи «15 Rules for Writing Quality Code»
Источник: tproger.ru
Языки программирования
Основы языков программирования изучаются в курсе информатики и программирования 10 класса. О некоторых языках программирования дополнительно можно узнать из данной статьи.
Что такое языки программирования
Языки программирования – это класс формальных языков, используемых для написания компьютерных программ. Каждый из языков имеет свой набор правил:
- Лексических – набор ключевых слов и правила их использования.
- Синтаксических – правила написания команд и операндов языка программирования.
- Семантических – знание смыслового значения операторов и основных конструкций языка.
Эволюция языков программирования шла параллельно развитию электронно-вычислительных средств.
На настоящий момент придумано более 8 000 языков программирования, но при этом широко используются в основном чуть более десяти.
Программы, которые создавались для программно-управляемых вычислительных машин первого поколения, представляли собой набор знаков машинного кода. Программисты, которые создавали такие программы, были высококвалифицированными специалистами. Они самостоятельно распределяли память компьютера и обращались непосредственно к регистрам микропроцессора. Процесс создания таких программ был очень трудоемким, и производительность работы программиста была низкой. В связи с этим появилась потребность в создании средств, упрощающих процесс создания программы.
Ассемблеры – первые языки программирования
В середине 20 века появились первые языки программирования, которые назывались ассемблерами. Эти языки представляли собой машинно-ориентированные автокоды. Они снимали проблему распределения памяти, а программисту не нужно было знать все внутренние коды команд процессора. Все эти функции, связанные с распределением памяти и переводом мнемокода ассемблера в машинный код, выполняет специальная системная программа – транслятор.
В настоящее время язык ассемблера используется, когда стоит задача организовать эффективную работу с аппаратурой компьютера. Также фрагменты, написанные на ассемблере, могут включаться в листинги программ, написанные на языках высокого уровня. Такой прием используется, когда предъявляются высокие требования к экономии времени выполнения программы и объема расходуемой памяти.
Для каждого типа процессора существовал свой ассемблер, так как набор команд у каждого процессора свой. В связи с этим, программу, написанную для одного процессора, нельзя было выполнить на другом. Поэтому возник вопрос в создании машинно-независимых языков программирования.
Языки программирования высокого уровня
Машинно-независимые языки реализуют парадигму процедурного программирования. Программы на этих языках представляют собой последовательность команд, описывающих процедуры обработки информации.
Языками программирования высокого уровня являются Паскаль, Си, Фортран, Бейсик, Java.
В этих языках не учитываются особенности процессорных архитектур, и программы легко могут быть перенесены на другой компьютер.
Все языки высоко уровня в зависимости от типа решаемых задач подразделяются на универсальные и проблемно-ориентированные языки. Универсальные языки, такие как C++, Visual Basic, Delphi, решают задачи создания Windows-приложений. Для создания интернет приложений используются высокоуровневые языки C#, Java, J#.
Проблемно-ориентированные языки используются для создания программ, решающих , специфические задачи на стороне сервера или клиентских интернет-приложений. Например, это языки PHP, Perl, JavaScript, VBScript.
Непроцедурные языки программирования
Класс непроцедурных языков объединяет объектно-ориентированных и декларативных языков.
Объектно-ориентированные языки программирования реализуют объектный подход, в основе которого лежит понятие класса и объекта. Текст программы, написанной на этом языке состоит из экземпляров классов и методов работы с ними. К языкам, реализующим объектный подход, относятся базовые языки Simula и SmallTalk. Современные языки программирования, как правило, реализуют объектно-ориентированную парадигму. При этом модель Simula лежит в основе языков С++, Delphi, C#, Java, а на модель SmallTalk ориентированы языки Objective-C, Python, Ruby.
В декларативном программировании не используются переменные, а решение задачи задается с помощью спецификации. К декларативным языкам можно отнести SQL – язык запросов и HTML – язык разметки гипертекста, а также языки искусственного интеллекта, такие как функциональные языки, например Lisp, и логические языки, например, Prolog.
Самыми старейшими языками высокого уровня считаются Lisp и Фортран, находящиеся в употреблении и по сей день.
Что мы узнали?
Языки программирования представляют собой формальные языки для построения компьютерных программ. Языки программирования подразделяются на процедурные и непроцедурные, высокого и низкого уровня.
Источник: obrazovaka.ru