Що є одним з бітів теорії інформатики, який я повинен знати? [зачинено]

Якщо говорити як про когось із електронної інженерії, а не про ступінь комп’ютерних наук, який би той біт інформатики я повинен знати, щоб зробити мене кращим програмістом у реальному світі ?

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

Якщо я повинен вибрати тільки один біт, який є важким рішенням, я б сказав , що піти на нотації Big O . Розуміння наслідків O (n), O (ln n), O (n²), O (2 ^ n), O (n!) Допомагає вам уникнути безлічі дорогих помилок, види яких добре працюють у тестове середовище, але катастрофічно виходить з ладу у виробництві.

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

Дізнайтеся про структури даних, алгоритми та складність даних.

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

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

Знання моделювання баз даних також важливо.

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

Це трохи складне питання.

Всі аспекти інформатики важливі в тій чи іншій мірі.

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

Розуміння великої нотації O важливо, а також розуміння того, як може виконуватися ваш код, також дуже важливо в реальних ситуаціях.

Так, це наштовхувало мене на роздуми годинами.

У процесі роботи мені довелося видалити деякі поширені відповіді, які вже дано тут.

НЕ СПИСОК

1. Велике O (n) позначення . Це важко сказати тут, але Ні, ми можемо інтуїтивно розробити неефективність та порівняти різні набори процедур, навіть не віддалено чуючи про асимптотичний алгоритмічний аналіз.

2. Функціональні мови Ні, Єдина сім'я мови - це лише один підхід до роздумів про проблеми. Чому тільки цей шматочок повинен мати значення?

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

4. Слухай Якщо ти не слухаєш, то живеш у своєму власному світі. Не обов’язково згубно!

5. Цикл розробки програмного забезпечення Nah! Ми все ще можемо натрапити на неймовірне програмне забезпечення або солі героїчні зусилля.

6. Теорія складності Я думаю, це могло бути, але без усіх формалізмів

Ця одна ідея від Comp Science

Я б сказав - " Абстракції Абстракції Абстракції ... ". Дізнайтеся про це. Перегляньте приклади навколо нього та дізнайтеся, як будувати його. Це є де. Вся інформатика, інженерія та програми виглядають як шари на шарах абстракції.

Як тільки ви це знаєте, ви починаєте вчитися добре оглядатись навколо.

Коли ви бачите кого - небудь , використовуючи list insertionв pythonі not append, ви посміхаєтеся , тому що ви знаєте , що списки пітона побудовані з використанням масивом абстракції , де вставки є дорогими і Append дешевше.

Це лише один приклад.

Теорія автоматів і ЧФМ. :-)

Конкурентні випадки використання структур даних.

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

Є лише три числа, які мають значення:

• нуль
• один
• багато

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

Проблема зупинки

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

Вам слід знати достатню теорію автоматів, щоб можна було знати, де проблема, з якою ви маєте справу, потрапляє в ієрархію формальних мов. З цього ви можете зрозуміти кілька важливих практичних застосувань, наприклад, чому ви не повинні використовувати REGEX для розбору HTML (HTML для його опису потрібна контекстна вільна граматика), і чому для збирання C ++ потрібно набагато більше часу на відміну від Java або C # (для C ++ потрібна машина Тюрінга, тоді як Java та C # можна описати контекстними граматиками).

Найважливіші рівні формальних мов - від найслабших до найсильніших:

1. Мови, які можна розібрати за допомогою кінцевих автоматів або REGEX (реалізації REGEX з зворотними перевагами є більш потужними, ніж ця категорія, але вони все ще не можуть розібрати все в категорії 2)

2. Мови, які можуть бути розібрані автоматами з пам'яттю стека або граматикою без контексту.

3. Мови, які можна проаналізувати машиною Тьюрінга або автоматами з пам'яттю з випадковим доступом.

Ну, я міг би дати вам сумну відповідь: теорія автоматів та теорія інформації.

Або я можу вам сказати, що я давно дізнався від консультанта по технічному забезпеченню:

• "Хороший" досить недостатньо.

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

Програмування

З кафедри математики та інформатики Гобарта та Вільяма Сміта коледжі приходять з інформатики 124 Вступ до програмування :

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

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

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

Чи програмування Інформатика, як ми це знаємо?

У відповідь на коментар @Thomas Owens, який зазначив (цілком справедливо), що програмування не є суворо інформатикою, я хотів би процитувати статтю з комп'ютерних наук Вікіпедії :

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

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

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

Тому, щоб бути кращим програмістом, спочатку потрібно СПИСОКУ. Слухайте клієнта. Прислухайтеся до їх потреб. Слухайте їхні бажання. І особливо, прислухайтеся до їх рівня "техні-пертіз". Я не можу вам сказати, скільки разів я бачив побудований проект, який був саме таким, що просили, але зовсім не те, що клієнт насправді потребував. Все тому, що програміст, що збирав запити, насправді не слухав.

Ще щось, що ви можете забрати - це, якщо ви не маєте досвіду в дизайні інтерфейсу, заручте когось, хто розробить дизайн інтерфейсу користувача. Я ВЖЕ МОЖУ побачити додаток, де інтерфейс призначений програмістом, а не експертом. Те, що для вас логічно і має сенс, не матиме сенсу для клієнта. І, якщо ваші клієнти не є смачними, (а хто це?), То ваше "функціонально правильне, але естетично некрасиве" рішення буде зустрінене теплом скунсу на вечері.

Функціональні мови!

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

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

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

Вирішення проблем та бажання продовжувати навчання!

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