Как писать ужасный код делимся опытом


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Как писать чистый и красивый код

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

Роберту Мартину удалось идеально описать измерение качества кода кода:

Единственным ценным измерением качества кода является WTF/мин.

Объясню чуть подробнее. Когда я провожу code review, у меня бывает только три эмоции:


  1. WTF (с отвращением) — этот код не нужен.
  2. WTF (с восхищением) — этот человек умен.
  3. WTF (раздраженно) — эту ерунду невозможно разобрать.

Что же влияет на нас первым делом, когда мы видим любой код? Это чистота и красота его написания. Создание чистого и красивого кода — это знак отличного мастера.

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

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

Начните с имени

Кендрик Ламар отлично сказал:

Если я захочу рассказать реальную историю, то я начну со своего имени.

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

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

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

Функции должны делать одну вещь

Луис Салливан однажды сказал:

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

Существует только два золотых правила создания чистых функций:

  • Они должны быть небольшими
  • Они должны делать одну вещь и делать ее хорошо

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

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

Комментарии не исправят плохой код

Винус Уильямс заметила:

Каждый оставляет свои комментарии. Так рождаются слухи.

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

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

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

Форматирование кода — всегда приоритет

Форматирование кода — это коммуникация, а коммуникация — это приоритет для профессионального разработчика, — отмечает Роберт Мартин.

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

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

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

Сначала напишите try-catch-finally

Жорж Кангилем правильно сказал:

Ошибаться — это по-человечески, постоянно ошибаться — это бесчеловечно.

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

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

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

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

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

Заключение


Каким словом можно обобщить все сказанное здесь?

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

Согласно Роберту Мартину, «написание чистого кода требует дисциплинированного использования мириад маленьких техник, примененных для ощущения чистоты. Эти маленькие методы вместе образуют чувство кода».

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

Подвести итог можно словами Гарольда Абельсона:

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

Как писать ужасный код: делимся опытом

69’517 подписчиков
14’821 просмотров на пост

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

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

  • Детальная аналитика 70’046 каналов
  • Доступ к 28’004’146 рекламных постов
  • Поиск по 112’332’059 постам
  • Отдача с каждой купленной рекламы
  • Графики динамики изменения показателей канала
  • Где и как размещался канал
  • Детальная статистика по подпискам и отпискам

Найдено 1677 постов

Как оптимизировать производительность запросов в PostgreSQL
Не понимаете, почему ваш SQL-запрос выполняется так долго? Разбираемся с планами запросов в PostgreSQL и рассматриваем инструменты визуализации анализа.

По стопам лучших: микросервисная архитектура в разрезе
Использовать микросервисную архитектуру или нет? Разбираемся с плюсами и минусами, внутренней коммуникацией, принципами и заблуждениями.

«Инфраструктурная платформа на основе Kubernetes» — профессиональный онлайн-курс от OTUS. Чтобы присоединиться к новой группе, нужно пройти вступительное тестирование на сайте: https://otus.pw/0TmP/

Для кого? Для разработчиков, администраторов и технических лидеров.

Если вы ответите «да» хотя бы на один вопрос, то это ваш курс:
— устали тратить время на автоматизацию?
— хотите единообразные окружения?
-хотите развиваться и использовать современные инструменты?
— небезразлична надежность инфраструктуры?
— приходится масштабировать инфраструктуру под растущие потребности бизнеса?
— хотите освободить продуктовые команды от части задач администрирования и автоматизации и сфокусировать их на развитии продукта?

Хотите подробностей? Приходите 27 ноября онлайн на день открытых дверей курса: https://otus.pw/XjWT/

Сдавайте вступительный тест и присоединяйтесь к новому набору!

Автоматическое распознавание автомобильных номеров на Raspberry Pi
Рассказываем, как самостоятельно создать компактную систему автоматического распознавания номеров автомобилей на одной плате Raspberri Pi с библиотекой OpenALPR.

