Почему я (всё ещё) пишу код


Оглавление (нажмите, чтобы открыть):

Почему скоро программистам не нужно будет писать коды?

Я как программист могу сказать что такое не наступит никогда. Все ровно нужно будет писать коды.

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

Что эта машина сама писала коды. В ее «голову» придется вложить кучу языков программирования (а их очень много, более того в каждой страны есть свои так называемые внутренние языки программирования которые разработаны в этой стране под свои нужды), кучу знаний по математике, физике, электрике и всем существующим отраслям. Так как программы пишутся для совершено разных заводов, фирм, производств в разных отраслях.

И что бы она была полностью уникальной. Над ней придется работать всем странам одновременно с сотнями ученых. Что очень финансово затратно.

И даже если представить что все таки ее создали. Услуги ее будут платные. А платные потому что ее все ровно нужно будет ремонтировать + она бы явно работа от электрики. И явно маленьким фирмам будет не по карману а проще нанять будет просто программиста.

Это просто физически на практике не возможно создать такую машину которая сможет писать сама кода по всем отраслям на всех языках программирования.

Да чего говорить о машине какой-то на данный момент фантастической. Если по сей день не существует даже телефона на котором можно программировать. С этим справляется только компьютер.

У тебя не будет багов, если ты не пишешь код

Лучший способ предсказать будущее – изобрести его.

Всем привет. Меня зовут Николай. Я хочу поделиться с вами историей о том, как у меня получилось стать программистом с помощью Хекслета.

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

К старшим классам появился домашний интернет, я стал играть в онлайн игры и общаться на форумах. В голову стали приходить идеи сделать какой-нибудь ресурс для тусовки гильдии, чтобы общаться и делиться информацией. В интернете нашел информацию, что нужно, чтобы поднять форум. Больше всего полюбил vBulletin, он хорошо расширялся и превращался в полноценную CMS. Денег не было, поэтому я делал всё на бесплатных хостингах. Получил первый опыт работы в вебе. Правда понятия не имел, как всё это работает. Ошибки гуглил, пытался исправить. Часто возникала ситуация, когда страницы отображались кракозябрами или знаками вопроса. В программировании ничего не понимал. Писали, что PHP скоро умрёт, а JS создан для того, чтобы анимировать падающие снежинки на Новый год.

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

В ВУЗе было интересно сидеть на информатике. Пожилой преподаватель рассказывал нам про Visual Basic, здесь я впервые написал первую программу. Интерфейс хоть и накидывался визуально, но внутри можно было сделать полноценную логику. Решил написать программу-калькулятор для своего охотника в Варкрафте, но не смог найти какую-то информацию и быстро забыл про это дело.

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

Вообще это основная проблема самообучения, когда ты что-то изучаешь и не видишь, куда идешь. Словно блуждание в темноте. Я пробовал изучить С++, товарищ, который админил пиратский сервер WoW предложил писать скрипты, если выучу что-то. Язык оказался слишком сложным, я слишком глупым, выучить что-то за 21 день не удалось. Также произошло с языком Ruby по учебнику Криса Пайна. Я изучаю не программирование, а язык. У нас есть переменные классы, мы что-то печатаем в консоль. Почему-то я смотрел на всё это и в голове была паника. Даже простецкие ресурсы codeschool и codeacademy не принесли значительной пользы.

Шёл гол за годом, я всё больше играл и меньше учился. Наступили тёмные времена, я оказался в тяжелой ситуации, когда мне 23, у меня нет образования и опыта работы. За окном бесконечная ночь, и я в депрессии. Меня отчисляют из учебного учреждения, я понимаю, что нужно готовиться к тому, чтобы отдать долг Родине. Времени свободного много, поэтому начинаю заниматься спортом и проходить курс слепой печати «Соло на клавиатуре». И то, и другое мне здорово помогают и вправляют мозги, уже нет той чернухи, что раньше.

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

Время идет, лето подходит к концу. Брат рассказывает про Хекслет, как он обучается и будет удалённо работать. Регистрируюсь только ближе к 2020 году. Денег на обучение у меня нет, сидеть вдвоём на одном аккаунте нельзя, даже если не заметят.

Начинаю пробовать учиться. Застреваю на первом же курсе «Основы программирования», часто заглядываю в решение учителя. В конце-концов бросаю, так как застрял на рекурсии. Хекслет откладывается, я к нему вернусь через 1.5 года. Вместо Хекслета пробую читать книжки по PHP и по ним что-то делать. Энергозатратно и неэффективно.

Нахожу работу продавцом-грузчиком, забываю про Хекслет. В свободное время читаю книги, которые помогают поменять мышление: «Пластичность мозга» Автор: Норман Дойдж, «Сила подсознания, или как изменить жизнь за 4 недели» Джо Диспенза, «Эссенциализм» Грег МакКеон.

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

Я уже хорошо освоился на своей работе, знаю плюсы и минусы, но понимаю, что долго так работать не могу. Я вижу людей, которые работают здесь по 5 лет, а может и больше, но по факту они остаются на своем месте, не обретая чего-то нового. Однажды в лифте слышу фразу, что «чем выше должности, тем больше политики». Компания предоставляет хороший социальные пакет, неплохие бонусы и так далее. Но то чувство, когда ты что-то делаешь и это вносит вклад в общее дело, оно отсутствует. Людей много, ты в них теряешься, в этом есть свой плюс, но работать так до конца жизни я не хочу. У меня есть план, который я разработал.

Май 2020. Мой первый в жизни отпуск. Я не собираюсь отдыхать, я знаю, что хочу делать. Я готовлюсь с утра до ночи проходить Хекслет, чтобы стать программистом и найти работу. Можно считать, что я обучаюсь с нуля. Начинаю с первых курсов, часть из них я вроде просмотрел, но повторить всегда полезно. Начинается «Введение в программирование». В этот раз я решаю всё сам. Занимаюсь каждый день, с перерывом на выходные. Кончается отпуск и я встаю в 5-6 часов утра, чтобы позаниматься. Теперь времени становится мало, 1.5 на дорогу, 9 часов работа. Можно позаниматься либо утром-вечером, либо в обеденное время. Приходится чем-то жертвовать развлечениями, домашними делами. Всем говорю, что я учусь.

При обучении стараюсь соблюдать правила, долго не сидеть над задачей, хорошенько высыпаться. Хотя всё равно были ситуации, когда я сидел и ничего не понимал. Я проходил профессию PHP программиста, всё было довольно понятно, но старый курс «PHP абстракции» мне никак не давался. Я просто не понимал, что происходит, когда мы возвращаем функцией функцию. Основные курсы давались легче. К концу лета я практически я прошёл доступные курсы по профессии. Теории тонны, но нужно закрепить знания. Денег на проекты у меня нет. Нахожу местную студию в Перми. Пишу письмо с просьбой выслать мне тестовое задание, так и говорю, что опыта у меня мало, я новичок. Через день получаю ответ, просят рассказать про себя, чем занимаюсь и так далее. Я пишу и получаю тестовое задание. Нужно реализовать CRUD по типу блога. Комментарии к постам должны подгружаться через AJAX. Предстоит знакомство с новыми технологиями. Javascript я не знаю вообще. JQuery тем более. но старый курс по созданию фреймворка мне помогает, я беру оттуда код, дописываю его, строю приложение, получается костыльный мини-фреймворк. Добавление статей работает, есть пагинация. В принципе всё работает, но тестовое задание заняло у меня два месяца. Делал я его в свободное время и не каждый день. Удалось сделать реализовать всё задуманное. Но так как я долго выполнял задание, мне перестали отвечать и давать обратную связь. Немного расстроился, написал еще пару раз и забыл. Самое главное, я получил опыт, создал небольшое приложение. Познакомился с деплоем на Heroku, Postgres и сопуствующими штуками. Без Хекслета я бы ничего не смог.

К концу 2020 года понимаю, что знаний у меня масса и нужно их как-то подтвердить. Уже нужно планировать отпуск на следующий год, в голову приходит идея подстроить отпуски под проекты, чтобы сделать 2-3 проекта за год. План осуществляется раньше, чем я задумал. Брат зовет делать проект в декабре-январе. Я смотрю расписание и 17 декабря действительно начинается 1 проект по PHP, который можно пройти. Я записываюсь, а брат нет. Не знаю, что читать для подготовки. Я уже научился использовать Vagrant, Composer, проблем с настройкой окружения не возникнет. 17 декабря старт проекта, группа постепенно заполняется. Внезапно вижу, что в моей группе Сергей Мелодин. Дополнительная мотивация сделать всё хорошо. Я просыпаюсь в этот день очень рано. У меня выходной, хочу по-максимуму получить пользу из полученного. Но проект всё никак не стартует, я нажимаю F5, читаю слак, но всё тихо.

