У меня есть стойкое ощущение, что можно написать универсальное средство, которое можно законфигурить под любой проект, чтобы быстро находить в нем ошибки, связанные с нарушениями такого рода.
Естественно, я говорю не по 100% случаев, но даже если 80% типичных ошибок нарушения уровней абстракции будет отлавливаться автоматически — это будет счастье. :-)
Инструменты созданы людьми.
Инженеры они были или нет — не важно.
Важно то, соответствуют эти инструменты своему назначению или нет.
Если соответствуют — это хорошие инструменты, и их можно использовать.
И совершенно неважно, кто его сделал: инженер ли придумал, или пещерный человек долотом выдолбил.
И еще. Один раз участвуя в большом проекте, я сделал очень простой, но очень важный вывод.
Проекты делают люди. Не инженеры, не программисты, не аналитики… Люди.
Это очень важно понимать.
Да, и если уж говорить о шансах посчитать все варианты, то у программистов они ничуть не лучше, чем у других людей.
Все зависит от навыка системного мышления, а этот навык развивается не только в программировании.
Как уже заметили в других комментариях, в некоторых профессиях он развивается даже лучше, чем у программистов.
Число песчинок в пустыне тоже счетно.
Но мне почему-то кажется, что до сих пор не нашлось ни одного человека, который смог бы их посчитать… :-)
P.S. И не говорите мне про оценку сверху — это и так все умеют. В программировании, например, перехват всех исключений без исключений — это что-то похожее. Перехватить-то перехватишь, а ничего толком сделать не можешь, ибо не знаешь, что перехватил. Так же и тут — сверху-то оценишь, а вопрос «сколько» ставит в тупик. :-) Ну, или хотя бы погрешность оценки сверху дайте — та еще задачка. Понимаете, надеюсь? :-)
ИМХО, прежде чем отвечать на вопрос «Почему трава зеленая» ребенку имеет смысл задать себе вопросы «Кому я пытаюсь это объяснить?», «Что он уже знает, на чем я могу строить рассуждение?» и «Какой уровень объяснения будет приемлемым?».
Без понимания базы ребенка вы ничего ему не сможете объяснить.
Если бы это было возможно объяснить, в школах бы не изучали математику перед университетской программой мат. анализа.
Максимум, что вы можете сделать — это расширить его базу знаний новыми понятиями или фактами. И если они не уложатся в его картину мира, то он их просто забудет.
А ответы про "… больше тепла..." или "… специальное вещество..." что дают ребенку?
Оба ответа плохи, ибо они не объясняют, что такое «зеленый».
Именно с понятия цвета и нужно начинать объяснение, потому как ребенок как раз и пытается понять, что же это такое.
Он видит цвет, но не понимает, откуда берется это «видит», что представляет собой процесс восприятия. В эту сторону и нужно объяснять.
Абстрактные сущности нужно связывать с конкретикой как можно раньше. И как можно больше аналогий.
Абстракция, подвешенная за одну ниточку, долго не живет.
Можно сделать более дипломатично.
— Видишь ли, есть очень много, чего мы не знаем. И узнать то трудно. Ты правда хочешь это узнать?
— Да, хочу.
— Тогда давай посмотрим на листик более внимательно (берем микроскоп)…
И т.д. Нужно сочетать практику с теорией — ребенок не может долго концентрировать внимание и запоминать поток информации. Нужно чередовать вид информации — слова, картинки, объяснения, и применение инструментов чтобы увидеть и пощупать что-то новое. И еще делать перерывы. Только системным подходом можно чему-то системному научить. А иначе познание так и ограничится заученными фразами, как и у всех нас. Как это ни печально, запомнить фразу проще, чем понять ее.
P.S. И, да, я так не умею. Иногда получается, но это скорее случайность + желание, чем системный процесс. Увы.
Работая над решением задачи всегда полезно знать ответ? (с) :-)
Лучше порешайте на досуге.
Ничто не сравнится с ощущением победы над задачей, которую никак не удавалось решить.
Если, конечно, решение не слишком простое, иначе чувствуешь себя дураком. :-)
Прикольно показывать Junior'ам, сразу запускающим debug, что путем чтения кода можно найти ошибку быстрее, чем соберется проект. :-) А без сборки и запуска, ясно-понятно, в debug не попадешь. Еще и тестовые данные нужно подготовить, попасть в нужный сценарий…
Программист — тот, кто умеет писать программы.
По-моему тут все понятно :-)
Естественно, я говорю не по 100% случаев, но даже если 80% типичных ошибок нарушения уровней абстракции будет отлавливаться автоматически — это будет счастье. :-)
Инженеры они были или нет — не важно.
Важно то, соответствуют эти инструменты своему назначению или нет.
Если соответствуют — это хорошие инструменты, и их можно использовать.
И совершенно неважно, кто его сделал: инженер ли придумал, или пещерный человек долотом выдолбил.
И еще. Один раз участвуя в большом проекте, я сделал очень простой, но очень важный вывод.
Проекты делают люди. Не инженеры, не программисты, не аналитики… Люди.
Это очень важно понимать.
Иногда из-за невозможности и/или непредусмотренности backup'а все летит в тартарары.
Все зависит от навыка системного мышления, а этот навык развивается не только в программировании.
Как уже заметили в других комментариях, в некоторых профессиях он развивается даже лучше, чем у программистов.
Но мне почему-то кажется, что до сих пор не нашлось ни одного человека, который смог бы их посчитать… :-)
P.S. И не говорите мне про оценку сверху — это и так все умеют. В программировании, например, перехват всех исключений без исключений — это что-то похожее. Перехватить-то перехватишь, а ничего толком сделать не можешь, ибо не знаешь, что перехватил. Так же и тут — сверху-то оценишь, а вопрос «сколько» ставит в тупик. :-) Ну, или хотя бы погрешность оценки сверху дайте — та еще задачка. Понимаете, надеюсь? :-)
Без понимания базы ребенка вы ничего ему не сможете объяснить.
Если бы это было возможно объяснить, в школах бы не изучали математику перед университетской программой мат. анализа.
Максимум, что вы можете сделать — это расширить его базу знаний новыми понятиями или фактами. И если они не уложатся в его картину мира, то он их просто забудет.
А ответы про "… больше тепла..." или "… специальное вещество..." что дают ребенку?
Оба ответа плохи, ибо они не объясняют, что такое «зеленый».
Именно с понятия цвета и нужно начинать объяснение, потому как ребенок как раз и пытается понять, что же это такое.
Он видит цвет, но не понимает, откуда берется это «видит», что представляет собой процесс восприятия. В эту сторону и нужно объяснять.
Абстракция, подвешенная за одну ниточку, долго не живет.
— Видишь ли, есть очень много, чего мы не знаем. И узнать то трудно. Ты правда хочешь это узнать?
— Да, хочу.
— Тогда давай посмотрим на листик более внимательно (берем микроскоп)…
И т.д. Нужно сочетать практику с теорией — ребенок не может долго концентрировать внимание и запоминать поток информации. Нужно чередовать вид информации — слова, картинки, объяснения, и применение инструментов чтобы увидеть и пощупать что-то новое. И еще делать перерывы. Только системным подходом можно чему-то системному научить. А иначе познание так и ограничится заученными фразами, как и у всех нас. Как это ни печально, запомнить фразу проще, чем понять ее.
P.S. И, да, я так не умею. Иногда получается, но это скорее случайность + желание, чем системный процесс. Увы.
А без них многие споры являются просто бессмысленным спором о словах
:-)
Причем все исходники я не стал включать, только алгоритмическую часть включил…
Программисты ведь тоже люди.
Чтобы учесть все нужно несколько больше. :-)
Лучше порешайте на досуге.
Ничто не сравнится с ощущением победы над задачей, которую никак не удавалось решить.
Если, конечно, решение не слишком простое, иначе чувствуешь себя дураком. :-)
Хотя иногда отладчик незаменим — бывает и такое.