Открытые Linux-бенчмарки: для нагрузочного тестирования серверов и веб-приложений
Это — подборка утилит, составленная на основе рекомендаций резидентов Hacker News и GitHub. В список вошли: Locust, Vegeta, Slow_cooker, k6 и Siege. Ими пользуются инженеры из DICE, EA и Buoyant, а также разработчики Kubernetes и Load Impact. Расскажем об этих инструментах.

❓Хочешь стать крутым программистом, но не хватает навыков и знаний?

�� Инновационный центр Ай-Теко проводит набор в школу разработчиков Java и тестировщиков.

Обучение очное, бесплатное, есть стипендия.
По окончании курса ученики, успешно прошедшие тестирование, сразу получают предложение о работе на наших проектах.
Требования: техническое образование (возможно неполное), базовые знания темы и минимальный опыт.
�� Место: Москва, Сколково, Инновационный центр Ай-Теко

���� Узнай подробности и успей зарегистрироваться на курс здесь: https://prglb.ru/4jnk8

Свой успешный бизнес: на чём зарабатывают пользователи Hacker News?
Хотите начать собственный бизнес, но не решаетесь? Держите 7 историй из жизни: пользователи Hacker News делятся секретами успеха и трудностями своего дела.
������

Мастер Йода рекомендует:  Как подключить WordPress к облачным сервисам хранения

Next generation retail на мероприятии X5 Retail Group

21 ноября соберёмся на X5 Tech Future Night, чтобы обсудить настоящее и будущее цифровизации рынка, больших данных и инноваций, проведём анализ различных экспертных подходов, дискуссию о возможностях применения современных технологий в российском ритейле, тематические батлы, а также rock afterparty с голосованием за лучшую музыкальную команду из ведущих цифровых компаний.

Приглашенные теоретики и практики готовы обмениваться деловыми контактами, разбирать кейсы Next Generation Retail, делиться опытом оценки и ведения проектов и вместе с гостями определять тренды цифровизации бизнеса.

8 признаков плохого программиста

Какие качества и профессиональные недоработки отдаляют от работы мечты? Разберемся подробнее, как представители IT-компаний и рекрутеры распознают плохого программиста.


Неумение писать код на листке бумаги

Игорь Зиновьев, технический директор компании «Дисциплина»:

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

«Все виноваты, кроме меня»

Александр Нинбург, генеральный директор сервиса «Нимбл»:

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

Неинтересный рассказ о работе, нежелание самостоятельно искать ответы и неструктурное мышление

Евгений Карюк, исполнительный директор компании «Биплан»:

«Когда специалист не фанатеет от своего дела или без энтузиазма делится всеми деталями, это сразу заметно и говорит о многом. Вряд ли вы потом увидите кропотливую работу над кодом, а следовательно, обрадуетесь его итоговым результатам.

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

Отсутствие самодисциплины

Антон Захаров, технический директор профессионального хостинг-провайдера .masterhost:

«Ключевым в работе программиста является самодисциплина. Регулярность и усердие в работе раскрывают творческий потенциал программиста, а его работу над любым проектом делают предсказуемой. Также ключевым качеством отличающим его от „кодера“, является умение обладать системным мышлением и понимать желание заказчика, находя взаимовыгодные и практичные решения поставленных задач.

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

Впадание в крайности

Николай Степанов, директор департамента разработки ПО «Лестэр ИТ»:

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

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

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

«Не люблю Ruby, на нем пишут только дураки»

Катерина Гаврилова, генеральный директор IT рекрутингового агентства DigitalHR:

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

— не люблю руби, так как на нем пишут дураки — плохо;
— не люблю руби, так как (и говорит что-либо про синтаксис и прочее) — хорошо».

Вывод

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

Будьте хорошими программистами: профессия «Веб-разработчик».

Какие качества и профессиональные недоработки отдаляют от работы мечты? Разберемся подробнее, как представители IT-компаний и рекрутеры распознают плохого программиста.

Неумение писать код на листке бумаги

