Как научиться решать задачи в java теория

Как решить задачу, если непонятно, с чего начать: советы от Хекслета

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

С чего начать

Обычно самое сложное в решении задачи — сделать первый шаг. Особенно на старте обучения, когда опыта ещё нет, может показаться, что вы совершенно ничего не понимаете и не способны решить даже самое простое упражнение. Если вы читаете задание и у вас нет никаких идей, с чего же вообще начать, мы предлагаем начинать с самых маленьких шагов.

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

Главный принцип решения задач — дробить задачу на подзадачи. Не пытайтесь сразу решить большое и сложное упражнение с первого подхода, делайте это постепенно. Если в задании сказано написать и экспортировать функцию, напишите пустую функцию и экспортируйте её. Ваш код в большинстве случаев уже будет работать, хоть и не проходить наших тестов. Проверьте примеры вызова функции, которую вам надо написать, посмотрите, что в неё передаётся. И так шаг за шагом продвигайтесь к реализации полного и нужного вам решения.

Ищем ошибки в коде

Важная часть работы над задачей — это поиск ошибок, который начинается с логов. Это то, что выводит программа во время своего выполнения. Например, когда вы запускаете проверку вашего решения во вкладке OUTPUT отображается вывод работы тестов — это и есть логи. Вы можете добавлять к этому выводу любой собственный вывод, используя инструменты своего языка программирования (например в JS — console.log() ).

Залогируйте входящие данные — это поможет понять, с чем придётся работать внутри функции. Как это сделать, мы рассказываем в наших справочных материалах. Для удобства вывода логов вы можете добавлять свои метки, чтобы видеть, какая именно переменная выводится. Например, так может выглядеть логирование в JS:

export default (first, second) =>  console.log('--------------------- START ------------------'); console.log('параметры:'); console.log(first); console.log(second); . console.log('Результат'); console.log(result); >; 

Отметка «START» нужна, чтобы увидеть, в какой именно момент вызывается ваша функция. Например, в упражнениях на Хекслете часто идёт проверка через тесты, которые несколько раз запускают нашу функцию с разными данными. Таким образом, в выводе информации можно будет легче разобраться, что и к какому запуску вашей функции относится.

Иногда вместо логирования гораздо удобнее использовать дебаггер. Например, если вы делаете упражнение, в котором есть Web-доступ, можно открыть DevTools браузера и посмотреть в нём исполняемый код. Здесь вы можете поставить на паузу выполнение программы и посмотреть, чему равны все значения переменных или констант в текущий момент.

Изолируем код

При знакомстве с задачей старайтесь сразу определять сложные моменты и максимально их прорабатывать. Например, если в решении нужно использовать цикл, а вы ещё плохо знакомы с ними, можно отдельно от решения попрактиковаться в их использовании. Старайтесь больше экспериментировать и подводить пример максимально близко к тому, что происходит в задаче.

Выделение изолированных участков кода — еще один важнейший механизм в решении задач. Попробуйте выделить в вашем алгоритме промежуточные результаты — так вы сможете написать отдельные модули, каждый из которых будет вычислять нужный результат. При этом логика таких модулей будет максимально простой и понятной. Тут мы подходим пожалуй к самой сложной вещи: построение алгоритма.

Описываем алгоритм

Решение любой задачи начинается с алгоритма, после чего уже идет его реализация. С ней обычно всё понятно: мы либо знаем, как нужно делать, либо не знаем — и вот тогда нужно искать информацию, читать документацию и так далее. Отдельным пунктом в реализации идёт работа над ошибками — об этом мы расскажем чуть позже.

Начните продумывать алгоритм без контекста языка программирования. Есть такое понятие как псевдокод — это конструкции, очень похожие на язык программирования, но не привязанные к какому-то конкретному языку. Они помогают составить алгоритм решения задачи и перенести его в код.

