От простого к сложному

Сегодня поговорим об использовании утверждений. Утверждения (assertion) – это код (метод или макрос), с помощью которого проверяется правильность заданного условия. Обычно утверждение использует два аргумента – логическое выражение для проверки и сообщение, которое должно выводиться пользователю в случае ошибки.

Вот пример утверждения на языке Java:

assert value != 0 : "value is equal to 0";

Утверждения не предназначены для использования в промышленных версиях программ. В основном они используются для отладки при разработке и поддержке ПО. При сборке промышленной версии программы утверждения обычно удаляют. Главная задача утверждений – выявить противоречивые допущения, некорректные значения и условия в ходе разработки программы.

Общие принципы использования утверждений

Для ожидаемых событий используйте собственные процедуры обработки ошибок. Утверждения применяйте для событий, которые никогда не должны произойти.

Обработчик ошибок в программе должен проверять некорректные входные данные из внешних источников, предусмотренные программистом, в то время, как утверждения – ошибки в самой программе.

Отработка предусмотренного обработчика – это штатная ситуация. Отработка утверждения – признак неверной работы программы и необходимости внесения изменений в её исходный код.

Не помещайте исполняемый код в утверждения.

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

Используйте утверждения для проверки предусловий и постусловий условий.

Предусловия – это набор требований, которые должны выполняться до вызова метода/создания экземпляра класса и т.п.

Постусловия – это набор требований, которые должны выполняться после отработки метода.

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

