Який самий абсурдний міф щодо проблем програмування?

Інакше кажучи ... З яким найпоширенішим і найчарішим нерозумінням щодо програмування ви стикалися?

Які поширені та давні міфи / хибні уявлення вам не важко програмістам розвіяти / виправити .

Будь ласка, поясніть, чому це міф.

Це тому, що ви програміст, ви знаєте, як виправити [людину] вірусну машину.

Загальна HR-річ, яка змушує мене зрізатися, коли я шукаю роботу: неявне припущення, що всі навички кодування є специфічними для мови, що не існує досвіду інженерії програмного забезпечення, що перевищує набори команд. Цей десятирічний досвід роботи в Java та ще п’ять в Perl означають, що ви будете абсолютно марними в проекті, який використовує, скажімо, C #.

"Так, є крива навчання. Але я зробив більш важкі переходи, ніж цей. Я зроблю вам угоду, платіть мені 80% за перший місяць і наприкінці цього часу, якщо я не ... ой , зачекайте, ми насправді не ведемо цієї розмови, оскільки ваша мавпа з HR просто видалила мою заяву ".

Якщо ви не пишете, ви не працюєте.

Я вважаю, що зомбі порожні погляди та прогулянки по каві є важливими для програмістів, які організовують щось у своїх головах.

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

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

Як інакше ви пояснюєте, що всі ці проекти, які працюють з часом та за рахунок бюджету, і люди (політики, засоби масової інформації тощо) все ще дивуються, і клієнти скаржаться, коли ви говорите їм, що їх "маленький веб-сайт" (чи що завгодно) насправді потребуватиме 6 місяці на розробку та вартість декількох тисяч доларів (фунтів, євро, [вставити валюту за вибором])

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

Я знаю, що це трохи складніше, ніж це;)

Складність програми прямо пропорційна складності інтерфейсу користувача. Виходячи з цього міркування, ви зможете створити Google або Twitter протягом вихідних.

Всі програмісти добре в математиці. :-)

Будь-яка дитина-підліток, яка хакує за комп’ютерами, рівнозначна (або перевершена) у майстерності, як працює програміст-ветеран.

Мій 14-річний племінник добре працює з комп’ютерами, і я плачу йому $ 10 / год, щоб скосити мою газон. Чому я повинен заплатити вам шість цифр, щоб написати наступний FaceBook?

Це в реальному часі означає швидке.

Заявивши "Пакети потрібно обробити в режимі реального часу". негідний і злий близнюк ... відповідаючи "Наскільки швидко потрібно статися Х?" з "В режимі реального часу" можливо менше, ніж нікчемне ... межує з дурним, а не невігласом.

У реальному часі означає, що, просто кажучи, ця функція Y завжди займе X кількість часу і що будь-яке відхилення вказує на серйозну помилку. Тривалість X не визначає "реального часу", вона може становити шість мікросекунд або шість днів. Те, що ви можете визначити, функція Y займе X часу, визначає "в режимі реального часу". Системи реального часу визначаються цим визначенням.

Тож збийте його ..

Чому ви, хлопці, просто не напишіть це правильно з першого разу, а не витрачаєте стільки часу набравши коду баггі, а потім пізніше прочитавши код, намагаючись знайти помилки?

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

Якщо ви не ходили до університету, ви не придатні для роботи

Ця передчасна оптимізація означає, що ви взагалі не повинні оптимізувати. Я бачив більше жахливо поганих баз даних, тому що ніхто не хотів розглядати продуктивність (критично важливу для будь-якої системи баз даних) в дизайні як передчасну оптимізацію, ніж будь-яка інша проблема дизайну баз даних. Сміття, є відомі вбивці продуктивності, перестаньте використовувати їх як ваш перший вибір.

Ще один міф: надто важко переробляти базу даних. Ні, але ви повинні розглянути, як зробити рефакторинг на етапі проектування, щоб зробити це ефективно. І BTW, чим довше ви будете чекати, щоб виправити цю надокучливу проблему продуктивності на основі дизайну, тим важче це буде виправити.

Ще один поганий міф: розробка баз даних повинна відображати принципи ООП. Ні, бази даних призначені для роботи з наборами, що не відповідають принципам OOP. Деякі речі OOP спричинять жахливі проблеми з роботою, а інші - просто нерозумно в термінах бази даних.

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

Що є якесь міфічне джерело абсолютних найкращих практик.

Жодне відхилення ніколи не може бути виправданим.

Жоден документ, який вимагає визначити щось як найкращу практику, ніколи не може ставити під сумнів.

Той факт, що маркетинг, здається, вважає, що додавання тонни дрібних функцій - це менше роботи, ніж додавання однієї, але досить важкої функції. Що, мабуть, є більш конкретним випадком хибного уявлення про те, що "переключення завдань не має накладних витрат".

Цей код коментування непотрібний, або що "хороший код не потребує коментарів". Іноді потрібно пояснити, що робить складний біт коду. Крім того, коментування розділів коду допомагає вам набагато ефективніше читати читання.

Найгірший міф: якщо ви програмуєте тривалий час, то ви можете легко бути менеджером проектів.

І що вам слід стати менеджером проекту, якщо ви довго програмували.

Якщо ми використовуємо щось інше, ніж Java, C # та C ++ у нашому проекті, ми не знайдемо жодних програмістів, які б його підтримували.

Java - це просто C ++ з різними класами.

Java є повільним .

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

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

Уроки виготовлення можуть бути застосовані до процесу розробки програмного забезпечення.

що як програміст ви знаєте все про найновіші тенденції обладнання, розгоні, моді випадку тощо. друзі та родичі консультуються з вами, купуючи свої передачі.

Коли програмісти кажуть, що це зробити дуже важко / просто неможливо, HR думає, що вони ліниві і немотивовані

Має бути програма з відкритим кодом для мого бізнесу. Ви не можете просто завантажити його і налаштувати мої вимоги.

У мене було більше однієї людини, щоб запитати мене про те, що таке програмувати, щоб лише зрозуміти, що посеред розмови про те, що вони насправді думають, що ми програмуємо безпосередньо у двійковій формі або використовуючи математичні символи.

Я не знаю, чи хочу я розвіяти цей міф, це робить мене справді розумним!

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

Програмування - це як робота з конвеєра. Ви працюєте над продуктом певний час (можливо, з колегами) і, нарешті, відправляєте його. Так само, як будувати будинок з цегли.

Контра: Програмування містить багато креативності та планування. Це мистецтво. Як і муляр, і програміст знає різницю між формуванням цегли та плануванням цілого собору.

Перенесення програми на C ++ автоматично призведе до її швидшого запуску.

Будь-яке середовище програмування з певним візуальним дизайнером зробить це таким чином, що ділові користувачі можуть "писати" програму, а фактичні програмісти не потрібні.

OOP повторне використання. Це найбільша помилка, що продається в програмуванні.