Игорь Зиновьев, технический директор компании «Дисциплина»:

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

«Все виноваты, кроме меня»

Александр Нинбург, генеральный директор сервиса «Нимбл»:

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

Неинтересный рассказ о работе, нежелание самостоятельно искать ответы и неструктурное мышление

Евгений Карюк, исполнительный директор компании «Биплан»:

«Когда специалист не фанатеет от своего дела или без энтузиазма делится всеми деталями, это сразу заметно и говорит о многом. Вряд ли вы потом увидите кропотливую работу над кодом, а следовательно, обрадуетесь его итоговым результатам.

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

Отсутствие самодисциплины

Антон Захаров, технический директор профессионального хостинг-провайдера .masterhost:


«Ключевым в работе программиста является самодисциплина. Регулярность и усердие в работе раскрывают творческий потенциал программиста, а его работу над любым проектом делают предсказуемой. Также ключевым качеством отличающим его от „кодера“, является умение обладать системным мышлением и понимать желание заказчика, находя взаимовыгодные и практичные решения поставленных задач.

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

Впадание в крайности

Николай Степанов, директор департамента разработки ПО «Лестэр ИТ»:

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

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

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

«Не люблю Ruby, на нем пишут только дураки»

Катерина Гаврилова, генеральный директор IT рекрутингового агентства DigitalHR:

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

— не люблю руби, так как на нем пишут дураки — плохо;
— не люблю руби, так как (и говорит что-либо про синтаксис и прочее) — хорошо».

Вывод

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

Будьте хорошими программистами: профессия «Веб-разработчик».

Как писать ужасный код: делимся опытом

Ну бывает-же такое.

Взято с одного форума :

function IsTrue(Value: boolean): boolean;
begin
if Value <> true then result := false
else if Value <> false then result := true
else // внимание!
result := (not true) and (not false);
end;

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

Ну а строка
result := (not true) and (not false);
возможно говорит просто о ч.ю.


>
> TDelphi © (22.10.09 09:29)
>
> Ну бывает-же такое.

Это шутка чья то, неужели не понятно.

Этот бойян здеся кажный год вываливают.

Skyle © (22.10.09 09:37) [2]
Опередил

TDelphi © (22.10.09 09:29)

Тоже боян, в копилку индусы пишут на Java.
void someFunc(boolean value)<
.
if(String.valueOf(value).Length() == 4)<

Ну а это просто убило )))))))))))))

function IntToMonth(NumberMonth: Integer): string;
begin
сase NumberMonth of
1: Result := «Январь»;
2: Result := «Февраль»;
3: Result := «Март»;
4: Result := «Апрель»;
5: Result := «Май»;
6: Result := «Июнь»;
7: Result := «Июль»;
8: Result := «Август»;
9: Result := «Сентябрь»;
10: Result := «Октябрь»;
11: Result := «Ноябрь»;
12: Result := «Декабрь»;
else
Result := «Август»;
end;
end;

Для этого есть LongMonthNames[Num]

Потому что по здравой логике д.б. быть

else
Result := «Нулябрь»;

else
raise Exception.Create(«Приколись, чувак, мы на Марсе!»);

> TDelphi © (22.10.09 10:26) [10]
> Для этого есть LongMonthNames[Num]

Где названия по-русски, ага. Да еще и индекс контроллируется. Или не контроллируется при непредсказуемых последствиях.
LongMonthNames не эквивалентно. Другое дело эффективность указанного решения.

Твое решение не полно. Как насчет решения вне диапазона 1..12.

И далее
Использование константных строк может дать свои преимущества.

Например сравни надуманный пример

const ArrayA:array[1..12] of string=(«Январь»,»Февраль»,»Март»,»Апрель»,»Май»,»Июнь»,»Июль»,»Август»,»Сентябр ь»,»Октябрь»,»Ноябрь»,»Декабрь»);

procedure TForm2.FormCreate(Sender: TObject);
var a:string;
i:integer;
b,c:dword;

