Самые красивые оркестровые композиции придумываются, когда я иду с работы домой.
И потом никогда не могу их вспомнить. :-)
Остается только чувство восторга: «какая здоровская была мелодия!».
Зато я точно знаю, что когда-нибудь завтра будет другая, тоже здоровская.
И мне не важно, лучше или хуже она предыдущей.
И мне не важно, что ее никто кроме меня не услышит.
И мне даже не важно, будет ли завтра другая. Может, и не будет.
Но я живу сегодня. На возможный максимум при текущем физическом и психическом состоянии, знаниях и т.д.
И именно это для меня ценно — быть собой и идти вперед, расставаясь с прошлым и встречая будущее.
И, самое главное — возможно, завтра я буду думать иначе, даже прямо противоположно сегодняшнему.
Так что главной задачей дня является… что?.. Система контроля изменений. :-)
Люди, столько много слов и споров…
Исходите из задачи и критериев оценки качества.
Определите, что хорошо, что плохо, и что в вашем случае более значимо.
Сведите это к одной шкале, чтобы для любой реализации в этих условиях можно было сказать, хуже или лучше она другой реализации.
И только тогда можно начинать сравнивать.
Иначе получается, что сравниваем теплое с мягким, акцентируя на разных сторонах одной проблемы, и используя свои личные весовые категории.
А в разных системах оценки одно и то же решение редко оказывается одинаково приемлемым.
Думаете, почему многие проблемы более-менее решаются инженерными способами, но не имеют адекватных решений в научных трудах? Все дело в постановке задачи.
Дублирование бывает разное.
Необходимо устранять семантическое дублирование (когда одинаковые действия производятся для одинаковой цели).
И не нужно устранять простое синтаксическое дублирование (когда синтаксис языка требует от Вас писать так, а не эдак), если за ним нет единой семантики.
Привести пример второго типа сложно, но мне два-три раза такое попадалось.
И еще один пример: не нужно устранять дублирование, если оно является частью разных бизнес-сценариев, подверженных изменениям. Завтра сценарии могут разойтись — и общие части придется опять распиливать. А вовремя сдублировать ветку кода для независимой модификации — этого не умеют делать многие миддлы, не говоря уже о Junior'ах. Как раз потому, что знают принцип «устранения дублирования», но не понимают его суть.
Не нужно ничего добавлять.
Это все уже было и повторялось везде и всюду.
Программирование — очень молодое искусство, поэтому проходит те же стадии развития.
Для драйверов тоже не пойдет.
Мне почему-то кажется, что не только меня бесит, когда при работе на грани доступной памяти система в произвольный момент времени может умереть.
Для прояснения контекста: работаю без SWAP, т.к. если Java начинает вытесняться в SWAP все становится ну очень печально — проще все закрыть и открыть заново.
P.S. В Windows 7 по сравнению с предыдущими версиями получить эту ошибку на уровне драйвера намного труднее.
Бинго.
И тут нас может спасти умение быстро адаптироваться под обстоятельства.
Если не можешь быстро из программиста стать сантехником — ты попал. :-) (утрирую, конечно же)
Большинство работают «на дядю», т.е. на работодателя.
А в этом случае работодатель запросто может отправить «на пенсию» — попросту уволить.
И в этом случае не все смогут найти себе нишу.
Быдлокодеры рождаются другим путем.
Они ищут высокой прибыли.
Они готовы отдать за это время и усилия.
Но у них нет желания учиться.
Именно поэтому у них в коде все печально.
У большинства детей это отобьет охоту разбираться.
Такие «нотации» им только мешают.
Они становятся нужны на этапе «куда дальше расти?», когда уже можешь писать код, но не знаешь, как разработать систему и интегрировать ее с тем, с тем и еще с тем.
Кодер пишет код.
Программист пишет программу.
Разработчик разрабатывает систему и строит бизнес-процесс, поддерживаемый этой системой.
Часто разработчик по-совместительству допиливает и процесс самой разработки.
1. Иногда программист не пишет логов, ибо их некуда писать. Например, на микроконтроллере.
2. Иногда программист не пишет тестов, ибо для их написания нужно отрефакторить такую кучу legacy-кода, который написали до него, что он понимает нецелесообразность этого действа.
3. Иногда программист может не знать про какой-то код ошибки одной из внутренних библиотек, которую используют уже давно, и у нее нет автора, исходников и документации. Как-то работает — и все тут.
Да, и иногда программист может некорректно обрабатывать исключения и коды ошибок — например, падать вместо попытки исправиться. Все бывает.
4. Иногда программист не расставляет assert'ы. Например, их нет в том языке программирования, на котором он пишет.
5. Программист не всегда пишет комментарии. Код — лучшая документация, поэтому лучше написать код так, чтобы надобность в комментариях отпала.
И потом никогда не могу их вспомнить. :-)
Остается только чувство восторга: «какая здоровская была мелодия!».
Зато я точно знаю, что когда-нибудь завтра будет другая, тоже здоровская.
И мне не важно, лучше или хуже она предыдущей.
И мне не важно, что ее никто кроме меня не услышит.
И мне даже не важно, будет ли завтра другая. Может, и не будет.
Но я живу сегодня. На возможный максимум при текущем физическом и психическом состоянии, знаниях и т.д.
И именно это для меня ценно — быть собой и идти вперед, расставаясь с прошлым и встречая будущее.
И, самое главное — возможно, завтра я буду думать иначе, даже прямо противоположно сегодняшнему.
Так что главной задачей дня является… что?.. Система контроля изменений. :-)
Исходите из задачи и критериев оценки качества.
Определите, что хорошо, что плохо, и что в вашем случае более значимо.
Сведите это к одной шкале, чтобы для любой реализации в этих условиях можно было сказать, хуже или лучше она другой реализации.
И только тогда можно начинать сравнивать.
Иначе получается, что сравниваем теплое с мягким, акцентируя на разных сторонах одной проблемы, и используя свои личные весовые категории.
А в разных системах оценки одно и то же решение редко оказывается одинаково приемлемым.
Думаете, почему многие проблемы более-менее решаются инженерными способами, но не имеют адекватных решений в научных трудах? Все дело в постановке задачи.
Предварительно убедившись, что данное устойчивое состояние Вам подойдет. :-)
Необходимо устранять семантическое дублирование (когда одинаковые действия производятся для одинаковой цели).
И не нужно устранять простое синтаксическое дублирование (когда синтаксис языка требует от Вас писать так, а не эдак), если за ним нет единой семантики.
Привести пример второго типа сложно, но мне два-три раза такое попадалось.
И еще один пример: не нужно устранять дублирование, если оно является частью разных бизнес-сценариев, подверженных изменениям. Завтра сценарии могут разойтись — и общие части придется опять распиливать. А вовремя сдублировать ветку кода для независимой модификации — этого не умеют делать многие миддлы, не говоря уже о Junior'ах. Как раз потому, что знают принцип «устранения дублирования», но не понимают его суть.
P.S. Увы, не знаю .NET достаточно глубоко для самостоятельного ответа на поставленный вопрос.
P.S.2. А google-ить влом. :-)
Это все уже было и повторялось везде и всюду.
Программирование — очень молодое искусство, поэтому проходит те же стадии развития.
Мне почему-то кажется, что не только меня бесит, когда при работе на грани доступной памяти система в произвольный момент времени может умереть.
Для прояснения контекста: работаю без SWAP, т.к. если Java начинает вытесняться в SWAP все становится ну очень печально — проще все закрыть и открыть заново.
P.S. В Windows 7 по сравнению с предыдущими версиями получить эту ошибку на уровне драйвера намного труднее.
Я с большой долей вероятности из этой категории, например.
:-)
И тут нас может спасти умение быстро адаптироваться под обстоятельства.
Если не можешь быстро из программиста стать сантехником — ты попал. :-) (утрирую, конечно же)
А в этом случае работодатель запросто может отправить «на пенсию» — попросту уволить.
И в этом случае не все смогут найти себе нишу.
Они ищут высокой прибыли.
Они готовы отдать за это время и усилия.
Но у них нет желания учиться.
Именно поэтому у них в коде все печально.
Такие «нотации» им только мешают.
Они становятся нужны на этапе «куда дальше расти?», когда уже можешь писать код, но не знаешь, как разработать систему и интегрировать ее с тем, с тем и еще с тем.
Он мыслит проблемами и бизнес-процессами с точки зрения пользователя.
Так точнее. :-)
Программист пишет программу.
Разработчик разрабатывает систему и строит бизнес-процесс, поддерживаемый этой системой.
Часто разработчик по-совместительству допиливает и процесс самой разработки.
Чувствуете разницу?
2. Иногда программист не пишет тестов, ибо для их написания нужно отрефакторить такую кучу legacy-кода, который написали до него, что он понимает нецелесообразность этого действа.
3. Иногда программист может не знать про какой-то код ошибки одной из внутренних библиотек, которую используют уже давно, и у нее нет автора, исходников и документации. Как-то работает — и все тут.
Да, и иногда программист может некорректно обрабатывать исключения и коды ошибок — например, падать вместо попытки исправиться. Все бывает.
4. Иногда программист не расставляет assert'ы. Например, их нет в том языке программирования, на котором он пишет.
5. Программист не всегда пишет комментарии. Код — лучшая документация, поэтому лучше написать код так, чтобы надобность в комментариях отпала.