Наконец-то начало, первый шаги не такие уж страшные. Нужно познакомиться с новыми инструментами. Наступает второй день, и я получаю кучу замечаний от ментора. В основном по исправлению кода на более понятный. Вечером получаю замечания по работоспособности кода. Проверки кода утром и вечером. Ночью понятное дело сон, а днём работа. Наступило невероятное отупляющее чувство, когда ты не знаешь, что делать, нужно было буквально «родить» идею того, как сделать структуру кода расширяемой. Пишу код, переписываю его, отправляю, получаю замечания. Как же мне бомбило, просто не передать словами. Александр Овчар превратился для меня в самого ненавистного человека на свете. Я торопился, дробил код на мелкие функции, мне говорят, что так делать не нужно. Ну откуда я могу знать, до какой степени дробить код, я же первый раз что-то серьезное пишу. Проект был для меня серьёзным стрессом, я переживал, что не успею, что не закончу к дедлайну. Читал канал Слака и предыдущие дискуссии. Писали, что какой-то шаг убрали, одного вообще отстранили от проектов пожизненно. Было страшно. В течение недели следил за своими товарищами по группе. Переживал за них не меньше, чем за себя. Два человека вообще не стартанули. Двое застряли в самом начале на настройке окружения, а Сергей меня опережал.

В конце-концов получилось завершить проект к пятнице. В душе было какое-то странное чувство. Неужели это закончилось? Если бы проект был чуточку сложнее, смог бы я справиться? Синдром самозванца меня не оставлял.

Проект помог мне понять, что у меня достаточно знаний. Как сказал Кирилл, «Вы можете устроиться на работу, даже просто пройдя Введение в программирование». Это меня воодушевило. Работать на текущей работе я больше не мог и после нового года написал резюме. Туда указал весь опыт, ссылки на код в Слаке помогли доработать, на сайте catwomenko я посмотрел что должно быть, а что нет.

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

Меня пригласили в два места. Оба собеседования в один день. Начну со второго, это компания занимающаяся аутсорсом. Минус был в том, что упор сделан на Битрикс. Четкое разделение разработчиков на фронт и бек. Обучение по одному из направлений 2 месяца, потом тебя проверяют. На собеседовании задали пару странных вопросов, разные технические (что происходит, когда мы в адресной строке переходим на сайт яндекс, про HTTP, версии PHP). На пару ответил, на одном немного подвис. Нужно было составить SQL-запрос, я забыл синтаксис, поэтому дома решил посоветоваться со Слаком, а Кирилл сделал из этого вопроса испытание.

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

Вот уже месяц я работаю программистом, получил первую зп и похвастался в Слаке. Я бы не сделал этого без Хекслета, без сообщества, которое здесь собрано. Когда я стал учиться, то превратился в ярого промоутера. Везде где что-то пишут про обучение на PHP или вообще программированию, я влетаю и кричу «СМОТРИТЕ, ТУТ ЕСТЬ ХЕКСЛЕТ, ЛУЧШИЕ КУРСЫ, СМОРИТЕ КАК КРУТО, ПОЧИТАЙТЕ ОТЗЫВЫ», мало кто верит верит мне, пишут, что мне проплатили. Нет, я просто хочу поделиться хорошей вещью со всеми, кто хочет стать программистом.

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

Программирование для себя: почему всем нужно научиться писать код

Nastya Nikolaeva

Навык программирования может пригодиться не только тем, кто хочет создавать программы или сайты профессионально. О том, как умение писать код может облегчить жизнь, рассказал Илья Щуров, доцент кафедры высшей математики ВШЭ и преподаватель Центра непрерывного образования факультета компьютерных наук НИУ ВШЭ. T&P публикуют конспект его лекции «Программирование как новый английский, или Почему программирование не только для разработчиков».

Илья Щуров

доцент кафедры высшей математики ВШЭ и преподаватель Центра непрерывного образования факультета компьютерных наук НИУ ВШЭ

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

Опрос профессиональных программистов этого года показал, что 81% из них программируют в качестве хобби. Это означает, что программирование доставляет удовольствие, что это не просто работа, но и развлечение. Вы можете пользоваться готовыми программами, и в 95% случаев вы будете это делать, даже если вы профессиональный программист. Но в любой области есть задачи, которые никто до вас не решал, и умение программировать позволяет решать их гораздо эффективнее. Однажды я был в , и меня попросили объединить две таблицы. Человек, который поручил мне эту задачу, ожидал, что я начну по одной копировать ячейки из первой таблицы во вторую. Я перенес пару записей, мне надоело, и я написал короткий скрипт, который брал данные из одной таблицы и вместо меня заполнял гугл-форму, что не очень сложно. Мне это понравилось, но больше всего мне понравилось то, что коллеги смотрели на меня так, будто я владею какой-то магией.

Писать код интересно, но, с другой стороны, это испытание. Ты взаимодействуешь с компьютером, и очень часто это взаимодействие, особенно если ты осваиваешь новую технологию, новый язык, выглядит так. Ты пишешь код, считаешь, что написал его верно, а компьютер говорит, что у тебя ошибка синтаксиса. Действительно, забыл точку с запятой, исправил, запустил заново. А компьютер говорит: «Закрой скобку». Через несколько таких итераций программа начинает работать, и становится ясно, кто в доме хозяин. Дело в том, что и у навыка программирования, и у процесса обучения ему есть некоторые побочные (в том числе положительные) эффекты.

1. Экстремальный опыт руководства

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

2. Новый подход к информации

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

3. Профессиональная коммуникация

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

Почему уметь программировать может быть опасным? Первая причина — «тыжпрограммист». Если вдруг кто-то узнает, что вы умеете программировать, на вас начинают сыпаться запросы: «Переустанови мне операционную систему, пожалуйста, ты ж программист», «Почини чайник, ты ж программист» и так далее. Это не самая страшная проблема, есть пострашнее. Например, в 2001 году на первом курсе, когда интернет еще был медленным, я решил, что нужно сделать какую-то штуку, чтобы быстрее обмениваться информацией с друзьями. Я подумал: есть почта, и она работает. Тогда я завел отдельный почтовый ящик для нашей тусовки и написал скрипт. Робот заходил в этот ящик, брал письма, которые туда пришли, и пересылал их всем, кто был подписан на эту штуку. Так сейчас работают гугл-группы. Если я хотел написать всем, я отправлял письмо на этот общий ящик; если кто-то хотел ответить, он отвечал на него же, письмо попадало ко всем, и можно было что-то обсуждать.

Но у переполнился ящик, а когда ящик переполняется, почтовый сервер в ответ на любое письмо направляет отлуп, который тоже является письмом. Оно тоже попало в общий ящик, мой скрипт разослал его по всем адресам, в том числе и по тому, который переполнился. Почтовый сервер сгенерировал новый отлуп и так далее. В результате в воскресенье утром меня разбудил звонок моего друга, который аккуратно сказал: «Возможно, там проблема, потому что у меня в почтовом ящике 6 тысяч писем, и их количество увеличивается». Ничего особенно страшного не произошло, но это была проблема. Тогда я понял, что код легко может выйти из-под контроля и натворить бед, поэтому надо действовать аккуратно.

Это история как в «Маленьком принце»: вы в ответе за тех, кого приручили. Люди и процессы зависят от кода, который вы написали. То есть, как только вы делаете что-то полезное для других, цена ошибки возрастает.

Как научиться?

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

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

Вполне вероятно, что задача, с которой вы столкнулись, уже решена и это решение где-то лежит. Иногда разобраться с тем, как оно работает, сложнее, чем написать заново. Это стандартная программистская проблема, но для этого у нас есть Stack Overflow, одно из главных изобретений человечества в сфере программирования. Это сайт, где разработчики делятся опытом и отвечают на вопросы друг друга. У каждого участника свой уровень репутации, все очень удачно спроектировано, поэтому на простые вопросы можно получить ответ в течение десяти секунд. Это очень помогает. В современном мире вы не просто пишете программу — вы одновременно используете огромное количество программ и инструментов, уже созданных другими людьми.

