В Си (точнее, в C++, т.к. в Си вообще нет объектов) функции не являются объектами.
И даже не являются переменными. Есть только типизированные указатели на функцию, для которых есть операция вызова ().
Нужность — понятие субъективное.
В программировании кроме как для тривиальных функций в одну строчку можно много чего надекомпозировать. Поэтому все определяется целью.
Если это учебная программа, то имеет смысл повышать читабельность, декомпозируя для увеличения прозрачности процесса (но не больше! см. KISS).
Если это тестовый код для проверки конкретной фичи — декомпозиция не нужна.
Если же живая система… Очень много зависит от контекста, требований и команды. На текущий момент есть несколько источников, в которых эта тема хорошо рассмотрена. Предлагаю почитать «Совершенный код» и «Чистый код» для определения нужной степени детализации.
единственный плюс у эклипсы — новичку проще адаптироваться.
Ну-у, не знаю. Если иметь минимальный опыт работы с какой-либо IDE (не только для Java), то IDEA намного удобнее Eclipse. Дело даже не в плюшках, а в организации интерфейса. С ужасом вспоминаю меню настроек Eclipse, где что-либо найти достаточно трудно.
Сейчас все больше споров по поводу легальности раздач всякого рода media.
Если их-таки позакрывают, то накопленные терабайты фильмов и книг очень даже пригодятся.
Освоить новый синтаксис для решения конкретной задачи — на это уйдет не более недели. А вот вникание в концепцию — это уже порядка месяца надо.
Итого: смотрим рынок, изучаем синтаксис и идем на собеседование.
Думаю, с точки зрения работодателя выделить хорошего специалиста, который слабо владеет синтаксисом, но очень хорошо разбирается в программировании, не трудно.
Вождь программистов, который не был программистом — IMHO, довольно редкое сочетание. Либо он будет неадекватен в управлении программистами, либо он должен представлять себе процесс разработки изнутри.
Точно.
Время — самый дорогой ресурс в разработке ПО, поэтому тратить его на излишнюю документацию расточительно.
Описанное управление требованиями рассчитано на крупные проекты, которых на рынке не очень много.
Для средних и мелких проектов, ИМХО, нужно не детально фиксировать требования, а быстро создавать прототип, получать feedback от пользователей и переходить к следующей итерации. Мышлению всегда проще работать, когда есть от чего оттолкнуться. А рассматривать сферического коня в вакууме — это, конечно, полезно для развития фантазии, но совершенно бесполезно для конкретных нужд разработки ПО.
Ответ был на данное утверждение.
Все остальное сказанное считаю вполне обоснованным.
И все-таки в некоторых случаях для решения определенной задачи имеет смысл выбрать не тот язык, который принят в компании. И некоторые компании так и делают. Как правило это происходит в тех случаях, когда для выбранного языка стоимость решения задачи и дальнейшей поддержки планируется существенно меньше, чем при использовании привычного языка.
ИМХО, соглашаясь представлять информацию в виде данных, автор автоматически соглашается со всеми неотъемлемыми качествами данных, в которые входит возможность копирования.
И даже не являются переменными. Есть только типизированные указатели на функцию, для которых есть операция вызова ().
В программировании кроме как для тривиальных функций в одну строчку можно много чего надекомпозировать. Поэтому все определяется целью.
Если это учебная программа, то имеет смысл повышать читабельность, декомпозируя для увеличения прозрачности процесса (но не больше! см. KISS).
Если это тестовый код для проверки конкретной фичи — декомпозиция не нужна.
Если же живая система… Очень много зависит от контекста, требований и команды. На текущий момент есть несколько источников, в которых эта тема хорошо рассмотрена. Предлагаю почитать «Совершенный код» и «Чистый код» для определения нужной степени детализации.
Ну-у, не знаю. Если иметь минимальный опыт работы с какой-либо IDE (не только для Java), то IDEA намного удобнее Eclipse. Дело даже не в плюшках, а в организации интерфейса. С ужасом вспоминаю меню настроек Eclipse, где что-либо найти достаточно трудно.
Если их-таки позакрывают, то накопленные терабайты фильмов и книг очень даже пригодятся.
А как бы Вы выбирали из миллионов?
Хотя бы вспомнить статью Почему программисты не умеют программировать.
Итого: смотрим рынок, изучаем синтаксис и идем на собеседование.
Думаю, с точки зрения работодателя выделить хорошего специалиста, который слабо владеет синтаксисом, но очень хорошо разбирается в программировании, не трудно.
Время — самый дорогой ресурс в разработке ПО, поэтому тратить его на излишнюю документацию расточительно.
Описанное управление требованиями рассчитано на крупные проекты, которых на рынке не очень много.
Для средних и мелких проектов, ИМХО, нужно не детально фиксировать требования, а быстро создавать прототип, получать feedback от пользователей и переходить к следующей итерации. Мышлению всегда проще работать, когда есть от чего оттолкнуться. А рассматривать сферического коня в вакууме — это, конечно, полезно для развития фантазии, но совершенно бесполезно для конкретных нужд разработки ПО.
Ответ был на данное утверждение.
Все остальное сказанное считаю вполне обоснованным.
И все-таки в некоторых случаях для решения определенной задачи имеет смысл выбрать не тот язык, который принят в компании. И некоторые компании так и делают. Как правило это происходит в тех случаях, когда для выбранного языка стоимость решения задачи и дальнейшей поддержки планируется существенно меньше, чем при использовании привычного языка.