Тривалі, неправильні припущення щодо програмування [закрито]

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

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

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

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

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

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

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

Щоб люди знали, чого хочуть.

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

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

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

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

Це я знаю, де проблема продуктивності без профілювання

Що я повинен мати лише одну точку виходу з функції / методу.

Щоб непрограмісти розуміли, про що я говорю.

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

Змінні приватного члена були приватними для екземпляра, а не для класу.

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

Щоб ви могли повністю зрозуміти проблему, перш ніж розпочати розробку.

Розумні люди завжди розумніші за мене.

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

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

Мораль історії: Ніколи не варто недооцінювати те, що можна подати до столу.

Тривалий час я думав, що Погане програмування - це те, що траплялося на межі. Це правильна робота - норма. Я сьогодні не такий наївний.

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

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

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

Що жінки вважають комп'ютерних програмістів сексуальними ...

Що якість програмного забезпечення призведе до збільшення продажів. Іноді так, але не завжди.

Щоб усі мови були (переважно) створені рівними.

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

Вибір правильної мови для роботи є настільки ж важливим / критичним, як і будь-яке інше рішення, яке приймається окремим проектом.

Це велике співвідношення коментарів / коду - це добре.

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

Та програмування неможливо.

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

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

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

"On Error Resume Next" - це якась обробка помилок

Це програмне забезпечення програмування вимагає міцної основи у вищій математиці.

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

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

Це оптимізація == переписування мовою складання.

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

• Щоб керівники компанії дбали про якість коду.
• Чим менше рядків, тим краще.

Я б сказав, що зберігання елементу року у вигляді двох цифр було припущенням, яке вразило ціле покоління розробників. Гроші, які видували на Y2K, були досить жахливими.

Що-небудь, крім вставки / міхура, було досить просто темною магією.

Цей XML був би справді сумісним та зрозумілим для людини форматом даних.

Цей C ++ був якось внутрішньо кращим, ніж усі інші мови.

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

Ніхто - і нічого - не ідеальний, завжди є можливість для вдосконалення.

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

Я вважав, що основні шаблони дизайну були приголомшливими, коли вони були представлені в класі CS. До цього я програмував близько 8 років як хобі, і я насправді не мав чіткого розуміння того, як створити хороші абстракції.

Дизайнерські візерунки відчували себе магічними; ви могли б зробити дійсно акуратні речі. Пізніше я виявив функціональне програмування (через Mozart / Oz, OCaml, пізніше Scala, Haskell і Clojure), а потім зрозумів, що багато зразків - це просто котельня чи додаткова складність, оскільки мова була недостатньо виразною.

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

Перші кілька років, коли я програмував, я не спіймав, що 1 Кбайт технічно становить 1024 байта, а не 1000. Мене завжди трохи здивувало те, що розміри моїх файлів даних здавалися дещо від того, що я очікував від них бути.

Цей стан перевіряється як:

if (condition1 && condition2 && condition3)

виконуються у невизначеному порядку ...

Щоб моє програмування було б швидшим і кращим, якби я виконував його поодинці.