Мастер Йода рекомендует:  Раздел AddUrl в различных поисковых системах

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

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

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

3. Не беспокойтесь по поводу математики. Желательно знать, что такое остаток от деления числа на другое число, но все зависит от задач, которые перед вами стоят. Конечно, если вы хотите хитро обрабатывать данные, то вам нужна математика в том объеме, который нужен для такой обработки.

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

Есть мнение, что на фоне развития искусственного интеллекта и машинного обучения программисты скоро будут не нужны: компьютеры сами научатся себя программировать. Но мне кажется, что это не так. До тех пор, пока есть задачи и пока нужно объяснять, как их решать, программирование будет существовать. Безусловно, программирование сильно эволюционирует, за последние 20 лет оно изменилось очень сильно. Но от того, что компьютеры стали умнее, разработчиков меньше не стало — наоборот, их стало гораздо больше. И мне кажется, что дальше будет происходить то же самое.


Почему я (всё ещё) пишу код?

ПОСЛЕ НАПИСАНИЯ КОДА СИСТЕМА ВЫДАЕТ,ЧТО ВВЕДЕН НЕПРАВИЛЬНЫЙ КОД. КОДЫ ПИШУ ВСЕГДА ВНИМАТЕЛЬНО. ИЗ ТРЕХ КОДОВ УДАЛОСЬ ЗАРЕГИСТРИРОВАТЬ ТОЛЬКО ОДИН. ПОЧЕМУ ТАК ПРОИСХОДИТ?

Отмечено как решение

Уважаемая Светлана, пожалуйста, пришлите нам фото кодов, который Вы не можете активировать, используя опцию «Скрыть ответ». Мы поможем Вам разобрать символы в данных кодах и активировать их на сайте.

Приносим Вам извинения за причиненные неудобства.

С уважением, Служба Поддержки.

Уважаемая Светлана, пожалуйста, пришлите нам фото кодов, который Вы не можете активировать, используя опцию «Скрыть ответ». Мы поможем Вам разобрать символы в данных кодах и активировать их на сайте.

Приносим Вам извинения за причиненные неудобства.

С уважением, Служба Поддержки.

Как ввести код с продукции Простоквашино? Почему я ввожу всё правельно. а он мне пишит что не правельно.

Уважаемая Анна, возможно, Вы неверно распознали некоторые символы в Вашем коде. Вы можете прислать нам фото кода, используя опцию «Скрыть ответ». Мы поможем Вам распознать символы в Вашем коде.

Приносим Вам свои извинения.

С уважением,
Служба Поддержки.

Уважаемая Екатерина, Ваш код SAFWR7E**F.
Вы можете успешно активировать его на сайте.

Благодарим Вас за обращение.

С уважением, служба Поддержки.

У меня тоже самое! Еще и вводила несколько раз, написано что сейчас заблокируют! Я верно распознала код. Написано все четко! Помогите мне) хочу баллы:)

Уважаемая Мария, ошибка «неверный код» при активации кода возникает, когда Вы действительно вводите неверный код. Возможно, вы неверно распознали некоторые символы в Вашем коде. Пожалуйста, пришлите нам фото Вашего кода в скрытом комментрии. Мы поможем Вам разобрать символы в коде и активировать его.

Благодарим Вас за обращение.

С уважением, Служба поддержки.

Уважаемый Рамис, возможно, Вы неверно распознали некоторые символы в Вашем коде. Пожалуйста, пришлите нам фотографию Вашего кода в скрытом комментарии и мы поможем Вам корректно распознать символы в Вашем коде и активировать его.

Благодарим Вас за обращение.

С уважением, служаб поддержки.

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

Благодарим Вас за обращение.

С уважением,Служба поддержки.

Безобразие! Ввела код с этикетки — пишет, что неверно. Ввожу варианты — пишет то же. Очень плохо пропечатаны коды, в лупу разглядываю, и то можно понять буквы и цифры двояко. На 5-м варианте вообще заблокирован ввод кодов на 24 часа.
Это для удобства клиентов?

Спасибо за участие в Клубе «Наше Простоквашино».

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

Прикрепить фотографии Вы можете в ответе на данное сообщение, где в форме ввода текста (в строке над текстом) Вам необходимо выбрать опцию «Картинка», после нажатия на которую вы сможете прикрепить файл(ы) к Вашему сообщению либо Вы можете выложить фотографии на любой ресурс и дать ссылку на файл в тексте сообщения.

Пожалуйста, поставьте также галочку «Скрыть ответ» ниже поля ввода текста.

Почему я писал код каждый день в течение года, что я узнал и как вы сможете сделать также. Часть 2

Так как же я всего этого достиг — и как этого достичь вам?

Чтобы не сойти с дистанции и достичь всех поставленных целей — вам необходимо выполнить несколько важных пунктов:

  • Нужно структурировать и дисциплинировать свое обучение, например поучаствовать в #100DaysOfCode
  • Нужно устанавливать небольшие цели и постепенно достигать их на пути к большой цели
  • Займитесь парным программированием
  • Ищите людей, с которыми можно совместно заниматься

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

Самое важное, что я делал

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

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

Что еще может вам пригодится?

Я использовал приложения WakaTime и Clockify для отслеживания времени, которое я ежедневно тратил на работу с кодом. WakaTime и Clockify дали мне дополнительный стимул дальше продолжать работу, так как я хотел превзойти свой ежедневный/еженедельный средний показатель. Какое-то время я даже занимал глобальные списки лидеров в этих приложениях.

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

Если вы решили, что это ваше и вы готовы продолжить обучение — переходите на платные ресурсы. У них много преимуществ. Во-первых, некоторые из них намного качественнее, чем бесплатные. Во-вторых, вы будете сильнее мотивированы, если вложите в обучение свои кровные. Многие люди серьезнее воспринимают вещи, если на них потрачены деньги. В-третьих, на платных курсах с вами будут персонально работать наставники.

В последние месяцы своего обучения, я подал документы на поступление в буткэмп под названием Microverse. И меня приняли! Хочу вам сказать, что хорошие буткэмпы недешево стоят и попасть в них очень трудно (конкретно Microverse принимает менее 4% подающих документы). Но попасть туда того стоило — я наконец-то видел именно те результаты, о которых мечтал в начале своего пути.

Дисклеймер

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

«Нет ничего страшного в том, чтобы пропустить денек-другой из-за незапланированных ситуаций. Но вы должны будете добавить эти дни в конце челленджа. Поймите, главная цель состоит в том, чтобы стать последовательнее, независимо от того, какие на вас сваливаются неприятности.» — Александр Каллавэй, создатель #100DaysOfCode

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

Я не кодил только на юбилей моей мамы, на мальчишник и в Рождество. Иначе меня бы ждали серьезные проблемы. А вот на Новый Год я кодил. И когда сильно болел тоже. Даже операция меня не остановила. В день перед и день после операции — я сидел и писал код. ��

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

Подведем итоги моего 365-дневного обучения

Таким образом, за год обучения я добился следующего:

  • Научился использовать редактор кода и создавать простые статические веб-страницы
  • Научился создавать калькуляторы и приложения для погоды
  • Научился создавать простые интерактивные 2D платформеры
  • На данный момент комфортно себя чувствую с full-stack разработкой: знаю несколько языков, фреймворков и операционных систем. Могу создать полноценную RESTful социальную сеть с нуля (в которой пользователи могут зарегистрироваться с выбранным ими паролем, отправлять сообщения, ставить лайки и писать комментарии, загружать свои фотографии, создавать события, отправлять и принимать запросы на добавление в друзья и приглашения на мероприятия с другими пользователями и т.д)
  • Могу создать материалы для курса, чтобы помочь начинающим разработчикам

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

Надеюсь, вам понравилось читать о моем путешествии. Я настоятельно рекомендую вам поучаствовать в челлендже #100DaysOfCode.

Основы программирования: как начать писать код

Окончил курс по языку программирования, но писать код не научился. С подобным сталкиваются многие новички. Пользователи Reddit описывают проблему так:

  • Я прошёл онлайн‑курс по Python, но всё равно не знаю, как написать полноценную программу.
  • Я знаю теорию, но не могу применить её на практике.
  • Я знаю, что такое цикл while, но не знаю, как и в каких случаях использовать его.


Разбираемся, в чём может быть проблема и как её решить.

Проблема: искусственная среда программирования

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

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

