Интересные истории о плохом коде

0
1147
views

Пользователи сайта Quora поделились интересными историями, когда сталкивались с худшим кодом, который был написан опытным программистом. Сайт KV.BY опубликовал перевод самых интересных ответов.

Плохой код: жизненные истории.

Аластер Стелл, Javascript, Python, C++, C#, Smalltalk, C, Web-разработка, SQL и т.д.

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

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

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

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

К сожалению, мне время от времени приходится сталкиваться с ужасным кодом. Фактически, это происходит вследствие 3 факторов:

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

Стив Коулман, аналитик в физической лаборатории Университета Джона Хопкинса

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

И вот я выхожу в своей первый день на рабочее место, где меня сажают напротив терминала, чтобы я мог познакомиться и разобраться с программой. Под маленькой неприятностью скрывались, по их словам, небольшие проблемы с производительностью. Естественно, я попытался ввести простейший запрос в систему, чтобы оценить ее работоспособность. Я нажал клавишу Enter, и мне пришлось «немного подождать. Всего лишь 45 минут! Я был одновременно в ужасе и возмущении: кто мог сконструировать подобного ни на что не годного монстра? И да, я прекрасно понимал, что на исправление этой «небольшой проблемки» придется потратить уйму сил и времени, и разбираться с ней придется именно мне – молодому программисту, который только пришел работать на это место. И это с учетом того факта, что по плану система должна быть введена в эксплуатацию уже через месяц!

Спустя несколько недель упорного труда я смог снизить время загрузки страницы до 8 секунд. Естественно, это все еще был слишком большой промежуток времени для Министерства Обороны. Я предложил план дальнейшей работы, но они посчитали его неполным и неподходящим. Поэтому они пригласили так называемого «Эксперта», которому пришлось платить по тысяче долларов за каждый рабочий день (а я напоминаю, что тогда это были просто огромные деньги). И что же в итоге? Спустя две недели он предложил им точно тот же концепт, в соответствии с которым я строил и предлагал им свой план. Конечно же, после этого они позволили мне реализовать мою идею, и уже через полторы недели я смог сократить время загрузки с 8 секунд до меньше чем 1 секунды. Это был действительно хороший результат, плюс, благодаря моей оптимизации во многих других моментах пользоваться программой стало намного удобнее. Так начался мой путь в качестве профессионального программиста.

Реальная история о плохом коде

Рагхавендра Нв, программист

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

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

Одному из разработчиков я дал задание написать несколько сервисных методов (API-вызовов). Я заранее написал 35 модульных тестов для этих еще не созданных сервисных методов. Ни один из этих тестов не работал, так как api были еще не готовы. Я попросил разработчика доделать работу с сервисными методами, потому что как только они будут готовы, то пройдут все модульные тесты. Я настоятельно попросил его удостовериться, что все модульные тесты завершены успешно. Он сказал, что все понял и что все будет сделано.

Я взял себе мини-отпуск и вернулся на работу только через 4 дня. После возвращения я запустил все 35 тестов и 34 из них прошли успешно. Я был искренне счастлив, что за время, пока меня не было, был достигнут такой прогресс. Я начал отладку кода для 35-го юнит-теста. И тут я заметил, что необходимый сервисный метод для него отсутствует. Несмотря на это, я все еще был в приподнятом настроении, ведь с остальными 34-мя все было нормально.

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

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

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

Дэнни Кодичек, разработчик программного обеспечения

Вне всяких сомнений, к такому провалу можно отнести один из моих кодов.

Самый худший код, который и по сей день вгоняет меня в краску, был создан мной по просьбе моих друзей из Лондона. Я должен быть сделать простую программку для финального отсчета времени, который должен был состояться при объявлении решения Олимпийского Комитета о том, где будет проводиться Летняя Олимпиада 2012. Именно Лондон был одним из главных фаворитов в том состязании за проведение олимпиады, поэтому обратный отсчет должен был транслироваться в офис в Лондоне.

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

00:05

00:04

00:03

00:02

00:01

00:00

00:-01

00:-02

Я сгораю со стыда каждый раз, когда я вспоминаю тот случай.



ОСТАВЬТЕ ОТВЕТ

Please enter your comment!
Please enter your name here