Какой самый абсурдный миф о проблемах программирования?


101

Другими словами, с каким наиболее распространенным и расстраивающим недоразумением в программировании вы сталкивались?

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

Пожалуйста, объясните, почему это миф.


24
Я хотел бы видеть, что Mythbusters берут некоторые из них.
Спонг

8
Кто-нибудь на YouTube-канал Mythbuggers? :-)
Тамара Вийсман

1
Оооо, Разрушители мифов и условия гонки! Мне нравится!

@ TomWij, было бы здорово иметь сайт с таким названием!
Младший М

Ответы:


272

Это потому, что вы программист, вы знаете, как починить зараженную вирусом машину [человека].


34
Пункт об аналогии с автомобилем: «Я гонщик, а не механик».
Питер Боутон

15
Этот комикс актуален: theoatmeal.com/comics/computers
lunixbochs


21
@ Тим, если она умеет готовить, начните предлагать ей волонтеры для вечеринок своих друзей
Стивен А. Лоу,

19
Дело не в том, что я не знаю, как ... Это то, что я не хочу тратить часы на починку вашей машины, которую вы все равно сломаете через 2 недели.
ChaosPandion

267

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

«Да, есть кривая обучения. Но я сделал более сложные переходы, чем этот. Я заключу с тобой сделку, заплачу мне 80% за первый месяц и в конце этого времени, если я не ... о Подожди, мы на самом деле не ведем этот разговор, потому что твоя обезьяна из отдела кадров просто удалила мое приложение. "


91
+ INF для HR обезьяны.
Расти

67
У меня был сотрудник отдела кадров, отказавший мне в должности, потому что я знал, как работать с C #, но он искал кого-то, кто мог бы писать код в dotNet.
burnt_hand

11
@burnt_hand: Да, я знаю dotNet. Я также знаю Excel и Internet Explorer. Теперь я могу заключить контракт?
Алан Плам

Хотя я согласен с тем, что между Java и C # существуют огромные совпадения с синтаксисом, структурой, SDLC и т. Д., Если они дадут вам достаточно сложный тест C # в вашем интервью, как вы будете жить?
JBRWilkinson

2
@Kyralessa - я думаю, что теперь я знаю достаточно о лежащей в основе теории вычислений и функциях компьютеров, чтобы не допускать основных ошибок в любом языке программирования. Я могу прочитать документацию. Тем не менее, кое-что, что нанимает конкретный язык с ограниченными инженерными навыками / будет / будет делать, - это делать основные ошибки в структуре, дизайне, корректности, масштабируемости, надежности и ремонтопригодности программы, которые потенциально могут стоить больших затрат на исправление. Если вы не потеряете всех своих клиентов из-за низкого качества программного обеспечения в то же время (при условии, что ваш проект действительно куда-нибудь попадет).
пламенеющий

261

Если вы не печатаете, вы не работаете.

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


9
Страница вверх, страница вниз ... страница вверх, страница вниз ...
чеснок

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


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

10
«Если бы у меня было больше времени для написания кода, я бы написал меньше строк». - сними на цитату Эйба Линкольна.
JeffO

158

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


28
Ах, из Мистического Месяца Человека. en.wikipedia.org/wiki/The_Mythical_Man-Month
губка

2
На самом деле, вы можете. -1 (да, вот мифоносец!)
П Швед

63
Мы используем красочную поговорку: «Вы не можете поместить 9 женщин в комнату и сделать ребенка за месяц».
Уолтер

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

7
@Walter, но вы можете иметь 9 детей за 9 месяцев и бейсбольную команду из малой лиги за 7 лет.
Гуперникетес

132

Это написание программного обеспечения легко.

Как еще вы можете объяснить все эти проекты, которые выполняются с течением времени и сверх бюджета, и люди (политики, СМИ и т. Д.) Все еще удивляются, и клиенты жалуются, когда вы говорите им, что их «маленький сайт» (или что-то еще) на самом деле займет 6 месяцы на разработку и стоимость несколько тысяч долларов (фунты, евро, [укажите валюту выбора])

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

Я знаю, что это немного сложнее, чем это;)


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

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

3
Дело не в том, что требования изменились, это просто не то, что они думали, что хотели.
JeffO

1
У меня был кто-то, кто отвергал программирование как «просто набор утверждений« если »». Хорошо, возможно, это так ... в этом случае поэзия - это «просто набор слов» ... кинопроизводство - это «просто набор сцен» и т. Д.
JoelFan

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