Проблема: чрезмерные руководства

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

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

Проблема здесь — в чрезмерном руководстве. Ученика натаскивают на синтаксис языка, не уделяя при этом должного внимания основным идеям и понятиям программирования.

Синтаксис — это просто набор символов, которые используются для определённого языка программирования. Можно провести параллель с естественными языками: умение написать и произнести фразу на французском “S’il vous plaît” не имеет смысла, если вы не знаете её значения.

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

Решение 1: использовать реальные среды разработки

Стоит помучиться: установить и настроить реальную среду разработки. Начать можно с обычного текстового блокнота или сразу с редактора кода.

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

Напишите код, сохраните его и запустите — это будет вашим первым серьёзным шагом, ведь именно так работают настоящие разработчики.

Решение 2: писать код с нуля

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

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

Не копипастите чужой код. Если вы используете работающих чужой код — вы ничему не научитесь. Изучайте чужой код, но не копируйте!

Главное на данном этапе — дойти до решения самостоятельно, а не получить уже готовое. Каждый раз, когда вы ищите и исправляете ошибку, вы получаете реальный опыт программирования.

Решение 3: писать много кода, очень много кода

Программирование — не теоретическая дисциплина: чтения книг, просмотра учебных видео и выполнения тренировочных упражнений недостаточно, чтобы освоить её. Чтобы научить программировать, нужно написать тысячи строк кода.

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

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

Решение 4: просить о помощи

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

Сделать это можно на сайтах вопросов и ответов для разработчиков, самый известный — Stackoverflow, который существует в англоязычной и русскоязычной версиях. Не забывайте: хороший программист должен владеть английским языком, ведь это основной язык разработчиков всего мира, и ответ вы быстрее найдёте или получите именно на нём.

Чтобы получить корректный ответ на свой вопрос, стоит научиться правильно составлять запрос:

  1. Скопируйте сообщение об ошибке, которое выводится в редакторе и укажите его в вопросе.
  2. Нет сообщения об ошибке, объясните, какого результата вы ожидаете от работы программы, и что происходит при её запуске на самом деле.
  3. Вставьте фрагмент кода, укажите код полностью в посте, если он небольшой. Если большой — используйте Github Gist или Pastebin и укажите ссылку на код.
  4. Отформатируйте код. Не вставляйте его обычным текстом, используйте редактор кода.
  5. Напишите, что вы уже пытались сделать с кодом.
  6. Используйте корректную терминологию — в этом вам поможет изучение теории.

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

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

Как перестать кодить и начать программировать?

приписать сюда можно что угодно

chupasaurus, Но и обратное:
Если вы понимаете что пишете говнокод, но не знаете как написать правильно, то не значит что вы плохой программист.

Тут следует уточнить, что имеется ввиду именно понимание факта говнокодинга, а не самооценка. Разница может быть не очевидна, но она есть. Хз как объяснить =)) надеюсь поймёте меня.

Забавно что все повторяют одно и то же.
Если я плохо вчера что-то нарисовал, потому что не умею, а сегодня мне картина не нравится, это значит что я стал лучше рисовать со вчерашнего дня?

Если код плохой и ты это видишь, это значит лишь то, что он плохой. Не надо обманывать себя, что сейчас ты напишешь лучше.

Бред, даже пояснять не буду почему.
Больше сиди и будет больше в сидячем положении. Прям сознание расширили.

Это кто вам такое сказал? Реакт это уже не JS? Это же обычная библиотека, как в ней в принципе можно гавногодить? К тому при условии если «хорошо знать JS» это иметь высокий скилл в программировании.

Это вы сами домыслили. Автор этого не писал. А мысль это глупая.

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

Здесь конечно я согласен. Нужно писать говнокод, стремясь к лучшему коду. Бежать медленно, но пытаясь бежать быстрее, так как пока что ты быстро бегать не можешь. Также и с кодом, вчерашний код всегда будет говнокодом, так как любой код можно улучшить.

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

Я как раз говорю, что зная язык, вы ничего не добьетесь, так как с языком идет множество смежных технологий. Для вас все просто кажется, потому что вы теоретик и ничего на самом деле не пробуете, разве не так? И соц сеть вы напишите и быстрое приложение для андроида сделаете и робота своего сделаете умнее Алисы от яндекса и аналог сбербанка сделаете =) Но все не так просто, как вы думаете.. Язык как вы сказали не так важен, важны технологии, которые привязаны к языку. Зная php, вы обязаны знать про memcached, redis, composer, elasticsearch, кучу пакетов для самого php. Без них вы не сделаете ничего серьезного. В мобильных приложениях также кучу своих прибамбасов. Вообщем просто сделайте хоть одно серьезное приложение, тогда можно будет поспорить с вами =)

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

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

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

Кроме математики/алгоритмов и какого либо языка ничего не нужно.

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

крутил я на юле все ваши сторонние «технологии», не считая разве что БД.

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

Вообщем я больше не буду с вами спорить! Вы правы, я не могу все знать, но я знаю точно, что вы за свою жизнь не работали ни с одним крупным проектом. Удачного вам развития =)

iamevg_, Начнем с того, что ваши вопросы не чуть не лучше.. А вообще я перфекционист и порой у меня появляются глупые вопросы как что то делать, потому что мне интересно как это делают другие.

Вы не понимаете даже, что без инструментов невозможно программировать, только кодить

Вы настолько неопытны, что не понимаете смысла этой фразы! Речь о том, что никому в реалии не нужен ваш говнокод (а для программиста, не знающего ИНСТРУМЕНТА любой код будет говнокодом, какой бы хороший он у вас не был) Поэтому каким бы гуру вы ни были никто не согласится поддерживать потом ваш код, навряд ли вы будете писать документацию. ХОТЯ БЫ поэтому невозможно нормально программировать, писав велосипеды, я уж не говорю, что над популярными решениями работают команды из десятков человек, а миллионы по всему миру тестируют их продукты и закрывают баги! Или вы такой идеальный что без единого бага все пишете? Хех, я просто уверен в этом!

По остальным пунктам тоже самое! Дело не в том, что нельзя написать что то, а в том, что это будет никому не выгодно и в итоге ничего не выйдет.

Кстати мы со знакомом не так давно разрабатывали систему умного дома на arduino. Там используется язык C, вы его наверняка знаете, он простой как пробка.. Для вас все пустяки.. Так вот как вы думаете, пригодилась нам математика.. Или какие то мудреные алгоритмы, структуры данных.. Нет! Мы изучали различные протоколы умного дома и всю инфаструктуру, которая с этим связаны! То, на что крупные кампании тратят сотни и миллионы тысяч долларов. Думаете мы сами не придумали бы, как сделать то, что нам было нужно? Конечно придумали бы, но кажется у компаний, которые вложили в это кучу денег решения получше чем у нас.. Да, конечно потому что мы тупые как пентиум 1 =) Вы бы по любому сделали лучшую систему в мире!

Мастер Йода рекомендует:  Плюсы аренды серверных стоек вместо покупки

И везде так, абсолютно в любой области! Сначала, чтобы дойти до пика событий, надо изучить все современные инструменты, которые сейчас популярны в этой отрасли.

Вы также сказали о нейронных сетях.. Вы делали нейронную сеть? Этого я не знаю, но я делал. И заюзал простейшую библиотеку! Она 12 года вроде была. Так вот сейчас кучи библиотек от крупнейших компаний, различные фреймворки и т.д. Это тоже херня по вашему? Конечно, надо выучить всю математику и пилить самому, разумеется. Только фишка в том, что вы один =)

Еще по поводу стандартизации, которую вы назвали бредом.. Вы хоть работали в компаниях? Вы знаете что средние компании обычно(почти всегда) специально разрабатывают свои фреймворки и решения.. А знаете почему? Думаете потому, что свое решение всегда стабильней, быстрее и лучше? Да всем похер!
Чтобы не ушли заказчики, так как больше никто не шарит в их фреймворках и цмсках, а поэтому требуют больше денег на поддержку, чем обычно, ну или предлагают все переписывать. Вы скажете — нормальный кодер за день разберется.. Ну ну.. Попробуйте разберитесь, когда там такие мастера-самописцы тысячи строк кода настрочили хер знает как. Скорее всего вы даже на установку такой цмски несколько дней потратите =)

Если он этого не умеет, это же не значит что не умеют и другие.


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