const ArrayA:array[1..12] of string=(«Январь»,»Февраль»,»Март»,»Апрель»,»Май»,»Июнь»,»Июль»,»Август»,»Сентябр ь»,»Октябрь»,»Ноябрь»,»Декабрь»);
begin
b:=GetTickCount;
for I := 0 to 30000000 do a:=ArrayA[1];
b:=GetTickCount-b;
c:=GetTickCount;
for I := 0 to 30000000 do a:=LongMonthNames[1];
c:=GetTickCount-c;
showmessage(inttostr(b)+» «+inttostr(c));
end;

Первоклассный программист должен об этом знать.


> Другое дело эффективность указанного решения.


The LongMonthNames variable provides an array of full string names of the months of the year. Since it is an array, you can update the default values (set by the Windows locale), but this is not advised. Related commands


> Сергей М. © (22.10.09 10:33) [11]
>
> > почему убило?
>
>
> Потому что по здравой логике д.б. быть
>
> else
> Result := «Нулябрь»;
>
> ))

:). Тогда уж внеябрь.

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

form1.Query1.Active:=true;
.
if form1.DBText1.Caption=»1″ then
.

Объясните какие могут быть задачи вне диапазона 1..12 ?

Может я что-то не понимаю? Ну пусть даже 0..11 🙂

> KSergey (22.10.2009 10:40:13) [13]

Решение довольно эффективно, там же case, а смеяться на слове else .

> TDelphi (22.10.2009 10:46:16) [16]

А это ты к чему написал?
Нафига мне немецкие названия?

Например берут разность двух дат. Если разность вне 1..12, то бабки должны вернуть в августе(может у длительных должников бабки только в августе появляются.).

> Anatoly Podgoretsky © (22.10.09 11:12) [20]
> а смеяться на слове else .

Ну а что? кризисный месяц. Логично.

может статься, что вот из-за этого кода он и кризисный 🙂

> KSergey (22.10.2009 11:17:23) [23]

В августе столько дел натворили, одним больше, одним меньше уже ситуацию не изменят.

Путина где-то в августе:)

> Ужасный код

public static string PreparePhoneForSearch(string str)
<
StringBuilder retVal = new StringBuilder(str);
retVal.Replace(» «, «»);
retVal.Replace(«-«, «»);
retVal.Replace(«(«, «»);
retVal.Replace(«)», «»);
retVal.Replace(«+», «»);
retVal.Replace(«.», «»); // как можно быть такими долбоёбами.
return retVal.ToString();
>

> clickmaker © (22.10.09 12:36) [27]

🙂
не сразу въехал


> result := (not true) and (not false);

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

>А это ты к чему написал?
>Нафига мне немецкие названия?

Какие немецкие? Данный массив вернёт название месяца согласно
локализации Windows.

>Например берут разность двух дат. Если разность вне 1..12, то бабки >должны вернуть в августе(может у длительных должников бабки только в >августе появляются.).

Так речь не идёт про :

else
Result := «Август»;

Про сам подход. И почему-то все сразу про диапазон . Ну а так, чем плохо :

function GetMonth (const Num: Integer): string;
begin
if Num in [1..12] then Result := LongMonthNames [Num]
else Result := LongMonthNames [8]; // Марбр 🙂
end;

А про принудительную локализацию в справке написано, я уже про это писал см . [16]

Я приводил пример со скоростью. Выигрышь для константных строк у меня более в 3 раза. Поэтому у того кода, есть также и приимущества, кроме указанных тобою недостатков(отсутствие унификации, и повторная используемость кода).
Я не пытаюсь сделать выводы, о качествах того программиста который написал такой код. Мне лично по этому коду однозначный ответ дать сложно. Обвинять очень просто, а понять гораздо сложнее. 🙂

> TDelphi (23.10.2009 07:00:30) [30]

Вот вот, у меня Немецкая Виндоус, а названия нужны на Русском.

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