Попытайтесь описать решение простыми словами другому человеку. Есть даже такой приём, он называется «метод утёнка» — это когда вы описываете, что делает каждая строчка вашего кода воображаемому собеседнику (игрушечной уточке). Этот приём работает не только когда код уже написан, но и ещё при поиске верного алгоритма. Когда вы описываете проблему другому человеку, вам невольно приходится систематизировать всю информацию, формализовать некоторые идеи и возможные пути решения, а это уже первый шаг к составлению работающего алгоритма.

И не стесняйтесь просить помощи. Не стоит расстраиваться, что у вас не получается решить с первого раза. А когда задаёте вопрос, задавайте его правильно. Когда у вас уже есть какое-то решение, но оно не работает, наступает следующий этап работы.

Читайте также: Как сохранять фокус на протяжении всего обучения: советы от Хекслета

Проверяем каждую идею

Даже опытные программисты далеко не всегда с первого подхода реализуют правильное решение. Обычно создаётся первый, черновой вариант решения, и уже дальше он дорабатывается. В ходе работы над ошибками очень важно проверять каждый участок кода.

Постарайтесь проверить каждый промежуточный результат, залогируйте изменения данных, разберите на мелкие детали работу вашего кода. Одна из самых распространенных ошибок в программировании это построение дальнейшего решения на неверных выводах. Например, вы написали какой-то код и считаете, что он работает верно. Далее вы добавляете код, но что-то уже не работает как надо. Можно сделать вывод, что проблема в новом коде, однако вполне возможно, что просто изначальный код был не верен. Такая ситуация опасна тем, что вы можете потратить очень много времени впустую — потому что просто будете искать проблему не в том месте.

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

Делаем шаг назад

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

Пройденный материал ещё полезно перепроходить и потому, что это хорошая подпитка вашей мотивации: вы будете быстрее решать уже пройденные задачи. Таким образом вы на себе почувствуете прогресс, это даст уверенности, что вы движетесь в правильном направлении.

Никогда не останавливайтесь: В программировании говорят, что нужно постоянно учиться даже для того, чтобы просто находиться на месте. Развивайтесь с нами — на Хекслете есть сотни курсов по разработке на разных языках и технологиях

Java. Решение практических задач

Книга Анджела Леонарда позиционируется как каталог типовых решений для Java разработчиков младшего и среднего уровней. Заявляется, что представленные решения производительны, корректны и поддерживаемы.

В книге все разбито на «задачи». Они тут нескольких типов:

• Алгоритмические задачи — 10%
• Структуры и алгоритмы — 5%
• Теория языка Java — 10%
• Стандартная библиотека Java — 50%
• Практические приёмы — 25%

Алгоритмические задачи здесь начального уровня. Их мало. Но самое интересное — это предлагаемые решения. Автор пишет, что книга поможет укладываться в сроки. В этом она похожа на рецепты со https://stackoverflow.com/ с ровно тем же результатом: работать может и будет, но в большинстве случаев так делать не стоит. Нет, я, конечно, больше за экономическую целесообразность и согласен с цитатой:

Преждевременная оптимизация — корень всех зол.

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

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

По поводу удобочитаемости тоже можно было бы поспорить, но это, в конце концов, дело вкуса. Но вот неэффективность никуда не денешь. Например, в задаче отыскания самого часто встречающегося символа предлагается в карте символ→количество искать максимум через Collections.max() для values() , а потом ещё циклом пройтись по entrySet() и поискать какой же getKey() соответствует значению, которое вернула Collections.max() .

Автор часто прибегает к регулярным выражениям там, где они совершенно излишни. И даже не предлагает их предварительно компилировать, а все время норовит вызвать replaceAll() или split() прямо внутри тела цикла. Опять же, можно было бы поспорить, что split() оптимизирована для случая односимвольного разделителя и не будет для них применять регулярные выражения. Однако, автор про это ни разу не упоминает. Более того, автор регулярно напоминает использовать Pattern.quote() при передаче параметра в split() , а значит он подразумевает именно регулярные выражения. Но даже если опираться на оптимизацию split() для односимвольных разделителей, то можно видеть, что внутри у нас ArrayList из которого данные копируются в новый массив, а автор после чуть ли не каждого split() предлагает конвертировать массив в список через Arrays.asList() . Копирования и мусор в куче, который надо будет собирать, автор просто игнорирует. StringTokenizer , по утверждению автора, обладает меньшей производительностью и из-за этого его не рекомендуется использовать. Нет, StringTokenizer , рассчитанный на Unicode code pointы и несколько разделителей, действительно медленнее в плане обработки строки по сравнению со split() при односимвольном разделителе (за вычетом дополнительного мусора и копирований). Но автор в своей сноске явным образом говорит про гибкость регулярных выражений. Да, в Javadoc на StringTokenizer есть рекомендация по использованию split() , но там нет ничего про производительность. На самом деле речь идет о том, что StringTokenizer — это Enumeration , а не Collection и значит придётся писать явный цикл для обхода, копирования и тому подобного. Не более.