Заказчикам не нужна «разработка инструментов», заказчикам нужно решение реальных задач. И заказчики не будут платить за повторное выполнение уже сделанной работы, просто потому что вам лень посмотреть документацию на существующую и надежно работающую библиотеку, а вы хотите «сделать инструмент», а еще.

Ну это вообще бред какой то. Инструменты созданы для стандартизации. что блин?!

А еще в любом хоть сколь-нибудь серьезном проекте важен не только сам функицонал и программный код, но и то, насколько удобно и трудозатрадно его возможно поддерживать и развивать. И здесь «изобретать свои уникальные велосипеды» — самый лучший способ угробить все что сделано.
Если в проекте использовать общеизвестную библиотеку/фреймворк/платформу, то быстро разобраться во всем этом и продолжить разработку сможет любой разработчик, знакомый с этой библиотекой/фреймвором/платформой.
Если вы нагородили своих уникальных велосипедов, то времени будет потрачено в несколько раз (а то и несколько порядков) больше не только на разработку, но и на введение в проект новых разработчиков. Если вместо общепринятого протокола или формата данных вы изобретете свой, вы просто не сможете интегрироваться с какими-либо другими модулями или комплексами, или же придется потратить время (а время — это деньги) на написание конвертеров и врапперов.
Не говоря уж о том, что очень маловероятно что лично вы во всех возможных случаях напишите код оптимальнее, надежнее и безопаснее, чем сотни отличных разработчиков и компаний со всего мира, работающих над общеизвестными «инструментами».

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

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

Вот вам небольшая задача. Напишите на любой языке, с любыми инструментами математический интерпретатор. Парсинг и вычисление выражения например вида (A + B * (C — D) ^ 3 + (E — F)) / G.

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

Про нейронку. Тем более не верю.

На то они и бич компании, чтобы клепать очередной высер.

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

Есть водитель, а есть инженер-механик. Одни пользуются другие создают.

Я вас попросил написать решение а не скинуть ссылку на готовое.
Естественно вы не можете этого сделать.

Код работает? Работает. Поставленную задачу выполняет? Выполняет. Всё. Вот вам решения.
Не, я прекрасно знаю, что вы ожидаете рассуждений про рекурсивный спуск или построения дерева токенов, но когда стоит задача «нужна возможность быстро считать простые выражения по заданным формулам», нормальному разработчику в нормальном проекте это НЕ НУЖНО.
Тот же muparser может обрабатывать более 100 миллионов выражений в секунду на современном процессоре, используя при этом пре-компиляцию с SSE. Сможете написать лучше за полчаса?

Нет. Причем тут это вообще? Но в любом случае уметь это делать необходимо.

В большинстве языков коллекции входят в стандартную библиотеку языку.

К тому же у вас не было задачи быстро вычислить какие либо выражения, у вас была задача написания инструмента.

Вот после такого, нам тем более не о чем разговаривать.

Конструктивные аргументы и пояснения своей позиции-то будут, или вы просто сливаетесь из обсуждения?

У вас полностью голый аккаунт. Я почти с полной уверенностью говорю что он создан сегодня и что в беседе участвует один и тот же человек.

iamevg_, я не читал ваши очередные споры, но отвечу на 1 ваш ответ мне.. Вы меня явно недооцениваете 😉 Ваша задача вроде одна из 1 в книге «Структура и интерпретация компьютерных систем» Вы читали эту книжку? Я читал много книг, также про то как работают компиляторы и это также одна из первых задач — парсинг таких выражений.

По поводу того что вы не верите.. Вы пробовали это делать? Написать нейронную сеть простейшую (я делал нейронку, которая определяет образ нарисованный, простейший) проще простого. Я делал на node.js и юзал brain.js, как мозги и с помощью paperjs простейшую рисовалку сделал. А до этого я целый день читал разные статьи и смотрел курсы, чтобы понять основы и изучил как работает перцептрон, там обычная работа с матрицами. Да,вы угадали, я использовал готовые решения, но я сделал это и в бизнесе это главное. Эту нейронную янаписал за день при том, что до этого не работал ни с нодой, точнее с експрессом(готовое решение опять же, как я посмел), ни с нейронами, ни с канвасом. Большая часть времени кстати ушла на канвас и обработку изображений, так как на Винду поставить imagemagic оказалось жутким гемороем. Вообще как то так. Я это сделал за 1 день, сколько бы вы все это писали на чистом js. Я полагаю если вам нужно было бы обработать изображение, вы бы не библиотеку скачали, а книгу по обработке изображения и за несколько месяцев написали бы свою.. Хотя вы бы наверное управились за пару часов, вы же гений от природы! Но только заказчик ждёт и он не готов вам столько платить, так как создание библиотеки с нуля не входит в его бюджет, да и вообще у бизнеса требования другие.

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

Вообще мне не важно, что вы об этом думаете, но теперь расскажите вы о своих интересных проектах, интересно будет почитать! Вы сделали парсер выражений или написали hello world 10 раз с помощью цикла?

iamevg_, уважаемый, вы понимаете, что комп, операционка, все комплектующие, компиляторы и вообще всё, что вы считаете, что помогает вам делать нечто «с нуля» и «без зависимостей» так же является инструментами кем-то сделанными и тоже является зависимостями. Предлагаю вам не отступаться от своих же принципов, стать аскетом, сделать свой комп из подручных средств, полностью самому спроектировать от начала и до конца, потом, написать под него ВЕСЬ софт (биосы, операционка, дрова и иже с ними) потом под это дело написать компилятор СВОЕГО языка и на нем решайте задачи для заказчиков или для себя любимого.

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

Гиперболизирую и утрирую я для того, чтобы вы поняли, какую же хрень несёте.

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

Скилл написать что-то самому с минимальным использованием достижений других — это круто, но скорее всего уйдёт в разы больше времени и результат будет хуже, чем если использовать чужие наработки. Всё равно вы это и так делаете.

Если вам дадут задачу написать новый ЯП, вы скажете что зачем создавать новый, если уже есть 100500 готовых решений?

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

скорее наоборот, это означает что разработчик уже давно перерос юношеский максимализм и многое повидал в жизни.

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

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

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

Если под «убогим кодом» подразумевать проблемы в поддержке этого дела, стандартизации и интероперабельности, то да, именно так. Причем в этом случае вы сами никогда не оцените убогость своего кода — об этом вам только смогут сказать другие.

Есть инженеры, а есть недопрограммисты

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

Мне все же очень интересно, какой такой злодей получил доступ к вашему аккаунту и задает настолько идиотские вопросы — Как изучать алгоритмы?

Явно не вы так как вы все учите за 2 дня, а этот ЧЕЛЛЛЛЛЛ задает уже полгода вопросы о ноде и как в этой чудо среде копировать файлы, лол =) Если это ваши друзья вопросы задают, это вас не оправдает, какие друзья такой и ты сам..

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

Если вы настолько глупы, что не можете грамотно понять это утверждение — мне жаль вас. Любой адекват поймет, что речь идет как раз о КОММЕРЧЕСКОЙ разработке. О какой разработке еще может речь идти? Другой не существует. То что вы свои убийцы реакта пишите это все катание на велосепеде. Или у вас есть популярная библиотека на гитхабе, которой пользуется хотя бы тысяча человек? ССЫЛКУ В СТУДИЮ. Хоть одну ссылку скиньте на свое творение, раз мы такие бичи и ничего не можем. И еще раз для непонятливых — я не имею ввиду, что написать СВОЙ инструмент НЕВОЗМОЖНО! Есть компании, которым это действительно необходимо. К примеру facebook сделал react, когда был ангуляр, но ангуляр их явно не устраивал и они решили сделать нечто свое — лучше ангуляра, удобнее конкретно для них, идеальный под их задачи. Или bootstrap даже взять. Они придумали эту удобную сетку.. Вы сейчас можете сказать — надо писать свои бутстрапы, а не чужими пользоваться. Но зачем, если их сетка достаточна удобна и к ней привыкли миллионы.. Если нужна сетка — возьми бутрстрап. Нахрен мне на вашем проекте изучать ваши новые названия классов, если я знаю бутстрап и мне удобно было бы использовать классы из него. Это в простейшем примере и есть стандартизация. Или скажем еще пример. Вы умеете водить машину и водите прекрассно. Вы побывали в куче экстремальных ситуациях, но тут вам дают такую же машину как была у вас, но с другим положением руля, теперь он справа. И отправляют вас на трассу с левостронним движение. Вы будете ехать как черепаха! Надо будет несколько дней чтобы привыкнуть и изменить свое поведение. Также и с инструментами. Где то вы будете ожидать одного, потому что в реакте было так, а начнете делать проект на vue, а он ведет себя по другому в той же ситуации. Поэтому чтобы хорошо изучить инструмент надо не 2 дня. Разумеется, hello world вы напишите уже в 1 день. Но сложные проекты вы начнете делать через несколько месяцев как минимум.