Привет.
Я пишу код 5 лет, и меня всегда дико пугает, когда кода становится больше чем 1000 строк.
Как бы я его не разбивал по файлам, классам (структурам). Дошло даже того, что в одном проекте все сделал на микросервисах, от них вообще офигел, они сложность повысили раза в 3.

Речь не про надежность, тесты я пишу. А именно про: «оставить код простым, чтобы куда не сунься, хоп и все понятно, в голову влезло, легко добавить новое.». После 1000 строк у меня код в голову не влазит, начинаю его боятся, филонить.

Пишу на Go, JavaScript.

В энтерпразе не работал, только стартапы, поэтому опыта в этом нет.
Опытные подскажете?

UPD.
Может я конечно код неправильно пишу. Вот мои репозитории

Лучшие ответы:

  • Один класс решает одну конкретную задачу, не стоит городить комбайны. — @jamakasi666
  • Абстрагировать все максимально. — @jamakasi666
  • Число строк одного метода — не более 20. — @karminski
  • Сжатые доки (на русском), как писать чистый javascript код — @BUY33
  • Комменты описывают намерение (зачем?) а не реализацию (как?). — @dmz9
  • Называть переменные и функции так, чтобы и без комментариев было понятно зачем они?

  • Вопрос задан более двух лет назад
  • 10698 просмотров
Мастер Йода рекомендует:  Варианты создания «треугольных» навигационных цепочек

если вы боитесь кода то этому могут быть 2 причины: а) лень читать/разбиратся в чужом/своем коде б) сложно читать/разбиратся в чужом/своем коде

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

Ну в общем-то ответов много. Могу кое-что добавить от себя.

Во-первых, голова не бесконечна во всех смыслах. Запихнуть в неё больше чем 10 объектов одновременно вряд ли получится, у многих начинаются огромные проблемы уже с 5. Лично я испытываю ДИКУЮ больше если собственный код становится больше чем большой. Для меня это где-то 15

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

Во-вторых, не стоит делать код пушистым. Однообразность воспринимается лучше. Массивы некоторых объектов надо называть $названием_объекта + ‘s’. Классы с большой буквы, любой объект стоит называть так же, как класс, но с маленькой буквы. Конечно, если семантически прям просится по другому, то стоит правило нарушить, но в общем случае никаких выдумок не надо. Временная строка — str, временное число — tmp, временный объект — obj. И пробелов не жалей, внутри файла разделяй разные структуры двумя-тремя пробелами, стоит обособлять регионы, например, «глобальные» функции наверху, по середине структуры, потом классы. В C# есть #region.

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

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

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

Пример немного утрирован, но суть, навроде, ясна. Не надо наследовать всё и вся от чего угодно, если есть возможность включить внутрь — включай. Всё остальное от лукавого и только в крайних случаях.

В-шестых, используй UML, mind maps, блокнот и таск менеджеры. Эти инструменты словно манна небесная спасают дедлайны от полного уничтожения. Хотя UML спорен, им очень удобно следить за структурой проекта, представлять картину с высока, рисовать его стоит самому, учитывая неявные связи и убирая рудиментарные. Mind maps помогут собрать мысли в кучу. Блокнот банально запишит то, что постоянно забывается. Таск менеджеры сформируют привычный график, отобразят прогресс, помогут фокусироваться на текущих задачах, не растекаясь по проекту.

В-седьмых, изучи декларативное программирование. Шикарная вещь, которая позволяет сконцентрироваться на задаче, а не на решении. Из коробки в функциональных (erlang) и логических (prolog) языках, однако многие элементы существуют и в монстрах вроде C#/Java, Python, особенно JavaScript. Насчёт Go не знаю, но на первый взгляд весьма декларативный.

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