StringTokenizer tokenizer = new StringTokenizer("abc, def, xyz", ";, "); List tokens = new ArrayList<>(tokenizer.countTokens()); while (tokenizer.hasMoreTokens())

Ну или тупо Collections.list() , если лень или повторное сканирование перевешивает динамический рост списка. Если хочется красоты и однострочности, то начиная с Java 9 можно сделать .asIterator().forEachRemaining() и оно ничем не будет отличаться от цикла for-each.

new StringTokenizer("abc, def, xyz", ";, ") .asIterator().forEachRemaining(System.out::println);

Вообще автор везде сует потоки с цепочками вызовов заканчивающимися collect(Collectors.toList()) и ни разу не упоминает, что список будет динамически расти, что данные будут копироваться, что мусор потом придется собирать.

Можно опять поспорить, что это копейки и на сложность алгоритма в целом не влияет. Плюс/минус 5-10% (кто же будет профилировать?) — не высокая цена за скорость разработки. Пусть так. Соглашусь. Часто важнее скорость разработки, а не скорость работы. Но тут же можно найти рецепт как скопировать объект через JSON:

1. Берем исходный объект;
2. Сериализуем его в JSON;
3. Парсим получившийся текст;
4. Копия объекта готова!

И это не прикол, а целая «задача» с детальным описанием рецепта и примером кода. Бери и копипасти. И ни слова о том, на сколько это будет быстро.

Часто говорят, что Java — это тормоза и излишнее потребление памяти. Есть мнение, что проблема не в Java, а в том как на Java пишут. Так вот автор не сильно старался сделать решения эффективными по времени или потреблению памяти.

Про структуры и алгоритмы в книге откровенно мало. В стандартной библиотеке конечно много всего готового и свое реализовывать надо не так уж и часто. Но можно было бы рассказать про варианты представления деревьев и графов с использованием инструментария Java. Дерево Фенвика и фильтр Блума здесь рассмотрены чисто для галочки.

Много «задач», в которых рассказывается о самом языке Java. В основном речь идет о нововведениях после Java 8:

• Новые выражения switch ;
• Автоматический тип локальных переменных и var ;
• Функциональные интерфейсы и лямбда-выражения.

С одной стороны это все полезно. Даже не новичку. Особенно когда подается в виде практических рецептов. Но есть проблемы. Например, автор утверждает, что автоматические типы улучшают сопровождаемость кода. Приводится пример, когда локальная переменная — результат возврата функции, функцию позже поменяли и автоматическая переменная волшебным образом изменила свой тип. В коде ничего менять не надо и все счастливы. Другой пример — использование автоматического типа для «исправления» непонимания программистом того, какой же тип вернет тернарный оператор. Ну или предложение прятать тип элемента в цикле for-each. Я бы еще мог понять, если бы речь шла о длинных вложенных обобщенных типах:

Map headers = new HashMap<>(); for (Map.Entry entry : headers.entrySet())

Тогда хоть какой-то смысл появляется:

Map headers = new HashMap<>(); for (var entry : headers.entrySet())

Но автор говорит о другом. О том, что можно менять тип элементов коллекции (с int на String ) и не заморачиваться изменением кода. Сразу вспоминаешь, что Groovy ругают за def .