Также если вы хотя бы немного инетересовались it, читали бы хабр и общались с умными людьми, вы бы знали, что эти, как вы говорите бичи — крупнейшие компании. Яндекс, сбербанк, гугл, facebook — ВСЕ КОМПАНИИ ИСПОЛЬЗУЮТ ЧУЖИЕ РАЗРАБОТКИ! Facebook делает vm на php — думаете чтобы повыпендреваться? Нет, им это необходимо! Лучше мутить vm, чем переписывать fb на другом языке.

Вообщем с вами вообще говорить не о чем, единственный бич здесь это вы! Даже по вашему сленгу видно что вы либо школьник, либо очень недалекий человек.

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

Блог GunSmoker-а

. when altering one’s mind becomes as easy as programming a computer, what does it mean to be human.

16 января 2011 г.

Как писать понятный код — руководство для учащихся

aka «Как писать код, понятный хотя бы себе самому»

Когда в школе или университете вам преподают язык программирования, вам рассказывают об инструментах («сегодня мы проходим циклы и условные выражения», «завтра мы будем изучать функции», «текст между < и >называется комментарием и игнорируется компилятором»), но обычно ничего не говорят про то, как (и когда, и зачем) их использовать.

В результате студент обычно берёт в руки отвёртку и начинает заворачивать ей шурупы, забивать гвозди и сверлить дырки (угх!). При этом получается программа, которая содержит весь свой код в одной процедуре. Иногда эта единственная процедура может занимать десятки страниц. Добавьте сюда отсутствие форматирования, комментариев и вразумительных имён — и вы получите рождение нового монстра.

Этот пост — попытка рассказать, что можно сделать с такой ситуацией.

Не способные понять свой же кусок кода, студенты публикуют свой код целиком на форумах, спрашивая, где тут ошибка? Или (наиболее продвинутые): как можно улучшить этот код? Вот пример такого кода (это ещё самый безобидный и маленький код!): О, Боже! Что, по-вашему, делает этот кусок кода? Его непонятность не имеет никакого обоснования. Каким бы опытным ни был программист, никто вам так сразу не ответит на этот вопрос. Не удивительно, что и вы его не понимаете! (а уж каково преподавателю, которому нужно вникать в десятки подобного вида работ) Не удивительно, что вы не можете найти ошибки в своём коде — ведь вы его даже не понимаете! И дело тут не в отсутствии комментариев, а в плохом стиле программирования. Имена переменных неинформативны, а форматирование практически отсутствует.

Вот улучшенный вариант кода: Одного взгляда на этот код достаточно, чтобы понять, что он имеет какое-то отношение к простым числам (prime numbers). Второй взгляд показывает, что он находит простые числа от 1 до MaxPrimes .

Что касается первого фрагмента, то, взглянув пару раз, вы даже не поймёте, где заканчиваются циклы!

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

Форматирование кода

Первый самый важный (и относительно простой) момент — форматирование кода. От форматирования кода не зависят скорость выполнения, объём требуемой памяти и другие внешние аспекты программы. Но от форматирования кода зависит, насколько легко вы можете понять, пересмотреть и исправить код. А также, насколько легко поймёт этот код другой человек (скажем, преподаватель).

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

Чего этому коду не хватает — так это хорошего форматирования.

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


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

Единственное различие между этими двумя кусками кода заключается в расстановке пробелов и переносов строк — в остальном код совершенно одинаков. Пробелы и разрывы строк нужны исключительно людям. Машина читает все эти куски кода одинаково легко.

Самое простое, что можно сделать с форматированием — использовать инструмент автоматического форматирования кода. Например, в некоторых версиях Delphi такой инструмент уже есть. Вызывается он из меню Project / Format Project Sources :

Среда спросит вас, точно ли вы хотите отформатировать код в стандартный стиль оформления. Отвечайте «Yes» (Да) и весь код, подключенный в проект будет отформатирован в стандартном стиле.

Если вы используете Lazarus, то аналогичная команда находится в меню Service ( Сервис ):

А если вы используете PascalABC.NET, то аналогичная команда находится в меню Сервис (но только в автономной версии среды, а не online WDE):

Конечно же, прежде чем запускать эти команды, убедитесь, что программа синтаксически корректна — т.е. она компилируется. Скомпилируйте (или запустите) программу. Успешно прошло? Тогда можно запускать форматирование. Нет? Тогда сначала исправьте ошибки. (Я не говорю сейчас про ошибки во время работы программы, а только в момент компиляции).

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

Что делать, если в вашей версии Delphi такой команды нет? Вы можете воспользоваться программой JEDI Code Format (скачать) или DelForExp (скачать). Скачайте архив с программой (для DelForExp проще всего выбрать «Standalone version»). Распакуйте архив с программой. Теперь запускайте программу — файл JCFGui.exe для JEDI Code Format или DelFor.exe для DelForExp.

Для JEDI Code Format вам также понадобятся настройки стиля форматирования. Можете взять вот эти. Распакуйте этот архив в ту же папку, куда вы распаковали JEDI Code Formatter. Затем, укажите этот файл в настройках программы:

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

Вы можете также установить опцию «No backup», как я сделал это на снимке экрана выше — такая настройка переформатирует файл «на месте».

Теперь достаточно нажать кнопку с зелёной стрелочкой и файл будет переформатирован.

Что касается DelForExp, то в нём всё то же самое: File / Open , указали файл, нажали на кнопку форматирования (только там нарисована молния, а не стрелочка, как в JEDI Code Format) и сохранили результат:

К сожалению, все описываемые способы имеют разные возможности. Кто-то выполняет очень мало действий и имеет мало настроек (или не имеет их вовсе), кто-то позволяет довольно много всего. Наиболее функциональными вариантами видятся JEDI Code Format и форматтер в Delphi. Наименее функциональными — встроенные варианты в Lazarus и PascalABC.NET.

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

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

Мастер Йода рекомендует:  Что такое SRT-файл

Комментирование кода

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

К примеру, что делает этот код? Этот метод вычисляет первые num чисел Фибоначчи. Стиль кодирования этого метода чуть лучше, чем у самого первого нашего примера, но комментарий, описывающий код, неверен. Это сводит на нет всю пользу от комментирования кода. Если вы поверите этому комментарию, то будете введены в заблуждение.

А что скажете насчёт такого кода? Этот метод возводит целое число base в целую степень num. Комментарии в этом коде верны, но они не говорят о коде ничего нового. Это не более чем многословная версия самого кода. Цикл от 2 до «num»? Я и так вижу, что это цикл от 2 до num — зачем это повторять? Это только создаёт лишний шум (мусор).

Наконец, ещё один код: Код вычисляет квадратный корень из num. Код не идеален, но комментарий верен и комментирует цель кода, а не дублирует код.

Какой метод было проще всего понять? Все они написаны довольно плохо — особенно неудачны имена переменных. Эти куски кода иллюстрируют достоинства и недостатки комментариев. Комментарий первого кода неверен. Комментарии второго кода просто дублируют код и потому бесполезны. Только комментарии третьего кода оправдывают своё существование.

Плохие комментарии — это хуже, чем их отсутствие. Поэтому первые два куска кода было бы лучше оставить совсем без комментариев.