114

Сложность приложения прямо пропорциональна сложности пользовательского интерфейса. Исходя из этого, вы сможете создать Google или Twitter за выходные.


2
это правда, я мог бы создать Twitter и Google за один уик-энд. Это не их программное обеспечение, которое является сложным; для Google это их алгоритм поиска (который более сопоставим с библиотекой кода или драйвером базы данных), а Twitter (до последних 1,5 лет) был чрезвычайно простым, только с проблемами масштабируемости и базы данных. Теперь, когда он более сложный (требует большего количества сотрудников), он также имеет гораздо более сложный пользовательский интерфейс и множество других пользовательских интерфейсов.
Орокусаки

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

3
1+ Было время, когда я демонстрировал свой связанный с SharePoint проект (многоязычное дополнение) своему бывшему боссу, потратив часы на работу со сложным внутренним кодом. Конечный результат был сделан не так много в пользовательском интерфейсе, что заставило моего босса поверить, что мало что было сделано по проекту. Это разозлило меня. Он не был тем, кто часами сидел за клавиатурой, пытаясь обойти странности SharePoint, а также логику замены текста.
Джейсон Эванс

1
Не ненавидите, когда какой-то огромный, почти невозможный запрос формулируется как «можете ли вы добавить кнопку, чтобы сделать…»
JoelFan

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

95

Все программисты хорошо разбираются в математике. :-)


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

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

@Diego: Хотя это не обязательно означает, что все программисты хорошо разбираются в математике.
Омега

95

Любой подросток, который взламывает компьютеры, эквивалентен (или превосходит) по мастерству ветеран-программист.

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


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

36
Встречный вопрос может быть таким: «Что бы вы заплатили ему, чтобы построить свой дом?»

7
Ребенок без квалификации, но пишет аккуратный код, может победить мистера Спагетти в любой день.
Заз

13
Я обвиняю Голливуд в этом
MAK

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

69

Это в реальном времени означает быстро.

Заявление «Пакеты должны быть обработаны в режиме реального времени». ничего не стоит, а злой близнец ... отвечает "Как быстро должен произойти Х?" с «в реальном времени» , возможно, менее чем бесполезно ... граничит с глупым, а не невежественным.

В реальном времени это означает, что функция Y всегда будет занимать X времени, а любое отклонение указывает на серьезную ошибку. Длительность X не определяет «в реальном времени», это может быть шесть микросекунд или шесть дней. То, что вы можете определить, что функция Y займет X, время определяет «в реальном времени». Системы реального времени являются детерминированными по этому определению.

Так что отбросьте это ..


в режиме реального времени = почти время
Брайан Чэндли

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

14
Вероятно, это только один из тех случаев, когда плохо названная концепция способствует путанице.
JohnFx

2
@JohnFx Хорошо сказано. Понятиям нужен контекст.
Расти

2
@Richard: Действительно, iTunes всегда требуется несколько минут, прежде чем что-то играть. О, это не то, что вы имели в виду?
конфигуратор

69

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

:-) :-) :-) :-)


34
Честно говоря, это хороший вопрос. Самое простое время, чтобы сделать код хорошим, это когда он пишется впервые.
DJClayworth

10
У нас есть настройка в конфигурации приложения: <add Key = "Bugs" Value = "true" />
burnt_hand

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

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

1
@Stephen C: да, но есть разница в том, чтобы сделать его в основном правильным (а не совершенно правильным) по сравнению с тем, чтобы делать в основном все влево и вправо, чтобы заставить его работать. Я знаю, что это не то, что вы сказали, но я все еще думаю, что это нужно сказать.
n1ckp

65

Если вы не учились в университете, вы не подходите для работы


27
Кроме того: программист со степенью лучше, чем программист без и должен получать соответствующую оплату. То же самое, вероятно, идет с эйджизмом и сексизмом. Такая ерунда бесит меня - если вы не знаете, как писать хороший код, мне наплевать, куда вы пошли и чем занимались. Это может быть еще один случай столкновения культуры программист / ботаник (навык == авторитет) с корпоративной культурой (ранг == авторитет).
Алан Плам

1
И все же люди, преподающие в университете, также, кажется, думают, что они могут обобщить поведение программистов и проектов, наблюдая, как студенты работают, когда объединяются. Коммуникации ACM хороши для 4-6 таких статей в год.
МВД

1
@ Билли Как насчет того, где диплом колледжа означает Джек, но диплом университета даст вам все? Оба ходят в школу, оба, возможно, лучше, чем другие, но есть социологическая разница
Tarka