Также сомнительны рецепты с заменой классических шаблонов на лямбды. Смысл ведь был в инкапсуляции и полиморфизме, а тут все кишки наружу. Нет, кодить конечно быстрее, но будет ли экономия, когда придётся выбросить и переписать с нуля?

Не могу согласиться с рецептами тестирования лямбд. Тестирование — это проверка соответствия контракту. Какой контракт у лямбда-выражения? Аналогично с отладкой путем System.out.println() . Кто, как и когда будет всё это потом вычищать? А ведь будут последствия. Вместо навязчивой рекламы лямбда-выражений и рекомендаций по запихиванию их всегда и везде стоило бы описать где и когда их применять не стоит и как и на что их надо заменить. С примерами.

Стандартная библиотека — это основная часть книги. Масса рассказов, что есть вот такой-то класс или метод, полезный тем и этим. Много и более практических рецептов: если стоит такая-то задача, то решается она так-то. В принципе, все эти практические рецепты работы с датами, коллекциями, файлами, потоками, интроспекцией, многопоточностью, инструментами синхронизации, клиентом HTTP и WebSocket полезны. Особенно, если не штудировал Javadoc и не читал Core Java в двух томах.

Но в бочке мёда снова не обошлось без кастрюли дёгтя ибо есть масса неточностей и неверностей. Например, рекомендуется локальную дату конвертировать в UTC, используя нулевой сдвиг. Работать это будет только в городе Гринвич.

LocalDateTime local = LocalDateTime.now(); Instant suggested = local.toInstant(ZoneOffset.UTC); Instant correct = local.atZone(ZoneId.systemDefault()).toInstant();

Другой пример, когда автор утверждает, что List.replaceAll() и цикл с List.set(i,v) «должны работать практически одинаково». Для ArrayList это может и так, но есть и другие списки. Нет, работать LinkedList.set(i,v) в цикле будет конечно корректно, но совсем не также как ListIterator.set(v) , используемый в LinkedList.replaceAll() . Автор на такие мелочи внимание не обращает.

Частенько автор противоречит Javadoc. Например, при описании ExecutorService.invokeAll() написано:

первый вызов метода Future.get блокирует до тех пор, пока не будут завершены все экземпляры Future .

То есть, как будто между разными Future есть какая-то связь и они друг друга ждут. На самом деле ничего такого не происходит, а блокируется не столько Future.get() , сколько ExecutorService.invokeAll .

Ну или другой пример расхождения с официальной документацией — это секция про StampedLock и оптимистическую блокировку. Весь смысл оптимистичных блокировок в отсутствии блокировок. В данном случае, если очень много читателей, то писатель может ждать слишком долго, особенно для non-fair случая по умолчанию. Так вот StampedLock как раз и позволяет избежать блокировки писателя. Правильный пример кода можно найти в официальной документации:

double distanceFromOrigin() < long stamp = sl.tryOptimisticRead(); try < retryHoldingLock: for (;; stamp = sl.readLock()) < if (stamp == 0L) continue retryHoldingLock; // possibly racy reads double currentX = x; double currentY = y; if (!sl.validate(stamp)) continue retryHoldingLock; return Math.hypot(currentX, currentY); >> finally < if (StampedLock.isReadLockStamp(stamp)) sl.unlockRead(stamp); >>

Перед возвращением (фиксацией результата) мы проверяем не было ли значение изменено. При необходимости перечитываем и заново вычисляем. Мы стараемся, по возможности, избежать readLock() , которая заблокирует писателей.

А что предлагает автор? Автор предлагает делать validate() сразу за tryOptimisticRead() и ничего не делать, если validate() скажет, что записи не было (между tryOptimisticRead() и validate() ). Налицо непонимание того, как работает StampedLock и нежелание разобраться в примере из библиотечной документации.

Практические приёмы — это всякие полезные практические хитрости, которые напрямую не указаны в документации, ну или просто указание на неприметный, но полезный класс в стандартной библиотеке:

• Преобразование 1000 в 1K и тому подобное.
• Комбинирование Stream.reduce() , Function.identity() и Function.andThen() на списке функций для вызова их цепочкой.
• Генераторы потоков.

