По поводу 10.
Нужно иметь хотя бы несколько выполненных проектов близких предметных областей, чтобы можно было переиспользовать прошлый опыт. Причем переиспользовать код, как правило, удается только для всяких утилитных вещей. Можно делать по аналогии — это все равно намного дешевле, чем писать «с нуля». И забудьте про серебрянные пули — их не бывает.
Чтобы переиспользование опыта старых проектов, он должен быть задокументирован. Документации подлежат:
все нетривиальные алгоритмы;
все компоненты и расширения используемых framework'ов;
высокоуровневая модель компонентов системы;
сложные системы взаимодействия для выполнения какой-то узкой задачи (например, progress bar'ы для веба) — и диаграммы, и текстовое описание (и то, и другое необходимо);
при выполнении для нескольких заказчиков — четко фиксировать участки, специфичные для заказчика;
все детали, специально проясненные у заказчика (резюме переписок и устных бесед);
все локальные решения и предположения, принятые в обход заказчика (с указанием причин выбора);
Мотивацией документирования может служить опыт успешных разработок, которые без документации никогда бы не выжили. Например, те же используемые framework'и. Нужно четко увязать в головах зависимость между управляемостью проекта и документацией. Каждый должен понимать, что если сегодня он это не задокументирует, то завтра он наткнется на чужой код, который кто-то не задокументировал, и положит кучу времени на анализ.
В обязательном порядке необходимо осуществлять проверку качества документации на предмет содержания в ней всех деталей из указанного выше списка. Если чего-то не хватает — необходимо явно указывать на это и добавлять (все мы люди, все ошибаемся). Должно быть понимание, что качественная документация является показателем профессионализма, что бы там не говорили. IMHO, профессионал всегда способен четко изложить детали. Оформлением может заниматься кто-то еще, но полноту информации должен обеспечить разработчик.
Билдит не сразу, чтобы не падала скорость, но это с лихвой окупается их парсером и полной индексацией. У меня всего раз (на версии 7 еще) была ситуация, когда IDEA подсветила баг, где его не было. Там сложные generic'и были.
Практически все (или даже все), что есть в Netbeans, есть и в IDEA.
Наоборот неверно.
Кстати, одна из сильных фич IDEA — это Language Injection. Т.е. редактирование части текста на одном языке внутри файла, написанном на другом языке.
Например, SQL внутри XML, RegExp внутри Java-строки и т.д.
Кстати, после просмотра исходников средств рефакторинга в IDEA убедился, что, впринципе, ничто не мешает все эти средства рефакторинга расширить для поддержки C++, например.
P.S. Вот только в меньшей мере, т.к. перегрузка операций и т.д., вы же меня понимаете :-)
ИМХО, Ваш принцип необходимо применять только вкупе с принципом «разделяй и властвуй». Т.е. для небольших участков кода. Написал законченный участок — пробежал код глазками на предмет ошибок. А для более крупного кода необходимо сразу проводить декомпозицию на такие мелкие участки, накидывать план. На этом уровне действительно не нужно думать над ошибками кодирования — на нем нужно думать над ошибками логики в целом.
Ну, и так далее. На каждом уровне — своя детализация и упор на разные типы ошибок. И, тем не менее, принцип маленьких, обозримых блоков, очень хорошо работает. С одной стороны — красивый и структурированный дизайн, с другой — не менее красивый и корректный код. Иногда некорректный — но процент подобных ошибок падает с опытом. Просто на автомате учитываешь разные варианты входных данных, не задумываясь.
Хотел бы добавить, что не зря придумали парное программирование.
Оно позволяет разделить написание и анализ кода между двумя разными людьми, но в одно и то же время.
Эффективность этого подхода, насколько я знаю, всегда оказывалась выше, чем просто написание и анализ кода обоими по-отдельности.
Ну и что?
Я лично часто после логически законченного участка кода вставляю assert'ы.
Во-первых они повышают субъективную уверенность в коде, во-вторых — никак не влияют на производительность. И, в-третьих, не отнимают много времени.
Есть абстрактный класс BigImage, у него подклассы BmpBigImage и GifBigImage, методы Load() и Show().
Есть абстрактный класс BigImageImp, у него подклассы WinImage и Os2Image, методы LoadImageFromFile() и PaintImage().
В иерархии BigImage зашиты алгоритмы работы с форматами GIF и BMP и определение участка, необходимого для текущей обработки, подготовка абстрактного представления картинки для вывода в соответствии с форматом изображения.
Иерархия BigImageImp занимается эффективностью операций работы с файлами для конкретной ОС и отображением (части) картинки заданного формата нативными средствами.
BigImage — абстракция формата хранения, они специфицированы и независимы от ОС.
BigImageImp — абстракция низкоуровнего характера, обеспечивающая эффективность атомарных операций для первой иерархии.
Нужно иметь хотя бы несколько выполненных проектов близких предметных областей, чтобы можно было переиспользовать прошлый опыт. Причем переиспользовать код, как правило, удается только для всяких утилитных вещей. Можно делать по аналогии — это все равно намного дешевле, чем писать «с нуля». И забудьте про серебрянные пули — их не бывает.
Чтобы переиспользование опыта старых проектов, он должен быть задокументирован. Документации подлежат:
Мотивацией документирования может служить опыт успешных разработок, которые без документации никогда бы не выжили. Например, те же используемые framework'и. Нужно четко увязать в головах зависимость между управляемостью проекта и документацией. Каждый должен понимать, что если сегодня он это не задокументирует, то завтра он наткнется на чужой код, который кто-то не задокументировал, и положит кучу времени на анализ.
В обязательном порядке необходимо осуществлять проверку качества документации на предмет содержания в ней всех деталей из указанного выше списка. Если чего-то не хватает — необходимо явно указывать на это и добавлять (все мы люди, все ошибаемся). Должно быть понимание, что качественная документация является показателем профессионализма, что бы там не говорили. IMHO, профессионал всегда способен четко изложить детали. Оформлением может заниматься кто-то еще, но полноту информации должен обеспечить разработчик.
Идеальный код — это абстракция, не имеющая инстансов :-)
IMHO, не самая удачная IDE для Java.
Наоборот неверно.
Кстати, одна из сильных фич IDEA — это Language Injection. Т.е. редактирование части текста на одном языке внутри файла, написанном на другом языке.
Например, SQL внутри XML, RegExp внутри Java-строки и т.д.
P.S. Вот только в меньшей мере, т.к. перегрузка операций и т.д., вы же меня понимаете :-)
P.S. Привет-привет :-)
Ну, и так далее. На каждом уровне — своя детализация и упор на разные типы ошибок. И, тем не менее, принцип маленьких, обозримых блоков, очень хорошо работает. С одной стороны — красивый и структурированный дизайн, с другой — не менее красивый и корректный код. Иногда некорректный — но процент подобных ошибок падает с опытом. Просто на автомате учитываешь разные варианты входных данных, не задумываясь.
Оно позволяет разделить написание и анализ кода между двумя разными людьми, но в одно и то же время.
Эффективность этого подхода, насколько я знаю, всегда оказывалась выше, чем просто написание и анализ кода обоими по-отдельности.
Я лично часто после логически законченного участка кода вставляю assert'ы.
Во-первых они повышают субъективную уверенность в коде, во-вторых — никак не влияют на производительность. И, в-третьих, не отнимают много времени.
А в «в моей программе ошибок нет» либо слепо верим, либо так же слепо не верим.
Неизбежная плата за гибкость.
Есть абстрактный класс BigImage, у него подклассы BmpBigImage и GifBigImage, методы Load() и Show().
Есть абстрактный класс BigImageImp, у него подклассы WinImage и Os2Image, методы LoadImageFromFile() и PaintImage().
В иерархии BigImage зашиты алгоритмы работы с форматами GIF и BMP и определение участка, необходимого для текущей обработки, подготовка абстрактного представления картинки для вывода в соответствии с форматом изображения.
Иерархия BigImageImp занимается эффективностью операций работы с файлами для конкретной ОС и отображением (части) картинки заданного формата нативными средствами.
BigImage — абстракция формата хранения, они специфицированы и независимы от ОС.
BigImageImp — абстракция низкоуровнего характера, обеспечивающая эффективность атомарных операций для первой иерархии.
Опишите, как Вы это реализуете без моста )