4
@Billy: в Канаде университет присуждает вам ученую степень, а колледжи дают вам дипломы. Колледжи больше похожи на «школы, где вы учите практические вещи». Думайте общественный колледж в США против нормального колледжа / университета. Здесь они обычно имеют двухлетние специализированные прикладные программы. Вы не можете получить степень бакалавра (магистра и т. Д.) В колледже. По сути, вы бы поступили в колледж, чтобы научиться писать программы, и в университет, чтобы изучать информатику. Университетские степени получают гораздо более сильные предпочтения при найме.
Адам Лир

4
Университеты учат как минимум одной важной вещи: мышлению . Это очень важно, но те, кто этого не знают ... ну, не знают этого.

61

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

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

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

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


+1, в частности, за комментарии по поводу проверки целостности базы данных.
Фрэнк Шиарар

+1 Особенно за последний абзац. Я побил этот барабан не раз.
бинарный беспорядок

5
+1 за первый абзац. Преждевременная оптимизация - корень всего зла; писать плохой код без кровавой причины - еще хуже.
конфигуратор

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

@HLGEM Меня также интересуют примеры, о которых @Tom задается вопросом ...
Armand

53

Что есть какой-то мифический источник абсолютных лучших практик.

Ни одно отклонение не может быть оправдано.

Ни один документ, претендующий на определение чего-либо в качестве передового опыта, не может быть подвергнут сомнению.


1
лучше член команды, чем ваши менеджеры ...
Билл

5
Вы можете переслать этот документ мне?
AShelly

1
Полностью согласен. Кому интересно, если вы смешиваете табуляции и пробелы в коде Python?
Заз

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

1
Я интерпретирую «это лучшая практика» как «я не могу это оправдать». Я, конечно, использую это таким образом сам.
Том Андерсон

51

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


12
И еще более забавная вещь маркетинга - не иметь представления, какие функции легки, а какие чертовски невозможны.
Дероберт

4
@derobert Точно, у меня часто был опыт, что некоторые из более внимательных маркетологов на самом деле боятся даже спрашивать о какой-то простой / легкой функции, которую они считают очень сложной для реализации. Хотя я гораздо чаще сталкиваюсь с противоположным: вот несколько «простых» функций X, которые мы уже продали покупателю, пожалуйста, сделайте это до вчерашнего дня…
Гиэль,

50

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


14
@DisgruntledGoad - Это правда, хотя. Недоразумение в этом «мифе» происходит из-за того, что слишком многие программисты считают свой монолитный запутанный код «хорошим». if user.is_logged_in: print('Welcome')не нуждается в комментарии.
orokusaki

3
@orokusaki Не каждый алгоритм такой простой.
Джук ван дер Маас

25
@orokusaki вы ошибаетесь «хороший код не нуждается в комментариях» с «простой код не нуждается в комментариях». Хороший код не всегда прост.
Рассерженная шлюха

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

2
@orokuskai: хороший код прост. То, что он делает, может быть сложным, но, на мой взгляд, простота (элегантность) кода делает его хорошим! Конечно, код делает много других вещей, а мусорный код может принести вам много денег. Но моя цель - написать простой код даже в сложных ситуациях.
пламенеющий пингвин

50

Худший миф: если вы долго программируете, вы легко можете стать менеджером проекта.

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


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

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

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

1
Также известный как принцип Питера. ru.wikipedia.org/wiki/Peter_Principle
Spoike

хорошо сказано действительно
Майкл Пасха

50

Если мы используем что-то кроме Java, C # и C ++ в нашем проекте, мы не найдем программистов, которые бы поддерживали это.


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