okbm(”http://prog-school.ru/2010/03/zashhitnoe-programmirovanie-kak-pravilno-ispolzovat-utverzhdeniya/”,”Защитное программирование. Как правильно использовать утверждения”)

Понравилась статья? Подпишись на RSS или e-mail рассылку

© Школа программирования - Обучение разработке ПО и интернет-проектов онлайн
Posted by feed2blogs.com

Завтра  4 марта в 22.00 по Московскому времени будем проводить бесплатный вебинар “Как начать зарабатывать программированием”. Все желающие могут присоединиться вот здесь: http://webinar2.ru/kak-nachat-zarabatyvat-programmirovaniem

okbm(”http://prog-school.ru/2010/03/besplatnyj-vebinar-kak-nachat-zarabatyvat-programmirovaniem/”,”Бесплатный вебинар “Как начать зарабатывать программированием””)

Понравилась статья? Подпишись на RSS или e-mail рассылку

© Школа программирования - Обучение разработке ПО и интернет-проектов онлайн
Posted by feed2blogs.com

Сегодня поговорим о том, как правильно обрабатывать входные данные программы, скрипта или функции. Сейчас уже непозволительно допускать некорректную работу системы в случае получения неправильных входных данных. Все варианты должны быть учтены. Это первая вводная статья из цикла, в котором мы рассмотрим все нюансы так называемого защитного программирования.

Итак, 3 вещи, о которых не стоит забывать.

Проверка данных из внешних источников

Если данные получены от пользователя, из файла, чужой программы или скрипта (то есть любого источника, которому мы не можем полностью доверять) следует выполнять следующие проверки:

• Значения числовых данных должны попадать в допустимый интервал.
• Строки должны иметь корректную длину.
• Если есть дополнительные условия на строку (например, она должна нести e-mail адрес), необходимо выполнить ответствующие проверки.
• В основном для веб-приложений также следует делать проверки на SQL-инъекции, внедренный HTML- или XML-код.

Проверка данных из внутренних источников

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

Выработка правил обработки некорректных входных данных

Существует более десятка подходов к обработке неправильной информации. Об этом мы поговорим в следующих статьях. Но в любом случае вы должны выработать единый подход к обработке некорректных данных. То есть должен быть четко определен набор правил по обработке различных ошибочных ситуаций, которым вы будете руководствоваться в процессе написания программы.

Конечно, лучшая защита от ошибок – это тестирование и исправление их внутри программы. Но когда наш код работает с данными, полученными из внешних источников, никто не может гарантировать корректность ввода. Поэтому защитное программирование является неотъемлемой частью большого количества программ. Подробнее в следующих статьях.

Понравилась статья? Подпишись на RSS или e-mail рассылку

© Школа программирования - Обучение разработке ПО и интернет-проектов онлайн
Posted by feed2blogs.com

Так как совсем недавно мы выпустили книгу «Путь программиста: от 100$ до 10000$ в месяц», сегодня хочу выложить небольшой отрывок, посвященный концепции развития программиста. Здесь приведен только общий принцип, все самое интересное в книге.

«…Есть такое выражение «Талантливый человек – талантлив во всем». Действительно, успешным людям часто сопутствует удача, за какое бы дело они не взялись. В чем же их секрет? Секрет в том, что они живут гармоничной жизнью. Они развиваются в разных направлениях одновременно, интересуются разными вещами, не зацикливаясь на чем-то одном. Всестороннее развитие позволяет смотреть на проблемы сверху и переносить идеи из одной сферы жизни в другую.

Кроме того, если не получается решить какую-то проблему, то можно попробовать её «отпустить». То есть переключиться на что-либо другое, и тогда ответ зачастую всплывет сам собой. Это все равно, что пытаться пробить стену головой. Иногда нужно просто сделать шаг назад и увидеть рядом открытую дверь.

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

1. Развитие профессиональных навыков. Естественно, профессии должно уделяться особое внимание.
2. Развитие сопряженных навыков. Помимо профессиональных существуют навыки тесно связанные с Вашей деятельностью, развитие которых позволит Вам существенно вырасти, как специалисту.
3. Развитие общих навыков. Не единым программированием жив человек, это надо понимать. Всестороннее развитие личности дает силы, энергию и настроение. Без этого, сами понимаете, никуда.

Далее подробно рассмотрим каждую из составляющих успеха…»

Скачать книгу «Путь программиста: от 100$ до 10000$ в месяц» можно здесь.

Понравилась статья? Подпишись на RSS или e-mail рассылку

© Школа программирования - Обучение разработке ПО и интернет-проектов онлайн
Posted by feed2blogs.com

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

1. Неумение кататься на велосипедах. Неожиданно, да?) На самом деле я хотел сказать, что в эпоху дот-нетов, мак буков и web 2.0 всё (ну или почти всё) уже написано. На любой более-менее популярный язык программирования – по несколько фреймворков и сред разработки. В том числе множество бесплатного, но качественного софта. Огромное количество CMS’ок и движков сайтов. Для коих, в свою очередь, тысячи плагинов, расширяющих функционал.
   Но начинающие программисты часто либо забывают про этот факт, либо его игнорируют. Они, может быть, и понимают, что кто-то уже решил задачу, которая перед ними стоит, и предлагает решение абсолютно бесплатно. Но это их почему-то не останавливает от изобретения велосипедов, которые в большинстве случаев оказываются менее качественными. А зря, вместо придумывания, лучше найти хороший пример с открытым кодом. Тогда можно сосредоточиться на других задачах.
2. Использование неподходящих средств разработки. Знаете, некоторые прям таки с гордостью заявляют, что пишут веб страницы в блокноте windows. Этим они, видимо, подчеркивают некий аскетичный стиль программирования, а на самом деле – свою глупость. Опять же, в наше время существует множество удобных сред и средств разработки, которые упрощают написание кода, заранее проверяют в нём ошибки, выдают подсказки и прочее и прочее. Зачем всем этим пренебрегать? Видимо для того, чтобы сделать больше ошибок и потратить лишнее время на отладку, иных причин я не вижу. Используйте блокнот, как блокнот.
3. Вопросы, на которые уже 100 раз ответили. Перед тем, как начать спрашивать что-либо в форумах, сообществах и т.п. поищите ответ на свой вопрос. Если вы начинающий программист, то наверняка кто-то до вас уже интересовался тем, что вам не понятно. Сначала ищите информацию в мануалах, документациях, форумах, разделах FAQ, а только потом, в случае неудачи, спрашивайте у других.
4. Костыли. У новичков код пестрит неочевидными ходами и решениями. Некоторые из них появляются в результате того, что при тестировании программа начинает вести себя не так, как ожидается. Вместо того чтобы докопаться до сути проблемы, неопытный программист на скорую руку начинает вставлять в код заплатки, которые уродуют программу.
   Доходит до смешного. Например, на сайте была форма, куда пользователь должен был ввести число от 0 до 999. Вместо того, чтобы получить из поля данные и проверить, действительно ли это число в заданном диапазоне, человек сделал проверку на количество символов не больше трех.
   В итоге в логике программы становится трудно разобраться. Ещё сложнее становится вносить изменения и расширять функционал.
5. «Этого точно никогда не будет». Любимая тема новичка – игнорировать обработку некорректных входных данных. Мотив – «этого точно никогда не будет» А ведь будет наверняка! Закон программистской подлости – случится именно то, что не предусмотрел. Надо быть готовым, что там, где должны ввести год рождения будет всё что угодно, кроме четырех цифр. При этом еще нужно придумать правильные ограничивающие условия.
6. Некрасивый код. Стоит ли говорить, что вначале многие не задумываются о длине строчек кода, размере функции, забывают о комментариях и т.д. Об этом много пишем в рубрике культура кода.
   Не задумываются об этом в основном потому, что нет опыта длительной разработки. Когда начинаешь понимать, что всё то, что на первый взгляд кажется мелочью, на самом деле очень важно для жизнеспособности программы в дальнейшем.
7. Не получилось с первого раза – ищем простой путь. Наверное, все за собой замечали: по какой-то непонятной причине программа работает некорректно, а в чем дело мы никак определить не можем. Тогда начинаем делать пункт 5, то есть костыли.
   Например, есть файл с объявлениями констант и функциями, который используют разные модули программы. В одном модуле этот файл забыли включить, что в ходе выполнения приводит к выводу ошибки интерпретатором о том, что не нашлась константа с таким-то именем. Вместо того, чтобы разобраться где она объявлена и почему не нашлась, мы берем и ещё раз объявляем её в проблемном модуле. Это – очень плохое решение. Не делайте так, ищите корень проблемы.

И не забываем: хорошо написанная программа – плюс один в карму!)

