Избранное сообщение

Фетісов В. С. Комп’ютерні технології в тестуванні. Навчально-методичний посібник. 2-ге видання, перероблене та доповнене / Мои публикации

В 10-х годах я принимал участие в программе Европейского Союза Tempus "Освітні вимірювання, адаптовані до стандартів ЄС". В рамк...

Благодаря Интернету количество писателей и поэтов увеличивается в геометрической прогрессии. Поголовье читателей начинает заметно отставать.

среда, 25 января 2017 г.

Какие ошибки никогда не стоит совершать программистам? / Начинающему программисту

Какие ошибки никогда не стоит совершать программистам? На этот вопрос попробовали ответить опытные пользователи сайта Quora. KV.by расскажет о самых интересных и полезных советах.

Кен Мазаика, технический директор, соучредитель и наставник thefirehoseproject.com
Я совершил ошибку, которая стоила моей компании более 10 000 долларов.
Давайте отмотаем назад. Раньше я чувствовал себя непобедимым программистом - и, как следствие, был немного эгоистом. Мне следовало бы проверять себя. Однако ошибка помогла мне вырасти, стать более умным и скромным разработчиком.
Я был молод, голоден и горел желанием что-то изменить, чтобы доказать свою ценность. Как и большинство разработчиков, я присоединился к небольшой команде. Благодаря усердной, почти круглосуточной работе, я добился руководства одним небольшим проектом, который быстро превратился для моей компании в серьезный источник дохода.
Несмотря на свою неопытность, я пытался делать все возможное для того, чтобы быстро и эффективно вносить поправки в код, когда бы об этом не попросили. События развивались быстро. И со своим весьма небольшим опытом работы с фреймворком Ruby on Rails я не имел ни малейшего понятия, как правильно вносить эти изменения.
Код был написан, мягко говоря, ужасно, но все работало. Итак, я кодировал как "ковбой", что позволяло моей команде продвигаться очень быстрыми темпами. У меня не было никакого тестирования неисправностей, но мой босс, который вероятно должен был знать лучше, не заботился об этом.
Все было идеально. Но потом случилось нечто ужасное. В пятницу поздно вечером я внедрял один элемент. Все в компании с нетерпением ожидали первых результатов тестирования в следующий вторник (понедельник был выходным). В понедельник утром я проверил электронную почту и обнаружил там несколько странных цепочек писем.
Я стал собирать все воедино и вскоре понял, что полностью лишил возможности пользоваться приложением огромное количество пользователей. Наша компания очень сильно зависела от управления данными, и у меня не заняло много времени, чтобы понять, что моя ошибка стоила компании более 10 000 долларов.
На следующее утро я первым делом извинился перед боссом... и сразу спросил, уволят ли меня. Недолго думая, он ответил фразой из одной известной городской байки: "С чего это мы должны тебя увольнять? Мы только что потратили 10 000 долларов на твое обучение".
Итак, в чем состояло это обучение? У ошибок всегда бывают последствия. Бывает, что из-за них компания теряет клиентов, деньги и авторитет. Но есть одна вещь хуже совершенной ошибки ‑ это решение никогда не брать на себя работу, которая может привести к совершению этой ошибки. Возникает риск срыва внедрения инноваций и обучения, а давать возможность конкурентам развиваться быстрее тебя куда более опасен.
Я уверен, мой босс знал, что я рано или поздно совершу какую-нибудь ошибку. Я был молод, неопытен и на меня свалилось больше ответственности, чем было мне по силам. Но работа в такой ненадежной манере позволила мне и нашей команде продвигаться невероятно быстрыми темпами... всего лишь ценой возникновения неполадок, которые я в конечном счете и вызвал.
За 9 месяцев работы в этой компании я научился большему, чем за всю свою последующую карьеру. Благодаря этому огромному провалу я усвоил уроки, которые со временем усваивают все ведущие разработчики:
  • Не внедрять новые элементы в пятницу (особенно после длинной рабочей недели).
  • Всегда четко осознавать риски, которые могут повлечь неполадки в новых элементах.
  • Всегда проверять и убеждаться, что код работает как и ожидалось.
  • Но, самое главное: не бояться, а действовать быстро и совершать ошибки.
Существует причина, по которой эта фраза была "мантрой" Facebook на протяжении многих лет. В большинстве профессий ошибки указывают на беспечность. Но что касается программного обеспечения, ошибки в вычислении приемлемы. Ведущие разработчики уже совершали те же ошибки, которые наверняка совершите вы.
Никогда не бойтесь браться за работу, при выполнение которой могут возникнуть ошибки. До тех пор, пока риск того стоит. Только так можно стать лучшим разработчиком.

