Какие ошибки никогда не стоит совершать программистам?
5 ошибок, которые могут помешать вам стать программистом
Привет! Собрал некоторые очевидные и не очень ошибки начинающих программистов. Это модели поведения и ложные представления, которые могут или вообще закрыть вам дорогу в программирование, или, по крайней мере, растянуть этот путь на много лет. Статья предназначена в первую очередь для новичков.
Розовые очки
У многих людей, которые только услышали об IT и загорелись желанием туда войти, сформировано неверное представление об этой сфере и специфике работы. Во многом в этом виноваты продающие страницы курсов по программированию, основная цель которых зачастую – убедить вас, что нужно только отправить деньги за обучение, все остальное за вас сделают умные наставники, и вот уже скоро вы начнете работать мега-программистом и Яндекс с Гуглом будут за вас сражаться. Конечно же это вранье.
Первым делом нужно осознать, что за вас никто ничего делать не будет. И что получить эту профессию очень и очень непросто. И чем больше вам лет, чем дальше ваша текущая профессия, образование и интересы от IT сферы, тем сложнее (и дольше) вам будет переучиваться. Поэтому будьте готовы к упорному труду. За месяц изучить программирование не выйдет. Придется учиться практически ежедневно на протяжении всей дальнейшей жизни. Обходных путей и каких-то тайных знаний тут не существует.
Нереальные/неконтролируемые цели
Цель «Стать программистом» – очень большая и серьезная. Типичный «слон». А значит, есть его надо по кусочкам. Эту цель не взять с наскока. Будут дни, когда вы будете впадать в депрессию из-за того, что результатов нет, вы весь день промучились с какой-нибудь задачкой, которую так и не получилось решить. Рассылаете свое резюме джуниор-программиста, а в ответ тишина. В такие моменты очень легко потерять мотивацию, разочароваться, сменить направление деятельности.
Чтобы поддерживать себя в мотивированном состоянии и плодотворно учиться, стоит ставить себе контролируемые цели. Например, учиться программировать каждый день минимум по 2 часа (этого мало, если вы хотите получить быстрый результат, но это гораздо лучше чем три дня по 8 часов, а потом забросить на 2 недели). Можно разбить эти 2 часа на 4 «помидорки» по полчаса в течение дня. (гуглите «техника Помодоро») Еще лучше – если вы распишете, что конкретно будете делать, например заниматься на Хекслете, или по какой-то конкретной книге. В этом случае, если вам удастся придерживаться этого графика, вы 100% будете двигаться вперед.
И каких-то самокопаний, неуверенности в себе будет в разы меньше, чем если поставить себе цель через месяц устроиться на работу программистом и с треском ее провалить. Это еще такая психологическая хитрость, если у вас небольшая четкая цель и вы день за днем ее выполняете, то уверенность в себе (и в нашем случае, умение программировать) будет только расти.
Читайте также
Зубрежка функций
Иногда люди думают, что главная (и единственная) их задача – это изучить сам язык программирования. Из этого заблуждения, кстати, вытекает еще одна ошибка. Тратить бесконечно много времени на попытки «с дивана» выяснить какой язык лучше.
Типа: Ой, Руби классный. Ой нет, Руби умирает, вот Питон супер, его рекомендовали в какой-то статье которую я краем глаза читал. А пхп так вообще ужас, да и к тому же полумертв. О, так джависты оказывается получают в 5 раз больше других программистов, мне срочно нужна Java! И так далее. Эти попытки разобраться какой язык лучше занимают уйму времени и плодят сотни новых вопросов на тостерах.
Какое занятие может быть еще бесполезнее? Это не выучив даже синтаксиса языка, до посинения читать форумы и пытаться разобраться, что же блин лучше React или Ангуляр.
На что лучше потратить это время? На изучение фундаментальных вещей, которые обязательно вам пригодятся, и которые должен знать любой профессиональный программист. Принципы работы операционных систем, структуры данных, алгоритмы, математика и т.п. Причем, не надо ждать собеседований, эти вещи стоит начать подтягивать уже с самых первых дней. Поверьте, все это вам очень пригодится и сыграет на руку при трудоустройстве и сильно ускорит ваш рост.
Дети Ютуба
Где брать эти знания? Кроме очевидного -Youtube, Coursera, Stepic, Openedu, курсы Хекслета, стоит начать активно читать книги (бумажные или электронные – разницы нет). Видеокурсы все больше движутся в направлении развлечений, народ хочет зрелищ. (и хлеба в виде больших зарплат). А скучать никто не хочет. Под видео часто можно видеть отзывы типа “Скучно! Монотонно!”. Людей приучают развлекаться, и они постепенно привыкают. А ведь обучение по книге гораздо более эффективно, потому что информация в книге сконцентрирована, а в видео наоборот, размазана, чтобы было подольше да повеселее.
Однако не зря говорят: «У бедных людей большие телевизоры, а у богатых большие библиотеки». Поэтому, читайте больше, друзья. Даже 3 хороших книги уже вас прокачают. И если вы решили изучать программирование, то очень советуем вам вдобавок к любым курсам и менторам с первых дней начинать читать книги.
Что именно читать? Смотрите здесь, в книжной подборке Хекслета.
Перфекционизм
Некоторые хотят выучить все идеально, даже и не приступая к реальным проектам. Чтобы не дай бог где-то не ошибиться, не показать себя глупым. Грубо говоря, хотят стать senior программистом, еще перед трудоустройством. Им всегда кажется, что они знают мало, нужно еще, еще, еще. Еще чуть-чуть подготовиться, тогда можно и сходить на собеседование. Наверняка, это явление исследовано вдоль и поперек всякими мощными психологами. Мне кажется, здесь основной страх один – показаться плохим(неумелым) перед какими-то людьми, мнение которых для тебя важно.
Реальность же такова, что практически невозможно к чему-то подготовиться «с дивана». Нельзя научиться драться по книгам, невозможно на 100% подготовиться к собеседованиям, не посетив ни одного. Стоит принять для себя, что неудачи это просто опыт. Конечно, сложно сломать устоявшиеся привычки за один раз, но пробуйте разрешать себе ошибаться, хотя бы в мелочах. Не бойтесь показаться глупыми. Не бойтесь ошибок, не бойтесь отказов, не бойтесь неудач – это путь к лучшей жизни.
Ладно это все общая болтовня, а вот конкретный совет. Если вы уже хотя бы несколько месяцев занимаетесь программированием, начинайте составлять резюме, читайте статью про алгоритм поиска работы и вперед!:)
Спасибо за то, что дочитали до конца и удачи во всех начинаниях!
А если вы уже готовы учиться, начните изучать разработку с бесплатного курса «Основы современной вёрстки». Вы научитесь создавать статические веб-страницы, стилизовать элементы, использовать редакторы кода с полезными расширениями. В конце курса вы опубликуете свой первый сайт на GitHub Pages.
Soft, интернет, безопасность: новости, статьи, советы, работа
Избранное сообщение
Фетісов В. С. Комп’ютерні технології в тестуванні. Навчально-методичний посібник. 2-ге видання, перероблене та доповнене / Мои публикации
В 10-х годах я принимал участие в программе Европейского Союза Tempus “Освітні вимірювання, адаптовані до стандартів ЄС”. В рамк.
среда, 25 января 2017 г.
Какие ошибки никогда не стоит совершать программистам? / Начинающему программисту
- Не внедрять новые элементы в пятницу (особенно после длинной рабочей недели).
- Всегда четко осознавать риски, которые могут повлечь неполадки в новых элементах.
- Всегда проверять и убеждаться, что код работает как и ожидалось.
- Но, самое главное: не бояться, а действовать быстро и совершать ошибки.
Самая большая ошибка, которую постоянно совершают новички-программисты, заключается в том, что они считают, что все знают о программировании.
Программирование похоже на английский, на поэзию, на искусство. Да, иногда встречаются гении-самородки, но вы вряд ли к ним относитесь. Что касается всех остальных, мы ищем пути отточить свое мастерство в течение жизни.
Когда мы только начинаем, мы похожи на младенцев, которые учатся ходить. Мы знаем, как совершить несколько шагов, мы способны ухватиться за что-нибудь и радостно взирать на свои достижения. Но мы многого не умеем.
Если мы просто подождем, подучимся и подрастем, мы станем взрослыми, и только тогда начнется настоящее обучение. Стать великолепным программистом – это посвятить свою жизнь оттачиванию навыков написания великолепного программного обеспечения.
Самая большая ошибка новичка – это думать, что вы что-то знаете, отвергать обучение, не просить более опытных людей взглянуть на ваш код, предполагать, что если какой-то чувак седой и не знает вашего замысловатого модного языка, его опыт не имеет значения. Самая большая ошибка новичка – не искать обзоры кодов от лучших программистов, не читать свой код, не критиковать себя, не ждать ответной реакции, не принимать ее к сведению.
Все остальное, и я действительно имею в виду все – просто шум. Любую ошибку, за исключением необоснованного высокомерия молодости и неопытности, можно исправить.
Многие программисты бездумно оптимизируют свои программы не особо понимая, зачем это вообще необходимо. Во многих случаях они проводят оптимизацию там, где этого не следует делать, тем самым получая менее читабельный код.
Опытные программисты знают, когда и как следует дорабатывать код, потому что они наверняка делают это не в первый раз. И ранее сталкивались с возникающими после оптимизации проблемами производительности.
Главная причина, почему стоит сосредоточиться на читаемости кода, состоит в том, что программы-компиляторы достаточно умны. В таких программах есть оптимизаторы, которые могут обнаруживать весьма специфические кодовые последовательности и автоматически их упрощать/оптимизировать.
Поэтому не стоит сосредотачиваться на фокусах с переменной, удаляя пустые линии или стремясь убрать одну из переменных, в то время, как с двумя переменными код был бы более легким для чтения.
Оптимизировать код, не особенно понимая, что делаешь, свойственно новичкам.
Многие опытные программисты могут рассказать страшные истории о проведении интеграции, после которой некоторые модули или подсистемы начали вести себя очень медленно… Такое воздействие на производительность в некоторых случаях может быть совершенно непредсказуемым до того момента, пока вы не введете систему в эксплуатацию.
Если вы видите или чувствуете какие-либо проблемы с производительностью, то это именно то, что действительно стоит оптимизировать. Выявите и проанализируйте все возможные проблемные места, после чего исправьте их.
Избавление именно от таких неприятных интеграционных проблем, а также жалобы на то, что многие компании делают крайне медленное программное обеспечение, является признаком опытного программиста.
50 серьезных ошибок в программировании и дизайне, которые стоили жизней, времени и денег. Часть 1
Когда-то я заинтересовался вопросом ответственности в IT. К финансовым потерям мы уже привыкли. Не проданный продукт, ошибка в расчете и недовольный клиент — это те последствия, о которых мы в курсе. Но что, если наши ошибки приведут к непоправимым последствиям. Я несколько раз читал лекции на тему ошибок в программировании, которые привели к человеческим жертвам.
1. Элаи Херцберг попала в историю как первый человек, который погиб под колесами беспилотного автомобиля. Весной 2018 года в темное время суток машина Uber засекла преграду. В начале она подумала, что это мусор, потом — что животное, и только за пару метров поняла, что это человек.
К сожалению, машина не успела затормозить, что привело к смерти человека. Тестирование проходило на модифицированной Volvo XC90, у которой была отключена система экстренного торможения, чтобы не мешать ПО Uber управлять машиной. Не может быть два короля в одном королевстве. Задача тормозить в экстренных случаях была возложена на плечи водителя, который страховал автопилот. Он же в это время смотрел Netflix.
2. Аппарат Therac-25 стал самым резонансным случаем в истории программирования для медицинских девайсов. В силу ошибки race condition, при быстром переключении между магнитным и рентгеновским режимами работы девайса заслонка для рентгеновских лучей не успевала установиться. Из-за этого у 10 пациентов диагностировали лучевую болезнь, что привело к смерти или ампутации пораженных частей тела.
3. 25 февраля 1991 года установка ПВО Patriot не смогла перехватить ракету, пущенную со стороны сил Саддама Хусейна. Ракета попала в барак солдат США, что привело к 28 смертям. Расследование показало, что 24-битные процессоры перехватчика при переводе времени совершают ошибку в 0.013 секунды каждый час. Patriot не перезагружали более 100 часов, что привело к ошибкам вычисления положения ракеты на 600 метров. Вот уж где перезагрузка спасла бы жизни.
4. В 2016 году актер Антон Ельчин был раздавлен собственной машиной при въезде домой. Антон многим запомнился как актер, сыгравший навигатора Чехова в полнометражках «Start Trek». Причиной смерти послужил не интуитивный дизайн ручки передач, представленный Jeep в новых моделях машин.
В отличие от стандартных ручек передач, где положение ручки показывает режим работы двигателя, у новых ручек местоположение выбиралось скорее как рычажок в меню. Антон вместо паркинга выбрал нейтральное положение, от чего машина скатилась и задавила невнимательного хозяина.
5. В 1992 году ошибки системы распределения маршрутов в Лондонской скорой помощи привели к смерти 30-45 человек (разброс большой, потому что не ясно, смогла бы скорая спасти того или иного человека). Все произошло, когда в Лондоне решили заменить людей операторов на компьютерную систему.
В результате система была введена в эксплуатацию без нагрузочного тестирования и с 81! известным багом. Добавьте к этому еще и то, что интегратор решил сэкономить и купил дешевое оборудование, которое сломалось через пару часов после активного пользования системой. Хаос был настолько безумным, что бывали случаи, когда человек, не дождавшись скорой, умирал, его увозили в морг, и только тогда приезжала скорая.
6. 1979 год. Пенсильвания чуть не стала еще одним Чернобылем, и это самый большой прецедент в истории атомной энергетики США. Внешний дизайн датчиков системы там был очень плохо продуман и был расположен по кругу комнаты. Смена, которая следила за состоянием, не заметила всех показателей, которые указывали на то, что есть утечка, и значение температуры реактора приблизилось к критическому значению. Ситуацию спасла следующая смена, которая выходила на вахту и начинала считывать показания датчиков.
Чтоб считать показатели, надо было пройти по круглой комнате и отдельно смотреть на каждый показатель во многих разных местах. Утечку нашли, реактор отключили, но еще 14 лет проводили работы по очищению территории. Это стало поводом огромных протестных митингов и очень поменяло общественное мнение про «мирный атом».
7. 1992 год, самолет под управлением опытной команды потерпел крушение возле Страсбурга. 87 из 92 человек погибли. Анализ черного ящика показал, что опытные пилоты перепутали настройки автопилота: угол и скорость снижения.
Дизайнер приборной панели очень стремился сэкономить место и расположил эти два индикатора друг возле друга. При том, что даже не смотря на то, что единицы измерения совершенно разные (пилоты хотели задать 3.3 градуса спуска, а задали 3300 футов в минуту). Но для экономии места оба показателя показывались как 3.3. Кому в голову придет показывать 3300 как 33?
8. Моя любимая история. Станислав Петров в 1983 году спас мир, не сделав ничего. Во время разгара холодной войны между США и СССР он служил в штабе антиракетной обороны. Так как две страны обладали атомным оружием, между ними была заключена доктрина взаимного гарантированного уничтожения. Это значило, что как только одна ракета полетит со стороны одной страны в другую, другая может ответить, как хочет. Грубо говоря — начало третьей мировой.
Станислав Петров в 1983 году как раз наблюдал за системой раннего обнаружения ракетного удара. И как же он удивился, когда увидел на экране 5 ракет, которые летели со стороны США в сторону СССР. По всем правилам Петров должен был отдать указания полномасштабного ракетного удара по США. Но, как он сказал: «У него была чуйка». Он предположил, что нападать на СССР всего лишь 5 ракетами — не логично, и решил подождать. Внезапно ракеты пропали, он сделал рапорт.
Расследование определило, что эти 5 ракет — edge case того, как лучи солнца падают на спутник на орбите Молния. Таким образом, Петров, не сделав ничего, подарил нам с вами мир, в котором мы живем. Хотя злые языки говорят, что он тогда был в стельку пьян. Но это не отменяет того, что даже будучи пьяным, ты можешь спасти миллиарды людей.
9. Пациентка Jenny (имя заменено в отчетах) погибла от обезвоживания после химиотерапии. Причина оказалась до ужаса идиотской. Дизайн медицинской системы был настолько плох, что опытные медсестры просто не заметили пункта, который говорил, что для этого пациента необходимо вводить дополнительные элементы сразу после операции.
10. Шестеро велосипедистов сошли с дистанции гонки в Осло в 2014 году. Оказалось, что велосипедисты выпили жидкость для мытья пола, решив, что это энергетик. Дизайн упаковки тоже имеет значение.
11. Два солдата армии США погибли во время учений артиллерийских подразделений. Солдаты понадеялись на данные тактической системы, но не знали, что, если не задать высоту цели — система считает ее равной 0. Вот тебе и рокетджамп.
12. 1994 год, борт авиакомпании China Airlines потерпел крушение и унес жизни более чем 250 человек. При приземлении второй пилот случайно включил автопилот, который начал вносить коррективы в действия пилотов. При снижении пилоты заметили это и смогли выключить автопилот, но, к сожалению, рассинхронизация действий людей и автопилота привела к крушению. При расследовании также была найдена ошибка, патч для которой уже был написан. Борт, потерпевший крушение, был запланирован на апдейт системы сразу после окончания рейса, который, к сожалению, так и не закончился удачно.
13. Knight Capital в свое время перепутали деплои и вместо тестового енва задеплоили новую версию на продакшен. Система думала, что тратятся виртуальные доллары, а на самом деле Knight потеряла 460 миллионов долларов за 45 минут. Скидывались на спасение Knight всем селом.
14. 2015 год, грузовой самолет испанских военно-воздушных сил потерпел крушение около Севильи. Авария была вызвана ошибкой ПО и унесла жизни 4 человек. Airbus после этого случая отозвала все самолеты A400 на проверку. Проблема заключалась в новой версии софта по контролю топлива в двигателях. Система подавала топливо, но очень медленно, от чего 3 из 4 двигателей отключились.
15. 1998 год, один из спутников Nasa, отправленный на Марс, достиг орбиты красной планеты и взорвался. Была ошибка в двух модулях ПО спутника: один ждал данные в метрической системе, а другой отдавал в имперской 🙂 Не додебажили на 327 лямов.
16. Как рассказывает SIG, один из самолетов F-14 разбился вследствие того, что случилась системная ошибка, но программист не обернул ее в catch. Это привело к полному отключению бортового компьютера. Пилот катапультировался, но самолет, конечно же, не спасли.
17. Кибервойна, или взрыв, который было видно из космоса. В 1982 ЦРУ внедрило шпиона в канадскую фирму по разработке софта для газопроводных систем, потому как знало, что этот софт будет использован СССР. Программист-шпион написал методы, из-за которых в 1982 году газопроводная труба взорвалась так сильно, что взрыв можно было наблюдать из космоса. К счастью, никто кроме оленей не пострадал.
18. Новая, в 1996 году, ракета Ariane 5, разработка которой стоила около 8! миллиардов долларов, должна была вывести на орбиту несколько спутников и другое оборудование. Полет ракеты завершился через 4 секунды после взлета. Она взорвалась. Один из модулей системы попытался сконвертировать 64-битное число в 16-битное. Оно оказалось больше, чем влезало в память, и модуль завалился. Но ведь есть дублирующий модуль, которому было передано управление! На нем была та же версия ПО, которая попытался сделать то же самое. Результат — самоликвидация и горящие осколки на площади в 12 км2 на потеху зрителям. Во время расследования инцидента была проведена симуляция полета Ariane 5 с использованием другой инерциальной платформы — баг воспроизвели. Программа сбойнула точь-в-точь как в случае с реальной ракетой.
С одной стороны, причиной сбоя можно назвать оптимизацию кода, который не проверял допустимые значения для той конкретной переменной — программисты не предполагали, что число, описывающее горизонтальную скорость, может быть настолько великим.
С другой стороны, провинились и тестировщики — хоть и были произведены сотни тестов и тысячи последующих корректировок, никто не сделал полноценного анализа опорной инерциальной системы. Проблема была в том, что на Ariane 5, чья траектория полета сильно отличалась от Ariane 4, поставили навигационный софт от Ariane 4. Тот случай, когда железо проапгрейдили, а софтину обновить забыли.