Сильно портит книгу перевод:

• Масса опечаток.
• Для многих терминов используется транслитерация вместо перевода («состояние терминации», «дерегистрированных участников», «конкурентно запустить», «с несколькими имплементациями этого интерфейс»).
• И наоборот, некоторые термины переведены крайне странно («обход должен быть жестоко терминирован», «альтернатива подклассированию», «стековая трасса сбоя», «замок на уровне объекта», «будет уменьшать стопор», «семафор может начинаться и умирать», «продвинуть исключение», «приращение», «атомарно наращивает переменную»).
• Ближе к концу книги, переводчик перестал заморачиваться и так и оставил машинный перевод с тут и там несогласованными окончаниями.

Орфография — это неприятно, но терпимо. Но терминология — это серьезней. Часть просто неприятно читать. Например, все эти многонитиевости. Причем, переводчик не поленился и расписал целую секцию почему именно нити, хотя редактор в сноске указала, что потоки. Но или уговорить не удалось, или (что видно по числу опечаток) ограничилась первым десятком страниц.

Вот научится человек стопорам, тупикам и запираниям на замок, и попробуй, пойми потом, что речь о CountDownLatch , deadlock и acquire lock (затвор, взаимная блокировка и получение блокировки в терминах той же Core Java).

В главе про шаблоны используется термин трафаретный метод. При этом, в тексте даже есть ссылка на GoF. То есть переводчик, даже если он не специалист в данной предметной области, мог просто подглядеть. А ведь шаблоны — это ещё и язык, который призван помочь в объяснении того, как система устроена или должна быть устроена.

Есть места, где корявый перевод меняет смысл написанного. Например:

Блокирующая нить исполнения обычно находится в состоянии BLOCKED …​

Неопытный разработчик может и не понять, что речь о том потоке, который был заблокирован, а не о том, который блокирует.

Резюмируя, можно сказать, что книга крайне неоднозначна. Опытный разработчик может найти что-то новое, если не следил за эволюцией. Может освежить память о том, что давно не использовал. Или даже может найти пару рецептов, о которых ранее не знал. Не очень опытный разработчик может узнать очень много. Это даже может быть лично ему полезно, чтобы «укладываться в сроки». Также как может быть полезен https://stackoverflow.com/, чтобы копипастить оттуда первый попавшийся рецепт. Если новичок «вырастит» на этой книге, то велик шанс того, что его работу придется переделывать. А ведь он ещё и может ссылаться на данную книгу в обоснование своей точки зрения. Тогда и взаимопонимание может быть затруднено. Хоть автор и позиционирует книгу для начального и среднего уровней, я бы рекомендовал её (и то не сильно) только сложившимся разработчикам. Прочитавший же её новичок будет просто опасен.

• Java
• Алгоритмы
• Профессиональная литература

Как научиться решать задачи на Java?

Всем привет, у меня такая ситуация.
Закончил бакалавр айти, за 4 года бездельничал, было не интересно программирование, короче провел за Dota 2, CS GO свои 4 года. И вот как не странно, после окончания универа(как я его закончил не спрашивайте, преподам было глубоко плевать на твои знания, хоть и было 0 коррупции) меня дико заинтересовало программирование.
И вот моя проблема. Я поступил в Польше на магистратуру, и там полный завал, преподают так, что я ничего не понимаю, ибо они ожидают, что мы уже суперпупер программисты. Причем там их усложняют, тоесть допустим задачу можно решить разными способами, но они ставят условия, чтоб ты решал определенным. Так вот. Мои знания на уровне видеоуроков, я понимаю основы, понимаю ООП(на процентов 50-70%). И я не знаю что мне нужно и как мне нужно заниматься, чтобы научиться решать задачи.
Я знаю про Array/Linkedlist, знаю такие классы как Scanner, File(reader, writer и тд), знаю про Socket, ServerSocket, и короче все отрывками, что уложилось в голове, то-есть я не могу самостоятельно решить не одну задачу, даже самую простую.