Брайан Кнэпп, христианин, автор "Творческого гения"
Новички-программисты в современную эпоху программирования имеют тенденцию совершать такие ошибки, на исправление которых у них могут уйти годы, и многие на этом ломаются.
Я бы назвал это проблемой идентичности, заключающейся в том, что человек работает  разработчиком, а не "решателем" проблем или создателем ценностей. В какой-то момент это случается с каждыми языком, набором инструментов, платформой, фреймворком и т.д.
Представьте, что кто-то, кто не разбирается в программировании, решает, что он(а) хочет стать разработчиком программного обеспечения. Они выходят в интернет и находят курсы, на которых обучают написанию кодов на Ruby on Rails. Они изучают достаточно, для того чтобы быть в состоянии создать программное обеспечение, используя Rails. И теперь они "Rails-разработчики". В этом и заключается проблема, но она пока не бросается в глаза.
Будучи Rails-разработчиком, человек изучает его тщательнее, совершенствует свои навыки. И каждый раз, когда в Rails появляется что-то новое, он(а) изучает это, а значит - становится лучше. И это прекрасно, какое-то время.
Но потом компания решает, что они хотят создать свое приложение в Ember.js или React. Вдруг все эти знания по Rails оказываются не такими уж ценными. И у Rails-разработчика остается всего несколько вариантов: переквалифицироваться в Ember- или React-разработчика, остаться Rails-разработчиком в той же компании, в то время как работа будет становиться все менее значимой, или перейти работать с Rails в другое место.
Многие люди предпочтут покинуть во всех прочих отношениях хорошую работу, чтобы сохранить свою идентичность в качестве Rails-разработчика. Некоторые останутся и будут жаловаться все время, пока будут чувствовать себя несчастными на своей работе. Некоторые изменят свои убеждения относительно самих себя и своего набора навыков для того, чтобы освоить новый язык и приобрести новую идентичность.
Каждый из этих вариантов является разумным. Но существует совершенно другой вариант.
Некоторые разработчики никогда не идентифицируют себя с каким-либо языком, фреймворком или набором инструментов. Они могут создать практически что угодно и на чем угодно, так как они не создают программное обеспечение на Rails, они решают проблемы и разрабатывают ценные вещи, которые можно использовать на Rails.
Для разработчика такого рода Rails будет лишь инструментом. Важным инструментом, но не более важным, чем та проблема, которую он(а) решает или ценность, которую он(а) разрабатывает.
Я считаю, что неопытные разработчики, которые отождествляют себя с теми инструментами, которыми они владеют, ошибаются. Иногда случается так, что они так и не оправляются от этой ошибки.

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

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

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

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

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

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

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

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

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

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

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

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

Маркс Милгром, запускает системы и управляет ими почти 20 лет
Я не знаю, касается ли это только неопытных программистов, но именно они точно более восприимчивы к заданным при вводе информации допущениям, при этом не сильно задумываются об экстремальных случаях и способах защиты от них.
Реальный пример из начала моей карьеры в сфере торговых систем:
Недавно нанятый программист (кандидат наук, но с ограниченным опытом реальной деятельности в разработке) посчитал странным, что все все переменные в системе, отражающие размеры заказов, были выражены целыми числами. Считая, что невозможно купить или продать меньше, чем 0 каких-либо акций или сделок, он решил переделать всю систему, чтобы классифицировать их в качестве целых чисел без запятой.
В теории все должно было работать, но оказалось, что а) место исполнения, например, обмена, отменит или скорректирует торговую операцию, в то время как б) исходная система попытается изменить заказ и, как следствие, эти события не гарантированы. В результате, состояние гонки может (и так оно и случилось) вылиться в то, что размеры заказов станут отрицательными. Эти отрицательные размеры заказов сейчас частенько случаются. Свяжем воедино то, что порядок для механизма автоматизированной торговли, который пытается выполнить этот заказ, и то, что менее, чем через час заканчивается торговый день, и все резко летит к черту.
Единственное, что радовало было то, что а) это случилось до того, как рынок стал полностью электронным, иногда автоматическое регулирование ставок заказов можно быть подтверждено и оформлено, б) механизм формировал только лимитные ордеры, число которых продолжало поддерживать и развивать рынок и за пределы этих лимитов, так что большинство из них не были оформлены, и в) тогда системы были еще 32-битными, так что общее количество акций составляло всего 2 миллиарда. (и слава богу, та история не была напечатана в прессе).
Как бы то ни было, максимальный размер лимитного ордера на Нью-Йоркской бирже составлял всего 9 999 акций, так что чистый объем заказов все еще наводнял наши линии обмена. И, не допуская многих из наших клиентов на рынок перед его закрытием, заставляя биржу изолировать нас,  вынуждая одного из наших партнеров создать исчерпывающую презентацию для высшего руководства биржи (аудитории без технического образования, которой требовалось объяснить, каким образом компьютеры отображают числа с помощью бинарной системы) с отчетом о произошедшем и о том, какие проверки мы планируем провести, чтобы избежать повторения ситуации.
Это пример того, что Мерфи имел в виду в своем законе: «Если есть вероятность того, что какая-нибудь неприятность может случиться, то она обязательно произойдёт». Поэтому принимайте всевозможные меры предосторожности, которые вы можете предпринять против любых непредвиденных обстоятельств, какие только могут прийти к вам в голову. Мерфи был инженером, который в действительности понимал коэффициент безопасности.

