Мне кажется правильно было бы сделать об этом пометку в тексте статьи. Те, кто благодаря вашей статье наконец-то разберутся, как же работает таймер и что это такое, скорее всего очень удивятся подобному поведению GC.
По-моему, все пункты высосаны из пальца: с IEnumerable возникают проблемы только тогда, когда автор кода не понимает смысл данного контракта и не более того. Это всего-лишь показатель того, что нам разрешено перебирать элементы конкретного набора элементов. Никто не обещает ни сложности данного перебора, ни тем более того, что метод, возвращающий такой набор, будет на самом деле всегда возвращать разные… Я молотком тоже не пытаюсь закручивать саморезы, хотя это и возможно.
Пока есть быдло и не развита инфраструктура, если ты не будешь пользоваться авто — всё-равно кто-то другой да начнёт. В итоге ты будешь и без авто, и обременён решением проблем, которые на тебя переложат остальные. Действительно адекватный человек всё это взвесит и из двух зол выберет меньшее, очевидно какое.
Так что правильные мысли — правильными мыслями, а современные реалии зачастую вынуждают делать мир хуже.
Автор написал, что если в проекте была и реляционная СУБД, и Монго — то от Монго они отказывались и получали минус один сервис, который необходимо поддерживать.
Мне даже стало интересно не поспорить, а конструктивно порассуждать на тему. Я примерно понимаю ваши доводы: хочется держать всю документацию в одном месте и именно — в коде. По-минимуму артефактов, т.к. их всё-равно никто не прочтёт, ибо даже ТЗ редко дочитывают до конца. А почему бы, например, не объяснять подобные решения в логах к коммитам, а затем blame'ом поднимать историю на сомнительных алгоритмах?
В WP7 так же сделано: меня перед установкой софта предупреждают, какие конкретно права необходимы приложению для работы. И ладно что у меня нет выбора (либо согласен, либо отказывайся от установки). Так ведь там всегда перечислено абсолютно всё! И GPS, и сеть, и доступ к контактам, к фото, к личным данным.
В моём восприятии окружающего меня мира, ответ на вопрос «почему» это реализовано так, а не иначе — находится на концептуально другом уровне.
Читать исходники скорее всего будет клиент моего кода. Ему не важны детали реализации, ему важен профит от использования данного метода. Комментарий, название в 60 символов — здесь не нужны.
Тому, кому важно почему я так сделал, будет преследовать несколько иные цели при прочтении кода. Поэтому необходимые ему ответы он найдёт в соответствующих артефактах проекта.
Вообще, автор имхо поднял более интересную тему, нежели «пожалуйста, комментируйте сложный код». Дело даже не в том, что в приведённом выше примере кода — возможно реально нужен комментарий, потому что код фигово организован и не является самодокументирующимся. Или если проект действительно большой и не очень элегантно спроектирован (а это ведь и правда сложно), то тоже есть места, нуждающиеся в пояснениях.
Автор, на мой взгляд, показал главное свойство junior'ов, делающее их junior'ами: неумение (и зачастую нежелание) разбираться в существующем коде! Я это вижу сплошь и рядом. Люди не могут найти в себе сил спокойно и обстоятельно разобраться в архитектуре проекта, решаемой им задаче и конкретной реализации конкретного бизнес-правила, над которым они сейчас работают. Им проще отвлечь более опытного (и занятого) коллегу. А те, кто могут — часто начинают копать вглубь именно слоя инфраструктуры или используемого фреймворка, вместо самой бизнес-логики.
Ну правильно: время — деньги. Есть время запариться с настройкой и автоматизацией, постоянным включением-выключением, то получишь экономию по деньгам. Времени нет — переплатишь, но зато забудешь и займёшься чем-то другим.
Так что правильные мысли — правильными мыслями, а современные реалии зачастую вынуждают делать мир хуже.
Читать исходники скорее всего будет клиент моего кода. Ему не важны детали реализации, ему важен профит от использования данного метода. Комментарий, название в 60 символов — здесь не нужны.
Тому, кому важно почему я так сделал, будет преследовать несколько иные цели при прочтении кода. Поэтому необходимые ему ответы он найдёт в соответствующих артефактах проекта.
А самодокументируемый код не обязан изобиловать подобными именами. Не ударяйтесь в крайности!
Автор, на мой взгляд, показал главное свойство junior'ов, делающее их junior'ами: неумение (и зачастую нежелание) разбираться в существующем коде! Я это вижу сплошь и рядом. Люди не могут найти в себе сил спокойно и обстоятельно разобраться в архитектуре проекта, решаемой им задаче и конкретной реализации конкретного бизнес-правила, над которым они сейчас работают. Им проще отвлечь более опытного (и занятого) коллегу. А те, кто могут — часто начинают копать вглубь именно слоя инфраструктуры или используемого фреймворка, вместо самой бизнес-логики.