Как мыслит программист?[закрыто]

Question

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

В принципе, какие общие шаги предпринимаются для устранения проблем и что нужно для того, чтобы "получить это"?Если бы вы нарисовали блок-схему того, как работает ваш мыслительный процесс, когда вы смотрите на код или пытаетесь решить проблему, на что это могло бы быть похоже?

Какие общие рекомендации, подсказки и умозаключения вы находите полезными при решении проблем?

Чем это отличается в разных доменах?Например, в чем мыслительный процесс веб-программиста похож или отличается от процесса традиционного разработчика настольных приложений?

Answer 1

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

Получите общую картину :

• Что это за приложение (веб, настольное, ...)?
• Насколько он многоуровневый (автономный, клиент-серверный, n-уровневый, ...)?
• Какова цель приложения?Что он должен делать?
• Для кого создано это приложение?

Посмотрите, как это работает :

• Какой язык (языки) используется (используются)?
• Как структурирован код?
• Как структурируются данные?

Понять (или, по крайней мере, попытаться), как было продумано приложение:

• Было ли это вообще продумано?
• Четко ли оптимизировано приложение?(Для выступлений?Для удобства чтения?)
• Готово ли приложение?Или есть место для эволюции?
• Есть ли признаки множественных релизов?
• и т.д...

1-й и 2-й шаги являются чисто техническими, в то время как 3-й ДОЛЖЕН быть следующим нетехнический насколько это возможно...это больше о психологии и понимании того, как было создано приложение.Очевидно, что это требует опыта, но если вы будете достаточно усердно думать и не будете тратить время своего мозга на технические детали, то в конце концов у вас все получится.

Весь этот процесс не должен требовать использования клавиатуры.От вас требуется только читать, думать и делать заметки на бумаге (я не шучу:ручка и бумага!).

Answer 2

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

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

Answer 3

Люди, как известно, плохо изучают свои мыслительные процессы, но я приведу их в порядок. Я тестирую очень высоко для визуально-пространственных способностей в тестах IQ, от среднего до высокого для вербальных навыков и умеренных для математических навыков (я полагаю, я объясняю мою оценку по математике A-level). Когда я начинаю разрабатывать программное обеспечение, я думаю о формах и связях между ними. Когда речь идет об описании этих мыслей для других (или прояснении их для себя), я использую простые блок-схемы или диаграммы объектов, взятые из метода Objectory Якобсона, а НЕ излишне сложные вещи, которые предлагает UML. Я иногда пишу текстовые описания сложных вещей, в основном как напоминания для себя, но никогда не использую цифры или математику.

Конечно, это только я - я работал с математиками, которые были такими же хорошими или даже лучшими программистами, как я.

Answer 4

Я не думаю ... я обрабатываю.

Это на самом деле меньше, чем кажется. Я всегда разбиваю задачи на их компоненты, а затем разбиваю их дальше, и это касается не только написания программного обеспечения! Так же, как @Mark Pim U, последовательно проходите через все.

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

Answer 5

Разделить & amp; Покори

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

Answer 6

Это один из тех редких случаев, когда я отвечал: «Это просто работает». Я изучаю вещи, катаясь по ним. У меня нет уловок или устройств, чтобы помочь мне. Мне потребовалось некоторое время, чтобы выучить PHP, но после этого Javascript стал намного проще. Как только вы решите одну задачу, следующие элементы станут кумулятивно-проще.

Answer 7

Лично я веду внутренний диалог с самим собой: «Хорошо, нам нужно перебрать этот список целых чисел». «Но мы можем сломаться, когда найдем ту ценность, которую хотим». «Хорошо, список обязательно будет инициализирован, когда мы начнем?»

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

Answer 8

Похоже на Джонатана Сэмпсона - это вроде как просто работает.

Когда я сталкиваюсь с реальной проблемой, я пытаюсь придумать наиболее логичный способ справиться с ней.Затем, когда все идет не так (как это обычно бывает), мне приходится делать сотни обходных шагов, чтобы добиться цели.Просто продолжайте фокусироваться на этой конечной цели, на этом логическом пути, и вы ее достигнете.

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

Answer 9

Лично я вижу код в своей голове не в текстовом, а в графическом виде (например, Нил Баттерворт) - это довольно сложно описать, поскольку (цитируя STIV) "нет единой системы отсчета".

Answer 10

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