Тут имеет смысл вспомнить, что ошибка может считаться ошибкой только тогда, когда есть спецификация. Нет спецификации — нет ошибки, т.к. «ошибочное» поведение ничему не противоречит, нигде не указано, как должно быть.
По-моему тесты должны описывать контракт.
И если не можете написать тестов — скорее всего, имеет смысл пересмотреть контракт.
Вот только создавать тесты в старом проекте, в котором об IoC и не слыхивали, довольно сложно, потому как тестируемый класс может лазить в базу, например. А возводить подобную инфраструктуру просто не хватает времени.
Когда теряешься, пару раз медленно сделай вдох/выдох, и представь, что это боевая задача =) или представь, что собеседующий — это твой коллега. Тем более, что это недалеко от истины.
Извините, но без знания Framwork'ов народ частенько пытается изобретать велосипеды. И опять же, или вы ищете специалиста под конкретный, определившийся с технологиями проект, то знание конкретных framework'ов подсказывает, насколько человек в теме, и нужно ли его обучать, как с этим работать.
Понятно, что нормальный специалист через некоторое время освоится, но это порядка месяца хотя бы требует (учитывая, что еще и к проекту надо попривыкнуть).
Структурирование — один из инструментов снижения сложности.
А для допиливания под физические ограничения (сливание в один CSS-файл) как правило используются соответствующие инструменты, которые делают это автоматически при сборке.
А про сложность отладки… Firebug всегда покажет место в CSS, далее ищем строчку соответствующего правила — и находим нужное место. В два шага, чуть сложнее чем в один.
Зато за счет снижения сложности ошибок будет гораздо меньше, и расширять такую систему проще.
Точно. Правильно именованная сущность как правило используется по назначению. Все мы люди, и имеем ассоциативное мышление. Чем более размытые рамки у ключа поиска — тем больше разброс для результата и возможность ошибиться.
Помнить номера строк сложнее, чем помнить говорящие названия файлов.
Да и работать с маленькими файлами приятнее, что не говори.
А про перекрытие стилей… необходимо писать таким образом, чтобы базовые стили перекрывались специфическими, и никогда в другую сторону.
При этом я склоняюсь к подходу main.css + специфичный для раздела .css с соблюдением правила .css может перекрывать main.css, наоборот — никогда.
Лучше всего выносить нужный участок кода в функцию, после чего ее заиспользовать.
В большинстве случаев добавив пару параметров функции это удается сделать.
Естественно, эти операции проводим не ручками, а средствами IDE, чтобы избежать потенциальных ошибок copy&paste.
И если не можете написать тестов — скорее всего, имеет смысл пересмотреть контракт.
Вот только создавать тесты в старом проекте, в котором об IoC и не слыхивали, довольно сложно, потому как тестируемый класс может лазить в базу, например. А возводить подобную инфраструктуру просто не хватает времени.
P.S. парсер съел в предыдущем комменте, каюсь.
С тех пор, как узнал про CSS, про font и color забыл напрочь, и вспоминаю только если где-то увижу.
Понятно, что нормальный специалист через некоторое время освоится, но это порядка месяца хотя бы требует (учитывая, что еще и к проекту надо попривыкнуть).
Сначала вроде бы все нормально поговорили, а потом — бац! — и предлагают и должность, и ЗП пониже, чем договаривались.
Хотя у нас Нск, может быть, в Москве с этим лучше.
А для допиливания под физические ограничения (сливание в один CSS-файл) как правило используются соответствующие инструменты, которые делают это автоматически при сборке.
А про сложность отладки… Firebug всегда покажет место в CSS, далее ищем строчку соответствующего правила — и находим нужное место. В два шага, чуть сложнее чем в один.
Зато за счет снижения сложности ошибок будет гораздо меньше, и расширять такую систему проще.
Да и работать с маленькими файлами приятнее, что не говори.
А про перекрытие стилей… необходимо писать таким образом, чтобы базовые стили перекрывались специфическими, и никогда в другую сторону.
При этом я склоняюсь к подходу main.css + специфичный для раздела .css с соблюдением правила .css может перекрывать main.css, наоборот — никогда.
В большинстве случаев добавив пару параметров функции это удается сделать.
Естественно, эти операции проводим не ручками, а средствами IDE, чтобы избежать потенциальных ошибок copy&paste.
Поэтому проводить всякие рефакторинги настоятельно рекомендую в одиночку (по вечерам или на выходных)