Уроки, извлечённые из опыта разработки программного обеспечения. Хоть список правил больше касается разработки ПО, это будет полезно почитать каждому новичку.
Разработка
1. Начинайте с небольших вещей, затем расширяйте их.
Как при создании чего-то нового, так и при добавлении функциональности к готовым системам, я всегда начинаю с очень простой версии, которая не делает почти ничего из необходимых функций. Затем я расширяю это решение шаг за шагом, до тех пор пока оно не станет тем, что было заявлено изначально. У меня ещё никогда не получалось расписать в плане все детали уже на старте. Вместо этого, я всё лучше и лучше понимаю то, что нужно получить в процессе разработки и использую эти знания в проекте.
Мне нравятся эти слова Джона Галла: «Любая достаточно сложная система, которая работает, так или иначе в своё время эволюционировала из простой системы, которая работала».
2. Изменяйте что-то одно за один раз.
Если при разработке программа начинает проваливаться на каком-то тесте или некоторая функция перестаёт работать, то гораздо проще найти причину, если вы поменял код только в одном месте. Другими словами, лучше использовать небольшие итерации, чем пытаться сделать всё и сразу. Сделайте что-то одно, убедитесь, что это работает, повторите.
Это также применимо и на уровне коммитов в систему контроля версий. Если вам надо провести рефакторинг, то прежде чем добавить какую-то новую фичу, сначала зафиксируйте изменения для рефакторинга, а только потом (отдельным коммитом) добавьте эту фичу.
3. Добавляйте логирование и обработку ошибок на ранних стадиях.
Когда я принимаюсь за разработку новой системы, одна из первых вещей, которую я делаю — это добавление логирования и обработки ошибок. Обе эти вещи приносят пользу с самого начала работы над проектом. В любой программе, которая больше пары десятков строк кода, вам нужно знать, что происходит в процессе выполнения. И особенно эти данные важны тогда, когда что-то работает не так, как было запланировано.
Примерно то же самое и с обработкой ошибок — раз уж исключений всё равно не избежать, и они будут кидаться на протяжении всей жизни проекта, то почему бы не начать обрабатывать их систематически уже в самом начале?
4. Каждая новая строчка кода должна быть выполнена хотя бы один раз.
Прежде чем закончить работу по какой-либо функциональной возможности, её нужно протестировать. Ведь иначе как вы поймете, что она делает именно то, что должна? Часто лучший вариант для этого — автоматические тесты, хотя бывают и другие варианты. В целом не важно как, но главное, что управление должна получить каждая написанная вами строчка кода.
Иногда может быть сложно воспроизвести нужные условия, чтобы зайти во все ветки кода. К счастью, у вас есть возможность немного смухлевать, не обязательно стараться воспроизводить полностью боевые условия. К примеру, отлов ошибок базы данных можно проверить специально допустив ошибку в написании названия колонки. Или можно временно инвертировать условие внутри if, тогда случай «ошибка произошла» поменяется местами со «всё прошло корректно». Это полезно для ошибок, которые в принципе происходят очень редко и их сложно сымитировать.
Иногда мне попадаются баги, которые показывают, что определённая строчка кода вообще никогда не должна работать. Она может выглядеть вполне нормально внешне, во время code-review, но всё равно не работать так, как должна. Вы избежите таких ситуаций, если примете за правило всегда выполнять хотя бы один раз каждую новую строку.
5. Тестируйте по частям прежде, чем проверять весь проект на работоспособность.
Чем тщательнее вы протестируете отдельные составляющие, тем больше времени сэкономите. Часто можно столкнуться с проблемой наладки взаимодействия между отдельными компонентами. И если вы будете уверены в том, что каждый из них работает корректно, вы сможете уделить достаточное время решению этой задачи.
6. Абсолютно всё занимает больше времени, чем вы думаете.
Особенно в программировании. Оценить, сколько времени уйдет на реализацию той или иной задачи, действительно трудно, даже если всё идет гладко. Но когда речь идет о разработке ПО, необходимо брать в расчет тот факт, что могут возникнуть неожиданные проблемы: в самое простое слияние может закрасться баг, обновление фреймворка вызовет необходимость изменить некоторые функции, или вызов API даст непредсказуемый или неверный результат.
Похоже старик Хофштадтер был прав, когда формулировал свой закон: «На любое дело требуется больше времени, чем казалось в начале, даже если вы учитывали при этом закон Хофштадтера».
7. Сначала поймите, что делает данный код.
В большинстве своем программирование подразумевает изменение существующего кода. Даже если вы включили в проект нечто совершенно новое, это новое должно стать частью написанного кода. Более того, необходимо понять найденное решение прежде, чем добавлять его. Иначе вы можете нарушить работоспособность чего-то, что уже было реализовано. Поэтому умение читать код так же важно, как умение его писать. И это еще одна причина, почему вроде бы простая задача по встраиванию кода может занять больше времени, чем кажется: нужно понимать контекст, в котором происходят изменения.
8. Читайте и запускайте код.
К счастью, есть два метода понимания кода, которые отлично дополняют друг друга. Вы можете читать код и вы можете смотреть, что происходит когда он выполняется. Запуск на исполнение может неплохо вам помочь в понимании того, для чего этот код был написан. Но убедитесь, что вы используете оба подхода.
Отладка
9. Ошибки будут всегда.
Мне не очень нравится подход «Сделать всё с первого раза». Не имеет значения, сколько усилий вы потратите, ошибки будут всё равно («Мы об этом не подумали…»). Гораздо продуктивней запустить приложение и исправлять баги по мере поступления.
10. Реагируйте на отчеты об ошибках.
Каждый разработчик должен тратить часть своего времени на разбор отчетов об ошибках и их исправление. Это даёт более глубокое понимание того, как работает система, чего от нее ждут клиенты, насколько сложно поддерживать систему. Кроме того, это отличный способ почувствовать ответственность за свою разработку. Не упускайте эту возможность.
11. Воспроизводите проблему.
Первым шагом по исправлению любого бага должно быть вопроизведение ошибки. Тогда вы можете быть уверены, что, когда вы исправите программу, ошибка исчезнет. Это простое правило поможет вам избежать ситуации, когда вы предполагаете проблему там, где ее нет, и убедиться, что решение будет работать.
12. Исправьте известные ошибки и смотрите, что останется.
Иногда есть некоторое количество проблем, о которых вы знаете. Различные ошибки могут взаимодействовать друг с другом и вызывать странное поведение. Вместо того, чтобы искать причину такого поведения, исправьте известные ошибки и проверьте, остались ли симптомы.
13. Совпадений не бывает.
Не верьте в совпадения, когда занимаетесь тестированием или отладкой. Вы поменяли значение таймера, и система стала перезагружаться чаще? Это не совпадение. Вы добавили новую функциональность, и другая функция стала работать медленнее? Исследуйте!
14. Учитывайте временны́е метки.
Используйте их при отладке, смотрите на взаимосвязь.К примеру, если примерно за 3000 мс до того, как система перезапустилась, был отправлен запрос, возможно таймер запустил какие-либо действия, которые привели к перезапуску.
Сотрудничество
Живой диалог не заменят видеоконференции, чат, звонок или электронная почта. Удивительно, насколько лучше становятся идеи и решения, если обсудить их с коллегами.
16. Резиновый утенок.
Если вы столкнулись с затруднениями, вы можете пойти к коллеге и рассказать ему о своей проблеме. Чаще всего, в процессе объяснения, вы сами придете к решению, даже если коллега не сказал ни слова. Звучит как магия, но работает достаточно часто.
17. Спрашивайте.
Чтение и запуск кода — отличный способ понять, как он работает. Но если у вас есть возможность спросить кого-нибудь компетентного (автора программы, к примеру), используйте её. Возможность задать вопрос и получить на него ответ, а затем, исходя из ответа задать дополнительные вопросы, позволит вам получить информацию за несколько минут вместо нескольких дней.
18. Признавайте заслуги других.
Говорите, напимер: «Маркусу пришла в голову замечательная идея …», вместо: «мы попробовали …». Старайтесь упомянуть всех, кто вам помог.
Разное
19. Экспериментируйте.
Если вы не уверены, как работает та или иная особенность языка, вы можете просто написать маленькую программу, которая продемонстрирует это на примере. Тот же самый метод применим и когда вы тестируете сложную систему. Что случится, если я передам -1 в качестве аргумента? А не упадет ли сервис, когда я перезагружу машину? Исследуйте, как что работает — вы наверняка обнаружите какие-то ошибки, и кроме того, глубже поймете систему.
20. Поспите.
Если вы работаете над сложной задачей или столкнулись с проблемой, попробуйте поспать, прежде чем принимать решение. Ваше подсознание все равно работает над решением, даже если вы не думаете о нём. В итоге, на утро вы легко найдете ответ, который покажется вам очевидным.
21. Меняйтесь.
Не бойтесь пробовать себя на разных ролях время от времени. Работа с разными людьми, разными продуктами, в разных компаниях стимулирует. Многие люди год за годом сидят на одной и той же работе, изменяя что-то в своей жизни только под влиянием внешних обстоятельств.
22. Учитесь.
Самая лучшая особенность ИТ — всегда есть, куда расти, есть, чему учиться. Пробуйте разные языки и инструменты, читайте книги, проходите онлайн-курсы. Маленькие улучшения, накапливаясь, значительно укрепят ваши навыки.
Так что теперь у вас есть проблема, если вы пишете библиотеку, которая будет использоваться как кодом старой школы, написанным с wchar_t , определённым как псевдоним для unsigned short , так и кодом новой школы, написанным с wchar_t как отдельным внутренним типом. Какой тип данных вам нужно использовать для строковых параметров?
Это перевод The sad history of Unicode printf-style format specifiers in Visual C++ .
Windows реализовала Unicode раньше, чем большинство других операционных систем. В результате решения Windows для многих проблем отличаются от решений, принятых теми, кто подождал, когда пыль осядет¹. Самым ярким примером этого является использование Windows UCS-2 в качестве кодировки Unicode. Тогда это была кодировка, рекомендованная консорциумом Unicode, потому что Unicode 1.0 поддерживал только 65"536 символов². Консорциум Unicode передумал пять лет спустя, но к тому времени было уже слишком поздно для Windows, которая уже выпустила Win32s, Windows NT 3.1, Windows NT 3.5, Windows NT 3.51 и Windows 95 - все из которых использовали UCS-2³.
Но сегодня мы поговорим о строках формата в стиле printf .
Это перевод If FlushInstructionCache doesn’t do anything, why do you have to call it, revisited .
Предполагается, что вы будете вызывать функцию FlushInstructionCache , когда вы генерируете или модифицируете исполняемый код в run-time - чтобы процессор при выполнении вашего сгенерированного/модифицированного кода читал бы написанные вами инструкции, а не старые инструкции, которые могут остаться в кеше команд процессора.
Ранее мы узнали, что . Это потому, что простого вызова функции было достаточно, чтобы очистить кэш команд.
Но в Windows NT функция FlushInstructionCache выполняет реальную работу, поскольку ей необходимо уведомить все остальные процессоры о необходимости очищать их кэши.
Однако если вы посмотрите на Windows 10, то вы обнаружите, что функция FlushInstructionCache выглядит как версия для Windows 95: она ничего не делает .
В чём тут дело?
- Перед началом каких-либо операций проверьте существование всех нужных файлов, папок и переменных. Например, если файл не будет найден, то вы его сможете создать и избавиться от ошибок.
- Проверяйте все входные данные, которые передаются по форме. Например, если в переменной должна прийти дата - проверьте являются ли пришедшие данные датой. Даже если в форме предлагается выбор этих самых дат. Помните, форму всегда можно сохранить локально и поправить ее на свое усмотрение.
- Проверяйте входные данные, чтоб они были только в пределах диапазона, указанного вами. Например, если вы поставили ограничение на 1000 символов в сообщении, а вам написали 2000.
- Длина слов и другие, так как в простую форму можно вести очень много символов, из которых вам нужно будет всего лишь 3-4 десятка с начала, то на форму лучше всего тоже поставить ограничение.
- Длина слов и другое. Если ввести слов 20 без пробела, то на странице это будет выглядеть некрасиво, а вам это не надо, поэтому либо запрещайте ввод таких длинных слов, либо разделяйте длинные слова самостоятельно, либо укорачивайте слова и другое
- Вы знаете, что в поле имени (скрипты: гостевые книги, форумы…) пользователь может ввести что угодно, в том числе и ваше имя. Но так как в интернете не все честные, то некоторые, подписавшиеся вашим именем могут наговорить много всего нехорошего. Чтобы подобного не произошло, создайте список с запрещенными именами и проверяйте не совпадает ли имя пользователя с именем из этого списка.
- Никогда не показывайте в форме пароля его текущее значение. Помните о том, что в этом случае пароль может попасть остаться в компьютере в так называемом каталоге временных файлов Интернета. А если это общественный компьютер? Тогда следующий кто сядет за него может легко узнать пароль. Кроме того форму с паролями обязательно отправляйте по методу POST.
- В вашем скрипте обязательно должно быть предусмотрено модерирование. Согласитесь, гораздо проще и удобнее зайти на сайт, зайти в на страницу модерирования и нажать на пару кнопок и заполнить пару форм, чем заходить по FTP на сайт, открывать нужную страницу и ковыряться в HTML коде.
- Кавычки. Заменяйте в получаемых данных все кавычки на ESCAPE - последовательность. Например, кавычку ["] на [\"]. Данные в форму можно ввести так, что при отображении может много чего натворить с вашей страницей. Например, можно вставить скрипт на Java, изменить оформление. Кроме того если это у вас форум или гостевая, можно заменять два пробела на пробел, для того чтоб количество пробелов отображалось верное.
- Храните пароли в закодированном виде. Ведь если какой-нибудь пользователь и сумеет скопировать себе этот файл с паролями, то он пароль не сможет расшифровать. Если пользователь забыл пароль - меняйте его на абракадабру и отправляйте на Email. При этом обязательно выдавайте вначале ссылку для подтверждения, чтобы никто не узнал пароль.
- Всегда заменяйте метки и разделители, которые вы используете для сохранения информации или отображения, на что-то подобное. Иначе имеется какой-то шанс, что его пользователь введет в форму ваш разделитель и на странице появится целый список ошибок.
- Никогда не забываете ставить error_reporting (0) в начало страницы, благодаря этому параметру все ошибки, если они будут, не будут отображаться на странице и злоумышленник не сможет узнать слабое место в вашем скрипте.
- При подгрузке какого-нибудь файла сначала удостоверьтесь в его существовании, а если он и вправду существует, то подгружайте его с помощью функции require, а не include, потому что в 1 случае если будет ошибка то файл совсем не будет подгружаться, а во 2 он подгрузится с ошибками.
- Проверяйте откуда пользователь пришел. Потому что пользователь может сохранить форму ввода у себя на компьютере и подправить ее, но если он попытается отправить через нее данные, то ничего не получится, так как он его запрос придет не с той страницы, с которой нужно.
Все мы люди и нам свойственно ошибаться. И даже компьютеры ошибаются, если программа, за счет которой они работают, была написана с ошибкой. Чтобы помочь Вам избежать некоторых ошибок при написании программ на любом языке программирования я расскажу о некоторых правилах используемых при написании программ и о методах программирования. Соблюдение ниже описанных методов поможет не только избежать некоторых ошибок, но также предупредит их появление и упростит отладку Вашей программы. Все ниже приведенные примеры и код программ написаны на языке Visual Basic 6.0. Вы можете использовать материал данной статьи и для других языков программирования. Статья не привязывает Вас к какому-либо конкретному языку и является универсальной.
Метод проектирования программных средств
Для решения задач программирования используется "Метод проектирования программных средств". Этот метод состоит из нескольких этапов:
1. Определение условий задачи.
2. Анализ задачи.
3. Создание алгоритма решения задачи.
4. Реализация алгоритма.
5. Тестирование и отладка готовой программы.
6. Поддержка и обновление готовой программы.
На первом этапе определяются условия задачи и необходимо ясно понять, что требуется для её решения. Основная цель в данном случае - отсеять второстепенные аспекты от основной сути задачи.
На втором этапе определяются входные данные, выходные, промежуточные и какие дополнительные трудности могут возникнуть при решении поставленной задачи.
На третьем этапе создается алгоритм - запись пошаговых процедур, а затем обеспечение таких условий, чтобы этот алгоритм решал задачу должным образом. Алгоритм может быть написан и в виде блок-схем.
Наверное, всем кто изучал программирование или информатику в учебных заведениях рассказывали, как нужно чертить блок-схемы. И наверняка большинство не любит их чертить. Ваш покорный слуга также относится к их числу. Но не стоит думать, что блок-схемы абсолютно бесполезны в программировании. Лично я никогда не черчу блок-схемы при разработке программ, но я умею хорошо это делать. И настоятельно советую Вам, научится чертить их лучше всех. Если Вы не научитесь самостоятельно и правильно чертить блок-схемы, Вы не сможете осознать суть того, как работает программа! Именно блок-схема позволяет наглядно и понятно (схематически) показать, как пошагово (построчно) выполняется программа. Ведь блок-схема это и есть алгоритм выполнения самой программы. А что такое алгоритм?
Алгоритм - это описание точного, пошагового выполнения действий решающих поставленную задачу должным образом. Поэтому если Вы сможете написать алгоритм выполнения программы, Вы сможете написать и саму программу, причем на любом языке программирования (который конечно будете знать). Научившись чертить блок-схемы, Вы научитесь построчно анализировать код программы, обрабатывая его в голове, так как это делает компьютер. Это очень важно при отладке программы (пятый этап).
Когда перед Вами стоит решение очень сложной задачи, можно (и нужно) применить метод "декомпозиции". Суть метода заключается в разбиении одной сложной задачи на множество взаимосвязанных, маленьких и простых подзадач, решив которые в отдельности Вы получите необходимый результат. Здесь можно привести аналогию с веником. Весь веник целиком сломать очень трудно, но если его ломать по одному прутику, то все получится.
Четвертый этап метода проектирования программных сред заключается в записи созданного алгоритма в виде программы на определенно языке программирования.
На пятом этапе производится тестирование и отладка программы. Он заключается в поиске всевозможных ошибок и позволяет добиться правильности работы программы. В процессе выявления ошибок используется "ручная отладка программы". Она заключается в мысленном выполнении каждого шага алгоритма, решающего свою задачу (так как это в последствии сделает компьютер), и позволяет убедиться, что данный алгоритм будет функционировать должным образом.
Также в процессе тестирования программы используется "эталонное решение". Это решение поставленной задачи другим методом (например, математически), которое позволяет получить заведомо верные результаты вычисления. Причем в эталонном решении используются не единичные данные, а множество различных данных позволяющих охватить все возможные ситуации вычисления. На основе такого "эталонного решения" можно выявить все возможные "подводные камни" и ошибки программы или ситуации, в которых программа не будет работать должным образом. Также необходимо реализовать в своей программе "защиту от дурака". Это когда учитываются такие ситуации, для которых программа в принципе не предназначена. Например, ввод цифр в поле или переменную, предназначенную для хранения фамилии.
Некоторые ситуации и ошибки невозможно выявить даже на основе "эталонного решения". Такие ошибки проявляются только в процессе длительного использования программы с множеством входных данных. Именно на шестом этапе и производится их исправление, а также изменение программы в соответствие изменившимся государственным нормам или политике компании.
При написании программ также необходимо соблюдать и другие правила, речь о которых пойдет ниже.
Переменные
Имена переменных
Почти во всех программах нам приходится использовать переменные, порой даже очень много переменных. Главное чтобы в последствии не запутаться какая переменная, какие данные хранит. Для этого необходимо давать именам переменных содержательные имена. Исключением могут быть только переменные, используемые в циклах, но не участвующие многократно в вычислениях.
For i = 1 to 10 Step 1
For j = 1 to 10 Step 1
dmsTable(i, j) = i * j
Next j
Next i
Если нам нужно сохранить в переменную чей-то год рождения. Назовите переменную "vblYearsBorn", а не "A". Старайтесь чтобы имя переменной отражало суть тех данных для хранения которых она предназначена, чтобы оно было интуитивно понятно. Пусть от этого имя переменной будет немного длинным, но зато это не даст вам запутаться и исключит повторное использования данной переменной в других вычислениях, для которых она не предназначена. Имя переменной желательно обязательно начинать с прописных букв vbl, от английского variable (переменная). Это особенно актуально в Объектно-Ориентированном Программировании (далее ООП). Так как имя переменной можно спутать с названием, какого либо объекта на форме (об этом пойдет речь ниже).
Давайте для понятности назовем эти три начальные буквы - "Идентификатором объекта", так как дальше я буду упоминать о них не однократно.
После идентификатора, без пробелов, следует писать имя переменной. Его нужно начинать с большой буквы, чтобы при просмотре листинга программы Вы видели, что это переменная, или какой-то другой объект, чтобы буквы выделялись, а не сливались в одну строку.
Объявление переменных
Некоторые языки программирования (например, Visual Basic) позволяют работать с переменными не объявляя их в коде программы. Я считаю это большой ошибкой и не солидностью языка программирования (но это не значит что этот язык программирования плох)!
Объявление переменной это определение ее типа и имени.
Dim vblFirstName as String (Visual Basic)
Var vblFirstName: String; (Turbo Pascal)
Char vblFirstName; (C++)
Т.е. мы как бы указываем программе, что будем использовать переменную с именем vblFirstName и тип данных этой переменной String (текстовый/литеральный).
Почему это важно (это касается только тех языков программирования, которые разрешают так делать. Например, если Вы не объявите переменную в С++ или Turbo Pascal-е, при компиляции будет сгенерирована ошибка, что используемая переменная не объявлена)? Все очень просто. Если мы не объявим переменную ей автоматически будет присвоен тип Variant, это значит что в переменную можно будет сохранять данные почти любого типа. Во-первых, мы сможем записать в переменную, которая хранит фамилию числовые данные или наоборот. ЭТО НЕПРАВИЛЬНО! Так как фамилия не может содержать цифры. Мы заведомо делаем в программе брешь, возможность для совершения ошибки. Вот такими ошибками и пользуются хакеры для взлома систем и прочее. Во-вторых, тип, присваиваемый автоматически, очень "много" занимает места в оперативной памяти. А хорошая программа должна как можно меньше весить. И не важно, сколько гигабайт оперативки у Вас на компьютере. В-третьих, явное объявление переменных позволит назначить им тот тип данных, который Вам необходим. И Вам будет намного легче узнать, какие переменные уже используются в программе. Достаточно будет посмотреть в начале программного кода или модуля, какие переменные уже заданы, а не перелопачивать весь код программы. Вы никогда не сможете повторно объявить уже объявленную переменную в одном и том же модуле, или перепутать их имена, а значить не используете переменную в тех вычислениях, для которых она не предназначена.
В ООП разрешается многократно объявлять переменные с одинаковыми именами, притом условии, что эти переменные локальны и используются только в разных модулях. О видимости переменных пойдет речь чуть ниже.
Инициализация переменных
После того как Вы объявили переменную её необходимо инициализировать, т.е. присвоить ей какое либо значение или обнулить. Это очень актуально для переменных используемых в вычислениях. Дело в том, при объявлении переменной для нее выделяется (резервируется) память. Резервирование памяти не отчищает ячейки от значений, которые ранее в них хранились, поэтому если за объявлением переменной не следует её инициализация, то текущее значение этой переменной будет непредсказуемым, а не нулевым, как думают многие. Не обязательно, что именно так и будет, но если это произойдет причину неправильных вычислений порой трудно выявить, так как код программы верен синтаксически и логически, но все равно вычисления идут неверные.
Если это переменная числового типа и используется в накоплении суммы, то достаточно её просто обнулить.
vblSum = 0
For I = 1 to 10 Step 1
vblSum = vblSum + i
Next i
Или присвойте ей единицу, если переменная используется, как множитель или делитель.
vblSum = 1
For I = 1 to 10 Step 1
vblSum = vblSum * i
Next i
Если это строковая переменная просто отчистите ее.
vblFirstName = ""
Лично я всегда инициализирую переменные, даже если в следующей строке присвою ей другое значение.
Глобальные и локальные переменные
Все переменные имеют свою область видимости в зависимости от того, как Вы их объявили. Переменные могут быть локальными и глобальными.
Локальные переменные - это переменные объявленные внутри какой-либо функции (подпрограммы). Они видимы только в пределах данной функции и не могут быть непосредственно вызваны из основного текста программы. Когда выполнение программы возвращается из функции к основному коду программы или другой функции, локальные переменные удаляются из памяти.
Глобальные переменные - это переменные, определенные вне тела какой-либо функции (для ООП, переменные объявленные в модулях проекта). Эти переменные имеют глобальную область видимости и доступны из любой процедуры, функции в подпрограмме.
Очень часто возникают ошибки при использовании глобальных переменных.
В некоторых языках программирования глобальная переменная имя, которой совпадает с именем локальной переменной, могут изменить значения друг друга.
Опасность использования глобальных переменных исходит из их общедоступности, в результате чего одна функция может изменить значение переменной незаметно для другой функции. В таких ситуациях возможно появление ошибок, которые очень трудно выявить.
Используйте глобальные переменные только при крайней необходимости, когда невозможно или проблематично обойтись другими методами.
Константы
О константах буквально в двух словах. С их использованием в программе также необходимо быть внимательным (как и вообще занимаясь программированием). Имена констант лучше всего начинать с трех буков con, от английского constant (константа).
Const conPi = 3.14159265
Помните, что значения констант нельзя изменить в программе (ведь они константы, а значить постоянные), в противном случае будут сгенерированна ошибка. Лучше всего использовать константы, когда есть какое-либо значение, участвующее во многих вычислениях и его значение никогда не меняется в программе. Либо когда необходимо использовать коэффициент (а они, как правило, тоже постоянны).
Структурное программирование
Структурное программирование - дисциплинирующий подход к программированию, обеспечивающий создание легких для понимания программ и снижающий вероятность ошибок. Суть этого подхода состоит в соблюдении общепринятого стиля программирования и обеспечения удобочитаемости исходного текста. Вы наверняка заметили, что весь программный код, приведенный в примерах, написан с определенной структурой. Вот это и есть структурное программирование.
Операторы начала и конца цикла пишутся строго друг под другом, а все операторы внутри цикла чуть правее. Все отступы делаются с помощью табуляции (клавиша Tab). Точно также пишутся логические схемы. Благодаря такому написанию ваша программа становится более читабельной и легкой для восприятия. Также облегчается отладка программы. Вы можете сами сравнить приведенный ниже пример, написания кода по принципу структурированного программирования и без него. Пример приведен на языке Turbo Pascal (часть кода сортировки массива).
Пример "Структурированный код":
For i:=1 to 9 do
begin
vblMin:=A[i];
k:=i;
For j:=1+i to 10 do
begin
If (vblMin>A[j]) Then
begin
vblMin:=A[j];
k:=j;
end;
end;
vblStuf:=A[i];
A[i]:=vblMin;
A[k]:=vblStuf;
end;
Пример "Обычный код":
For i:=1 to 9 do
begin
vblMin:=A[i];
k:=i;
For j:=1+i to 10 do
begin
If (vblMin>A[j]) Then
begin
vblMin:=A[j];
k:=j;
end;
end;
stuf:=A[i];
A[i]:=vblMin;
A[k]:=vblStuf;
end;
Какой вариант более читабелен и понятен? Несомненно, первый.
Вы должны приучить себя соблюдать все вышеописанные нюансы. Конечно, несоблюдение не критично, но использование этих методов намного упростит Вам написание программ и в будущем их сопровождение.
Ошибки
Программы очень редко работают правильно с первого раза. Закон Мерфи гласящий "Если что-то плохое может случиться, оно непременно случиться", похоже, был написан как раз применительно к компьютерным программам.
Ошибки, возникающие в процессе работы программы можно разделить на несколько типов:
1. Синтаксические ошибки
2. Ошибки времени выполнения
3. Логические ошибки
Синтаксические ошибки имеют место, когда исходный код программы записан с нарушением одного из правил грамматики того языка программирования, на котором Вы пишите программу. Обнаруживается это нарушение при попытке откомпилировать программу.
Ошибки времени выполнения выявляются компьютером во время выполнения программы. Подобные ошибки имеют место, когда программа дает компьютеру указание выполнить неверную операцию (например, деление на ноль или манипулировать неописанными или неверными данными).
Ошибки ввода данных - также являются ошибками времени выполнения. Причиной таких ошибок является попытка ввести данные неверного типа (например, переменной целочисленного типа присваивается строковый параметр или число вещественного типа).
Логические ошибки имеют место, когда программа выполняет неверный алгоритм. Данные ошибки являются самыми коварными, их очень сложно выявить, потому что они не фиксируются при компиляции. Данные ошибки проявляются при выводе неверных результатов программой. Единственно возможные способы выявления таких ошибок это использование методов: "эталонного решения" и "ручной отладки".
Умелое использование всех этих методов и правил: метод декомпозиции, структурное программирование, метод проектирования программных средств, эталонное решение и другие, говорят о профессионализме.
Компьютер всегда прав
Самая раздражающая ситуация в программировании - когда код верный, но не работает. “Да тут три строчки, блин, просто негде ошибиться! Наверное баг! Пойду потрачу три дня на изучение баг-репортов компилятора/интерпретатора/фреймворка... ”. Возникает чувство, будто компьютер над вами издевается!Тут главное помнить, что в этих трех строчках есть ошибка. Если код работает не верно - значит код написан не верно . Точка. Виноваты только вы. Универсальный совет - идите спать! Ну или хотя бы отвлекитесь на чашку чая. Когда, через некоторое время, вы вернетесь к коду, наверняка станет ясно, что тут лишний оператор отрицания, или перепутаны две переменные с похожими именами, или еще какая-нибудь мелочь, в которой мы никогда никому не признаемся.
Успокойся и все получится
Эмоции - наш злейший враг. Лично я, как вы уже догадались по количеству восклицательных знаков, человек эмоциональный. И мне, порой, бывает сложно сконцентрироваться на коде, особенно если этот код писал не я, и код не самого лучшего качества. Мозг как-то сам собой переключается на разработку особо изощренных методов пыток для автора кода.Нужно заставить себя успокоиться. Нужно принять задачу не как издевательство над вашим мозгом, а как вызов. Да плохой код, да отсутствует документация, да сложно, но я программист, это часть моей работы и я справлюсь .
Самое сложное - начать
Бывает смотришь на задачу, и не знаешь как к ней подступиться. С какой стороны начать? И вообще, что-то лень сегодня. «Посижу 10 минут во Вконтактике, потом начну. Ну, после кофе. Ну вот, старый код надо порефакторить, и потом начну. А это что-за таск с низким приоритетом? Выполню его и точно начну…» .Просто начните . Начните с любого конца. Разбейте задачу на мелкие части и начните выполнять их. Перестаньте откладывать, отбросьте посторонние мысли, сконцентрируйтесь на задаче, и начните работу. Дальше пойдет как по маслу.
Читай книги
Читайте книги. Я еще раз напишу: Читайте книги!Почему-то многие программисты совершенно игнорируют книги. “Я и на работе отлично просвещаюсь ”, “У меня нет времени ”, “Я читаю статьи в интернете ”. Это все здорово, но лично я считаю, что лучший источник знаний - это все еще книги. Я стабильно покупаю по одной-две книги в месяц, плюс время от времени перечитываю что-то старое. Не буду врать, у меня на полке скопилась внушительная стопка того, что я купил, но пока не читал (как с играми в стиме) , но я дойду, обязательно дойду.
Знай свои инструменты
Не поленитесь выделить время на подробное изучение инструментов и технологий с которыми вы работаете. Это многократно окупится. Досконально изучите все возможности языка на котором вы программируйте. Просто возьмите, и прочтите официальную документацию от корки до корки. Не используйте IDE только в качестве редактора кода, в любой современной среде есть куча инструментов для повышения качества кода и вашей продуктивности. Не используйте фреймворк только как скелет архитектуры. Изучите его и он сэкономит вам уйму времени. Разберитесь в тонкостях системы контроля версий. Чем лучше вы знаете свои инструменты, тем больше работы они делают за вас .Не будь перфекционистом
Выше я писал, что самое трудное - это начать. Так вот, закончить - тоже не всегда легко. Отлаживать и рефакторить код можно бесконечно. “Что-за длинный метод? ”, “Может это в отдельный класс? ”, “Было бы удобнее если бы... ”, “А вдруг потом понадобится... ”, “А вдруг... ”. В программировании нельзя быть перфекционистом. Проблема в том, что достаточно почитать Роберта Мартина или Банду четырёх, как тут же возникает желание переписать нафиг весь свой код. Нужно понимать, что идеального кода нет. Я придерживаюсь правила: “Код должен работать без багов, быть тестируемым и читаемым ”. Все. Пока код метода отвечает этому требованию, я его не трогаю. Даже если в нем два цикла, три условных оператора и четыре параметра.Умей отдыхать
Самая большая проблема программистов в том, что мы любим свою работу. У меня в отпуске начинается ломка, неделя без программирования - и мне снится сон о том как я продумываю архитектуру нового приложения. Плюс программисту не сложно найти заказы на стороне, которыми можно заниматься по ночам. Плюс свои проекты. А сколько раз вы не могли уснуть, потому что мозг отказывался переключаться с задачи, которой вы занимались весь день?Все это ведет к переутомлению, и, как правило, к снижению продуктивности. Отдохнувший программист - эффективный программист . Высыпайтесь. Найдите себе хобби, которое никак не связанно с мозговой деятельностью и посвящайте ему пару часов в день. Это позволит отвлечь мозг от работы, перезагрузить его. Самые интересные идеи и самые верные решения в последнее время приходят мне в голову в спорт-зале.