Вот несколько правил, придерживаясь которых, вы сделаете свою программу понятнее:

  • Не пишите комментарии, которые повторяют код.
  • Пишите комментарии на уровне цели кода. Комментарий должен отвечать на вопрос «зачем?» или «почему?», а не «как?» или «что?». Что и как — видно из кода. А комментарий должен говорить о том, что код не говорит — а зачем мы вообще это делаем? К примеру: А вот пример полезного комментария, отвечающего на вопрос «почему?»: Этот комментарий гораздо лучше, потому что говорит что-то, чего нет в коде.
  • Рассмотрите возможность замены комментария улучшением кода. К примеру, предыдущий пример можно было переписать так: или так: В обоих случаях код становится настолько очевиден, что комментарий уже не нужен. (дальнейшее улучшение: переименовать AccountFlag в AccountType и сделать её не числом, а перечислимым типом.)
  • Большинство полезных комментариев в программе состоят из одной-двух строк и комментируют блок кода за ними, например:
  • Избегайте комментирования отдельных строк кода. Если отдельная строка требует комментирования — это признак, что её надо переписать. Сюда же относятся комментарии в конце строк. Да, иногда бывают и исключения, но обычно польза таких комментариев сомнительна. Хороший пример полезного использования комментарии в конце строк — пояснение цели переменной при её объявлении.
  • Размещайте комментарии на отдельных строках.
  • Используйте для однострочных комментариев и для многострочных.
  • Придерживайтесь одного стиля комментирования. К примеру, вставляйте поясняющий комментарий до блока кода, а не после. Не отделяйте комментарий пустыми строками от блока кода, к которому он относится. Но вставьте по пустой строке до и после всего блока с комментарием, чтобы отделить их от других аналогичных блоков.
  • Не украшайте комментарии сверх меры. Это затрудняет чтение и их модификацию. Если вы тратите своё время на исправлениие оформления и выравнивания комментариев или стиля кода после того, как вы переименовали переменную, то вы не программируете — вы занимаетесь ерундой. Используйте такой стиль, который не потребует переформатирования при правках. Вот пример неудачного стиля: Если длина комментария меняется, вам нужно выравнивать оформление.
  • Избегайте сокрашений. Цель комментария — пояснить код. Использование сокрашений не помогает достижению этой цели. Не нужно заставлять читающих расшифровывать обозначения.

Кодирование

Программирование с псевдокодом

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

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

Если вы будете следовать этому способу, то ваши комментарии будут полными, ясными и полезными.

Попробовав этот способ на практике, вы обнаружите, что некоторые способы формулировки ваших мыслей предпочтительнее других:

  • Применяйте формулировки, в точности описывающие отдельные действия.
  • Избегайте использования элементов языка программирования. Псевдокод — это более высокий уровень. Не надо его ограничивать языком программирования.
  • Пишите псевдокод на уровне цели/намерений. Говорите про то, что нужно сделать, а не про то, как это делать.
  • Однако пишите псевдокод на уровне, позволяющем переписать его на языке программирования. Если шаги псевдокода будут иметь слишком высокий уровень, то нужно дальше детализировать псевдокод.

Например, процесс кодирования одной задачи мог бы выглядеть примерно так:

  • Определите решаемую задачу. Сформулируйте задачу, которую будете решать. Определите входные данные (что вводим), выходные данные (результаты, что получаем), обязательно соблюдаемые условия (к примеру, какой-то параметр должен быть больше нуля и т.д.), что метод должен скрывать, а что — показывать.
  • Исследуйте существующую функциональность. Посмотрите, быть может эту задачу решает какая-то стандартная функция языка, либо какой-то другой, уже написанный вами, метод.
  • Выберите название метода или функции, выполняющей задачу. Вопрос выбора хорошего названия кажется тривиальным, но дело это непростое. Затруднение в выборе имени может свидетельствовать, что задача не понятна, либо вы пытаетесь делать несколько вещей в одном месте.
  • Продумайте обработку ошибок. Подумайте о всём плохом, что может случится. Что если кто-то передал вам -1 в параметре, который должен быть больше 0? Что если пользователь ввёл не число? Что если файл уже существует? Продумайте, как вы будете реагировать на эти ситуации.
  • Продумайте типы данных, с которыми вы собираетесь работать.
  • Исследуйте алгоритмы и типы данных. Вы можете взять готовый алгоритм и адаптировать его к своей задаче.
  • Напишите псевдокод. Если вы прошли предыдущие этапы, то это не должно составить сложности. Вы можете писать псевдокод прямо в редакторе кода Delphi. Начните с основных моментов, с самого верхнего уроня, а затем детализируйте их.
  • Вы можете написать несколько вариантов псевдокода и выбрать лучший.
  • Сделайте псевдокод комментариями и закодируйте его на языке программирования.