Ещё пара абзацев. Ну про вредные советы: методы надо делать ровно такими, какие они должны быть. 20 строк — это что-то вроде лакмусовой бумажки, однако это лишь один из параметров. Очень часто требуется сделать громадную функцию для работы со сложным API или подробить много разных чисел в циклах. Поэтому ориентироваться на это плохая идея. Равно как и папки-подпапки-подпапками погоняемы, максимум — два уровня в чрезвычайно сложных проектах. Иначе будет очень сложно ориентироваться. Ещё происходит странный возврат к комментариям. На мой взгляд, если это не продаваемая за большие деньги библиотека — нах*й надо. Документация в комментариях — рудимент кода, он нигде не используется, зато требует поддержки, на что приходится распылять внимание. Если нет условного рефлекса править комментарий после кода — выбрасывайте и не жалейте. Везде! Без исключений. Ещё есть много «архитектурных» паттернов. Снова вред, если вы не работаете в Google, где вашу зарплату надо оправдать умными словами. Самый эффективный способ — программировать наивно. Чем проще для вас сейчас, тем лучше для вас потом. Если думаете больше десяти минут — плохо думаете. Но об этом позже. Паттерны это некая систематизация неких знаний, причём совершенно не понимаю, зачем её вообще сделали. Да, архитектура в некотором роде нужна, но постоянно искать какой паттерн здесь надо использовать, если это не проект на 100500 лет вперёд — нельзя. Почти всегда будет дешевле в случае неуспеха отрефакторить всё и вся, чем переписывать с нуля или тратить месяцы на продумывание архитектуры. В которой также могут быть ошибки.

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

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

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

Nastya Nikolaeva

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

Илья Щуров

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

16 советов копирайтеру: как написать хороший текст

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

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

Мастер Йода рекомендует:  Ближе к земле Python и низкоуровненые операции

1. Задевайте за живое

Самое главное — найти то, что «зацепит» человека. Людей не волнуют мировые проблемы, им важно, что происходит у них дома. Вот и выступите в роли детектива: найдите эти животрепещущие темы.

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

2. Придерживайтесь темы

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

Маркетолог Райан Бокрос считает: «Контент должен иметь отношение к определенной теме и развивать ее. Нет более верного способа все испортить, чем распыляться на десять запутанных тем, пытаясь охватить их одновременно. Я скорее выберу меньший по объему и более конкретный контент, способный удерживать внимание, чем объемное смысловое месиво, от которого хочется бежать».

ТОП-100 лучших SEO-агентств России 2020

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

Ответ – в свежем рейтинге SEO-компаний за 2020 год по версии RUWARD.

3. Не бойтесь цитировать других

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

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

4. Обращайтесь к сердцу

Люди выбирают того, кто понравился, того, кто симпатичен, то есть, как в предвыборном слогане, «голосуют сердцем». «Хочу» возникает внутри нас раньше, чем мы успеваем взвесить все за и против. Голова лишь откликается на это «хочу», пытаясь его оправдать. Именно поэтому так важно достучаться до сердца.

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

5. Не жалейте слов: делайте подробные описания и фото

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

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

Ведущий гастрономической колонки в Los Angeles Times отзывается об этом блоге следующим образом: «В начале каждой статьи излагается ее суть, затем следует сам обзор, обильно снабженный иллюстрациями, каждую фотографию сопровождает описание. Все это располагает читателей к тому, чтобы сесть поудобнее и неторопливо поедать взглядом всю статью, наслаждаясь каждым „кусочком“».

6. Приглашайте к диалогу

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

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

7. Утоляйте информационный голод читателей

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

«Для меня хороший контент полностью соответствует интересам аудитории, — говорит Кармен Портела. Если ваша целевая аудитория — отцы, необходимо создавать контент, который представляет интерес для большинства отцов».

8. «Упаковывайте» контент красиво

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

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

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


9. Сделайте текст инструментом передачи знаний

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

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

10. Ищите истории успеха

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

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

11. Не торопитесь: первый не значит лучший

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

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

12. Избегайте канцелярита

Это должно стать аксиомой. Никаких сложных зубодробительных формулировок — общайтесь с читателями на нормальном языке, не пытаясь поразить их воображение замысловатыми лингвистическими фортелями. Нора Галь в своей книге «Слово живое и мертвое» очень точно выразилась.