P.S. Статья в тему: http://www.happy-pm.com/blog/?p=4125

okbm(”http://prog-school.ru/2010/02/7-tipichnyx-oshibok-neopytnyx-programmistov/”,”7 типичных ошибок неопытных программистов”)

Понравилась статья? Подпишись на RSS или e-mail рассылку

© Школа программирования - Обучение разработке ПО и интернет-проектов онлайн
Posted by feed2blogs.com

1. Регулярная практика программирования

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

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

2. Культура программирования

Относитесь к коду разрабатываемой программы, как к лицу своей работы. Выработайте правила оформления текста и постоянно придерживайтесь их. Не загромождайте текст ненужными функциями, закомментированными блоками старого кода и прочим мусором. Старайтесь постоянно улучшать качество кода, стремиться сделать его как можно более понятным, лаконичным и концептуальным.

3. Храбрость

Если вам кажется, что от кода «дурно пахнет», и вы знаете, как его улучшить – немедленно удалите этот код и напишите заново. Да, да – именно удалите. Не надо комментировать старое ненужное барахло, думая, что оно еще когда-нибудь пригодится. Просто возьмите, удалите и напишите с чистого листа новый качественный код.

4. Вера в свои силы

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

Например, недавно мы с коллегой мучились, пытаясь скомпилировать огромную старую систему, использующую кучу сторонних компонент на древнем компиляторе (вот такая уж задача). В итоге возникала ошибка линковщика, которая не говорила ни о чем. Мы создали новый пустой проект и постепенно стали добавлять туда модули злосчастной программы. Так мы смогли локализовать ошибку. Ну а когда знаешь, в чем именно проблема – решить ее значительно проще!

Верьте в свои силы. Человек умнее машины!

5. Быть в авангарде

ИТ развиваются быстро и замедляться не планируют. Можно писать замечательные консольные программы на Паскале, но только вряд ли они найдут благодарных пользователей. Все потому, что средства разработки совершенствуются постоянно. Та область, в которой сегодня вы пионер, завтра будет использоваться повсеместно. То, что сегодня используется миллионами, завтра станет вчерашним днем, «legacy», «deprecated». Нужно постоянно держать руку на пульсе, чтобы в один прекрасный день не оказаться за бортом парохода современности.

На самом деле следить за технологиями не так уж и сложно. В ИТ, как и везде, все новое – это хорошо забытое старое. Нельзя сказать, что за последние годы в программировании появилось нечто принципиально новое, кардинально отличающееся от всего известного ранее. Все, что человек придумывает, основывается на его предыдущем опыте. Секрет в том, что помимо чьих-то там технологий есть ваш личный опыт, собственная база знаний и технический склад ума, которые от Вас никуда не денутся. И если Вы обладаете этим бесценным багажом, то оставаться в авангарде информационных технологий оказывается вовсе и не сложно.

6. Английский язык

Без этого никуда. Пока все новое в сфере как программирования, так и ИТ в целом идет к нам с Запада. Самая лучшая документация, самые полезные форумы, самые интересные блоги всегда были и будут на английском языке. В ИТ индустрии английский давным-давно завоевал полное господство и перемен не предвидится. Техническую документацию придется читать любому программисту.

Впрочем, нет никакой необходимости доводить свой английский до Upper Intermediate. Достаточно знать столько, сколько необходимо для работы. Программист обязан уметь читать по-английски. Говорить и писать не так критично, хотя и крайне желательно, но читать обязан.

7. Книги must read

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

Безусловно, прочтение такой литературы поднимает вас, как специалиста, на новую ступень.

Хороших книг много, но эти просто жемчужина литературы:

• «Искусство программирования», Дональд Э. Кнут
• «Объектно-ориентированный анализ и проектирование», Гради Буч
• «Совершенный код», Стив Макконел
• «Мифический человеко-месяц», Хилл Чапел, Фредерик Брукс
• «Приемы объктно-ориентированного проектирования. Паттерны проектирования», Э. Гамма, Р. Хелм, Р. Джонсон, Д. Влиссилес

okbm(”http://prog-school.ru/2010/02/7-sovetov-dlya-professionalnogo-rosta-programmista/”,”7 советов для профессионального роста программиста”)

Понравилась статья? Подпишись на RSS или e-mail рассылку

(c)http://prog-school.ru
Posted by feed2blogs.com