Ноам Бен-Ами, создаю вещи в то время, пока вы обедаете
  1. Существует лишь малое количество случаев, когда нормальным является использование статических классов и членов статических классов (public static final), и я в целом считаю это замечание обоснованным.
  2. Самая ужасная ошибка, которую могут допустить неопытные программисты, это слабые места в безопасности. Каждая линия вашего кода может быть использована как лазейка. Будьте внимательны, просматривайте свой код!
  3. Следующее. Неопытные программисты злоупотребляют объектно-ориентированным программированием. Самой вопиющей ошибкой является нарушение принципа единоличной ответственности.
  4. Отсутствие документации и пометок. Ок, это точно не уровень новичка в программировании – большинство программистов полные профаны в документации кода, поэтому они и рассказывают страшилки тем, кто только приходит в эту сферу. Не стоит быть таким, как они. Документируйте свои коды. Для большей четкости дайте кому-нибудь другому проверить ваш код.
  5. Преувеличение сложностей. Это ошибка, которую новички допускают во всех профессиях. Потратьте время, чтобы понять проблему, которую вы решаете, и найти средства, доступные для ее решения, после чего упорно трудитесь, чтобы устранить все ненужное. Запутанность убивает программное обеспечение. Я видел, как раз за разом на эти грабли наступали даже профессионалы своего дела. Я был в компаниях, которые не могли подняться, потому что очень яркие, но очень глупые люди принимали в таких компаниях решения о создании масштабных вещей, усложненных тысячей мелочей. В то время, как использование более простых решений и более мелких инструментов ускорило бы процесс в десятки раз. 
  6. Слишком сильное упрощение вещей. Убедитесь, что ваш код надежен, что он хорошо справляется с критичными ситуациями и должным образом управляет памятью.
  7. Плохо продуманная или вообще не продуманная обработка ошибок. Обработка ошибок является важной частью программного обеспечения, но, несмотря на это, большинство новичков даже не знают о существовании стратегии управления исключительными ситуациями.
  8. Непонимание производительности. Трата слишком большого количества времени на оптимизацию маловажных вещей. 
  9. Отсутствие должного тестирования. Отсутствие модульного тестирования, отсутствие контроля в проектировании классов, отсутствие комплексного тестирования. 
  10. Отсутствие надлежащего отраслевого управления. Я был во многих компаниях, не имеющих представления о том, как управлять системой отраслевого контроля. Черт возьми, да я был в компаниях, которые даже не используют современную систему управления исходным кодом! 
  11. Недостаточная доработка мониторинга показателей. Есть ли у вас регистрационный журнал? Есть ли у каждой из ваших систем безопасная проверка конечных точек? Публикуете ли вы где-нибудь ключевые индикаторы производительности? 
  12. Отсутствие испытания на стойкость в экстремальных условиях. Что произойдет, если я выключу вашу базу данных, а потом включу ее снова? Что случится с вашей маленькой счастливой системой, если я войду туда и снесу весь кэш? Вы понимаете, что ваша система будет делать дальше, если я все это осуществлю?
  13. Отсутствие четких сообщений об ошибках. Черт, я трачу кучу времени на это! И если вы решили не париться по этому поводу, создавая код, и программа в какой-то момент выдаст мне «системная ошибка, недействительное состояние», я приеду к вам и...в общем, из этого не выйдет ничего хорошего. Научитесь общаться.
  14. Нарушение формирования слоев. Или отсутствие слоев вообще. Научитесь строить систему в четких, компонуемых слоях, или же ваш код в скором времени будет представлять собой неуправляемый хаос.

Йан Трейси, инженер по программному обеспечению в Latitude, бывший инженер-программист в компании Cisco
Две самые большие ошибки, с которыми я сталкивался, работая в самых разных командах разработчиков:
  1. Игнорирование основной задачи. Начинающие программисты очень часто слишком увлекаются созданием самого продукта. И это вместо концентрации на том, какой фактический результат принесет продукт. Такое мышление в конечном итоге приведет к замедлению работы над проектом. А основные модули программы, что составляют 80% продукта, будут упущены из виду. Вместо этого программисты будут сосредоточены на более мелких компонентах: таких, как забавные детали или специфические особенности продукта.
  2. Незнание кодов, которые пишут другие люди. Вместо того, чтобы попытаться освоить и понять уже существующие кодовые базы, начинающие программисты считают, что намного легче написать все заново с нуля или же выкинуть за ненадобностью уже большие секции программы, заменив их дубликатом того, что уже по сути существует. Чтение документации, а также попытки понять уже существующие коды, имеет решающее значение для успеха проекта. В противном случае начинающие программисты тормозят проект, сводя на нет все усилия своих коллег.

Источник: https://www.kv.by/post/1050384-kakie-oshibki-nikogda-ne-stoit-sovershat-programmistam?utm_source=weekly_letter

Смотри также:

Автор: на

Комментариев нет:

Отправить комментарий