Обучение C#
Формула программиста
Работая с этим сайтом, Вы даете согласие на использование файлов Cookie.
Как одному написать сложную программу
Эпиграф: Разделяй и Повторяй.
Крупные проекты не появляются на пустом месте. Написать в самом деле большую и сложную программу на пустом месте не получится.
Однако, выход есть, и его название я вынес в эпиграф. Лучше всего это правило продемонстрировать на примере. Например, вы хотите написать программу для решения судоку. Чтобы навёл камерой на журнал судоку — и сразу увидел ответ.
Круто? Было бы классно.
Как написать такую программу?
Сначала нужно разделить её на множество подзадач, как технических, так и алгоритмических.
- Как получить фото с камеры?
- Как его сделать чёрно-белым?
- Как выделить область с судоку?
- Как распознать цифры?
- Как решить головоломку?
- Как показать результат?
- Как запустить это всё на телефоне?
Далее необходимо в «лабораторных» условиях разобраться с каждым пунктом. То есть найти способ решения каждой подзадачи, хорошенько «погуглить», сделать тестовый проектик, реализовать указанный функционал по принципу «лишь бы заработало», только чтобы поставить галочку, что ты понял, как это делается, что у тебя есть рабочий пример.
Когда все части реализованы, начинается самое интересное — создание полной программы.
Не нужно перед собой ставить задачу сделать супер-правильное архитектурное решение, просто пиши, чтобы заработало:
- вызывай модуль фотографирования, делай фотку чёрно-белой,
- находи область задачки, запускай распознавание,
- вычисляй решение и показывай его на экране.
На данном этапе не стоит отвлекаться на оптимизацию, проверку данных, универсальность.
Твоя задача состоит в том, чтобы сделать так, чтобы программа могла отработать от начала до конца под твоим контролем.
Когда это всё получится, тогда можно сделать «ресет» и начать создавать программу «с нуля», имея в запасе функционал для решения каждой подзадачи и опыт их совмещения.
Опять же, не стоит слишком заморачиваться на универсальности и на оптимизации, впрочем, ты сам почувствуешь, как лучше начать писать эту программу, с определённой долей объектно-ориентированности и удобности использования.
Когда и это будет завершено, ты, наконец-таки поймёшь, как твоя программа на самом деле должна работать.
И вот теперь можно в самом деле начать её создавать.
Да, снова «с нуля», используя все былые наработки.
Крупные проекты не создаются на пустом месте. Необходимо сделать несколько итераций, от эскиза до прототипа и до рабочего продукта.
На каждой итерации продукт будет получаться более качественным и эффективным. Может не всегда новая версия будет лучше прежней, впрочем, при желании можно вернуться к прошлой версии, ведь так?
Зачем начинать сначала? Чтобы избежать «монстров» и «колосов», которые могут обрушиться, когда уже не ясно, как оно работает.
Программисты любят создавать своё, а не разбираться в старом. И это прекрасно, если только позволяет бюджет 🙂
Разделяй и повторяй, и будет тебе счастье 🙂
Да мыслишки тут собраны достаточно в правильном ракурсе и вся правда жизни на лицо. Правильно сказал Михайл — перед написанием кода надо обязательно сказать — Аминь. Что бы не навести порчу на код. Что бы этот код был лаконичным и гармоничным. Без этого нынче никак — это нанотехнологии. Без них да же современные ракеты не взлетают — не то что бы современный код взлетел. Ну и опираться на интуицию и удачу — гугл в помощь как говориться!
Источник статьи: http://www.videosharp.info/article/id=479
Как писать компьютерные программы
сообщество редакторов, исследователей и специалистов
wikiHow работает по принципу вики, а это значит, что многие наши статьи написаны несколькими авторами. При создании этой статьи над ее редактированием и улучшением работали, в том числе анонимно, 12 человек(а).
Количество просмотров этой статьи: 52 777.
По мере того как технология становится все более и более доступной широкой публике, растет и потребность в программистах. Написание компьютерных кодов и программ, оно же кодинг (от английского «сoding») — это навык, который приобретается и совершенствуется на протяжении долгого времени, но даже самый опытный программист когда-то был новичком. Существует большое разнообразие языков программирования, которые великолепно подходят для начинающих программистов, вне зависимости от того, в какой сфере деятельности вы хотите применять ваши навыки (например, JavaScript довольно сложен, так что лучше начать с HTML или CSS). Узнайте, как научиться писать компьютерные программы, прочитав эту статью.
Наш специалист делится своей историей:: «Я пришла к написанию кодов, не зная ничего ни о компьютерном дизайне, ни о программировании. Когда я захотела научиться писать программы, я начала с чтения книг по языку и с использования информации из интернета. Сегодня в мире доступно так много ресурсов, что научиться новым навыкам очень легко!»
Программирование (С#) для тех, кто хочет научиться, но не знает с чего начать
Это статья будет полезна людям, которые хотят получить новые навыки (писать программы), но не знают с чего начать или плохо понимают самые простые термины связанные с программированием. Людям абсолютно любого возраста и образования (достаточно среднего уровня знакомства с операционной системой Windows).
Я много лет программировал на языке С++, но мне захотелось (как хобби,а не для работы) сделать модель системы с хорошей визуализацией процесса. И тут я осознал, что надо использовать другой язык. Выбор пал на С# (читается Си Шарп ), потому что потом его удобно стыковать будет с графикой Unity . Я полез в документацию к языку и подумал: это мне легко начать программировать на новом языке, имея опыт других языков и сред разработки, а кто-то может хочет научиться, но бросает потому что просто не знает куда печатать код программы или как организовать программу, чтобы она делала то, зачем её писали. Поэтому я решил параллельно со своим обучением писать статью, в которой буду рассказывать что и как делать, видя проблемы, с которыми сталкивается новичок, изнутри.
Итак у нас есть компьютер с Windows и желание программировать. Программирование — это создание программы (чаще всего в текстовом виде). Потом эта программа выполняет то, что мы от неё хотим. Сам текст программы надо написать в редакторе. Затем этот текст при необходимости подвергается отладке ( дебаг ) и упаковывается в файл-программу ( компиляция ). Редактор, который умеет делать отладку и компиляцию называется средой разработки ( IDE ). Я предлагаю использовать одну из самых крутых IDE (которая к тому же предоставляется бесплатно самими Microsoft) Visual Studio. Скачиваем её (версию Community, читается как комъюнити и переводится как «сообщество») с официального сайта и устанавливаем (на диске C желательно иметь около 20 Гб свободного места). Процесс установки интуитивно понятен. Ставим галочку в блоке C# и устанавливаем. Я поставил галочку ещё и в Unity, чтобы не качать и устанавливать его отдельно.
По процессу установки есть огромный кусок документации . Язык в документации переключается в левом нижнем углу, слева в колонке выбор тем, сверху в строке текущий раздел — всё в одном месте интуитивно понятно. Вообще С# имеет документацию, уроки и примеры почти на всех языках и это очень удобно, потому что на все вопросы можно найти ответы, в отличии от многих других языков программирования. Так же у языка имеется развитое комъюнити, так что типичные вопросы можно найти уже заданными кем-то на форумах просто воспользовавшись поиском Яндекса или самому задать, зарегистрировавшись на каком-то форуме по этому языку. Программирование это больше поиск способа решения, чем набор самого кода (текста программы), поэтому зачастую больше времени уходит (даже у опытного программиста) на чтение документации, поиск и изучение вариантов решения похожих задач (библиотек и шаблонов).
Пока скачивается и устанавливается расскажу чуть теории, а потом продолжим.
Основной принцип написания программ
Далее без теории всё равно не обойтись, поэтому я расскажу основной принцип написания программ. Алгоритм работы — это порядок действий сформулированный так, что не допускает домыслов или разных способов выполнения одного и тоже действия. Многие не любят конкретные примеры, но для того чтобы человек понял как работает программа следует поставить программу на место человека, тогда станет понятно отличие логики работы программы от человеческой.
Например жена хочет что-то приготовить и посылает Вас в магазин за продуктами и говорит: купи батон, молоко, если будут зелёные яблоки, то купи один килограмм, если будут красные, то сходи в магазин столько раз, сколько надо, пока не скупишь все красные яблоки.
Человек услышав такое, скорее всего увидев на полке и зелёные и красные яблоки, не купит килограмм зелёных, а скупит все красные. С точки зрения программы все команды выполняются последовательно и если сначала сказано взять килограмм зелёных яблок, то наличие красных будет проверено только после этого. Чтобы были или зелёные или красные следует сказать » если будут зелёные яблоки, то купи один килограмм, если будут красные, то вместо покупки зелёных сходи в магазин столько раз «. Но тогда программа убедится, что зелёные яблоки есть, но отложит выполнение или отмену до тех пор пока не проверит наличие красных яблок. Эффективнее сказать сначала про красные, а потом про зелёные. На уроках информатики принято рисовать блок-схемы алгоритмов, но на практике к ним прибегают очень редко и они содержат много придуманных только что, но наглядных элементов. Нарисуем алгоритм этой задачи от жены (после дебага), используя для действий прямоугольник, для условий ромб.
Мы видим что в такой простой задаче использованы условия ( если ), повторы или циклы ( пока ). Алгоритм выглядит компактнее записи в виде слов, но программы чаще всего пишутся словами. Попробуем написать эту программу сначала словами нашего языка:
3. Есть ли в магазине красные яблоки?
4. Если да, тогда купи красных яблок сколько унесёшь.
5. В магазине остались красные яблоки?
6. Если да, тогда вернись в магазин и продолжай покупки с третьей строки списка.
7. Если в ответе на третью строке списка первый раз было «нет», тогда есть ли в магазине зелёные яблоки?
8. Если да, тогда Купи один килограмм зелёных яблок.
Строки «Попытайся купить батон» можно заменить на «Есть ли в магазине батон? Если есть Купи батон.», но можно и не менять, так как в большинстве языков программирования существует оператор попытки. Эти 8 строк нельзя выполнить двумя разными способами и они не нуждаются в додумывании действия, если что-то пошло не так. Такой алгоритм можно перевести на любой язык программирования высокого уровня.
Сам алгоритм можно составить несколькими способами. Следует выбирать наиболее простой с точки зрения выполнения компьютера и объёма текста, учитывая возможную необходимость вносить изменения (то есть чтобы был понятным и легко масштабируемым, если так не получается, то программисты такой код называют костылём ). Повторяющиеся операции следует объединять в процедуры (или функции ), чтобы не копировать уже написанное, и ставить комментарии по работе сложных фрагментов (даже для самого себя).
Первая программа на C#
Обычно примером первой программы становится вывод на экран текста «Hello, World!». Раздел изучения C# на официальном сайте с этого и начинается. Далее там рассказываются основы синтаксиса и примеры использования. Со знанием этого словесный алгоритм из «Если А равно Б Тогда Действие» переводится в «if(a==b)действие;» . Справа вверху примеров есть зелёная кнопка для того чтобы пробовать фрагмент кода прямо в браузере. Либо для консольных приложений можно пользоваться сторонними сайтами, например первой же строкой найденной в Яндексе .
Например, я хочу, чтобы моя программа угадывала какую логическую операцию я выполнил (И или ИЛИ) над парой двоичных чисел. Для начала сделаем консольную программу ( приложение ). Вот её алгоритм (не такой подробный как с яблоками):
1. Запросим ввод трёх чисел. Проверим, чтобы введённое было тем, что мы ждём (три двоичных числа одинаковой длины).
2. Попытаемся конвертировать то, что нам ввели в двоичный формат (числа, состоящие из нулей и единиц). Если вы приступили к созданию первой программы сложнее «Hello World», то наверняка прочитали основы языка до циклов включительно (занимает около двух часов времени). Если ещё нет и предпочитаете разведку боем, то я буду делать комментарии, но помните, что язык намного шире того, что я использовал.
3. Выполняем операцию И, если это не И, то выполняем операцию ИЛИ, если это не ИЛИ, то признаёмся, что не знаем какая это операция. Такая конструкция называется условным оператором или ветвлением или ифчиком .
4. Повторяем пункт 3 для каждой пары символов. Предположение об операции делаем по факту большинства опознанных результатов побитового сравнения.
5. Программа должна вывести на экран сообщение о предполагаемой логической операции.
При первом запуске программа предложит открыть сторонний проект (потом будет предлагать из Ваших проектов плюс эти же варианты). В самом низу есть ссылка по которой просто открывается программа. В самой программе нажимаем Файл->Создать->Проект. Выбираем «Консольное приложение C# «.
Источник статьи: http://zen.yandex.ru/media/pss/programmirovanie-s-dlia-teh-kto-hochet-nauchitsia-no-ne-znaet-s-chego-nachat-5ec0f87272423a6de38c5726
7 правил написания программ, которые не умрут вместе с вами
Ваши программы – это ваше наследие. Решайте сами, как долго оно будет существовать.
Жизнь заканчивается, но программы не обязательно должны умирать.
После серии моих твитов на тему того, как нужно писать программы, меня попросили раскрыть эту тему. Предупреждаю, что редко в каком проекте удаётся чётко следовать всем семи правилам. У меня самого это часто не получается. Но чем больше правил вы соблюдаете, тем больше ваши программы проживут. Каждый символ добавляет что-то к общей экосистеме, и наша задача, как инженеров, поддерживать экосистему в чистоте и порядке.
Что можно получить, выдавая хороший код? Разве не имеет права на жизнь подход в обучении под названием «двигайся быстрее, ломая всё на своём пути?» Нет. Обучиться писать код – это навык, это доступно каждому. Обучиться писать хороший код – это искусство. Это требует усилий, времени и целеустремлённости.
Разве вы хотите оставить после своей смерти миру ещё больше SEGFAULT-ов? Хотите ли вы, чтобы сисадмины занимались починкой систем, которые сломались из-за вашего дерьмового кода? Чтобы ваш менеджер проектов вспоминал вас как инженера, работа которого бесила пользователей?
Ничего плохого в быстром продвижении вперёд нет, но в какой-то момент нужно осознать, что низкокачественный код далеко вас не уведёт.
Когда вы приходите к врачу, тот сначала задаёт вам много вопросов, чтобы понять, что с вами случилось. Он не выписывает лекарства перед постановкой диагноза. Точно так же важно разобраться, действительно ли с вашим кодом что-то не так.
1. Накат обновлений отнимает много времени и сил?
2. Система рушится даже от небольшого обновления?
3. Выкатывали ли вы когда-нибудь сломанный код на продакшн, причём это становилось известно только после жалоб пользователей?
4. Знаете ли вы, что именно нужно делать, когда система падает? Как добраться до бэкапов и восстановиться из них?
5. Проводите ли вы больше времени за сменой окружений, повторных выполнений одних и тех же команд, запуска каких-то утилит – чем за самим написанием программ?
Если вы ответили «да» – эта статья для вас. Читайте, а лучше прочтите два раза.
1. Делите на модули
Мозг человека – сложное устройство, сложнее любого процессора, при этом он не справляется с решением сложных задач. Допустим, сложно сразу умножить 13*35. Но если разделить эти операции на простые: 35*10 + 30*3 + 5*3 = 455, то подсчёт упрощается. Разбивая задачу на простые и независимые, мы приходим к ответу.
Так же и с программами. Разбейте программу на несколько частей, файлов, директорий. проектов. Все зависимости выведите в одно место, используйте принцип MVC или его вариант. Такой код и читать проще, и отлаживать легче. В большинстве случаев отладка приведёт вас к нескольким строкам кода, а не к файлу из тысячи строк. Накатывая апдейты одного модуля, вы не сломаете всю остальную систему.
2. Тестируйте
Такая реакция естественна, потому что нас учили, будто тесты не являются частью программирования. Вас учат шаблонам в С++, но не тому, как их тестировать. В этом и проблема. Некоторые считают, что тесты над писать до самой программы.
Мне всё равно, когда вы пишете тесты, если вы их пишете. Не надо геройствовать, начните с простого (print(add(1, 1) == 2)), а затем уже переходите на фреймворк для тестов в вашем языке.
Тогда вы начнёте понимать сложность вашей программы, учиться делить её на модули, части, которые можно тестировать по отдельности. Получается, что используя тесты, вы уже будете выполнять два из семи правил.
3. Непрерывная интеграция
Тесты должны успешно отрабатывать, причём в разных окружениях (например, в разных версиях Python). Также тесты надо проводить после каждого изменения. Вместо того, чтобы делать это вручную из командной строки, удобнее и быстрее создать платформу для непрерывной интеграции.
Непрерывная интеграция (НИ) – это практика разработки, при которой код интегрируется в репозиторий несколько раз в день. Каждый раз проверяется автоматически, что позволяет отслеживать проблемы на ранней стадии.
Для своих проектов я использую TravisCI и Drone.io. Когда я делаю новое дополнение кода, платформа делает билд и выполняет тесты.
4. Автоматизируйте
У больших проектов всегда есть куча мелких вспомогательных задач. Некоторые люди делают текстовики с командами и копируют их оттуда. Но проще освоить скрипты на bash (и/или Python). Вот некоторые задачи, которые необходимо автоматизировать скриптами:
— преобразование README.md в другие форматы
— автоматическое тестирование (включая создание тестовых серверов и данных, удаление временных файлов и т.д.)
— заливка кода на сервер разработки
— размещение программы на продакшене
— автоматическое обновление зависимостей
5. Избыточность
Первое, что вы видите на git-scm.com:
Git – бесплатная распределённая система контроля версий с открытым исходным кодом, предназначенная для работы как с малыми, так и очень большими проектами, с высокой скоростью и эффективностью.
Распределённая. Это ключевое слово. Ущипните себя, если вы хоститесь только на гитхабе. Потому, что это единая точка отказа. Если гитхаб падает, или во время push-операции вы повредили файлы, ваш процесс разработки останавливается.
Залогиньтесь на Bitbucket и выполните следующее в вашем репозитории:
Теперь, когда вы заливаете код, изменения идут как на Github, так и на Bitbucket. Никогда не знаешь, когда что-либо сломается. И всегда полезно иметь бэкапы. Вот, как это работает у меня:
— весь код живёт в директории Codebase в Dropbox. Автоматическая синхронизация.
— почти весь код живёт на Github
— самый важный код живёт на двух частных зеркалах – одно в школе, другое на моём AWS
Я потеряю свой код, только если настанет конец света.
6 Коммиты
Это должно быть вам знакомо. Загляните в историю, и вы увидите что-то вроде:
Исправил? Какую ошибку? В каком модуле?
Многие расценивают систему контроля версий как бэкап, а не как способ хранить историю. История из таких сообщений бесполезна. Допустим, через неделю после этого коммита вы решили что-то вернуть назад, потому что оно привнесло в проект новый баг. Но поскольку описания действия нет, вам нужно просматривать все изменения. Именно для предотвращения этого и создавались системы контроля версий.
Чтоб не напрягаться, просто воспользуйтесь следующей шапргалкой:
— у каждого коммита должен быть смысл. Исправление ошибки, добавление новой функции, удаление существующей?
— только одно изменение на один коммит
— включайте номер проблемы в сообщение о коммите
— включайте описание изменений. Это зависит от правил текущего проекта, но обычно вы упоминаете, что приводило к ошибке, как вы её исправили и как это тестировать
— пишите осмысленное сообщение:
добавил новую форму в заголовок, чтобы было легче собирать ссылки. закрыл #3
удалил всякое, ибо почему бы и нет, хех
7. Планируйте
Даже если вы выполняете все предыдущие правила и чувствуете себя богом программирования, всё равно может случиться всё, что угодно. Имейте план на самый плохой случай. Что, если трафик побьёт рекорды? Откуда вы возьмёте бэкапы, если система упадёт? Кому звонить ночью, если сервер навернётся?
Продумайте, но не перестарайтесь. Автоматизируйте всё, что возможно. Затем задокументируйте всё подробно. Так, чтобы тот, кто получит ваш код, тоже смог следовать плану. Иметь план – не только значит выглядеть умнее, это значит реально быть умнее.
Вот такие правила и определяют хорошую программу. Если вас они не убедили, ответьте мне на два вопроса:
1. Ожидаете ли вы от новичка, присоединившегося к вам, что он поймёт существующий код с лёгкостью?
2. Является ли рефакторинг кода простым и быстрым делом?
Если нет – перечитайте заново. Сохраните, поделитесь с командой.
Эти правила поначалу могут показаться очевидными. Так и есть. Плохой код постоянно создают, и, в конце концов, он умирает. Ваши программы – это ваше наследие. Решайте сами, как долго оно будет существовать.
Источник статьи: http://habr.com/ru/post/250645/