Открывал сайты с задачниками, не мог сделать ни одну арефметическу, с файлами, массивами и тд задачи.
Тоесть допустим я умею создавать и объекты, и файл создать, массив, но решить по ней задачу я не знаю как, даже самые елементарные на первый взгляд.(например. Дан текстовый файл, содержащий целые числа. Удалить из него все четные числа.)
И я не понимаю, что нужно мне, чтоб научиться, я не нашел ни одного видеоурока, где бы рассказывали и объясняли как нужно мыслить, что нужно уметь, чтобы решать задачи. Везде просто теория+пример самых обычных и тупых заданий типа как в ООП class Animal cat, dog бла бла, короче юзлесс примеры, которые никак на практике не используются. А когда я открываю реальный код или реальные задачи с универа, я просто потерян и без понятия как это делается и что там происходит.
Вот такой у меня ступор. Не знаю как взять и изучать эти классы, методы, говорят их тысячи, и что нет смысла их всех запоминать, но ведь как то программистов я вижу и они мне сразу начинают отвечать, что и как нужно использовать в какой задаче(какой класс нужен, какой метод), значит они как то запомнили их.
Короче прошу вас очень, обьяснить, что мне делать и как обучаться в такой ситуации.

Лучшие ответы ( 1 )
94731 / 64177 / 26122
Регистрация: 12.04.2006
Сообщений: 116,782
Ответы с готовыми решениями:

Надо решать задачи по Java. Посмотрите
1. Дана символьные строки. Надо найти короткое слова на букву "а" и заменить ее первым словом из.

Как научиться быстро решать задачи.Советы, литереатура?
Совсем недавно начал изучать Си. Я очень люблю программировать на Си. Могу с утра до ночи это.

Как «научиться» решать задачи по теории вероятностей?
Здравствуйте уважаемые, подскажите пожалуйста, как "научиться" решать задачи по теории вероятности.

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

3638 / 2970 / 918
Регистрация: 05.07.2013
Сообщений: 14,220

Сообщение было отмечено Kukstyler как решение

Решение

открываешь на форуме любую тему, читаешь задачу, решаешь, если непонятно что-то — гуглишь, если совсем мозгов нет — смотришь решение. Повторяешь 100500 раз, . PROFIT!!1111

Как научиться решать задачи [закрыт]

Закрыт. На этот вопрос невозможно дать объективный ответ. Ответы на него в данный момент не принимаются.

Хотите улучшить этот вопрос? Переформулируйте вопрос так, чтобы на него можно было дать ответ, основанный на фактах и цитатах.

Закрыт 7 лет назад .

Всем доброго дня! Год назад я начал изучать Pascal, сейчас перешел к программированию с++. Читаю, смотрю курсы, изучаю синтаксис. Но, нет четкого алгоритма решения задачи. Нет вообще представлений как решать задачу. Вроде бы есть догадки, но это все сводится к не решению. Чита ю множество материалов о различных алгоритмов но нет понятии структуры кода((. Посоветуйте, как можно научиться решать задачи. HELP

Отслеживать
5,185 3 3 золотых знака 23 23 серебряных знака 48 48 бронзовых знаков
задан 15 дек 2013 в 20:32
Nursultan Daupayev Nursultan Daupayev
1 1 1 серебряный знак 1 1 бронзовый знак
а что именно вы подразумеваете под задачами?
15 дек 2013 в 20:34

Решать задачи язык программирования не учит, он является инструментом решения задач. Для разных задач могут использоваться разные языки и методики решения. ООП или функциональное и т.д. Структура кода так же выбирается разработчиком (программистом); то, как будет выглядеть проект, его внутренности, зависит от задачи, сроков ее решения и инструментов которые будут использоваться. В учебных заведениях обычно начинают с выработки у учащихся понимания принципа работы компьютера, программы. Начинается все с блок-схем и решения примитивных задач (проверок на да\нет, уравнений a=b+c . ).

15 дек 2013 в 21:49

Задача 1. Проверить, начинается ли каждый из членов последовательности с цифры, на которую оканчивается предыдущий Задача 2. Проверить, является ли последовательность пилообразной? таких вот типов задач имею ввиду