5
@bigown, "неясный"? Как малоизвестно? TCL неясен? Haskell? Паскаль (Delphi)? Python? Я думаю, что они не неясны. Многие думают, что это так, и только «очень узкий» набор языков (C ++, C # и Java) допускается для «серьезной» разработки.
П Швед

5
@bigown: о, ты имеешь в виду неясный, как Кобол? : p
AnonJr

2
Однажды я работал в небольшой компании, занимающейся написанием кода Objective-C для Linux. Генеральный директор, который не был инженером, но имел некоторые технические знания, не мог поверить, что вокруг были программисты ObjC или кто-то другой использовал его. На самом деле у них никогда не было проблем с наймом хороших разработчиков.

4
Я читал аргумент, что с точностью до наоборот: для языков, которые неясны (или, по крайней мере, коммерчески незначительны), но круты, забавны и интересны (что в данном контексте означало Python и Ruby), программистов больше, чем рабочих мест. Плюс, все они люди, которые любят крутые, веселые и интересные языки, поэтому они должны быть умными. Так что на самом деле работа в Python означает, что вам будет проще нанимать умных программистов, чем если бы вы работали в Java. Не знаю, верю ли я этому, но это, по крайней мере, так же правдоподобно, как и ортодоксальная идея!
Том Андерсон

42

Java это просто C ++ с разными классами.


57
+1 Однажды я попросил интервьюера спросить: «В чем разница между C ++ и Java?» Поэтому я перечислил некоторые различия. Родной компилятор против JVM, стандарт ANSI против проприетарного, сборщик мусора, загрузчики классов и т. Д. Он взревел: «НЕПРАВИЛЬНО! Разницы нет! Они идентичны!» Он не был студентом, он был техническим инженером.
Билл Карвин

11
@ Билл, тогда мой ответ будет: «Тогда зачем обращаться к ним с совершенно разными именами?»
Джесси С. Слайсер

2
@ Билл, значит, ты провалил тест и получил работу?

20
Мой ответ будет "До свидания".
Фул

6
@ Foole Разве вы не имеете в виду System.exit (1)?
Барри Браун

33

18
Но, честно говоря, раньше это было ...
Дэн Дипл

70
Это все еще есть ...
Fosco

16
Как кофе может быть медленным?
Расти

6
@ Расти без кофеина? ,
Джо Филлипс

29
«Тук-тук». - «Кто там?» - очень длинная пауза… «Ява». (Предоставлено stackoverflow.com/questions/234075/… )
RegDwight

33

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

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


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

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

3
Вам нужен мощный язык. См. Обсуждение языков Пола Грэмса и того, что вы можете сделать: paulgraham.com/power.html

4
@ Thorbjørn: я читал эту статью, и Пол Грэм ошибается. Он сторонник Лиспа, поэтому он превращает факты в корыстные аргументы, чтобы Лисп хорошо выглядел. Может быть, даже не осознанно, поскольку на самом деле это не займет много времени. Существует много совпадений между удобочитаемостью и краткостью, как он указывает в конце статьи. Но выводы, которые он делает, совершенно не соответствуют состоянию разработки программного обеспечения в реальном мире. Да, вам нужен мощный язык, но он измеряет силу по неправильным критериям, и вредно верить тому, что он говорит.
Мейсон Уилер

3
@rtperson: То, что производительность может варьироваться в десять раз, не миф. Люди, которые быстро заканчивают, обязательно более продуктивны.
Дэвид Торнли

31

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


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

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

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

+100 за это, особенно люди, которые изучали экономику, думают так
Кугель

1
Каждый должен прочитать Джек Ривз: developerdotstar.com/mag/articles/reeves_design_main.html - это начало (или, по крайней мере, раннее и мощное утверждение) идеи о том, что исходный код - это дизайн, а не продукт . Программисты похожи на дизайнеров в чертёжной комнате, а не на машинистов на заводе, и управление программированием должно быть похоже на управление другими видами инженерного проектирования, а не на производство.
Том Андерсон

31

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


5
Я имел обыкновение быть в курсе некоторых из этих вещей еще в старшей школе, но в настоящее время я нахожу, что они, как правило, не имеют отношения к тому, что я делаю, и, хотя некоторые из них аккуратны, я бы предпочел заплатить тому, кто знает их вещи и использует время, которое я сохранить делать то, что мне нравится (т.е. писать код). Может быть, еще одно недоразумение "хорошо с компьютерами".
Алан Плам

2
+1, или немного необычный - потому что вы программист, у вас супер вентилятор с водяным охлаждением и 300 светодиодными вентиляторами, вращающийся в верхней части диапазона новинки, поставляемой с завода-изготовителя перед выпуском корпуса. Хм не очень! Это прилично быстрая машина в черном очень дешевом корпусе. На самом деле все равно!
Хирургический кодер

Смейтесь, на работе есть помощник премьер-министра, у которого дома есть какая-то всемогущая игровая установка, он всегда переходит в зону разработки, чтобы спросить, должен ли он купить (Продукт A) или (Продукт B) ... в несвязанной записке, он также предполагает, что все команды разработчиков тусуются на 4Chan (что он и делает на самом деле) - вздох
ocodo

+1 слово. Это место. Я разработчик программного обеспечения, и меня попросили настроить чей-то интернет много раз, и в основном все, что я делаю, это метод проб и ошибок, а также поиск в Google. Мне больше всего нравится, когда что-то совершенно не связанное ломается после того, как вы сделали кому-то одолжение, и тогда это ваша вина.
Анна Шуесслер

30

Когда программисты говорят, что это очень трудно / просто невозможно, HR считает, что они ленивы и не мотивированы


2
Включите управление тоже
Prasham

Когда вы говорите «нет», они думают, что с вами просто сложно работать.
Капитан Разумный

+100, и что при достаточной «мотивации» они могут изменить ваш ответ. Или обратитесь к другому [менее опытному] разработчику и намеренно оставьте половину деталей, чтобы он сказал «да», только чтобы закончить половину разработки и наткнуться на ту проблему, о которой вы их предупреждали.
Wildpeaks

28

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


2
+1. О да, все, что нам нужно сделать, уже должно быть в открытом коде.
Sharp

7
в большинстве случаев ... по крайней мере, это верно для веб-разработки.
WalterJ89

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

правда ... но в случае Wordpress, Drupal, jQuery, ... могут быть области, где бесплатность невелика, например, электронная коммерция, но чаще всего Интернет очень открыт, и я нахожу, что мне нравится работать с Сообщество open source гораздо больше, чем просто служба поддержки.
WalterJ89

7
Противоположность - тоже миф. То, что вы не можете использовать FOSS для удовлетворения потребностей своего бизнеса.
конец

27

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

Я не знаю, хочу ли я развеять этот миф, он заставляет меня выглядеть очень умно!


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

7
«Мы пишем рецепты вязания». Бабушки, как правило, понимают это.

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

1
@ Джош - если нет проблем с производительностью, это кажется пустой тратой времени.
JohnFx

1
@oosterwal - ассемблер не является двоичным и не использует математические символы.
JohnFx

26

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


5
* v (int) (void) ++
Расти

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

4
Ах, да, код «Только для записи» ...
Paddyslacker

24

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

Против: Программирование содержит много творчества и планирования. Это искусство. Как и каменщик, программист знает разницу между формовкой кирпича и планированием всего собора.


6
Согласитесь с отличием от работы на конвейере - но во многих отношениях я не думаю, что это сильно отличается от строительства дома.
Билли ОНил

24

Портирование программы на C ++ автоматически заставит ее работать быстрее.


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

2
Другой распространенный вариант - переход на архитектуру клиент-сервер. «Обновление до SQL сделает мое приложение намного быстрее!» Не обязательно.
JohnFx

Да, много раз наоборот. Базы данных типа SQL хороши для того, чтобы быть ACID или почти что, это идет с ценой. И, что может быть хуже, неправильное представление о методах SQL может отрицательно сказаться на производительности.
Маньеро

6
Портирование на C ++ / C для тех, кто написан на Python / Perl / Ruby / и т.д. Портирование на asm для тех, кто написан на C / C ++: P. Интересно, что бы вы перенесли в asm? проектирование его в аппаратное обеспечение?
МАК,

1
@MAK - проверьте en.wikipedia.org/wiki/Handel-C
flamingpenguin

21

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


9
О да. Всегда весело, когда какая-то компания создает новый инструмент авторинга, чтобы сделать излишним программистов, и тогда каждый, кто его применяет, идет вперед и нанимает высокооплачиваемых специалистов по <инструменту авторизации>, чтобы фактически использовать его. Показательный пример: Joomla! и все это бессмысленно.
Алан Плам

ХА ХА ХА ХА ХААА ХА +1 :)
Билли ОНил

Кобол уже попробовал это :)
Carra

20

ООП повторного использования. Это самая большая ошибка на рынке программирования.


1
Что ж. HP XL WESM примерно на 85% совпадает с Symbol WS5100 (происходит OEM-разработка). Вы бы попросили меня скопировать и вставить этот процент моего кода мониторинга и конфигурации, чтобы в два раза больше ошибок, или вы бы предпочли, чтобы я переписывал его с нуля и занимал в сорок раз дольше, а их в пять раз больше? Или вы просто испытываете давление со стороны глупого руководства, которое думает, что это одна из нескольких волшебных панацей, чтобы сделать $ проект быстрее?

1
Повторное использование в малых было решено 40 лет назад и более. Повторное использование в целом сложно и пока не решено ИМХО. Точно так же, как Роберт Гласс говорит в «
Фактах
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.