Давайте посмотрим, как это работает на примере. Пусть перед нами стоит задача «найти все простые числа до заданного пользователем». Вот как бы могли её решать:

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

    Уже в этот момент можно запустить Delphi, создать новое VCL приложение и бросить на форму Edit (для ввода данных), Memo (для вывода данных) и Button (для запуска поиска).

    Выбор названий. Ну, давайте назовём Edit на форме — edMaxPrime , Memo — mmPrimes , а кнопку — btCalculatePrimes . Здесь же можно быстренько сделать косметические изменения — типа ReadOnly для Memo и так далее.

    Далее надо написать интерфейс метода, который будет выполнять поставленную задачу. В данном случае название метода достаточно очевидно — скажем, CalculatePrimes . Как мы определили в анализе предварительных требований, ему на вход нужно число — максимальное простое число для поиска, а нам он должен вернуть массив простых чисел. Запишем это так: Добавим заголовочный комментарий поясняющий метод, его требования, а заодно и определённый нами пользовательский тип: Как видите, уже здесь в код включается важная информация — условие для AMaxPrimes и описание поведение при краевом случае (включать ли в результат само число AMaxPrimes или нет).

    Далее, надо бы выбрать или придумать алгоритм, которым мы будем решать эту задачу. Иногда, этот шаг фиксируется преподавателем, иногда он остаётся на ваш выбор. В данном случае мы выберем решето Эратосфена (ну, это будет не в точности этот алгоритм, но очень похож).

    Будем последовательно записывать алгоритм на псевдокоде: Затем: (Здесь единственный комментарий в первом варианте является, по сути, заголовочным, поэтому мы вынесем его в описание функции)

    Достаточно просто. Вы можете легко увидеть, что должна делать программа и проверить правильность её действий.

    Мы создали достаточно подробный псевдокод всего в два шага. Если бы алгоритм был бы сложнее, нам бы могло потребоваться несколько проходов с всё более подробным описанием деталей. Хотя, возможно, последний шаг можно было бы расписать подробнее. Но пока остановимся на этом.

    Теперь под каждым блоком комментария нужно написать код. Если с написанием кода возникают сложности, то это признак того, что псевдокод нужно больше детализировать. Начнём с первого блока: Вы ввели массив для отслеживания «вычеркнутости» числа и закодировали первые строчки псевдокода. Заметьте, что при переводе псевдокода на реальный код у нас возникли новые детали: динамические массивы в Delphi начинаются с нуля, так что нам пришлось ещё описать ситуацию с нулём.

    Продолжаем кодировать: И далее: И так далее. В итоге вы получите готовый код.

    Проверьте, не нужна ли дальнейшая декомпозиция получившегося кода. К примеру, псевдокод, сконвертированный в реальный код может существенно разростись. Тогда его имеет смысл разбить на несколько методов. Или вы можете увидеть, что в результирующем коде у вас есть большие блоки кода, занимающиеся логически связанным действиями. Либо это может быть повторяющийся код. К примеру, в коде выше первый блок кода проводит инициализацию, второй блок — поиск, а третий — вывод результатов. Вот как вы могли бы переписать код: Названия подпрограмм говорят сами за себя и не нуждаются в комментировании. Заметьте, как код программы всё больше и больше начинает напоминать сценарий.

    Этот процесс может быть рекурсивным. Т.е. код в выделенных подпрограммах тоже может потребовть дальнейшего разбиения на подпрограммы. К примеру, код SetResult может быть таким: Вы можете захотеть выделить в ней такую подпрограмму:

    Удаление ненужных комментариев. Некоторые получаемые комментарии могут быть избыточны и могут быть удалены. К примеру, «Для каждого числа от 2 до AMaxPrimes» может быть рассмотрен как избыточный (поскольку он дублирует информацию цикла), но, с другой стороны, он является частью следующего комментария. Лучшим решением будет объединить оба комментария. Не нужным является и «Подсчитать количество не вычеркнутых чисел». В итоге, подчистив всё, мы получаем такой код:

    Обработка ошибок. Для примера я вынес этот момент в самый конец, но по плану он должен стоять ближе к началу. К примеру, в нашем случае это условие для AMaxPrimes . Суть в том, что в методе должны стоять проверки таких ограничений. Делать это можно разными способами, я не буду рассматривать тут варианты, поскольку это выходит за рамки этой заметки. Укажу лишь способ, которой предпочитаю лично я: в самом методе все его ограничения заворачиваются в Assert, вот так: Что касается необходимости получать «читабельные» сообщения об ошибках, то делать это может вызывающий. Пример этого рассмотрен чуть ниже.

    Проверка кода. Следующий шаг после реализации метода — его проверка. Многие ошибки алгоритма вы заметите ещё на стадии псевдокода. Но некоторые ошибки могут не проявится вплоть до окончательного кодирования. Поэтому проверьте код прежде, чем двигаться дальше. Первая простая проверка — умозрительная. Мысленно пройдитесь по всем ветвям метода. Сделать это может быть не всегда просто, но если правильно выделяли дополнительные методы так, что они получаются простыми и делают только одну вещь, то такая проверка будет достаточно простой. Внимание нужно обратить на особые (краевые) случаи и согласованность разных методов. Такую проверку можно попросить выполнить и другого человека — сторонний человек может найти ошибку, которую вы упорно не замечаете («глаза видят то, что хочет видеть мозг»).

    Дальше надо. скомпилировать программу 🙂 Да, до этого момента мы ещё ни разу не запускали её. Здесь нужно убедиться, что программа компилируется. Также нужно устранить все замечания компилятора по коду.

    Дальнейшее тестирование — это прогон программы под отладчиком и проверка её работы экспериментами и бета-тестированием. Чтобы сделать это, нам нужно вообще-то как-то вызвать метод. Если бы это писалось для опытного программиста, то в этом месте стояло бы написание модульных тестов. Для начинающих это явно чересчур сложно, поэтому мы просто вставим метод в программу и проверим его ручками. Вот как это можно сделать: Остаётся запустить программу и погонять её.

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

    Другие темы кодирования

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

    Самое минимальное, что тут можно сказать — давайте названия компонентам, которые вы бросаете на форму! Не оставляйте им названия вроде Button1 , Edit1 , Edit2 и т.д. И снова пример (это реальный пример кода с форума): Что делает этот код? Я понятия не имею. И никто этого не знает, за исключением самого автора кода. Но если вы назовёте компоненты, то код станет понятным: Тут уже стало понятно, что речь идёт про сохранение редактируемой записи в файл. И ещё небольшие улучшения дадут нам:
    Тем не менее, из примеров выше у вас должно было уже сложиться какое-то минимальное представление о правильном коде. А, для надёжности, я привожу краткую выдержку в заключении.

    Заключение

    Я надеюсь, что следуя этим советам, вы сможете писать понятный код. Для удобства я приведу контрольный список вещей для выполнения:

    • Форматирование кода:
      • Делали ли вы автоматическое форматирование кода?
      • Применяется ли форматирование кода для логического структурирования кода?
      • Однообразно ли форматирование?
      • Улучшает ли стиль форматирование читаемость кода?
      • Отделяются ли последовательные блоки друг от друга пустыми строками?
      • Форматируются ли сложные выражения для повышения удобочитаемости?
      • Не содержит ли какая-то строка более одного оператора?
      • Сделаны ли для комментариев такие же отступы, как и для кода?
      • Отформатированы ли прототипы функций и методов так, чтобы их было легко читать?
      • Используются ли пустые строки для разделения составных частей функций и методов?
      • Применяете ли вы схему хранения и именования множества функций, методов и классов?
    • Комментирование кода:
      • Использовали ли вы прототипирование с псевдокодом?
      • Может ли сторонний человек, взглянув на код, понять его?
      • Объясняют ли комментарии цель кода?
      • Переписали ли вы непонятный код, вместо того, чтобы комментировать его?
      • Актуальны ли и правдивы ли комментарии?
      • Позволяет ли стиль комментариев быстро их менять?
    • Стиль кода:
      • Присвоены ли переменным, типам и функциям удачные имена?
      • Выполняют ли функции и методы лишь одно действие?
      • Имеют ли ваши функции и методы небольшой размер?
      • Вынесен ли дублирующийся код в отдельные функции или методы?
      • Очевиден ли и ясен интерфейс каждой функции, метода и класса?
      • Используются ли переменные лишь один раз, а не повторно?
      • Используются ли переменные с той целью, с которой они названы?
      • Используются ли перечислимые типы вместо целочисленных типов с константами или логических флажков?
      • Используте ли вы волшебные константы?
      • Используете ли вы дополнительные переменные для пояснения кода?
      • Просты ли ваши типы данных? Помогают ли они понять программу?
      • Очевиден ли стандартный путь выполнения программы?
      • Сгруппированы ли связанные операторы?
      • Вынесен ли независимый код в отдельные функции или методы?
      • Просты ли управляющие структуры?
      • Выполняют ли циклы только одну функцию?
      • Пишете ли вы программу в терминах проблемной области?

    Суммируя совсем кратко: верный способ написать ужасный и непонятный код — сразу же кинуться его писать, не продумав.

    Как перестать писать говнокод?

    Здравствуйте! Три месяца назад меня взяли работать в небольшую организацию, для нужд которой необходимо написать приложени (под Android, пишу на Java). На собеседовании особых вопросов не задавали. Сказали, мол, приложение будет простенькое , учиться вместе будем и тд. Руководитель мой, программист C#, он мне задания и даёт. Т.к. база программирования у меня крайне слабая уповаю я, лишь на гугл. Со временем, понимание начинает приходить, мозги работать. Т.е. постоянно идет работа с поиском кода, его чтением, анализом, что непонятно сразу в доки, книжки, статьи. Как то раз даже нашел в городе программиста, и напросился на встречу, где он мне написал кусок кода, который меня спас от увольнения. Даже зарегистрировался тут и на стэковерфлоу. Но я пишу откровенный говнокод. Руководитель ругает меня за низкую скорость. И может иногда карательные меры предпринять, хоть и не смертельные. Я действительно неэффективно работаю. Напрашивается вывод, нужно увеличивать знания java core. И писать, писать, писать. Но после рабочего дня, если я его честно отрабатываю, откровенно не халтуря, то мои мозги не могут воспринят информацию, в нужном объёме. Мне код снится ночью уже. Чаще мой рабочий день это 12 часов, за которые я успеваю выжать себя как лимон, потратить время на отвлекающие факторы и что то написать, вернее «наговнокодить«. Проект двигается, разрастается и с каждым днем я понимаю, что это вавилонская башня.

    Мне нужен Ваш совет, умеющие программисты. Какой то жизненный опыт, ваш. Как перестать говнокодить?? Спасибо!

    Заблокирован участником Nicolas Chabanovsky ♦ 5 сен ’17 в 16:46 .

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

    Подробнее о заблокированных сообщениях здесь.

    Перенесён с ru.meta.stackoverflow.com 5 сен ’17 в 16:45 .

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

    3 ответа 3

    Да в общем-то никак. Умение писать грамотный код придет со временем, если, конечно же, регулярно практиковаться. Для новичка (особенно если речь идет всего о трех месяцах опыта) говнокод и медленная скорость работы — это вполне нормальная картина. Ему просто неоткуда знать, как писать код грамотно и быстро (к сожалению этому не учат даже в институтах ). Со временем, если у новичка есть голова на плечах и желание развиваться, он будет накапливать положительный и отрицательный опыт, научится грамотно распределять свое время и усилия, и мало-помалу этот процесс сдвинется с мертвой точки. Главные условия — это регулярная практика и самообучение. Описанная вами картина очень хорошо знакома многим (читая ваши строки, вспоминал, что почти то же самое происходило и со мной) — срывы сроков работы, регулярные баги, любовь к костылям, повсеместный говнокод, нагоняи от начальства. Серебряной пули здесь нет, это болезнь роста. Она излечивается со временем при соблюдении вышеуказанных условий.

    В любом случае хорошим подспорьем будет ковыряние в чужих исходниках (Гитхаб к вашим услугшам), чтение подходящей литературы («Совершенный код» Макконелла или «Рефакторинг и улучшение существующего кода» Фаулера). Поинтересуйтесь также такой вещью, как рефактринг — изучение его принципов способно помочь в понимании того, как следует писать код. Если вы пишете на C# в Visual Studio, то великолепнейшим помощником для вас может стать Resharper. Он способен разглядеть тысячу потенциальных проблем в вашем коде и просто облегчить работу. Также очень благотворно может повлиять наличие наставника, который мог бы что-то показать и объяснить. Хотя с этим обычно сложнее.

    Почему не стоит писать хороший код

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

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

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

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

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

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

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

Добавить комментарий