«Берегись канцелярита! Это — самая распространенная, самая злокачественная болезнь нашей речи. Много лет назад один из самых образованных и разносторонних людей нашего века, редкостный знаток русского языка и чудодей слова Корней Иванович Чуковский заклеймил ее точным, убийственным названием. Статья его так и называлась „Канцелярит“ и прозвучала она поистине как SOS. Не решаюсь сказать, что то был глас вопиющего в пустыне: к счастью, есть рыцари, которые, не щадя сил, сражаются за честь Слова. Но, увы, надо смотреть правде в глаза: канцелярит не сдается, он наступает, ширится».

Незабвенная Нора Галь, — источник

13. Не бойтесь делиться опытом

Пишите статьи, которые действительно дают полезную информацию. Помогают читателю. Объясняют, как делать то или иное. Раскрывают понятия и принципы. Делятся чем-то нужным и учат чему-то полезному.

Саша Карепина объясняет: «Казалось бы, обучая своих потенциальных клиентов,вы рубите сук, на котором сидите. Ведь если они научатся, то ваши консультации станут им не нужны. Они будут все уметь сами! И потом, отдавать информацию бесплатно попросту жаль. Обучение стоит денег, а тут получается — на тебе на блюдечке все задарма! Именно так мы зачастую думаем и оказываемся неправы!

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

14. «Одевайте» тест в цифры

Большинство текстов, призванных рассказать о компании, продуктах или сервисах, написаны одинаково: общими словами описан профессионализм, индивидуальный подход и всевозможная крутость. Но это же может оказаться выдумкой. С чего читателю вам верить? Может быть, вы только что это выдумали. Цифры и факты — вот доказательство. И признак качественного контента.

Известный копирайтер Денис Каплунов делится опытом: «Один из сильных аргументов, которые я использую в подобных текстах, — прием „компания в цифрах“. Это нумерованный (или маркированный) список, в котором компания представлена не столько словами, сколько цифрами и точными данными.

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

  • Специализация — квартиры на вторичном рынке стоимостью от 4 миллионов рублей.
  • Количество заключенных сделок — 232 (покупка — 83, продажа — 149).
  • Максимальная сумма сделки — $4 320 000.
  • Максимально быстро проданная квартира — за 1 день (причем продана на 300 000 рублей выше желаемой цены).
  • Максимально быстро найденная квартира по четким указаниям покупателя — 2 дня.
  • Общая сумма проведенных сделок — 1 512 960 000 рублей.
  • Стаж — с 2006 года.

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

15. Употребляйте меньше «лишних» слов

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

Сравните: «Если зубы здоровы, то целоваться приятно!» и «Зубы здоровы — целоваться приятно!» Сравните: «Чистые зубы — это хорошо!» и «Чистые зубы? Хорошо!» Что вам больше нравится?

16. Не пишите текст ради текста

В последнее время популярно «правило чистого листа»: если нет вдохновения, просто начните писать. Лучше пользоваться правилом «мысли по делу» (честно говоря, я его только что придумала, но не суть). Сначала подумать, а потом уже сделать. Вот что на этот счет думает журналист и автор учебных программ по писательскому мастерству Ольга Соломатина.

«Представьте себе, что завтра утром вы встанете в 4:30, быстро соберетесь, прихватите чемодан с вещами, вызовете такси. Вы выйдете на улицу, сядете в машину и скажете водителю: „Я отправляюсь в путешествие. Оно будет захватывающе интересным, но я еще точно не знаю, куда еду“.

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

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

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

Только для читателей Cossa — скидка 50% на электронные книги из этой статьи. Промокод: 0307mif.

Действует до завтра, 4 июля, 23:59 (мск).

Почему «Делиться своим опытом» лучше, чем «Давать совет»?

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

Но сначала хотелось бы коснуться значения фраз: «давать совет» и «делиться своим опытом».

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

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

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

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

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

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

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

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

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

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

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

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

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