Некоторые из измеренных нами черт достигают своего пика гораздо позже в жизни. Например, сознательность достигает пика примерно в 65 лет. Эмоциональная стабильность достигает пика примерно в 75 лет.
Всегда хотелось знать, что стоит за подобными утверждениями. Каковы способы оценки? И что именно оценивается? Не производится ли (вольно или невольно) подмена понятий, когда под сознательностью подразумевается не ответственность, а лояльность, а под эмоциональной стабильностью — не устойчивость, а чёрствость, привычность.
С чего это вдруг? Это не входит в критерии чистого кода.
Для меня это так. Если для других всё иначе, то я с этим ничего не могу поделать. Хотелось бы, конечно, всегда говорить об одном и том же. Но каждый акын дует в свою дуду.
Ну и что с того, что я проверил, что производительность библиотеки, написанной чистым кодом, для моей задачи недостаточна? Мне-то надо, чтобы работало быстрее.
Уберите из Ваших рассуждений словосочетание "чистый код". Вы хотите получить некий код. У Вас два варианта. Взять уже готовый. Или написать самому. Какой выберете?
Все хотят быстрее. Но мы знаем, что многое зависит от самих данных. Отсюда вопрос: на каких данных (быстрее)? И... быстрее чего?
И? При чем тут чистый код-то?
Всегда мечтается о том, что что-то можно один раз написать и пользоваться.
Вы написали про сайт, я вам сказал, что такой сайт уже есть. Вы сказали, что он не подходит, но на вопрос почему ответить не можете.
ВП:НЕСЛЫШУ
А что Вы можете сделать с ГитХабом?
Это вас надо спрашивать, почему вы сначала неправильно написали. Откуда другие люди должны это знать?
Всегда надеешься на то, что более опытный человек умеет лучше организовывать свою работу. Да и, вообще, опытного человека всегда интересно послушать.
А всё почему? Потому что она состоит из исходников. Мы долгие годы в вузах изучаем исходники. Потом пользуемся. Да и само строение математики. Математика — это язык! Сам себя объясняющий и сам себя проверяющий. В теоремах водятся посылки, к теоремам ведёт чёткая мотивация (зачем).
А что? Если 30-летняя кодовая база позволяет решать практически любую современную задачу за малое (по отношению к современной кодовой базе, которую приходится создавать по ходу реализации проекта) время, то лучше пользоваться и поддерживать старую базу.
Есть очень просто вопрос. Возьмите какой-нибудь свой работающий код. Как Вы его писали? Сколько шишек набили? И! Могли ли Вы действовать так, чтобы написать примерно такой же код, но без набивания шишек и, возможно, за меньшее время? Вот в чём вопрос. (с)
Математика сама есть доказательная база и пример хорошего подхода. Большинство книг по математике дают все необходимые определения и теоремы (всё своё ношу с собой).
Вы куда-то уходите в сторону. Я говорил о том, что все разговаривают на различных языках программирования не в смысле самих языков программирования, а в смысле трудностей понимания, в общечеловеческом смысле, просто программирование приводит к тому, что, фактически, мы пользуемся различным ПО, хотя подразумеваем одно и то же.
Чистый код — это код, который не надо править и который можно смело использовать. Это вещь с известными хорошо проверяемыми свойствами (включая и производительность).
Вот, Вы. Вы можете писать код так, чтобы его не надо было мучительно править, исправляя собственные ошибки? Вот сейчас я учусь писать код. И меня очень занимает вопрос, откуда берутся ошибки, и можно ли мыслить так, чтобы запускать редактор кода уже тогда, когда в голове уже сложилось практически всё, что надо. В этом смысле, идеальный программист — это тот, который сначала долго думает, а, потом, быстро делает.
Разработчики всегда пользуются какими-то своими библиотеками. В каждом языке программирования есть свои библиотеки. В СУБД — свои. Все разговаривают на разных языках, используют различные реализации. Трудно сравнивать. Было бы удобнее ссылаться на что-то одно и иметь в виду конкретную реализацию.
Итерации будут всегда. Но, в целом, нужно обязательно всё продумывать. Непродуманность потом и оборачивается значительными тратами этого самого бюджета.
Для продукта это означает, что встроенные процессы экспериментов, прототипирования и быстрой обратной связи должны быть частью цикла разработки.
Потрясающе! И как это здорово звучит на фоне всеобщего отрицания водопадной модели (мол. всем только и подавай гибкие "агайлы" и "скрумы"). Но именно водопадная модель и предполагает, что все исследования (изыскания) проходят до того, когда программист берётся за написание конкретного программного кода, когда надо ответить на множество вопросов и написать (если и написать) множество различных проверочных кусочков, чтобы в проектной документации прописывать уже нечто заведомо выполнимое и каким образом выполнимое.
Как, всё-таки, интересно получается. На словах, всё это соответствует диалектике — развитию через самотрицание и снятие, а на деле всё оборачивается подменой понятий, когда бизнес просто заставляет клиента переходить на новое. Настоящая конкуренция, когда побеждает лучшее. В реальности, побеждает самое продвинутое в плане маркетинга решение.
Как выясняется, все эти переделки довольно дорого обходятся. Вопрос для меня в том, почему практически никогда с самого начала не удаётся понять, а что, собственно, надо делать?
Тааак! А можно ли его сегодня где-то взять? Покрутить. (Придётся наводить справки...)
Всегда хотелось знать, что стоит за подобными утверждениями. Каковы способы оценки? И что именно оценивается? Не производится ли (вольно или невольно) подмена понятий, когда под сознательностью подразумевается не ответственность, а лояльность, а под эмоциональной стабильностью — не устойчивость, а чёрствость, привычность.
Для меня это так. Если для других всё иначе, то я с этим ничего не могу поделать. Хотелось бы, конечно, всегда говорить об одном и том же. Но каждый акын дует в свою дуду.
Уберите из Ваших рассуждений словосочетание "чистый код". Вы хотите получить некий код. У Вас два варианта. Взять уже готовый. Или написать самому. Какой выберете?
Все хотят быстрее. Но мы знаем, что многое зависит от самих данных. Отсюда вопрос: на каких данных (быстрее)? И... быстрее чего?
Всегда мечтается о том, что что-то можно один раз написать и пользоваться.
ВП:НЕСЛЫШУ
А что Вы можете сделать с ГитХабом?
Всегда надеешься на то, что более опытный человек умеет лучше организовывать свою работу. Да и, вообще, опытного человека всегда интересно послушать.
А всё почему? Потому что она состоит из исходников. Мы долгие годы в вузах изучаем исходники. Потом пользуемся. Да и само строение математики. Математика — это язык! Сам себя объясняющий и сам себя проверяющий. В теоремах водятся посылки, к теоремам ведёт чёткая мотивация (зачем).
А что именно вызвало у Вас отторжение?
И Вы работаете в таком месте? Вам повезло. :-)
Почему?
А что? Если 30-летняя кодовая база позволяет решать практически любую современную задачу за малое (по отношению к современной кодовой базе, которую приходится создавать по ходу реализации проекта) время, то лучше пользоваться и поддерживать старую базу.
Есть очень просто вопрос. Возьмите какой-нибудь свой работающий код. Как Вы его писали? Сколько шишек набили? И! Могли ли Вы действовать так, чтобы написать примерно такой же код, но без набивания шишек и, возможно, за меньшее время? Вот в чём вопрос. (с)
Это всё — констатация печальных фактов нашей повседневной обыденности. Но это не значит, что не надо думать о лучшем.
Математика сама есть доказательная база и пример хорошего подхода. Большинство книг по математике дают все необходимые определения и теоремы (всё своё ношу с собой).
Вы куда-то уходите в сторону. Я говорил о том, что все разговаривают на различных языках программирования не в смысле самих языков программирования, а в смысле трудностей понимания, в общечеловеческом смысле, просто программирование приводит к тому, что, фактически, мы пользуемся различным ПО, хотя подразумеваем одно и то же.
Чистый код — это код, который не надо править и который можно смело использовать. Это вещь с известными хорошо проверяемыми свойствами (включая и производительность).
Вот, Вы. Вы можете писать код так, чтобы его не надо было мучительно править, исправляя собственные ошибки? Вот сейчас я учусь писать код. И меня очень занимает вопрос, откуда берутся ошибки, и можно ли мыслить так, чтобы запускать редактор кода уже тогда, когда в голове уже сложилось практически всё, что надо. В этом смысле, идеальный программист — это тот, который сначала долго думает, а, потом, быстро делает.
Разработчики всегда пользуются какими-то своими библиотеками. В каждом языке программирования есть свои библиотеки. В СУБД — свои. Все разговаривают на разных языках, используют различные реализации. Трудно сравнивать. Было бы удобнее ссылаться на что-то одно и иметь в виду конкретную реализацию.
Итерации будут всегда. Но, в целом, нужно обязательно всё продумывать. Непродуманность потом и оборачивается значительными тратами этого самого бюджета.
А кто заставляет исполнителя торопиться писать код?
Вы так и не ответили на мой вопрос: почему так происходит? Почему нельзя иначе?
Потрясающе! И как это здорово звучит на фоне всеобщего отрицания водопадной модели (мол. всем только и подавай гибкие "агайлы" и "скрумы"). Но именно водопадная модель и предполагает, что все исследования (изыскания) проходят до того, когда программист берётся за написание конкретного программного кода, когда надо ответить на множество вопросов и написать (если и написать) множество различных проверочных кусочков, чтобы в проектной документации прописывать уже нечто заведомо выполнимое и каким образом выполнимое.
Как, всё-таки, интересно получается. На словах, всё это соответствует диалектике — развитию через самотрицание и снятие, а на деле всё оборачивается подменой понятий, когда бизнес просто заставляет клиента переходить на новое. Настоящая конкуренция, когда побеждает лучшее. В реальности, побеждает самое продвинутое в плане маркетинга решение.
Как выясняется, все эти переделки довольно дорого обходятся. Вопрос для меня в том, почему практически никогда с самого начала не удаётся понять, а что, собственно, надо делать?
Почему не работает?