Здравствуйте, VladD2, Вы писали:
AVK>>Можно, конечно, все это руками реализовать, но с использованием WCF будет существенно проще.
VD>Честно признаюсь, что на WCF я очень давно не глядел.
По-моему автор все усложняет. А все на самом деле — просто. Если ты делаешь что-то сам для себя — делай как хочешь. Если ты делаешь что-то в команде и(или) для других — соберитесь в самом начале и договоритесь о стиле кодирования, который бы устраивал всех. Точка.
Здравствуйте, ZevS, Вы писали:
ZS>По-моему автор все усложняет. А все на самом деле — просто. Если ты делаешь что-то сам для себя — делай как хочешь. Если ты делаешь что-то в команде и(или) для других — соберитесь в самом начале и договоритесь о стиле кодирования, который бы устраивал всех. Точка.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, ZevS, Вы писали:
ZS>>По-моему автор все усложняет. А все на самом деле — просто. Если ты делаешь что-то сам для себя — делай как хочешь. Если ты делаешь что-то в команде и(или) для других — соберитесь в самом начале и договоритесь о стиле кодирования, который бы устраивал всех. Точка.
I>Автор говорит не про стиль
Здравствуйте, ZevS, Вы писали:
ZS>>>По-моему автор все усложняет. А все на самом деле — просто. Если ты делаешь что-то сам для себя — делай как хочешь. Если ты делаешь что-то в команде и(или) для других — соберитесь в самом начале и договоритесь о стиле кодирования, который бы устраивал всех. Точка.
I>>Автор говорит не про стиль
ZS>Да я вобшем тоже. )
"договоритесь о стиле кодирования" — разве это не о стиле ?
Здравствуйте, enji, Вы писали:
E>Может и баян, поиском не нашел.
E>Перевод статьи на хабре: http://habrahabr.ru/blogs/development/127635/
E>Там как бы две части. Первая — про комментарии в коде, а вот вторая, поинтереснее, про описание моделей и, в частности, про статическую типизацию:
E>
E>Мы с вами знаем, что статические типы — это тоже метаданные. Они как специализированные комментарии к коду, предназначены для двух разновидностей читателей: для программистов и для компиляторов. Статические типы — это истории о вычислениях, помогают и тем и другим понять действия программы. Их тоже можно выбросить в рантайме, потому что они всего лишь комментарии, и ничего больше. Они как паспорт родословной у собаки — радует владельцев и заставляет гордиться. Но собаке все равно, есть ли у нее паспорт, или нет.
E>Если статические типы являются коментами, тогда мне кажется, что люди, которые уж очень сильно полагаются на статическую типизацию, люди, которые обожают процесс статического моделирования — нубы.
E>Ха-ха.
E>Ну, если посерьезнее, то я ничего не имею против статической типизации. Я против ее чрезмерного использования. Младшие программисты злоупотребляют статической типизацией точно так же, как они злоупотребляют коментами.
Не понял
Что Вы хотели сказать то?
Не понятно
Так как название темы никак не соотносится с тем, что Вы написали в корневом сообщении?
Или Вы хотели сказать, что использовать статическую типизацию — признак нуба/гика/лоха??
Здравствуйте, Ikemefula, Вы писали:
I>"договоритесь о стиле кодирования" — разве это не о стиле ?
"автор все усложняет" и "договоритесь" — не только о стиле, стиль — только для примера. Вполне можно привести к общему знаменателю как количество/качество коментариев и отступы, так и степень углубления в моделирование с паттернами, наследованием и типизацией. Зачастую можно выбрать и язык, какой больше подходит/нравится. А когда программист чего-то программирует сам по себе неизвестно для кого, тогда, либо его работа никому нафиг не нужна, либо налицо проблема управления проектом и его качеством.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, Доктор ТуамОсес, Вы писали:
ДТ>>А?
I>Да, статическая типизация, как и её отсутствие является признаком нуба. God Developer не нуждается ни в какой типизации
Здравствуйте, VladD2.
Вы писали:
VD> Да и что это за чудные сервисы? Где вы их берете? Весь цивилизованный мир в последнее время клепает сервисы в REST-стиле. Публичные сервисы в формате Soap делают только люди с полным майрософтом головного мозга.
Здравствуйте, xBlackCat, Вы писали:
VD>> Да и что это за чудные сервисы? Где вы их берете? Весь цивилизованный мир в последнее время клепает сервисы в REST-стиле. Публичные сервисы в формате Soap делают только люди с полным майрософтом головного мозга.
BC>Как же ты так. Взял и опустил RSDN-team
Здравствуйте, xBlackCat, Вы писали:
VD>> Да и что это за чудные сервисы? Где вы их берете? Весь цивилизованный мир в последнее время клепает сервисы в REST-стиле. Публичные сервисы в формате Soap делают только люди с полным майрософтом головного мозга.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, enji, Вы писали:
E>>Перевод статьи на хабре: http://habrahabr.ru/blogs/development/127635/
VD>Все развивается по спирали. Когда ньюб осознает, что вместо того чтобы писать комментарии, можно изменить программу так, чтобы она сама выражала текст этих комментариев, то он начинает думать, что стал гуру. Некоторые даже начинают посматривать на ньюбов с высока.
VD>Но потом "гуру" осознает, что то что он писал в комментариях — это высокоуровневая спецификация задачи. И используемые им язык просто неспособен выразить это так же внятно. Тогда он снова начинает писать комментарии сетуя на то, что его язык недостаточно хорош.
VD>Далее, гуру, осознавший, что он снова стал ньюбом начинает искть выход. И тут, вдруг, сама собой, появляется сакраментальная мысль... А причем тут немерле?
VD>
Для высокоуровневой спецификации задачи есть тесты (модульные и функциональные). А комментарии ИМХО в основном нужны для описания мотивации принятого технического решения.
Здравствуйте, mrTwister, Вы писали:
T>Для высокоуровневой спецификации задачи есть тесты (модульные и функциональные). А комментарии ИМХО в основном нужны для описания мотивации принятого технического решения.
Для высокоуровневой спецификации есть (хотя, на деле далеко не всегда) файл с описанием системы. А тесты лишь проверяют корректность её работы в некоторых условиях.
Здравствуйте, hardcase, Вы писали:
H>Здравствуйте, mrTwister, Вы писали:
T>>Для высокоуровневой спецификации задачи есть тесты (модульные и функциональные). А комментарии ИМХО в основном нужны для описания мотивации принятого технического решения.
H>Для высокоуровневой спецификации есть (хотя, на деле далеко не всегда) файл с описанием системы. А тесты лишь проверяют корректность её работы в некоторых условиях.
Если тест написан правильно, то он по сути фиксирует либо контракт (в случае модульного теста), либо требования (в случае функционального теста). А если кто-то думает, что "тесты лишь проверяют корректность в некоторых условиях", то это значит, что он не умеет писать тесты.
Здравствуйте, mrTwister, Вы писали:
T>Если тест написан правильно, то он по сути фиксирует либо контракт (в случае модульного теста), либо требования (в случае функционального теста). А если кто-то думает, что "тесты лишь проверяют корректность в некоторых условиях", то это значит, что он не умеет писать тесты.
Вот именно; тестами мы фиксируем соответствие системы требованиям, но никак не описываем требования в виде тестов. В простых случаях требования можно понять из тестов, но не все и не всегда. Похоже что мы имеем разные понятия "высокоуровневости", свое я поясню на примере: высокоуровневым описанием FFT будет вовсе не тест, который проверяет корректность преобразования сигнала нашей реализацией, но известные формулы из учебника. VladD2 говорит очевидную мысль — чем ближе язык к подобному высокоуровневому описанию, тем проще с его помощью создавать системы удовлетворяющие требованиям.
E>Ну, если посерьезнее, то я ничего не имею против статической типизации. Я против ее чрезмерного использования. Младшие программисты злоупотребляют статической типизацией точно так же, как они злоупотребляют коментами.
Как то странно звучит, насколько я понимаю "младшие программисты" как раз наоборот злоупотребляют неиспользованием комментов, void* и переменными a, b, c ... Помоему автор переживает деэволюцию.
Статья учит плохому — мне очень не понравилось что там в комментах сразу же повылазили ленивые программисты, которые гордяться что не комментят код. Хотя известно что поддерживать такой некоментированный монолитный код ...
