«Все имена классов и переменных должны быть понятны даже новому разработчику. Избегайте длинных имен и аббревиатур.»
Тут явное противоречие. Аббревиатуры используются для того, чтобы сократить длинные имена. Короткие имена становится трудно читать, потому что обычно их сокращают до неузнаваемости от оригинального слова, получается они не понятны. Может быть тут идет речь о каких-то супер длинных именах?
«Архитектурные решения должны быть наиболее простыми. Не нужно закладывать в приложение зачатки будущей функциональности.»
Есть два типа простоты. Простота в написании здесь и сейчас этого метода. И простота его поддержки и возможность расширения функционала. Если не думать о возможных требованиях к коду в будущем, получается простота по первому типу и сложность по второму. А все мы знаем, что отлаживание и существующего кода происходит гораздо дольше, чем написание нового. В итоге сложность поддержки скажется гораздо существеннее на времени разработки, если делать все как бог на душу положит. Ну конечно стоит минимизировать сложность первого типа, где возможно но и не забывать про возможную расширяемость и мзменения требований.
О, и у меня еще много вопросов про Eclipse!
Как навесить hot-key на action «Extract Constant»?
Есть ли хоткей, чтобы перейти к следующей ошибке в файле?
Есть ли возможность перейти в конкретную имплементацию метода в подклассе, если находишься в интерфейсе?
Как удалить плагин, который не понравился?
Можно ли две кнопки «Open file» и «Open folder» заменить на «Open»? Это когда хочешь подключить исходники и не знаешь они в зипе лежат или в отдельной папке. И если не угадал, приходится весь путь сначала проходить другой кнопкой.
И наконец можно ли убрать эту гадость?
Спасибо.
А разве продолжительное хранение сессии на сервере в течении месяца это просто и лаконично??? Особенно если к сессии какие-нибудь объекты привязаны… По идее за такое должны по рукам бить.
Просто есть люди, которые думают, что если они не понимают, как что-то сделать, значит никто больше не в состоянии в этом разобраться. Особенно удручающе, если это сочетается с проблемами в самооценке, такой эскулап на высоких должностях обычно не дает проходу практически никаким свежим идеям.
«самый плохой из которых — это анти-паттерн «переделать заново» («do over»)» — к сожалению с этим вынужден не согласиться. Все еще существуют системы, которые выполнены не в соответствии с принципами, приведенными в топике, и их проще переделать, чем рефакторить. Да и тов. Брукс писал, что первая система всегда разрабатывается на выброс, так что даже следование данным правилам, не факт, что приведет к желаемому результату, но Очень сильно поможет направить проект в нужное русло, если развитие пошло криво. Вообщем контент в заклады. Каждый архитект должен иметь подобный чеклист под рукой.
Понимание тенденций это конечно хорошо. Но не кажется ли Вам, что это не то же самое, что отслеживание багов в бета версиях? Тестировать Crome Вы конечно можете, но если бы вместо этого вы потратили свое время на имплементацию какой-нибудь полезной фичи для клиентов они бы Вам были более благодарны. Вариант, когда у вас вагон времени и вы готовы его потратить не только на себя и своих клиентов но и помочь гуглу с тестированием, не рассматриваем.
Попробуйте отгадать, в какое время года фитнесс-клубы больше всего забиты посетителями?
Январь-Февраль. Это все те, кто собираются начать новую жизнь с нового года. В лучшем случае через пару месяцев от них в зале не остается и следа. Не становитесь в очередь тех, кто начинает что-то делать с нового года или понедельника. Действовать нужно здесь и сейчас.
Тут явное противоречие. Аббревиатуры используются для того, чтобы сократить длинные имена. Короткие имена становится трудно читать, потому что обычно их сокращают до неузнаваемости от оригинального слова, получается они не понятны. Может быть тут идет речь о каких-то супер длинных именах?
«Архитектурные решения должны быть наиболее простыми. Не нужно закладывать в приложение зачатки будущей функциональности.»
Есть два типа простоты. Простота в написании здесь и сейчас этого метода. И простота его поддержки и возможность расширения функционала. Если не думать о возможных требованиях к коду в будущем, получается простота по первому типу и сложность по второму. А все мы знаем, что отлаживание и существующего кода происходит гораздо дольше, чем написание нового. В итоге сложность поддержки скажется гораздо существеннее на времени разработки, если делать все как бог на душу положит. Ну конечно стоит минимизировать сложность первого типа, где возможно но и не забывать про возможную расширяемость и мзменения требований.
у меня эклипс 3.3.1.1
Как навесить hot-key на action «Extract Constant»?
Есть ли хоткей, чтобы перейти к следующей ошибке в файле?
Есть ли возможность перейти в конкретную имплементацию метода в подклассе, если находишься в интерфейсе?
Как удалить плагин, который не понравился?
Можно ли две кнопки «Open file» и «Open folder» заменить на «Open»? Это когда хочешь подключить исходники и не знаешь они в зипе лежат или в отдельной папке. И если не угадал, приходится весь путь сначала проходить другой кнопкой.
И наконец можно ли убрать эту гадость?
Спасибо.
Январь-Февраль. Это все те, кто собираются начать новую жизнь с нового года. В лучшем случае через пару месяцев от них в зале не остается и следа. Не становитесь в очередь тех, кто начинает что-то делать с нового года или понедельника. Действовать нужно здесь и сейчас.