Там как бы две части. Первая — про комментарии в коде, а вот вторая, поинтереснее, про описание моделей и, в частности, про статическую типизацию:
Мы с вами знаем, что статические типы — это тоже метаданные. Они как специализированные комментарии к коду, предназначены для двух разновидностей читателей: для программистов и для компиляторов. Статические типы — это истории о вычислениях, помогают и тем и другим понять действия программы. Их тоже можно выбросить в рантайме, потому что они всего лишь комментарии, и ничего больше. Они как паспорт родословной у собаки — радует владельцев и заставляет гордиться. Но собаке все равно, есть ли у нее паспорт, или нет.
Если статические типы являются коментами, тогда мне кажется, что люди, которые уж очень сильно полагаются на статическую типизацию, люди, которые обожают процесс статического моделирования — нубы.
Ха-ха.
Ну, если посерьезнее, то я ничего не имею против статической типизации. Я против ее чрезмерного использования. Младшие программисты злоупотребляют статической типизацией точно так же, как они злоупотребляют коментами.
Здравствуйте, enji, Вы писали:
E>Перевод статьи на хабре: http://habrahabr.ru/blogs/development/127635/
E>Там как бы две части. Первая — про комментарии в коде, а вот вторая, поинтереснее, про описание моделей и, в частности, про статическую типизацию:
E>
E>Мы с вами знаем, что статические типы — это тоже метаданные. Они как специализированные комментарии к коду, предназначены для двух разновидностей читателей: для программистов и для компиляторов. Статические типы — это истории о вычислениях, помогают и тем и другим понять действия программы. Их тоже можно выбросить в рантайме, потому что они всего лишь комментарии, и ничего больше. Они как паспорт родословной у собаки — радует владельцев и заставляет гордиться. Но собаке все равно, есть ли у нее паспорт, или нет.
E>Если статические типы являются коментами, тогда мне кажется, что люди, которые уж очень сильно полагаются на статическую типизацию, люди, которые обожают процесс статического моделирования — нубы.
E>Ха-ха.
E>Ну, если посерьезнее, то я ничего не имею против статической типизации. Я против ее чрезмерного использования. Младшие программисты злоупотребляют статической типизацией точно так же, как они злоупотребляют коментами.
Автор за свои стопицот лет программизма так и не врубился в статическую типизацию
E>Если статические типы являются коментами, тогда мне кажется, что люди, которые уж очень сильно полагаются на статическую типизацию, люди, которые обожают процесс статического моделирования — нубы.
А в строго статически типизированном Хаскелле, например, все типы выводит компилятор. Неужели в Хаскелл-комьюнити нету нубов?!
H>Автор за свои стопицот лет программизма так и не врубился в статическую типизацию
Автор за стопицот лет так и остался нубом, только комментарии перестал писать
Несколько слов стоит посветить JUnit 4. Разработчики этого фреймворка, являя собой пример эталонного нуба, решили, что представленные в Java 5 аннотации — решение всех проблем человечества. Не знаю, смеятся или плакать, но они перенесли весь свой код из нормальных методов в тела аннотаций — самое абсурдное применение метаданных, что я когда-либо видел.
Чотоянепонял.
1. Охаиваем качественный олдскульный код (новички так не пишут, не обманывайтесь).
2. Хвастаемся "а я вот как могу"
3. Начинаем учить жизни.
4. ??????
5. А, собственно, где?
Что самое неприятное, все утверждения поданы в бескомпромиссном гуру-стиле и возразить получается только "отучаемся говорить за всех". Я специально прочитал текст дважды и не нашёл ни одного более-менее внятного тезиса, только "все вокруг — нубы, а я — д'Артатьян!". Что тут обсуждать —
Метаданные — это любая форма описаний или моделирования чего-либо. В нашем случае коменты выступают в роли естественного для языка программирования описания вычислений на этом языке. То, что делает метаданные мета-данными — отсутствие строгой необходимости в них. Если у меня есть собака и паспорт родословной на нее, и я вдруг потеряю паспорт, то у меня останется совершенно нормальная собака.
Метаданные и коменты — это не родословная, а история болезни. Пока собака будет здорова — история не нужна, и её можно потерять. Но если собака заболела, то без истории болезни можно нанести большой вред здоровью, потому что у собаки бешеная аллергия на какой-нибудь антибиотик.
Здравствуйте, hardcase, Вы писали:
E>>Ну, если посерьезнее, то я ничего не имею против статической типизации. Я против ее чрезмерного использования. Младшие программисты злоупотребляют статической типизацией точно так же, как они злоупотребляют коментами. E>>[/q]
H>Автор за свои стопицот лет программизма так и не врубился в статическую типизацию
Его код выдаёт в нём императивного программиста С т.з. психологии статья просто адская. А вот про метаданные и каменты как то подкачала, изложение сильно невнятное.
Здравствуйте, Sinix, Вы писали:
S>1. Охаиваем качественный олдскульный код (новички так не пишут, не обманывайтесь).
Пишут. Не те, которые программирование осваивают, а новички которые только начали работать программистом. Собственно про это и говорит автор: "junior-программисты"
S>2. Хвастаемся "а я вот как могу"
Он сравнивает себя молодого с собой нынешним. Это не хвастовство, а просто хороший, удачный пример. Очень многим людям очень тяжело выдать адекватное сравнения себя с собой. Многим даже кажется что они всегда были вот такими крутыми программистами как сейчас
S>3. Начинаем учить жизни.
Не больше, чем местные евангелисты или другие хабровцы.
S>5. А, собственно, где?
Он выдал портрет нуба, сделал прогнозы по индустрии и предложил свои решения. Чего еще тебе надо ?
Если читать его статью как ИМХО, все очень просто,понятно и проблем не вызывает
S>Что самое неприятное, все утверждения поданы в бескомпромиссном гуру-стиле и возразить получается только "отучаемся говорить за всех".
Вещь про временное повествование это вообще шедевр. Это собственно одна из основных причин, почему новички пишут императивный код — они еще не дошли до концепции, что время непрерывно.
Евангелистам функциональщины нужно в обязательном порядке изучить этот вопрос.
S>Я специально прочитал текст дважды и не нашёл ни одного более-менее внятного тезиса, только "все вокруг — нубы, а я — д'Артатьян!". Что тут обсуждать —
Очевидно, автор текста сильно увлекается психологией, а ты сильно вряд ли. Потому тебе непонятно. А далее, как и все типичные программисты ты отрицаешь непонятное(особенно если автор ошибается в неключевых рассуждениях ). Следующая ступенька — ты начнёшь изобретать велосипед А потом обнаружишь, что изобретатель этого велосипеда Жан Пиаже, умер уже тридцать лет назад
Здравствуйте, enji, Вы писали:
E>Может и баян, поиском не нашел.
E>Перевод статьи на хабре: http://habrahabr.ru/blogs/development/127635/
E>Там как бы две части. Первая — про комментарии в коде, а вот вторая, поинтереснее, про описание моделей и, в частности, про статическую типизацию:
Там три части.
Первая часть про психологию программиста.
Вторая — проявление этой психологии в языках и фреймворках.
Третья — проблемы, методы решения и прогнозы автора.
Здравствуйте, Ikemefula, Вы писали:
I>Пишут. Не те, которые программирование осваивают, а новички которые только начали работать программистом. Собственно про это и говорит автор: "junior-программисты"
Неа. Такой код пишут после того, как перестают бояться "а вдруг меня посчитают новичком" и начинают ценить время тех, кто будет сопровождать ваш код.
S>>2. Хвастаемся "а я вот как могу" I>Он сравнивает себя молодого с собой нынешним.
Я бы не сказал, что нынешний код мне нравится больше. Особенно в сочетании с переливающимся через край самомнением.
I>Это не хвастовство, а просто хороший, удачный пример.
Да, это не хвастовство, это хамство. За редкими исключениями (обойдёмся без личностей) даже на рсдн очень редко доказывают своё превосходство обливанием помоями. Не тем меряться надо.
I>Не больше, чем местные евангелисты или другие хабровцы.
Это перевод, а автор как бы не хабрашкольник а "солидный" разработчик с 25 годами стажа.
I>Он выдал портрет нуба, сделал прогнозы по индустрии и предложил свои решения.
Судя по портрету, нубы — все, кроме него. Прогнозы и решения в студию, плиз.
S>>Что самое неприятное, все утверждения поданы в бескомпромиссном гуру-стиле и возразить получается только "отучаемся говорить за всех". I>Вещь про временное повествование это вообще шедевр. Это собственно одна из основных причин, почему новички пишут императивный код — они еще не дошли до концепции, что время непрерывно.
Плиз, перечитайте абзац выше и ваш ответ, это шикарно Да-да-да, отучаемся говорить за всех
I>Очевидно, автор текста сильно увлекается психологией, а ты сильно вряд ли.
А теперь вы додумываете ещё и за автора. Увлечение психологией — не повод к самолюбованию, переходу на личности и к оплёвыванию всех, с кем вы не согласны. Не надо.
Смешно читать "профессионала", который кого-то называет "нубом". Можно сразу отложить в сторону этот в***р и пойти заняться чем-то полезным. Настоящий профессионал да и просто взрослый воспитанный человек никого не назовёт нубом. У настоящего профессионала на каждую запятую в коде будет филосовско-техническое обоснование на двух листах её здесь появления. Ну и так далее. Как я себе это представляю.
Для нас [Thompson, Rob Pike, Robert Griesemer] это было просто исследование. Мы собрались вместе и решили, что ненавидим C++ [смех].
Здравствуйте, enji, Вы писали:
E>Может и баян, поиском не нашел.
E>Перевод статьи на хабре: http://habrahabr.ru/blogs/development/127635/
E>Там как бы две части. Первая — про комментарии в коде, а вот вторая, поинтереснее, про описание моделей и, в частности, про статическую типизацию:
E>
E>Мы с вами знаем, что статические типы — это тоже метаданные. Они как специализированные комментарии к коду, предназначены для двух разновидностей читателей: для программистов и для компиляторов. Статические типы — это истории о вычислениях, помогают и тем и другим понять действия программы. Их тоже можно выбросить в рантайме, потому что они всего лишь комментарии, и ничего больше. Они как паспорт родословной у собаки — радует владельцев и заставляет гордиться. Но собаке все равно, есть ли у нее паспорт, или нет.
E>Если статические типы являются коментами, тогда мне кажется, что люди, которые уж очень сильно полагаются на статическую типизацию, люди, которые обожают процесс статического моделирования — нубы.
E>Ха-ха.
E>Ну, если посерьезнее, то я ничего не имею против статической типизации. Я против ее чрезмерного использования. Младшие программисты злоупотребляют статической типизацией точно так же, как они злоупотребляют коментами.
Вкратце:
Комментарии не нужны, комментарии — частный случай метаданных (подмножество), следовательно любые метаданные не нужны.
С точки зрения булевой логики это некорректное выражение.
Здравствуйте, Sinix, Вы писали:
I>>Пишут. Не те, которые программирование осваивают, а новички которые только начали работать программистом. Собственно про это и говорит автор: "junior-программисты" S>Неа. Такой код пишут после того, как перестают бояться "а вдруг меня посчитают новичком" и начинают ценить время тех, кто будет сопровождать ваш код.
Ты уверен, что они вообще нужны ? Что полезного ты нашел в его коментах ? И даже тот, что counter++ инкрементит ?
Просьба ответить на три вопроса, а не только на первый прочитаный.
И совсем не ясно, что для тебя нуб. Если чел перестал бояться, что его посчитают нубом, то возможно он согласился с этим, а может и был согласен, но этот статус докучал ему
Я совсем недавно выкосил тонны подобных каментов, как то незаметил, что они облегчают код. Если бы был какой то инструмент, который позволяет держать каменты в согласовании с кодом и дела это автоматически — было бы очень круто. Но такого инструмента нет, потому простыни камментов отвлевают тех, кто уже перерос данную стадию развития — коментировать каждую строчку.
I>>Он сравнивает себя молодого с собой нынешним. S>Я бы не сказал, что нынешний код мне нравится больше. Особенно в сочетании с переливающимся через край самомнением.
А он и не приводт свой код как эталон. Он приводит его как пример изменений в его собственном случае.
I>>Это не хвастовство, а просто хороший, удачный пример. S>Да, это не хвастовство, это хамство. За редкими исключениями (обойдёмся без личностей) даже на рсдн очень редко доказывают своё превосходство обливанием помоями. Не тем меряться надо.
Процитируй, где он хвастается или хамит ? На РСДН, сравнивая с англоязычными вроде SO, SF и подобными, _очень_ _часто_ обливают помоями что бы доказать своё превосходтсво Я бы сказал, что это норма на РСДН.
I>>Не больше, чем местные евангелисты или другие хабровцы. S>Это перевод, а автор как бы не хабрашкольник а "солидный" разработчик с 25 годами стажа.
Я не сразу заметил, что статья переводная, но это абслютно неважно. Его изложение, по моему, разумению очень нейтральное и сравнивая с хаброй ничем не выделяется на общем фоне.
I>>Он выдал портрет нуба, сделал прогнозы по индустрии и предложил свои решения. S>Судя по портрету, нубы — все, кроме него.
Процитируй, где ты увидел "нубы все, крмое него" ?
>Прогнозы и решения в студию, плиз.
Прогнозы и проблемы в разделе "Ползучая бюрократия ", решения "Решения и соглашения"
Например:
"Эти языки никогда-никогда-никогда не добьются никакого коммерческого успеха, точно так же как его не добился концепт “семантического веба”. Вы не можете заставить людей создавать метаданные для всего, с чем они хотят работать. Они будут ненавидеть вас за это. "
"С моделированием связана еще одна очень актуальная проблема. Модели, которые получаются в результате этого процесса, часто оказываются “неправильными”. Наверное, это сложно понять с самого начала — как может модель быть неправильной? Код (или данные), живут в этой модели и подгоняются под ее правила и ограничения, поэтому и код и данные корректны с точки зрения модели. Однако, модель “неправильная” тогда, когда с ее помощью нельзя отразить реальные вещи из какой-нибудь области, под которую эта модель создавалась. Взять ту же java — всегда, когда вы хотите использовать множественное наследование или примеси, вам нужно изменять представление вещей у себя в голове, чтобы они подошли под ограничения и правила мира java. Вы портите естественный дизайн, поэтому java — “неправильная”.
"
"При моделировании следует придерживаться тех же правил, что и при комментировании кода: не пытайтесь смоделировать все на свете! Оставьте код в покое — пусть он сам за себя говорит.
"
"думаю, общим ответом на такой вопрос было бы вот что: если сомневаетесь — не моделируйте. Просто пишите код, продвигайтесь вперед. Не позволяйте себе увязнуть в деталях моделирования вспомогательного класса, который сам по себе не несет никакой ценности.
"
S>>>Что самое неприятное, все утверждения поданы в бескомпромиссном гуру-стиле и возразить получается только "отучаемся говорить за всех". I>>Вещь про временное повествование это вообще шедевр. Это собственно одна из основных причин, почему новички пишут императивный код — они еще не дошли до концепции, что время непрерывно. S>Плиз, перечитайте абзац выше и ваш ответ, это шикарно Да-да-да, отучаемся говорить за всех
Ты можешь отрицать такой феномен как временное повествования, но это твои личное дело. Автор просто указывает связь между количеством и качеством каментов и этим самым феноменом. Если ты расскажешь, как можно говорить про психологию в любом виде и что бы это не подходило под "говорить за всех" то наверняка получишь нобелевскую премию
Здравствуйте, Sorc17, Вы писали:
S>Смешно читать "профессионала", который кого-то называет "нубом". Можно сразу отложить в сторону этот в***р и пойти заняться чем-то полезным. Настоящий профессионал да и просто взрослый воспитанный человек никого не назовёт нубом.
нуб — всего-навсего "новичек", негативного окраса вроде бы нет. Или я не прав?
Здравствуйте, enji, Вы писали:
S>>Смешно читать "профессионала", который кого-то называет "нубом". Можно сразу отложить в сторону этот в***р и пойти заняться чем-то полезным. Настоящий профессионал да и просто взрослый воспитанный человек никого не назовёт нубом.
E>нуб — всего-навсего "новичек", негативного окраса вроде бы нет. Или я не прав?
Многим мыслителям очень неприятно вспоминать, что когда то они были детьми, ходили в детский сад, писяли и какали в штанишки, не могли подтереть себе задницу. Стив Йегг умело троллит на эту тему и заставляет вспомнить и заново натянуть на себя эти ассоциации
Потому мыслители всегда стараются дистанцироваться от нубов любыми легальными и нелегальными способами.
P.S. Это я потроллил, а Стив Йегг очень сильный психолог
Здравствуйте, gandjustas, Вы писали:
G>Вкратце: G>Комментарии не нужны, комментарии — частный случай метаданных (подмножество), следовательно любые метаданные не нужны.
G>С точки зрения булевой логики это некорректное выражение.
Если прочесть только процитированое в первом сообщении, то так и будет В статье, особенно англоязычной, нет никакого намёка на "любые метаданные не нужны", более того, есть совсем другое
"consider adding some extra static types to clarify it (for you and for your compiler). Just keep in mind that it's a trade-off: you're introducing clarifying metadata at the cost of maintenance, upkeep, flexibility, testability and extensibility. Don't go too wild with it."
То есть, он говорит, 1 за метаданные нужно платить 2 нужен баланс.
Трудно не согласиться со всем изложенным. Вопрос, какие делать выводы. По 20 лет программированием занимаются или кармакИ, или мудаки. И третьи Думы я что-то не часто вижу, так что, выбор невелик. Поэтому нубство программистов неизбежно и нубы, подчас, делают важнейшую часть проекта. Если им проще с избыточностью комментариев, типов и прочих метаданных, то и хрен с ними. Далее, а вы видели нубский код БЕЗ комментариев? Я видел. Без комментариев.
А суть передана удивительно точно. Сколько раз за собой замечал, что когда на работу не стоИт, начинаю заниматься всякой херней: раскладываю по полочкам, пишу тексты вокруг да около и так далее. Усиленно мастумоделирую, короче.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, gandjustas, Вы писали:
G>>Вкратце: G>>Комментарии не нужны, комментарии — частный случай метаданных (подмножество), следовательно любые метаданные не нужны.
G>>С точки зрения булевой логики это некорректное выражение.
I>Если прочесть только процитированое в первом сообщении, то так и будет В статье, особенно англоязычной, нет никакого намёка на "любые метаданные не нужны", более того, есть совсем другое I>
I>"consider adding some extra static types to clarify it (for you and for your compiler). Just keep in mind that it's a trade-off: you're introducing clarifying metadata at the cost of maintenance, upkeep, flexibility, testability and extensibility. Don't go too wild with it."
I>То есть, он говорит, 1 за метаданные нужно платить 2 нужен баланс.
А в чем смысл процитированного утверждения? Если мы добавляем статической типизации, то мы теряем поддерживаемость, гибкость и тестируемость кода? Ну бред же.
Тут есть переход от частного к общему, но нет доказательства что утверждения верные для частного будут верны и для общего.
Например в статье активно рассматриваются комментарии и атрибуты, но потом утверждается что те же утверждения верны и для статических типов.
Более того становится очевидной бредовость рассуждений о статических типах если вспомнить что есть языки с автоматическим выводом типов.
Чувак явно путает понятие метаданные. Вот определение dictionary.com:
metadata
noun data about data; "a library catalog is metadata because it describes publications"
Автор думает, что метаданные в этом примере — это data about data..., но на самом деле метаданные — это noun.
Ну а дальше из этой ошибки он делает далекоидущие выводы.
Если определять по аналогии с его разделением его возрастную категорию, то похоже у него сейчас жесточайший кризис среднего возраста. А в этом случае ещё и не такого бреда понапишешь.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, gandjustas, Вы писали:
I>>То есть, он говорит, 1 за метаданные нужно платить 2 нужен баланс. G>А в чем смысл процитированного утверждения? Если мы добавляем статической типизации, то мы теряем поддерживаемость, гибкость и тестируемость кода? Ну бред же.
G>Тут есть переход от частного к общему, но нет доказательства что утверждения верные для частного будут верны и для общего. G>Например в статье активно рассматриваются комментарии и атрибуты, но потом утверждается что те же утверждения верны и для статических типов.
Вот нигадяй, написал всего лишь статью в блоге, а не монографию "Влияние психологических аспектов личности разработчика на ..."
Если статические типы являются коментами, тогда мне кажется, что люди, которые уж очень сильно полагаются на статическую типизацию, люди, которые обожают процесс статического моделирования — нубы.
Неужели абзац выше сложно прочесть ?
G>Более того становится очевидной бредовость рассуждений о статических типах если вспомнить что есть языки с автоматическим выводом типов.
Судя по баталиям в этом форуме, это такой очевидный вопрос, ага
I>Ты уверен, что они вообще нужны ? Что полезного ты нашел в его коментах ? И даже тот, что counter++ инкрементит ?
Вы снова переходите на личности. Зачем? Комментарии показывают, что код небезопасен для рефакторинга: count++ имеет побочные эффекты, на которые завязаны вызывающие функции. Кроме того, автор сам признаётся, что утрирует.
I>Если чел перестал бояться, что его посчитают нубом, то возможно он согласился с этим, а может и был согласен, но этот статус докучал ему
Опять, но на этот раз вы небрежно макнули самого Йогге Попробую сформулировать иначе: код с комментариями такого уровня пишут, когда не видят нужды в самоутверждении — человек уже доказал всё, что можно и себе, и окружающим.
I>А он и не приводт свой код как эталон. Он приводит его как пример изменений в его собственном случае.
А где я называл второй листинг эталоном? Он просто хуже читается и поддерживается, чем код в первом листинге.
I>Процитируй, где он хвастается или хамит ?
if u dont no wat a n00b iz, u r 1.
...
This is how junior programmers write code. ... you'll notice a striking similarity to the real-life 2-year-old Emily
...
programmers eventually have to go through a stupid-teenager phase
...
programmers with five to ten years of experience under their belts (still n00bs in their own way)
...
"5 to 10 years of experience" on a resume ... means "crazy invincible-feeling teenager with a 50/50 shot at writing a pile of crap
...
If you're a n00b, you'll look at experienced code and say it's impenetrable
...
people who really love the static modeling process, are n00bs
...
They're usually the logical modelers ... you'll doubtless also have noticed they're always getting in your way.
Ещё?
I> На РСДН, сравнивая с англоязычными вроде SO, SF и подобными, _очень_ _часто_ обливают помоями что бы доказать своё превосходтсво
Если не считать КСВ, где без забрала в принципе не ходят, я ничего подобного не наблюдаю. В любом случае, какое отношение это имеет к своеобразному стилю Йегге?
I>Я не сразу заметил, что статья переводная, но это абслютно неважно. Его изложение, по моему, разумению очень нейтральное и сравнивая с хаброй ничем не выделяется на общем фоне.
It depends. После постов Липперта, Синофски, Де Смета, да даже Спольски — Йегге унылый тролль.
I>Процитируй, где ты увидел "нубы все, крмое него" ?
См цитаты выше
I>
"Эти языки никогда-никогда-никогда не добьются никакого коммерческого успеха, точно так же как его не добился концепт “семантического веба”. Вы не можете заставить людей создавать метаданные для всего, с чем они хотят работать. Они будут ненавидеть вас за это. "
Это прогнозы? Хотя нет, закрывать глаза на тонны успешных мейнстрим-языков со статической типизацией — это важнейший принцип онолитега, так что всё ок.
I>
С моделированием связана еще одна очень актуальная проблема. Модели, которые получаются в результате этого процесса, часто оказываются “неправильными”.
С кодированием связана еще одна очень актуальная проблема. Код, который получается в результате этого процесса, часто оказывается “неправильным”.
С анализом требований связана еще одна очень актуальная проблема. Дизайн, который получается в результате этого процесса, часто оказывается “неправильным”.
Продолжать? Кривые результаты — это проблемы не инструмента, а его неправильного применения. Это я говорю как человек, как минимум лет 5 успешно применяющий моделирование в разработке.
При моделировании следует придерживаться тех же правил, что и при комментировании кода: не пытайтесь смоделировать все на свете! Оставьте код в покое — пусть он сам за себя говорит.
Код вообще не имеет никакого отношения к модели, тем более к модели предметной области. Очень странно читать такие пёрлы от девелопера с 25 годами боевого опыта.
I>
думаю, общим ответом на такой вопрос было бы вот что: если сомневаетесь — не моделируйте. Просто пишите код, продвигайтесь вперед.
Бекк/Амблер, вид сбоку. Это работает только для очень узкого набора сценариев и только при поставленном процессе разработки. Давать подобные советы без оговорок — моветонЪ
S>>>>Что самое неприятное, все утверждения поданы в бескомпромиссном гуру-стиле и возразить получается только "отучаемся говорить за всех". I>>>Вещь про временное повествование это вообще шедевр. Это собственно одна из основных причин, почему новички пишут императивный код — они еще не дошли до концепции, что время непрерывно. S>>Плиз, перечитайте абзац выше и ваш ответ, это шикарно Да-да-да, отучаемся говорить за всех I>Ты можешь отрицать такой феномен как временное повествования, но это твои личное дело.
Сорри, но здесь у меня терпение лопнуло. Продолжать наезжать после повторного намёка "не додумываем за окружающих" — это редкостная степень одарённости, я так не могу.
I>Если статические типы являются коментами, тогда мне кажется, что люди, которые уж очень сильно полагаются на статическую типизацию, люди, которые обожают процесс статического моделирования — нубы.
I>Неужели абзац выше сложно прочесть ?
Кто сказал что они являются комментами? Почему далее все рассуждения опираются на то что статические типы являются кооментами\метаданными?
E>Если статические типы являются коментами, тогда мне кажется, что люди, которые уж очень сильно полагаются на статическую типизацию, люди, которые обожают процесс статического моделирования — нубы.
E>Ха-ха.
E>Ну, если посерьезнее, то я ничего не имею против статической типизации. Я против ее чрезмерного использования. Младшие программисты злоупотребляют статической типизацией точно так же, как они злоупотребляют коментами.
Берд евангилиста динамической типизации. Причем чисто демагогический, так как аналогия с паспортом у собаки уже ни в какие ворота не лезет.
Злоупотребление типами тоже прикольный слоган. Это типа злоупотребления земным тяготением. Как это сделать я не понимаю.
Если язык статически типизированный, то говорить можно только об объеме аннотаций типов которые задает программист. Тут конечно может быть и злоупотребление (если язык позволят их не задавать), но даже если ты не укажешь ни одного типа в программе, но программа скомпилируется, то все равно все типы будут известны. Таким образом, как их не задавай их все равно будет 100%. Так что есть "злоупотреблением типами"?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, avpavlov, Вы писали:
A>Автор за стопицот лет так и остался нубом, только комментарии перестал писать
A>
A>Несколько слов стоит посветить JUnit 4. Разработчики этого фреймворка, являя собой пример эталонного нуба, решили, что представленные в Java 5 аннотации — решение всех проблем человечества. Не знаю, смеятся или плакать, но они перенесли весь свой код из нормальных методов в тела аннотаций — самое абсурдное применение метаданных, что я когда-либо видел.
И еще он не понял, того что в большинстве случаев просто нельзя написать код настолько близким к описанию проблемы, чтобы избавиться от комментарией. Точнее может и можно, но для этого язык должен позволят вводить другой язык — язык предметной области (DSL).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, deniok, Вы писали:
D>А в строго статически типизированном Хаскелле, например, все типы выводит компилятор. Неужели в Хаскелл-комьюнити нету нубов?!
Есть. И они не указывают типы во всей программе. Те же кто по опытнее указывают типы для экспортируемых сущностей.
Так что вопрос о ньюбстве автора остается открытым. Точнее для меня он закрыт.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Все развивается по спирали. Когда ньюб осознает, что вместо того чтобы писать комментарии, можно изменить программу так, чтобы она сама выражала текст этих комментариев, то он начинает думать, что стал гуру. Некоторые даже начинают посматривать на ньюбов с высока.
Но потом "гуру" осознает, что то что он писал в комментариях — это высокоуровневая спецификация задачи. И используемые им язык просто неспособен выразить это так же внятно. Тогда он снова начинает писать комментарии сетуя на то, что его язык недостаточно хорош.
Далее, гуру, осознавший, что он снова стал ньюбом начинает искть выход. И тут, вдруг, сама собой, появляется сакраментальная мысль... А причем тут немерле?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Снение несколько изменилось. Основная суть мысль статьи — перегибы это плохо. С ней нельзя не согласиться.
В прочем, сам автор перегибает палку, но в другую сторону.
ЗЫ
Интересно, а кто-нибудь оценил юмор автора? В одном месте он был очень самокритичным и ироничным. Вот оно:
Постскриптум
Оставляю коменты включенными. Ну, до тех пор, пока мне в почту не повалятся ссылки “нажми-на-мой-спам”. Мне очень любопытно, что из всей этой затеи получится. Это был очень трудный пост для меня. Мне сложно было его писать, я очень много раз его правил. Мне кажется, что я не очень ясно высказал свою точку зрения. Я так же не уверен, что смог достучаться до одержимых метаданными людей и показать им, что у них есть проблема. Хотя, раз уж теперь они знают, что где-то рядом ходят другие люди, которые имеют такие проблемы, то это уже хорошо.
Это хорошо! Это шедёвръ!
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Злоупотребление типами тоже прикольный слоган. Это типа злоупотребления земным тяготением. Как это сделать я не понимаю.
VD>Если язык статически типизированный, то говорить можно только об объеме аннотаций типов которые задает программист. Тут конечно может быть и злоупотребление (если язык позволят их не задавать), но даже если ты не укажешь ни одного типа в программе, но программа скомпилируется, то все равно все типы будут известны. Таким образом, как их не задавай их все равно будет 100%. Так что есть "злоупотреблением типами"?
For instance, as just one random illustrative example, you might need to return 2 values from a function in Java (a language with no direct support for multiple return values). Should you model it as a MyFunctionCallResult class with named ValueOne and ValueTwo fields (presumably with actual names appropriate to the problem at hand)? Or should you just return a 2-element array (possibly of mixed types) and have the caller unpack it?
Это пример автора. От себя другой пример:
// Где-то внутри OM, не API.void Foo(bool rakom, bool bokom, bool sNaskoku) {}
...
Foo(false, true, true); // Плохо, ничего не понятно.void Foo(Rakom rakom, Bokom bokom, Naskok sNaskoku) {}
Foo(Rakom.NeRakom, Bokom.Bokom, Naskok.SNaskoku);
// Часто рекомендуется, требует новых типов для, по сути, вызова одного лишь метода.void Foo(bool rakom, bool bokom, bool sNaskoku) {}
...
Foo(rakom:false, bokom:true, sNaskoku:true); // Все понятно, новые типы не нужны.
Я весь опус не читал: много буков. Но вот про dense code не могу согласиться. Если код достаточно dense, то он начинает быть похожим на непрерывную простыню, в которой уже не просматривается структура кода. И тогда в код нужно вчитываться, чтобы понять, что он делает. Тогда как в разумно разреженном коде структура видна с первого взгляда, и поэтому его гораздо легче читать и понимать.
Кстати, пример, который он привел не является плотным кодом. Это видно по тому, что на одной строке всего по одному выражению, параметры разбиты на несколько строк, и структура просматривается легко.
Плотный код, кстати, обычно наблюдается у начинающих. Совсем не тот, что он привел, — с обширными комментариями ни о чем, — а именно простыни плотнейшего кода без малейших комментариев и какой либо структуры — удел всех тех, у кого еще мало опыта.
Здравствуйте, Sinix, Вы писали:
I>>Ты уверен, что они вообще нужны ? Что полезного ты нашел в его коментах ? И даже тот, что counter++ инкрементит ? S>Вы снова переходите на личности. Зачем?
Здесь нет перехода на личности, здесь просто вопросы
>Комментарии показывают, что код небезопасен для рефакторинга: count++ имеет побочные эффекты, на которые завязаны вызывающие функции. Кроме того, автор сам признаётся, что утрирует.
То есть, вместо каметов надо писать код пригодный для рефакторинга, избегать побочных эффектов.
I>>Если чел перестал бояться, что его посчитают нубом, то возможно он согласился с этим, а может и был согласен, но этот статус докучал ему S>Опять, но на этот раз вы небрежно макнули самого Йогге Попробую сформулировать иначе: код с комментариями такого уровня пишут, когда не видят нужды в самоутверждении — человек уже доказал всё, что можно и себе, и окружающим.
Код с такими каментами пишут когда не в курсе, что можно написать легко читаемый и понятный код без комментов. Это и есть нубы.
I>>А он и не приводт свой код как эталон. Он приводит его как пример изменений в его собственном случае. S>А где я называл второй листинг эталоном?
"Я бы не сказал, что нынешний код мне нравится больше." — если ты прочел статью, то в ней достаточно просто подаётся мысль, что его код тебе и не должен нравиться.
>Он просто хуже читается и поддерживается, чем код в первом листинге.
Конечно хуже. Во первых, благодаря Лиспу, во вторых, в первом листинге комментариев примерно в двадцать раз больше чем кода.
Посему вопрос — ты и вправду считаешь, что пример из лиспа будет проще поддерживать, если насовать в него каментов 20 к 1 относительно строк кода ?
I>>Процитируй, где он хвастается или хамит ? S>
S>Ещё?
Мне кажется, ты не смог отделить форму от содержания Примеры что ты процитировал это просто форма подачи.
I>> На РСДН, сравнивая с англоязычными вроде SO, SF и подобными, _очень_ _часто_ обливают помоями что бы доказать своё превосходтсво S>Если не считать КСВ, где без забрала в принципе не ходят, я ничего подобного не наблюдаю.
Не только КСВ, но и Философия, Декларативное, Архитектура, Управление, Немерле
>В любом случае, какое отношение это имеет к своеобразному стилю Йегге?
И там и там нужно отделять форму от содержания
I>>Я не сразу заметил, что статья переводная, но это абслютно неважно. Его изложение, по моему, разумению очень нейтральное и сравнивая с хаброй ничем не выделяется на общем фоне. S>It depends. После постов Липперта, Синофски, Де Смета, да даже Спольски — Йегге унылый тролль.
Йегге между тем внятно объясняет, почему нубы пишут вот такой код. Он даже больше сделал — он показал почему люди пишут императивщину. Так что кто унылый троль это еще бабушка надвое сказала.
I>>Процитируй, где ты увидел "нубы все, крмое него" ? S>См цитаты выше
Это просто троллинг на который ты повёлся.
I>>
S>"Эти языки никогда-никогда-никогда не добьются никакого коммерческого успеха, точно так же как его не добился концепт “семантического веба”. Вы не можете заставить людей создавать метаданные для всего, с чем они хотят работать. Они будут ненавидеть вас за это. "
S>Это прогнозы? Хотя нет, закрывать глаза на тонны успешных мейнстрим-языков со статической типизацией — это важнейший принцип онолитега, так что всё ок.
Перечисли не тонну, а хотя бы десяток успешных мейнстрим-языков со статической типизацией при чем коммерчески успешных. Я знаю где то три таких — C# Java C++. Delphi вот уже нельзя назвать коммерчески успешным.
I>>
S>С моделированием связана еще одна очень актуальная проблема. Модели, которые получаются в результате этого процесса, часто оказываются “неправильными”.
И что тебя смущает ? Это ж очевидная вещь Чуть иначе это формулируют ту проблему в Аджиле.
S>Продолжать? Кривые результаты — это проблемы не инструмента, а его неправильного применения. Это я говорю как человек, как минимум лет 5 успешно применяющий моделирование в разработке.
И вероятно все твои модели были правильны на любое количество времени вперёд ? Я не поверю. Как только сменились цели(а стало быть требования и задачи), твоя модель внезапно становится неправильно. Вроде и ежу понятно, что эта часть меняется крайне часто и это норма для ПО.
S>Код вообще не имеет никакого отношения к модели, тем более к модели предметной области. Очень странно читать такие пёрлы от девелопера с 25 годами боевого опыта.
Код имеет непосредственное отношение к модели решения. ООП, ФП, АОП — это разные способы моделирования решения задачи.
Еще раз — не задачи, а её решения.
I>>Ты можешь отрицать такой феномен как временное повествования, но это твои личное дело. S>Сорри, но здесь у меня терпение лопнуло. Продолжать наезжать после повторного намёка "не додумываем за окружающих" — это редкостная степень одарённости, я так не могу.
Вмест церемониальных расшаркиваний лучше говорить напрямик, оно эффективнее. Есть определенные факты и их легко установить из твоей писанины.
I>>Если статические типы являются коментами, тогда мне кажется, что люди, которые уж очень сильно полагаются на статическую типизацию, люди, которые обожают процесс статического моделирования — нубы.
I>>Неужели абзац выше сложно прочесть ? G>Кто сказал что они являются комментами? Почему далее все рассуждения опираются на то что статические типы являются кооментами\метаданными?
Хорошо, давай начнём с меньшего : "Если статические типы являются коментами, тогда мне кажется,"
Здравствуйте, VladD2, Вы писали:
VD>Но потом "гуру" осознает, что то что он писал в комментариях — это высокоуровневая спецификация задачи. И используемые им язык просто неспособен выразить это так же внятно. Тогда он снова начинает писать комментарии сетуя на то, что его язык недостаточно хорош.
В большинстве проектов язык не является узким местом. 90% времени/бюджета не на код.
Здравствуйте, deniok, Вы писали:
D>Здравствуйте, enji, Вы писали:
E>>Если статические типы являются коментами, тогда мне кажется, что люди, которые уж очень сильно полагаются на статическую типизацию, люди, которые обожают процесс статического моделирования — нубы.
D>А в строго статически типизированном Хаскелле, например, все типы выводит компилятор. Неужели в Хаскелл-комьюнити нету нубов?!
Ну как же, а компилятор?!
Здравствуйте, alexeiz, Вы писали:
A>Кстати, пример, который он привел не является плотным кодом. Это видно по тому, что на одной строке всего по одному выражению, параметры разбиты на несколько строк, и структура просматривается легко.
A>Плотный код, кстати, обычно наблюдается у начинающих. Совсем не тот, что он привел, — с обширными комментариями ни о чем, — а именно простыни плотнейшего кода без малейших комментариев и какой либо структуры — удел всех тех, у кого еще мало опыта.
Простыни плотного кода без признаков структуры это признак совсем неопытного программиста или программиста, которому нужна только ЗП
Я заметил нечто похожее за своим сыном, правда он еще не научился программировать. Сначала он складывал фигурки из конструктора присоединяя по одной детальке, мусолил долго и нудно,и толком ничего не выходило. Фигурки получались нагромождением деталей, были хлипкими и ему не нравились, из за чего он сильно расстраивался.
Совсем недавно он взял очередной уровень — сначала собрал крупные детали из мелких, а потом из крупных собрал сначала танк, а потом переделал его в робота.
На этом не остановился и в тот же вечер "взял рекурсию" — из нескольких одинаковых составных деталей, это был самолётики, собрал один, точно такой же, самолёт, но большого размера. При чем мне самому не сразу стало понятно, как он это сделал
Cамое интересное — в это же время он начал изъясняться намного более сложными фразами. Т.е. это значит что произошли качественные изменения в мышлении.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, gandjustas, Вы писали:
I>>>
I>>>Если статические типы являются коментами, тогда мне кажется, что люди, которые уж очень сильно полагаются на статическую типизацию, люди, которые обожают процесс статического моделирования — нубы.
I>>>Неужели абзац выше сложно прочесть ? G>>Кто сказал что они являются комментами? Почему далее все рассуждения опираются на то что статические типы являются кооментами\метаданными? I>Хорошо, давай начнём с меньшего : "Если статические типы являются коментами, тогда мне кажется,"
Давай, теперь надо доказать что статические типы являются комментариями, иначе все следующие рассуждения не имеют смысла.
I>
I>lookup :: (Monad m, Ord k) => k -> Map k a -> m a
I>
Это к чему?
I>С чем ты не согласен ?
Я не согласен с некорректными, с точки зрения булевой логики, утверждениями.
SV.>For instance, as just one random illustrative example, you might need to return 2 values from a function in Java (a language with no direct support for multiple return values). Should you model it as a MyFunctionCallResult class with named ValueOne and ValueTwo fields (presumably with actual names appropriate to the problem at hand)? Or should you just return a 2-element array (possibly of mixed types) and have the caller unpack it?
SV.>Это пример автора.
Нормальным решением этой проблемы было бы введение типа Tuple, или смена языка на язык поддерживающий кортежи.
SV.>От себя другой пример:
SV.>
SV.>// Где-то внутри OM, не API.
SV.>void Foo(bool rakom, bool bokom, bool sNaskoku) {}
SV.>...
SV.>Foo(false, true, true); // Плохо, ничего не понятно.
SV.>void Foo(Rakom rakom, Bokom bokom, Naskok sNaskoku) {}
SV.>Foo(Rakom.NeRakom, Bokom.Bokom, Naskok.SNaskoku);
SV.>// Часто рекомендуется, требует новых типов для, по сути, вызова одного лишь метода.
SV.>void Foo(bool rakom, bool bokom, bool sNaskoku) {}
SV.>...
SV.>Foo(rakom:false, bokom:true, sNaskoku:true); // Все понятно, новые типы не нужны.
SV.>
Я бы выбрал четвертый вариант — оставил бы у функции один параметр и сделал бы его битовой маской описанной перечислением.
ЗЫ
Названия параметров порадовали.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Ikemefula, Вы писали:
VD>>Но потом "гуру" осознает, что то что он писал в комментариях — это высокоуровневая спецификация задачи. И используемые им язык просто неспособен выразить это так же внятно. Тогда он снова начинает писать комментарии сетуя на то, что его язык недостаточно хорош.
I>В большинстве проектов язык не является узким местом. 90% времени/бюджета не на код.
Ага. 90% бюджета тратится на то, чтобы выразить на языке то, что на нем плохо выражается. Ради этого придумываются архитектуры, модели и прочая дребедень о которой говорит автор. Достаточно взглянуть на его пример с парсером, чтобы понять что тот кто писал этот код бездарно убил 99% своего времени. И наличие или отсутствие комментариев никак не улучшат этот код.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
I>>В большинстве проектов язык не является узким местом. 90% времени/бюджета не на код.
VD>Ага. 90% бюджета тратится на то, чтобы выразить на языке то, что на нем плохо выражается.
90% тратится на вещи вообще не связаные напрямую с кодом
>Ради этого придумываются архитектуры, модели и прочая дребедень о которой говорит автор. Достаточно взглянуть на его пример с парсером, чтобы понять что тот кто писал этот код бездарно убил 99% своего времени.
Вероятно проблема не в языке, а в том, что автор решил изобрести велосипед. И здесь как то не очевидно, что наличие модного языка как то поможет исправить проблему.
Здравствуйте, gandjustas, Вы писали:
I>>>>Неужели абзац выше сложно прочесть ? G>>>Кто сказал что они являются комментами? Почему далее все рассуждения опираются на то что статические типы являются кооментами\метаданными? I>>Хорошо, давай начнём с меньшего : "Если статические типы являются коментами, тогда мне кажется," G>Давай, теперь надо доказать что статические типы являются комментариями, иначе все следующие рассуждения не имеют смысла.
Не надо. Сравни "Если статические типы являются коментами" и "Статические типы являются коментами"
I>>С чем ты не согласен ? G>Я не согласен с некорректными, с точки зрения булевой логики, утверждениями.
Здравствуйте, Ikemefula, Вы писали:
I>90% тратится на вещи вообще не связаные напрямую с кодом
Если у вас это так, то вы напрасно едите свой хлеб. Все что делается в программном проекте должно быть связано с кодом получаемым в итогде. Ну, за исключением документации и заключения контрактов .
>>Ради этого придумываются архитектуры, модели и прочая дребедень о которой говорит автор. Достаточно взглянуть на его пример с парсером, чтобы понять что тот кто писал этот код бездарно убил 99% своего времени.
I>Вероятно проблема не в языке, а в том, что автор решил изобрести велосипед. И здесь как то не очевидно, что наличие модного языка как то поможет исправить проблему.
Ну, ты выше уже сказал, что 90% времени работы над своим проектом вы тратите в пустую.
Вот только вывод сделал не верный, что это не зависит от языка.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Если у вас это так, то вы напросто едите свой хлеб. Все что делается в программном проекте должно быть связано с кодом получаемым в итогде. Ну, за исключением документации и заключения контрактов .
Вот вот. А еще есть требования, к примеру, набор кадров, переписка всякая, настройки всякой всячины, переговоры всякие и тд и тд и тд.
I>>Вероятно проблема не в языке, а в том, что автор решил изобрести велосипед. И здесь как то не очевидно, что наличие модного языка как то поможет исправить проблему.
VD>Ну, ты выше уже сказал, что 90% времени работы над своим проектом вы тратите в пустую.
Ничего подобного я не говорил Обычно время записи решения в коде много меньше времени собственно времени решения. Или ты хочешь сказать, что решаешь только те задачи, которые не требуют размышлений ? В этом случае конечно скорость кодогенерации крайне важна
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Ikemefula, Вы писали:
I>>90% тратится на вещи вообще не связаные напрямую с кодом
VD>Если у вас это так, то вы напросто едите свой хлеб. Все что делается в программном проекте должно быть связано с кодом получаемым в итогде. Ну, за исключением документации и заключения контрактов .
Если сюда добавить анализ требований, тестирование и внедрение, то от написания кода и останется 10-20 процентов времени. И в итоге надо получить не программный код, а работающее решение, которое устраивает заказчика/покупателя. А не красивый код. Красивый код — это средство, которое в общем случае помогает снизить издержки на только часть процесса производства программного продукта.
ЧТо бы написать код надо (грубо):
1. Сделать предпроектное исследование, в рамках которого код не пишут, продаться
2. Иметь заключенный контракт, в рамках которого будут куча документации, но ни строчки кода.
2. Формализованные и понятные требования. ТОже без единой строчки кода
После кодирования:
1. тестирование.
2. Потом это все что накодировали надо установить и заставить взлететь.
3. закодировал — задокументруй за собой (РП, РА )
4. Теперь все это надо СДАТЬ
Так что поддержу утверждение, что на код тратиться меньшая часть времени. Просто разработчикам в основном она и видна
И кстати , если кодирование начинает занимать в процессе слишком много времени, то одно из двух:
1. Слишком мало времени уделяется другим фазам (скорее всего страдает тестирование или сбор требований — соответственно или много багов доходит до заказчика или заказчик получает не то что хотел ).
2. Сликом много не поддерживаемого кода — большая стоимость внесения изменений.
VD>Ну, ты выше уже сказал, что 90% времени работы над своим проектом вы тратите в пустую. VD>Вот только вывод сделал не верный, что это не зависит от языка.
Не правда, было сказано, что 90% занимает не код И это время не впустую проходит. Это кодить без это работы — впустую выкинутое время — все равно придется перекодировать.
Здравствуйте, Ведмедь, Вы писали:
VD>>Ну, ты выше уже сказал, что 90% времени работы над своим проектом вы тратите в пустую. VD>>Вот только вывод сделал не верный, что это не зависит от языка.
В>Не правда, было сказано, что 90% занимает не код И это время не впустую проходит. Это кодить без это работы — впустую выкинутое время — все равно придется перекодировать.
Ну что ты, в самом деле, раз 90% занимает ни код, ни, тем более, код на ...(ой!), значит время тратится впустую.
Следующим шагом в развитии индустрии ПО вероятно будет обязательное требования уметь писать на ...(ой!) начиная от охраны, уборщиц и заканчивая CEO и советом директором, не говоря про дизайнеров в т.ч. интерьера, отделы маркетинга и продаж, но также и контрактёров — переводчиков документации.
Здравствуйте, Ikemefula, Вы писали:
I>Вот вот. А еще есть требования, к примеру, набор кадров, переписка всякая,
Это не работа для программиста.
I>настройки всякой всячины, переговоры всякие и тд и тд и тд.
А это тем более. В любом, случае, если на настройку у вас уходит более одного дня в год, то вы опять же тратите время зря.
Одна из задач тех кто управляет процессом разработки автоматизировать все сопутствующие процессы и распределить обязанности в конторе.
VD>>Ну, ты выше уже сказал, что 90% времени работы над своим проектом вы тратите в пустую.
I>Ничего подобного я не говорил
Ага. Ты это сказал не так явно. Но суть от этого не меняется. Программист должен 90% времени посвящать своему коду. Это конечно, не значит, что он должен долбить код с утра до вечера, но все его действия должны быть связаны с написанием кода. Скажем, разработка алгоритма — это часть процесса разработки. В этот момент ты можешь не писать код, но это все равно часть общего процесса в результате которого получается код. И эффективность этого процесса несомненно зависит и от выбранного языка. Ведь если язык не позволяет описать задачу близко ее естественному описанию, то вы будете тратить море времени на "архитектуру" и прочую фигню, которая, как вам кажется, имеет отношение к делу, но на самом деле является накладными расходами используемого языка.
I>Обычно время записи решения в коде много меньше времени собственно времени решения.
И это говорит о неэффективности. Разве что мы по разному понимаем понятие "записи решения".
I> Или ты хочешь сказать, что решаешь только те задачи, которые не требуют размышлений ? В этом случае конечно скорость кодогенерации крайне важна
Я как раз люблю решать сложные задачи, которые требуют много размышлений. И иногда я даже специально отхожу от компьютера чтобы подумать о задаче по-серьезнее. Но 90% на размышления я точно не трачу. Задачи средней легкости я вообще проектирую в процессе решения, так как опыт подсказывает правильное решение.
Я просто хочу сказать, что когда я думаю о решении сложной задачи, я еще больше программирую, так как пробую разные решения.
Частенько я создаю новый проект просто чтобы попробовать ту или иную идею. Я создаю требуемое окружение (эмулирющее реальное) и провожу в нем тесты. Если решение получается удачным, я его использую в реальном коде.
Много времени приходится проводить в отладчике, так как приходится разбираться в чужом нетривиальном коде. Казалось бы тут то точно не должно быть зависимости от языка. Но и тут она есть, так как чем более декларативно решение, тем проще в нем разобраться, и тем меньше ты тратишь время на отладку. Конечно, на любом языке можно наклепать говнокода, но все же используя более мощный язык больше шансов написать более высокуровневый и понятный код.
Другими словами язык — это не панацея, волшебным образом превращающая говнокод в конфетку. Но язык — это очень важный инструмент помогающий хорошим руками писать хороший код. А хороший код — это залог успешности всего проекта.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
I>>Вот вот. А еще есть требования, к примеру, набор кадров, переписка всякая,
VD>Это не работа для программиста.
Опаньки, до тебя что, доводят абсолютно истинные требования, которые ты не имеешь права обсуждать если чего вылезет ?
Или вопросов у тебя никогда не возникает ?
I>>настройки всякой всячины, переговоры всякие и тд и тд и тд.
VD>А это тем более. В любом, случае, если на настройку у вас уходит более одного дня в год, то вы опять же тратите время зря.
Для некоторых контор дешевле научить программиста настраивать окружение(сервер, продукт и тд), для некоторых — дать в помощь админа, для некоторых — и целый отдел будет ненакладно.
У тебя же как то категорично выходит
I>>Ничего подобного я не говорил
VD>Ага. Ты это сказал не так явно. Но суть от этого не меняется. Программист должен 90% времени посвящать своему коду.
Если точнее, то я говорил про разработку ПО, а не про конкретного человека.
Но даже с программистомне все так просто. Программист-кодер может и должен сидеть в коде. А вот инженер разработчик софта имеет гораздо более широкий круг обязанностей, чем только код.
Опять же, в зависимости от конторы спектр задач меняется. Здесь нет серебряной пули — в крупных контора разделение задач более сильное, в мелких чаще приходится совмещать обязанности. Везде свои плюсы и свои минусы.
I>>Обычно время записи решения в коде много меньше времени собственно времени решения.
VD>И это говорит о неэффективности. Разве что мы по разному понимаем понятие "записи решения".
Решение бизнес задачи разумеется, а не генерация парсера. Есть много вариантов — держать программистов которые понимают в бизнес-задачах или держать технарей которым можно дать эксперта по бизнесу. Везде свои плюсы и минусы. А у тебя почему с одного краю эффективно, а с другого — нет
I>> Или ты хочешь сказать, что решаешь только те задачи, которые не требуют размышлений ? В этом случае конечно скорость кодогенерации крайне важна
VD>Другими словами язык — это не панацея, волшебным образом превращающая говнокод в конфетку. Но язык — это очень важный инструмент помогающий хорошим руками писать хороший код. А хороший код — это залог успешности всего проекта.
Другими словами есть разработка есть сложный процесс, который нужно оптимизировать с учетом всех факторов. И как то выходит, что девелопер здесь далеко не самый важный фактор
Что же касается языка, то нужно разделять понятия язык и речь
Здравствуйте, Ikemefula, Вы писали:
I>Опаньки, до тебя что, доводят абсолютно истинные требования, которые ты не имеешь права обсуждать если чего вылезет ?
Если вы не доверяете тем, кто собирает сведения, то лучше их заменить, а не заставлять проверять их работу.
Ну,и в любом случае, если кто-то начинает выполнять эту работу, то он уже не программист, а в лучшем случае совместитель.
I>Или вопросов у тебя никогда не возникает ?
Вопрос надо решать в рабочем порядке. Но не тратить же на это основное время?
I>>>настройки всякой всячины, переговоры всякие и тд и тд и тд.
VD>>А это тем более. В любом, случае, если на настройку у вас уходит более одного дня в год, то вы опять же тратите время зря.
I>Для некоторых контор дешевле научить программиста настраивать окружение(сервер, продукт и тд), для некоторых — дать в помощь админа, для некоторых — и целый отдел будет ненакладно.
Все эти конторы тратят время зря. Правильный выход — автоматизация процесса кофигурирвоания и развертывания. Вот на это должны идти админские часы. Но первый тип контор (по твоей классификации) просто уроды закапывающие деньги в песок.
I>У тебя же как то категорично выходит
Ага. Потому что тут двух мнений быть не может. Или процесс эффективне, или нет.
Программист эффективно выполняет только одну задачу — разрабатывает ПО. Если он вынужден тратить время на договары или внедрение, то эффективность его труда будет низкой.
И совершенно не удивительно, что в конторе где программист тратит на код 10% времени, низка и общая эффективность. Это следствие неверной организации работы.
I>Если точнее, то я говорил про разработку ПО, а не про конкретного человека.
А у вас разработку ПО делает один человек? Если, нет, то наши позиции, возможно, сходятся. Фирма не должна посвящать разработке ПО 90% своего времени. Но программист (разработчик) обязан. Все что не посвящено непосредственно разработке — это накладные расходы. Без них, конечно же, никуда. Но оптимальный процесс разработки ПО — это процесс в котором такие накладные расходы минимизированы.
И язык — это одно из важнейших средств снижения накладных расходов. Не единственное, конечно. Но очень важное. Просто парадокс Блаба не дает людям это понять. Ведь если тебе предложить писать код на ассемблере, то скорее всего ты рассмеешся в глаза и скажешь, что это глупо. Но менее очевидных случаях ты этого просто не замечаешь.
I>Но даже с программистомне все так просто. Программист-кодер может и должен сидеть в коде. А вот инженер разработчик софта имеет гораздо более широкий круг обязанностей, чем только код.
Это попытка словоблудием прекрыть неверную организацию работы.
Если программист вынужден тратить свое время на ручное тестирование, домысливание тех-задания, ручное развертывание, и тем более, на заключение контрактов, то — это просто не эффективное его использование. Большую часть времени он просто не далает ничего полезного, или выполняет чужие обязанности. Совмещение же обязаностей приводит к тому к крайне не эффективному выполнению всех обязанностей, так как человеку нужно переключаться, отвлекаться, держать в голове больше информации и т.п.
I>Опять же, в зависимости от конторы спектр задач меняется.
+1, уважаемый КО.
I>Здесь нет серебряной пули — в крупных контора разделение задач более сильное, в мелких чаще приходится совмещать обязанности. Везде свои плюсы и свои минусы.
Не спорю. Но совмещение задач — это от бедности. И если уж кто-то совмещает задачи, то надо это и рассматривать как выполнение разной работы, и не говорить, что "программист тратит 90% не на программирование". Просто он же на 90% не программист.
Но для нас важно не то, что он на Х% не программист, а то, что частенько, выполненяя обязанности программиста, такой совместитель выполняет работу которя вообще не несет никакой пользы. Например, тот же ручной деплоймент.
Совмещение же обязанностей тоже вредно. Это я знаю по своей шкуре, так как от той же бедности, так же вынужден совмещать несколько профессий в своем лице. Но я не рад этому. Я понимаю, что это плохо, и что это от бедности.
VD>>И это говорит о неэффективности. Разве что мы по разному понимаем понятие "записи решения".
I>Решение бизнес задачи разумеется, а не генерация парсера.
Это дагестанская точка зрения. Термин "бизнес-задача" не имеет отношения к решению "автоматизации бизнеса" в понимании которое принято у нас. "Бизнес" — это дело. Генерация парсеров такое же дело как и все остальные. Чтобы сгенерировать эффективный парсер, может понадобиться даже больше усилий, нежели для проектирования БД для сложной финансовой системы (как и наоборот).
Думать надо везде. Но процесс обдумывания системы — это тоже не целевое расходование времени. И если этот процесс занимает очень много времени, то эффективность точно так же снижается.
А процесс этот тем сложнее, чем менее гибкий инструментарий используется при разработке. Ведь проектируя систему мы исходим, в первую очередь, из имеющихся возможностей. Если наш язык не позволяет нам легко описать DSL, а задача легче решается при введение такого DSL, то мы вынуждены тратить море времени, на проектирование системы на значительно более низком уровне, а потом тратить еще больше времени, чтобы сначала закодировать свое низкоуровневые решение, а затем для поиска ошибок и поддержки этого решения.
В итоге, низкий уровень (не в плане качества, а в плане близости к естественному описанию) решения всегда обходится дороже. Причем на всех стадиях (проектирование, кодирование, отладка, сопровождение, развитие).
I>Есть много вариантов — держать программистов которые понимают в бизнес-задачах или держать технарей которым можно дать эксперта по бизнесу. Везде свои плюсы и минусы. А у тебя почему с одного краю эффективно, а с другого — нет
А я не об этом говорю. Программист обязан понимать что он делает. Тут нечего обсуждать. Но как это связано с временем затрачиваемым на разработку? Или мы учитываем в этом времени время на обучение прикладной области? Тогда давай еще и время на изучение программирования сюда приплетем.
VD>>Другими словами язык — это не панацея, волшебным образом превращающая говнокод в конфетку. Но язык — это очень важный инструмент помогающий хорошим руками писать хороший код. А хороший код — это залог успешности всего проекта.
I>Другими словами есть разработка есть сложный процесс, который нужно оптимизировать с учетом всех факторов. И как то выходит, что девелопер здесь далеко не самый важный фактор
Это полнейшая чушь. Единственное что делает разработчик — пишет код. Все остальное, неизбежные накладные расходы. И их нужно сокращать. Без подходящего языка — это невозможно.
Просто есть задачи, где достаточно любого языка имеющего операции сложения и управления адресами. Но таких задач не так много. Чаще сложность разработки упирается в банальную не состыковку выразительных средств используемых средств разработки и тем как понимает решение постановщик задачи.
И таки, да, вы будете тратить 90% черт знает на что, если вы будете пытаться построить дом каменным топором. Но если взять правильные инструменты, грамотно организовать труд, то можно строить по дому в день.
Разработка ПО конечно не конвейер, но это тоже инженерная дисциплина.
Так почему, когда вам говорят, что рыть траншею лопатой — это не эффективно, вы соглашаетесь, но когда вам говорят, что писать ПО на не подходящем для этого инструменте не эффективно, то вы сразу начинаете рассуждать на тему того, что инструмент не главное?
Да не главное, но без него эффектности не добиться.
I>Что же касается языка, то нужно разделять понятия язык и речь
Ага. И еще не разводить демагогию .
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Ведмедь, Вы писали:
В>Если сюда добавить анализ требований, тестирование и внедрение, то от написания кода и останется 10-20 процентов времени.
О, как? А написание тестов — это не написание кода?
Сбор же требований и внедренеие — это не задачи программиста. Если у вас эти задачи решает программист, то вы заведомо используете его время не эффективно.
С тестами же все как с обычным кода. Чем гибче язык, тем лучше на нем можно автоматизировать тестирование.
Ну, и на тесты не должно уходить более 20% времени разработки.
В>И в итоге надо получить не программный код, а работающее решение, которое устраивает заказчика/покупателя. А не красивый код.
Несомненно! Но работает в этом решении как раз таки код. А раз так, то все что не связанно с написанием кода — это не производтиельные расходы. И их нужно сокращать. Так?
В> Красивый код — это средство, которое в общем случае помогает снизить издержки на только часть процесса производства программного продукта.
Я не понял что в этой фразе должно было быть вместо выделенного "на только". Если там должно было быть "не только", то я полностью согласен с этой точкой зрения.
И еще я не согласен с термином "красивый". Код, есть продукт. Он должен быть в качественным. Понятие качества, конечно, многостороннее, но все же выразимо.
В>ЧТо бы написать код надо (грубо):
В>1. Сделать предпроектное исследование, в рамках которого код не пишут, продаться
Если код не пишут, то это не работа программиста. Хотя как раз разумно было бы код все же писать (прототипировать).
В>2. Иметь заключенный контракт, в рамках которого будут куча документации, но ни строчки кода.
Это уже точно не дело программиста. Хороший программист вам таких контрактов на заключает, что вы потом их толпой юристов не разгребете. Чтобы заключить грамотный договор, нужно знать законодательную базу, судебную практику и т.п., а не языки программирования и методы проектирования.
В>2. Формализованные и понятные требования. ТОже без единой строчки кода
Вот это уже дело программистов. И то скорее, в некоторых случаях, ее выполняют выделенные еденицы вроде архиеткров и т.п.
Опять же, для формилизации прототипирование будет не лишним. Так что строчки кода уже могли бы и появиться. А то такого можно на проектировать, что... Кстати, обсуждаемая заметка во многом именно об этом, а не о статической и динамической типизации.
В>После кодирования:
В>1. тестирование.
Без кодирования? Вы мышкой что ли свое ПО тестируете?
В>2. Потом это все что накодировали надо установить и заставить взлететь.
Это у вас тоже программисты делаю? Не, я согласен, тут нужно создать инсталлятор (если пользователей много), проестироват его, написать инструкцию, если надо. Но это не задача программиста. Или задача специально выделенного программиста-прикладника.
В>3. закодировал — задокументруй за собой (РП, РА )
А на этапе проектирования вы что делали? Или у вас получившееся решение отличается от исходного?
Ну, да опять же. По уму тут нужно привлекать техрайтеров. Или опять получается использование программиста не по назначению. Ну, да по бедности и такое бывает. Но раз так, то не надо считать, что это часть разработки. Это часть работы которую человек вынужден совмещать с трудом программиста.
В>4. Теперь все это надо СДАТЬ
О, как? А это тоже программист делает?
В>Так что поддержу утверждение, что на код тратиться меньшая часть времени. Просто разработчикам в основном она и видна
Ребята, да у вас какая-то каша получается. Вы смешиваете несколько видов деятельности и на этом основании говорите, что разработка не является основным видом деятельности. Но это всего лишь разные виды деятельности. В конторах где есть более 4 человек она должна выполнятся разными людьми. А программист должен:
1. Проектировать.
2. Кодировать.
3. Писать и прогонять тесты.
4. Отлаживать и исправлять ошибки.
Все это процессы непосредственно связанные с кодом. В любой из фаз, программист пишет, читает или думает о коде.
В>И кстати , если кодирование начинает занимать в процессе слишком много времени, то одно из двух: В>1. Слишком мало времени уделяется другим фазам
Ага. Заключению договров и внедрению .
В>(скорее всего страдает тестирование или сбор требований — соответственно или много багов доходит до заказчика или заказчик получает не то что хотел ).
И что, много багов не относится к коду? Халтурно писали код, получите море отладки. Уделяйте больше времени и внимания качеству написания кода, и получите меньше отладки. А лучше повышайте уровень кода, и уровень его контроля.
В>2. Сликом много не поддерживаемого кода — большая стоимость внесения изменений.
А это тоже от кода не зависит?
Ну, да если плевать на код и не считать его главным, а потом обосновывать баги тем, что код — это не главное, то конечно можно и до такого абсурда договориться.
В>Не правда, было сказано, что 90% занимает не код И это время не впустую проходит. Это кодить без это работы — впустую выкинутое время — все равно придется перекодировать.
Совершенно без различно как тратить время в пустую. Можно 90% "кодить" и получить никому не нужный бред или багодром, а можно 90% дизайнить и получить еще худший результат. Время все равно будет потеряно.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Ikemefula, Вы писали:
I>Не надо. Сравни "Если статические типы являются коментами" и "Статические типы являются коментами"
I>>>С чем ты не согласен ? G>>Я не согласен с некорректными, с точки зрения булевой логики, утверждениями.
I>"Если" != ""
Главное, что верно то, что статические типы не являются коментариями. Остальное вытекает по индукции.
Так что рассматриваемое утверждение исходно не верно.
Чтобы понять ошибочность этих утверждений можно заменить типы на тесты или ассерты. Ведь без них программа тоже не перестанет быть программой. Вот только качества они свои изменим. Например, мы не сможем быть уверены, что программа осталась работоспособной после рефакторинга.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
А зря. То что процитировано здесь — это фразы выдранные из контекста. Статья ни разу не о статической типизации или о комментариях и т.п. Статья о перегибах. И при все ошибочности предпосылок и аналогий присутствующих в ней, ее утверждения довольно разумны.
Вот только правильные выводы сделанные на базе не верных предпосылок говорят только о том, что автор не справился со своей задачей.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Ikemefula, Вы писали:
VD>>>Но потом "гуру" осознает, что то что он писал в комментариях — это высокоуровневая спецификация задачи. И используемые им язык просто неспособен выразить это так же внятно. Тогда он снова начинает писать комментарии сетуя на то, что его язык недостаточно хорош.
I>>В большинстве проектов язык не является узким местом. 90% времени/бюджета не на код.
VD>Ага. 90% бюджета тратится на то, чтобы выразить на языке то, что на нем плохо выражается. Ради этого придумываются архитектуры, модели и прочая дребедень о которой говорит автор.
Отчасти согласен. Но не 90% времени.
(вспоминается паттерн "виртуальный конструктор")
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, VladD2, Вы писали:
VD>Если вы не доверяете тем, кто собирает сведения, то лучше их заменить, а не заставлять проверять их работу.
У тебя баги бывают ? Бывают. Почему не вижу от тебя призывов заменить VladD2 ?
Не бывает идеальных исполнителей.
VD>Ну,и в любом случае, если кто-то начинает выполнять эту работу, то он уже не программист, а в лучшем случае совместитель.
Правильно, SSE как правило больше чем программист.
I>>Или вопросов у тебя никогда не возникает ?
VD>Вопрос надо решать в рабочем порядке. Но не тратить же на это основное время?
А что значит в рабочем порядке ? Основное время это 8 часов в день. Оставаться после работы что ли ?
I>>Для некоторых контор дешевле научить программиста настраивать окружение(сервер, продукт и тд), для некоторых — дать в помощь админа, для некоторых — и целый отдел будет ненакладно.
VD>Все эти конторы тратят время зря. Правильный выход — автоматизация процесса кофигурирвоания и развертывания. Вот на это должны идти админские часы. Но первый тип контор (по твоей классификации) просто уроды закапывающие деньги в песок.
Ну ты в курсе, оптимизация должна быть mature Конторы ничего не закапывают. Оптимизировать такие расходы нужно в том случае, если они становятся критическим местом.
VD>Ага. Потому что тут двух мнений быть не может. Или процесс эффективне, или нет. VD>Программист эффективно выполняет только одну задачу — разрабатывает ПО. Если он вынужден тратить время на договары или внедрение, то эффективность его труда будет низкой.
А почему ты решил, что во всех фирмах программист это самый критический участок процесса ?
VD>И совершенно не удивительно, что в конторе где программист тратит на код 10% времени, низка и общая эффективность. Это следствие неверной организации работы.
Конечно. Это хорошо объясняет положение #1 на рынке Общая эффективность слабо зависит от программиста. А вот например от качества работы маркетинга зависит крайне сильно.
VD>А у вас разработку ПО делает один человек? Если, нет, то наши позиции, возможно, сходятся. Фирма не должна посвящать разработке ПО 90% своего времени. Но программист (разработчик) обязан. Все что не посвящено непосредственно разработке — это накладные расходы. Без них, конечно же, никуда. Но оптимальный процесс разработки ПО — это процесс в котором такие накладные расходы минимизированы.
Оптимальный это процесс это такой, который позволяет максимально эффективно достигать цели. Минимизация издержек о которой ты говоришь это каменный век, путь в никуда.
Смотри, минимизировать накладные расходы можно одним простым путём — закрыть контору и оставить одного человека на телефон. Меньше просто не бывает. При этом совершенно не ясно, как фирма будет достигать цели.
VD>И язык — это одно из важнейших средств снижения накладных расходов. Не единственное, конечно. Но очень важное. Просто парадокс Блаба не дает людям это понять. Ведь если тебе предложить писать код на ассемблере, то скорее всего ты рассмеешся в глаза и скажешь, что это глупо. Но менее очевидных случаях ты этого просто не замечаешь.
Снижение накладных расходов это одна из самых неэффективных оптимизаций.
VD>Если программист вынужден тратить свое время на ручное тестирование, домысливание тех-задания, ручное развертывание, и тем более, на заключение контрактов, то — это просто не эффективное его использование.
Появление Канбана в ПО однозначно доказывает что твой взгляд мягко говоря устарел.
>Большую часть времени он просто не далает ничего полезного, или выполняет чужие обязанности. Совмещение же обязаностей приводит к тому к крайне не эффективному выполнению всех обязанностей, так как человеку нужно переключаться, отвлекаться, держать в голове больше информации и т.п.
Конечно надо, но овчинка стоит выделки. Например если программисту приходится совать нос в тестирование, это даёт опыт который практически ничем нельзя заменить. Важно иметь как можно больше вариантов решения проблемы и совмещение обязанностей способствует этому.
VD>Не спорю. Но совмещение задач — это от бедности. И если уж кто-то совмещает задачи, то надо это и рассматривать как выполнение разной работы, и не говорить, что "программист тратит 90% не на программирование". Просто он же на 90% не программист.
Термин программист на нынешний день устарел.
VD>Но для нас важно не то, что он на Х% не программист, а то, что частенько, выполненяя обязанности программиста, такой совместитель выполняет работу которя вообще не несет никакой пользы. Например, тот же ручной деплоймент.
Для того, что бы внедрить автоматический деплоймент, очень хорошо заставить программистов деплоить руками. Тогда они сами сделают автоматизацию и вычистят из кода всё, что мешает автоматическому деплойменту. А вот в конторах, где деплоймент отделяют от программистов очень часто ручной деплоймент сохраняется на годы.
VD>Совмещение же обязанностей тоже вредно. Это я знаю по своей шкуре, так как от той же бедности, так же вынужден совмещать несколько профессий в своем лице. Но я не рад этому. Я понимаю, что это плохо, и что это от бедности.
Самый ценный опыт я получал в то время, когда совмещал обязанности. То есть, дело сводится к тому, как извлечь из этого пользу. Если мне нужно кликать в UI неделю-другую, я четко понимаю, что это за польза лично для меня и для конторы. Контора прибегает к такому способу когда тестирование становится критическим участком — больше кликов, больше фиксов. Для меня такой этап заканчивается четким представлением что не так с программой с т.з. пользователя.
I>>Решение бизнес задачи разумеется, а не генерация парсера.
VD>Это дагестанская точка зрения. Термин "бизнес-задача" не имеет отношения к решению "автоматизации бизнеса" в понимании которое принято у нас. "Бизнес" — это дело. Генерация парсеров такое же дело как и все остальные. Чтобы сгенерировать эффективный парсер, может понадобиться даже больше усилий, нежели для проектирования БД для сложной финансовой системы (как и наоборот).
Бизнес это то, что приносит основной доход. Парсеры это техническая сторона. То есть я говорю про отделение мух от котлет. Если ты парсер ты пишешь на продажу, то да, генерация парсера это бизнес. При этом настолько специфичный, что его даже рассматривать всерьез нельзя.
VD>А я не об этом говорю. Программист обязан понимать что он делает. Тут нечего обсуждать. Но как это связано с временем затрачиваемым на разработку? Или мы учитываем в этом времени время на обучение прикладной области? Тогда давай еще и время на изучение программирования сюда приплетем.
Да, и время на обучение, и время на освоение технологий, инструментов и в т.ч..
I>>Другими словами есть разработка есть сложный процесс, который нужно оптимизировать с учетом всех факторов. И как то выходит, что девелопер здесь далеко не самый важный фактор VD>Это полнейшая чушь. Единственное что делает разработчик — пишет код. Все остальное, неизбежные накладные расходы. И их нужно сокращать. Без подходящего языка — это невозможно.
Когда код становится самым критичным участком только тогда и надо оптимизировать. В большинстве случаев проще купить готовый компонент, а не выписывать на коленкемега-языке целый стек технологий.
VD>Разработка ПО конечно не конвейер, но это тоже инженерная дисциплина.
В ПО уже появился такой процесс разработки как конвейер
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Ведмедь, Вы писали:
В>>Если сюда добавить анализ требований, тестирование и внедрение, то от написания кода и останется 10-20 процентов времени.
VD>О, как? А написание тестов — это не написание кода?
В общем случае нет, конечно. автоматическими тестами к сожеланию все не покрывается. Да и собственно написание тестов это далеко не 100% времени тестирования. Более того, по хорошему автоматические тесты к коду должен писать не тот же человек, который пишет сам код. Что бы была точко рабочего конфликта.
VD>Сбор же требований и внедренеие — это не задачи программиста. Если у вас эти задачи решает программист, то вы заведомо используете его время не эффективно.
А кто сказал, что работа над программным продуктом это только работа прграммиста? А остальные так, покурить вышли?
VD>С тестами же все как с обычным кода. Чем гибче язык, тем лучше на нем можно автоматизировать тестирование. VD>Ну, и на тесты не должно уходить более 20% времени разработки.
В>>И в итоге надо получить не программный код, а работающее решение, которое устраивает заказчика/покупателя. А не красивый код.
VD>Несомненно! Но работает в этом решении как раз таки код. А раз так, то все что не связанно с написанием кода — это не производтиельные расходы. И их нужно сокращать. Так?
Нет, не так. сбор, анализ требований, тестирование и т.д. это такие же производительные расходы.
В>> Красивый код — это средство, которое в общем случае помогает снизить издержки на только часть процесса производства программного продукта.
VD>Я не понял что в этой фразе должно было быть вместо выделенного "на только". Если там должно было быть "не только", то я полностью согласен с этой точкой зрения.
Не, все правильно. Я к тому, что красивый и правильный код сокращает издержки только на часть производственного процесса.
VD>И еще я не согласен с термином "красивый". Код, есть продукт. Он должен быть в качественным. Понятие качества, конечно, многостороннее, но все же выразимо.
Во! И оказывается, что достижение идеального кода это зло — достаточно просто кода нужного качества. Иначе слишком большие издержи и time to market.
В>>ЧТо бы написать код надо (грубо):
В>>1. Сделать предпроектное исследование, в рамках которого код не пишут, продаться
VD>Если код не пишут, то это не работа программиста. Хотя как раз разумно было бы код все же писать (прототипировать).
Эм... чую все таки надо определиться, мы говорим о проценте кодирования вообще в производстве продукта или процент времени(трудоемкости, стоимости) кодирования только прграммиста?
В>>2. Иметь заключенный контракт, в рамках которого будут куча документации, но ни строчки кода.
VD>Это уже точно не дело программиста. Хороший программист вам таких контрактов на заключает, что вы потом их толпой юристов не разгребете. Чтобы заключить грамотный договор, нужно знать законодательную базу, судебную практику и т.п., а не языки программирования и методы проектирования.
В>>2. Формализованные и понятные требования. ТОже без единой строчки кода
VD>Вот это уже дело программистов. И то скорее, в некоторых случаях, ее выполняют выделенные еденицы вроде архиеткров и т.п.
VD>Опять же, для формилизации прототипирование будет не лишним. Так что строчки кода уже могли бы и появиться. А то такого можно на проектировать, что... Кстати, обсуждаемая заметка во многом именно об этом, а не о статической и динамической типизации.
В>>После кодирования:
В>>1. тестирование.
VD>Без кодирования? Вы мышкой что ли свое ПО тестируете?
А что вы вообще без людей тестируете? И пользовательский интерфейс? И бак трекинга нет? И никто не "дравит" баги?
В>>2. Потом это все что накодировали надо установить и заставить взлететь.
VD>Это у вас тоже программисты делаю? Не, я согласен, тут нужно создать инсталлятор (если пользователей много), проестироват его, написать инструкцию, если надо. Но это не задача программиста. Или задача специально выделенного программиста-прикладника.
Опять же надо определеиться мы говорим про программиста только ии вообще про весь процесс
В>>3. закодировал — задокументруй за собой (РП, РА )
VD>А на этапе проектирования вы что делали? Или у вас получившееся решение отличается от исходного?
Ну во первых конечное решение решение может отличаться. Во вторых на этапе проектирования все детали прописывать слишком дорого. Более того на этапе на этапе сбора требований, например получается ответ на вопрос "что надо", а после кодирования видно "как это работает". Детальная информация о настройке системы доступна только после кодирования. А РП вообще пишется в другом ключе — с точки зрения обучения операторов. Как бы не дело это делать на этапе проектирования
VD>Ну, да опять же. По уму тут нужно привлекать техрайтеров. Или опять получается использование программиста не по назначению. Ну, да по бедности и такое бывает. Но раз так, то не надо считать, что это часть разработки. Это часть работы которую человек вынужден совмещать с трудом программиста.
В>>4. Теперь все это надо СДАТЬ
VD>О, как? А это тоже программист делает?
В>>Так что поддержу утверждение, что на код тратиться меньшая часть времени. Просто разработчикам в основном она и видна
VD>Ребята, да у вас какая-то каша получается. Вы смешиваете несколько видов деятельности и на этом основании говорите, что разработка не является основным видом деятельности. Но это всего лишь разные виды деятельности. В конторах где есть более 4 человек она должна выполнятся разными людьми. А программист должен: VD>1. Проектировать. VD>2. Кодировать. VD>3. Писать и прогонять тесты. VD>4. Отлаживать и исправлять ошибки.
VD>Все это процессы непосредственно связанные с кодом. В любой из фаз, программист пишет, читает или думает о коде.
В>>И кстати , если кодирование начинает занимать в процессе слишком много времени, то одно из двух: В>>1. Слишком мало времени уделяется другим фазам
VD>Ага. Заключению договров и внедрению .
В>>(скорее всего страдает тестирование или сбор требований — соответственно или много багов доходит до заказчика или заказчик получает не то что хотел ).
VD>И что, много багов не относится к коду? Халтурно писали код, получите море отладки. Уделяйте больше времени и внимания качеству написания кода, и получите меньше отладки. А лучше повышайте уровень кода, и уровень его контроля.
Достаточно много багов относится не к коду — например к требованиям.
В>>2. Сликом много не поддерживаемого кода — большая стоимость внесения изменений.
VD>А это тоже от кода не зависит?
VD>Ну, да если плевать на код и не считать его главным, а потом обосновывать баги тем, что код — это не главное, то конечно можно и до такого абсурда договориться.
При чем тут плевать на код? Просто считать код главным тоже заблуждение. Это все равно что считать, что самый главный на стройке тот кто кладет кирпичную стену.
В>>Не правда, было сказано, что 90% занимает не код И это время не впустую проходит. Это кодить без это работы — впустую выкинутое время — все равно придется перекодировать.
VD>Совершенно без различно как тратить время в пустую. Можно 90% "кодить" и получить никому не нужный бред или багодром, а можно 90% дизайнить и получить еще худший результат. Время все равно будет потеряно.
А можно написать прекарсный код, а потом узнать что он делает не то что надо заказчику. Это будет пустое кодирование.
Здравствуйте, VladD2, Вы писали:
VD>Нормальным решением этой проблемы было бы введение типа Tuple,
...что мало отличается от массива из 2 элементов. Напомню, рассматриваемая альтернатива — MyFunctionCallResult class.
>или смена языка на язык поддерживающий кортежи.
На практике смена языка — нереальное решение для grunt'ов.
VD>Я бы выбрал четвертый вариант — оставил бы у функции один параметр и сделал бы его битовой маской описанной перечислением.
То есть, ввели бы новый тип. Это и есть злоупотребление типами. Я особо оговорил в комментарии, что это не API, а кишки объектной модели. То есть, отдельная частная имплементация одной функции. Стоит ли заводить enum? Более того, если уж все-таки создавать enum'ы, то по одному на каждый параметр, ибо смешивать несвязанные параметры в одном перечислении никак нельзя.
VD>ЗЫ VD>Названия параметров порадовали.
Боюсь, из-за глупого юмора в примере, от прочитавших ускользнула несвязанность параметров (например, можно предположить, что это способы последовательно выполняемых действий, то есть связь все-таки есть). Mea culpa. В жопу литерадуру.
Здравствуйте, Ведмедь, Вы писали:
VD>>Сбор же требований и внедренеие — это не задачи программиста. Если у вас эти задачи решает программист, то вы заведомо используете его время не эффективно. В>А кто сказал, что работа над программным продуктом это только работа прграммиста? А остальные так, покурить вышли?
Да какая разница чем остальные занимаются?
Нет, я понимаю, что самая главная в мире профессия — маркетолога-продажника, но разговор вроде же немного не об этом.
Здравствуйте, Философ, Вы писали:
Ф>Отчасти согласен. Но не 90% времени. Ф>(вспоминается паттерн "виртуальный конструктор")
Ну, процент обсуждается . Потом он, конечно же, разный в разных случаях.
Я то отвечал на реплику "от языка ничего не зависит, так как 90% времени тратится не на программирование". На это я и ответил, что а) вы тратите силы программистов не эффективно; б) подходящий язык сокращает не только время на кодирование, но и на проектирование, и отладку.
Казалось бы простые истины, но с ними так ожесточенно спорят, чтобы оправдать свой выбор.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Ikemefula, Вы писали:
VD>>Если вы не доверяете тем, кто собирает сведения, то лучше их заменить, а не заставлять проверять их работу.
I>У тебя баги бывают ?
Бывают.
I>Почему не вижу от тебя призывов заменить VladD2 ?
Потому что я себе доверяю. Если есть баг и я знаю о нем, то поправлю.
I>Не бывает идеальных исполнителей.
Не бывает. Но это не оправдание чтобы заниматься не своим делом.
VD>>Ну,и в любом случае, если кто-то начинает выполнять эту работу, то он уже не программист, а в лучшем случае совместитель.
I>Правильно, SSE как правило больше чем программист.
Это по фигу. Больше или меньше тут не применимы. Он не программист и потому говорить о том, сколько он тратит время на программирования не имеет смысла.
I>>>Для некоторых контор дешевле научить программиста настраивать окружение(сервер, продукт и тд), для некоторых — дать в помощь админа, для некоторых — и целый отдел будет ненакладно.
VD>>Все эти конторы тратят время зря. Правильный выход — автоматизация процесса кофигурирвоания и развертывания. Вот на это должны идти админские часы. Но первый тип контор (по твоей классификации) просто уроды закапывающие деньги в песок.
I>Ну ты в курсе, оптимизация должна быть mature
Какая на фиг оптимизация? Я сказал "автоматизация".
I>Конторы ничего не закапывают. Оптимизировать такие расходы нужно в том случае, если они становятся критическим местом.
А если они не критичны, то о них и говорить не стоит. Но раз у вас 90% времени программиста уходит на черт знает что (вроде развертывания софта), то они точно критичны и их нужно автоматизировать.
В прочем, непроизводственные действия всегда нужно автоматизировать. Я стараюсь все нужные действия заложить в один батник, так чтобы после нажатия на него в итоге я получил бы запущенные тесты или сообщения об ошибках.
VD>>Ага. Потому что тут двух мнений быть не может. Или процесс эффективне, или нет. VD>>Программист эффективно выполняет только одну задачу — разрабатывает ПО. Если он вынужден тратить время на договары или внедрение, то эффективность его труда будет низкой.
I>А почему ты решил, что во всех фирмах программист это самый критический участок процесса ?
Я так не решал. Но мы говорим о программисте. Так что не надо сюда приплетать черт знает что.
Если в вашей фирме основные трудозатраты — это навешивание лапши на уши клиентов, то это всего лишь значит, что основной деятельностью вашей фирмы не является разработка ПО. Но если у вас есть программист, то его основной задачей, все равно, остается написание кода. А если он делает что-то еще, то он а) не программист; б) априори неэффективен (так как совмещение всегда снижает эффективность).
VD>>И совершенно не удивительно, что в конторе где программист тратит на код 10% времени, низка и общая эффективность. Это следствие неверной организации работы.
I>Конечно. Это хорошо объясняет положение #1 на рынке Общая эффективность слабо зависит от программиста. А вот например от качества работы маркетинга зависит крайне сильно.
VD>>А у вас разработку ПО делает один человек? Если, нет, то наши позиции, возможно, сходятся. Фирма не должна посвящать разработке ПО 90% своего времени. Но программист (разработчик) обязан. Все что не посвящено непосредственно разработке — это накладные расходы. Без них, конечно же, никуда. Но оптимальный процесс разработки ПО — это процесс в котором такие накладные расходы минимизированы.
I>Оптимальный это процесс это такой, который позволяет максимально эффективно достигать цели. Минимизация издержек о которой ты говоришь это каменный век, путь в никуда.
I>Смотри, минимизировать накладные расходы можно одним простым путём — закрыть контору и оставить одного человека на телефон. Меньше просто не бывает. При этом совершенно не ясно, как фирма будет достигать цели.
VD>>И язык — это одно из важнейших средств снижения накладных расходов. Не единственное, конечно. Но очень важное. Просто парадокс Блаба не дает людям это понять. Ведь если тебе предложить писать код на ассемблере, то скорее всего ты рассмеешся в глаза и скажешь, что это глупо. Но менее очевидных случаях ты этого просто не замечаешь.
I>Снижение накладных расходов это одна из самых неэффективных оптимизаций.
VD>>Если программист вынужден тратить свое время на ручное тестирование, домысливание тех-задания, ручное развертывание, и тем более, на заключение контрактов, то — это просто не эффективное его использование.
I>Появление Канбана в ПО однозначно доказывает что твой взгляд мягко говоря устарел.
>>Большую часть времени он просто не далает ничего полезного, или выполняет чужие обязанности. Совмещение же обязаностей приводит к тому к крайне не эффективному выполнению всех обязанностей, так как человеку нужно переключаться, отвлекаться, держать в голове больше информации и т.п.
I>Конечно надо, но овчинка стоит выделки. Например если программисту приходится совать нос в тестирование, это даёт опыт который практически ничем нельзя заменить. Важно иметь как можно больше вариантов решения проблемы и совмещение обязанностей способствует этому.
VD>>Не спорю. Но совмещение задач — это от бедности. И если уж кто-то совмещает задачи, то надо это и рассматривать как выполнение разной работы, и не говорить, что "программист тратит 90% не на программирование". Просто он же на 90% не программист.
I>Термин программист на нынешний день устарел.
VD>>Но для нас важно не то, что он на Х% не программист, а то, что частенько, выполненяя обязанности программиста, такой совместитель выполняет работу которя вообще не несет никакой пользы. Например, тот же ручной деплоймент.
I>Для того, что бы внедрить автоматический деплоймент, очень хорошо заставить программистов деплоить руками. Тогда они сами сделают автоматизацию и вычистят из кода всё, что мешает автоматическому деплойменту. А вот в конторах, где деплоймент отделяют от программистов очень часто ручной деплоймент сохраняется на годы.
VD>>Совмещение же обязанностей тоже вредно. Это я знаю по своей шкуре, так как от той же бедности, так же вынужден совмещать несколько профессий в своем лице. Но я не рад этому. Я понимаю, что это плохо, и что это от бедности.
I>Самый ценный опыт я получал в то время, когда совмещал обязанности. То есть, дело сводится к тому, как извлечь из этого пользу. Если мне нужно кликать в UI неделю-другую, я четко понимаю, что это за польза лично для меня и для конторы. Контора прибегает к такому способу когда тестирование становится критическим участком — больше кликов, больше фиксов. Для меня такой этап заканчивается четким представлением что не так с программой с т.з. пользователя.
I>>>Решение бизнес задачи разумеется, а не генерация парсера.
VD>>Это дагестанская точка зрения. Термин "бизнес-задача" не имеет отношения к решению "автоматизации бизнеса" в понимании которое принято у нас. "Бизнес" — это дело. Генерация парсеров такое же дело как и все остальные. Чтобы сгенерировать эффективный парсер, может понадобиться даже больше усилий, нежели для проектирования БД для сложной финансовой системы (как и наоборот).
I>Бизнес это то, что приносит основной доход. Парсеры это техническая сторона. То есть я говорю про отделение мух от котлет. Если ты парсер ты пишешь на продажу, то да, генерация парсера это бизнес. При этом настолько специфичный, что его даже рассматривать всерьез нельзя.
VD>>А я не об этом говорю. Программист обязан понимать что он делает. Тут нечего обсуждать. Но как это связано с временем затрачиваемым на разработку? Или мы учитываем в этом времени время на обучение прикладной области? Тогда давай еще и время на изучение программирования сюда приплетем.
I>Да, и время на обучение, и время на освоение технологий, инструментов и в т.ч..
I>>>Другими словами есть разработка есть сложный процесс, который нужно оптимизировать с учетом всех факторов. И как то выходит, что девелопер здесь далеко не самый важный фактор VD>>Это полнейшая чушь. Единственное что делает разработчик — пишет код. Все остальное, неизбежные накладные расходы. И их нужно сокращать. Без подходящего языка — это невозможно.
I>Когда код становится самым критичным участком только тогда и надо оптимизировать. В большинстве случаев проще купить готовый компонент, а не выписывать на коленкемега-языке целый стек технологий.
VD>>Разработка ПО конечно не конвейер, но это тоже инженерная дисциплина.
I>В ПО уже появился такой процесс разработки как конвейер
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Ведмедь, Вы писали:
В>Здравствуйте, VladD2, Вы писали:
VD>>Здравствуйте, Ведмедь, Вы писали:
В>>>Если сюда добавить анализ требований, тестирование и внедрение, то от написания кода и останется 10-20 процентов времени.
VD>>О, как? А написание тестов — это не написание кода?
В>В общем случае нет, конечно.
Ну, тогда вам придется признать, что ваш процесс разработки далек от эффективности.
В>автоматическими тестами к сожеланию все не покрывается.
Это почему это? Разве что ГУИ трудно автоматизировать. Но те у кого его много и это делают.
В>Да и собственно написание тестов это далеко не 100% времени тестирования.
О, как? А что же еще такое трудозатратное вы делаете? Разрабатываете архитектуру тестирования? Проводите консилиумы?
Я знаю два вида тесто. Один закрепляет реализованный функционал. Другой закрепляет исправленный баг, что по сути вариация первого случая. Что же еще с ними можно делать?
В>Более того, по хорошему автоматические тесты к коду должен писать не тот же человек, который пишет сам код.
Согласен! В идеале даже можно двух тестеров на одного плодотворного разработчика посдаить. Это так же повысит его эффективность. Но от бедности пишут тесты и сами.
В>Что бы была точко рабочего конфликта.
Вот это что-то очень сложное. Им бы не конфликтовать, а работать в паре.
VD>>Сбор же требований и внедренеие — это не задачи программиста. Если у вас эти задачи решает программист, то вы заведомо используете его время не эффективно.
В>А кто сказал, что работа над программным продуктом это только работа прграммиста? А остальные так, покурить вышли?
Остальные нас не колышат. Мы обсуждали вопрос эффективности программистов. ПО — это код и документация. Остальное — это уже не разработка ПО.
VD>>Несомненно! Но работает в этом решении как раз таки код. А раз так, то все что не связанно с написанием кода — это не производтиельные расходы. И их нужно сокращать. Так?
В>Нет, не так. сбор, анализ требований, тестирование и т.д. это такие же производительные расходы.
Нет. Это расходы которые не отностяся напрямую к разработке. И их нужно сокращать. Они, несомненно, нужны, так как без них время на написание кода может увеличиться. Но если кто-то тратит на сбор требований или тестирование больше времени чем на разработку, то он просто работает дико не эффективно.
В>Не, все правильно. Я к тому, что красивый и правильный код сокращает издержки только на часть производственного процесса.
Это заблуждение. Когда-нибудь, возможно, ты поймешь это.
В>Во! И оказывается, что достижение идеального кода это зло
Чушь какая-те. Причем тут идеал?
В>- достаточно просто кода нужного качества. Иначе слишком большие издержи и time to market.
Судя по вашим словам, в качество кода у вас низкое. Ваши методы разработки ПО столь чудовищно не эффективны, что вы разводите демагогию на тему неважности кода. Но суть в том, что именно тот факт что ваш код плох и приводит к неэффективности всего процесса.
В>Эм... чую все таки надо определиться, мы говорим о проценте кодирования вообще в производстве продукта или процент времени(трудоемкости, стоимости) кодирования только прграммиста?
Конечно программиста. Процент труда бухгалтера нас вообще не трогает. Язык то бухгалтер не использует.
А если ваша фирма тратит мало времени на разработку и много на разные другие вещи, то просто отдайте разработку профессионалам. Они обойдутся дешевле. А сами сосредоточитесь на том что у вас получается хорошо. Ну, там на продажах, маркетинге, выигрывании тендеров и т.п.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, SV., Вы писали:
VD>>Нормальным решением этой проблемы было бы введение типа Tuple,
SV.>...что мало отличается от массива из 2 элементов. Напомню, рассматриваемая альтернатива — MyFunctionCallResult class.
В статически-типизированном то языке?
Просто это грамотное обобщение. Но в каком-нибудь Обероне это просто невозможно сделать, например.
SV.>На практике смена языка — нереальное решение для grunt'ов.
Словарь мне сказал, что grunt — это "хрюканье", "ворчанье", "мычание", т.е. какие-то животные.
SV.>То есть, ввели бы новый тип.
Ну, да. У меня по этому поводу пунктиков нет. Если так для дела лучше, то почему бы не ввести?
SV.>Это и есть злоупотребление типами.
Злоупотребление — это значения свойств в классы запихивать. А ввести тип для описания состояния — это совершенно нормально.
SV.>Я особо оговорил в комментарии, что это не API, а кишки объектной модели. То есть, отдельная частная имплементация одной функции. Стоит ли заводить enum?
Зависит от обстоятельств. Может и стоит. Зачем-то ведь отдельную функцию завели? Я вот, если функция частная, делаю ее локальной функций. Но это опят же требует использования более продвинутого языка.
SV.>Более того, если уж все-таки создавать enum'ы, то по одному на каждый параметр, ибо смешивать несвязанные параметры в одном перечислении никак нельзя.
Ну, да. Кода вместо доводов разума начинают тупо применять заученные правила, жопа и появляется.
Орел привел конкретный метод где значения были НеРаком, Боком, Наскоком. Все часть одного состояния. Ну, так на фиг мне его по параметрам разбивать?
SV.>Боюсь, из-за глупого юмора в примере, от прочитавших ускользнула несвязанность параметров (например, можно предположить, что это способы последовательно выполняемых действий, то есть связь все-таки есть). Mea culpa. В жопу литерадуру.
Может быть. Что говорит об авторе примера, но не как не об обсуждаемой проблеме.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
В>>>>Если сюда добавить анализ требований, тестирование и внедрение, то от написания кода и останется 10-20 процентов времени.
VD>>>О, как? А написание тестов — это не написание кода?
В>>В общем случае нет, конечно.
VD>Ну, тогда вам придется признать, что ваш процесс разработки далек от эффективности.
Нет в мире совершенства. Но свести тестирование только к написанию кода тестов это еще дальше от эффективности. Поговорите с любым грамотным QA инженером на эту тему.
В>>автоматическими тестами к сожеланию все не покрывается.
VD>Это почему это? Разве что ГУИ трудно автоматизировать. Но те у кого его много и это делают.
Именно что UI. И оно автоматизируется. НО не все и трудоемко. А заказчику плевать, что у вас прекрасно работает внутренние функции, если в интерфейсе он видит какую то гадость.
В>>Да и собственно написание тестов это далеко не 100% времени тестирования.
VD>О, как? А что же еще такое трудозатратное вы делаете? Разрабатываете архитектуру тестирования? Проводите консилиумы?
1. Создание тестовой модели (регресс старого функционала, описание новых требований. как нис транно что бы даже тест закодить надо сначала подумать как можно проверить те или иные требования)
2. Локализация бага (источник бага живет чаще всего не там где его обнаружили)
VD>Я знаю два вида тесто. Один закрепляет реализованный функционал. Другой закрепляет исправленный баг, что по сути вариация первого случая. Что же еще с ними можно делать?
А баги настройки? Ведь бывает такое, что код верный, но криво настроен. Или все, раз код написан и выполняется в тестовой среде, то дальше жизнь заканчивается?
В>>Более того, по хорошему автоматические тесты к коду должен писать не тот же человек, который пишет сам код.
VD>Согласен! В идеале даже можно двух тестеров на одного плодотворного разработчика посдаить. Это так же повысит его эффективность. Но от бедности пишут тесты и сами.
В>>Что бы была точко рабочего конфликта.
VD>Вот это что-то очень сложное. Им бы не конфликтовать, а работать в паре.
Это очень простое — что бы не было стимула сговариваться У того, кто пишет тесты и тот кто пишет код задачи разные. Если это будет один и тот же человек, то он всегда сможет с собой договориться. Нужен высокий уровень самодисциплины и квалификации что бы честно прописать тесты самому себе.
VD>>>Сбор же требований и внедренеие — это не задачи программиста. Если у вас эти задачи решает программист, то вы заведомо используете его время не эффективно.
В>>А кто сказал, что работа над программным продуктом это только работа прграммиста? А остальные так, покурить вышли?
VD>Остальные нас не колышат. Мы обсуждали вопрос эффективности программистов. ПО — это код и документация. Остальное — это уже не разработка ПО.
Так мы говорим про эффективность программиста или про эффективность разработки ПО? Потому как программист это обычно только код. А код, даже с документацией без поддержки и настройки.
Вы знаете, что разработчики больших систем практически не боятся кражи исходников? ДАже с документацией? Потому что эти исходники и документация без людей и процесса ни шиша не стоят. Где то лет 8 назад был эпический флейм на эту тему — кто то хотел на одном из форумов хотел продать исходники билинговой системы. Сейчас не могу найти, но никто почему то покупать не хотел.
VD>>>Несомненно! Но работает в этом решении как раз таки код. А раз так, то все что не связанно с написанием кода — это не производтиельные расходы. И их нужно сокращать. Так?
В>>Нет, не так. сбор, анализ требований, тестирование и т.д. это такие же производительные расходы.
VD>Нет. Это расходы которые не отностяся напрямую к разработке. И их нужно сокращать. Они, несомненно, нужны, так как без них время на написание кода может увеличиться. Но если кто-то тратит на сбор требований или тестирование больше времени чем на разработку, то он просто работает дико не эффективно.
Вы под разработку ПО с кодированием не путаете? Написать 1000 строк кода, пусть даже и работающего это не разработка ПО. Нужен код, который делает то что от него требуется.
В>>Не, все правильно. Я к тому, что красивый и правильный код сокращает издержки только на часть производственного процесса.
VD>Это заблуждение. Когда-нибудь, возможно, ты поймешь это.
В>>Во! И оказывается, что достижение идеального кода это зло
VD>Чушь какая-те. Причем тут идеал?
В>>- достаточно просто кода нужного качества. Иначе слишком большие издержи и time to market.
VD>Судя по вашим словам, в качество кода у вас низкое. Ваши методы разработки ПО столь чудовищно не эффективны, что вы разводите демагогию на тему неважности кода. Но суть в том, что именно тот факт что ваш код плох и приводит к неэффективности всего процесса.
Я не говорил про неважность кода. Я говорил что остальные аспекты не менее важны. Нельзя утверждать, что код это самая важная часть разработки ПО.
В>>Эм... чую все таки надо определиться, мы говорим о проценте кодирования вообще в производстве продукта или процент времени(трудоемкости, стоимости) кодирования только прграммиста?
VD>Конечно программиста. Процент труда бухгалтера нас вообще не трогает. Язык то бухгалтер не использует.
А тестер? А аналитик? А архитектор? А ПМ? А технический писатель? А тех. саппорт? Они не участвуют в производстве программного продукта?
VD>А если ваша фирма тратит мало времени на разработку и много на разные другие вещи, то просто отдайте разработку профессионалам. Они обойдутся дешевле. А сами сосредоточитесь на том что у вас получается хорошо. Ну, там на продажах, маркетинге, выигрывании тендеров и т.п.
Все наоборот. Если фирма тратит много на кодирование, то что то там не ладно — за последение 10-15 лет эффективность кодирования за счет новых технологий, языков, библиотек и т.д. выросла на порядок, если не больше. А вот эффективность других операций выросла не сильно ( ну за исключением может быть тестирования путем введения ). Так что доля кодирования в производстве программного продукта упала.
Вы наверное просто не участвовали в серьезных внедрениях. Например в случае полугодового проекта фаза кодирования занимает месяца два. А большая часть — сбор и обработка требований, внедрение.
Кстати из того списка активностей, что я привел нет ничего про маркетинг, продажи и выигрование тендеров Только активности разработки ПО.
Здравствуйте, VladD2, Вы писали:
SV.>>На практике смена языка — нереальное решение для grunt'ов.
VD>Словарь мне сказал, что grunt — это "хрюканье", "ворчанье", "мычание", т.е. какие-то животные.
Сразу видно, что ты не играл в Z (там так базовый юнит назывался)
Вот тебе ссылка на правильный словарь. Grunt — это пехотинец.
Здравствуйте, Ведмедь, Вы писали:
В>Нет в мире совершенства. Но свести тестирование только к написанию кода тестов это еще дальше от эффективности. Поговорите с любым грамотным QA инженером на эту тему.
Да говорил. Они так и делают.
В>Именно что UI. И оно автоматизируется. НО не все и трудоемко. А заказчику плевать, что у вас прекрасно работает внутренние функции, если в интерфейсе он видит какую то гадость.
Конечно! Если это так, то у вас тесты плохие. Ну, или это единичный случай которым можно пренебречь.
VD>>О, как? А что же еще такое трудозатратное вы делаете? Разрабатываете архитектуру тестирования? Проводите консилиумы?
В>1. Создание тестовой модели (регресс старого функционала, описание новых требований. как нис транно что бы даже тест закодить надо сначала подумать как можно проверить те или иные требования)
ОТ, ОНО! Эта статья как раз об этом. Читайте ее внимательнее .
В>2. Локализация бага (источник бага живет чаще всего не там где его обнаружили)
Хорошая тема. Но это не тестирование. Это отладка. И она опять таки упрощается, если вы грамотно используете более мощный язык.
Простой пример, если мы пишем парсер, то куда проще отладить грамматику нежели вручную написанный парсер, потому как за деревьями не будет видно леса.
VD>>Я знаю два вида тесто. Один закрепляет реализованный функционал. Другой закрепляет исправленный баг, что по сути вариация первого случая. Что же еще с ними можно делать?
В>А баги настройки? Ведь бывает такое, что код верный, но криво настроен.
Отличная тема! Это к вопросу о автоматическом деплойменте и качестве используемого языка.
Если деплоймент автоматический, а язык не требует подпорок вроде разных Струтсов и прочих IoC-ов, то и проблемы этой не возникнет никогда.
В>Или все, раз код написан и выполняется в тестовой среде, то дальше жизнь заканчивается?
Мы снова вернулись к багам? Или речь снова о ручном развертывании с ошибками?
В>Это очень простое — что бы не было стимула сговариваться
Сговариваться о чем? Им же обоим нужно рабочее ПО сдать.
В>У того, кто пишет тесты и тот кто пишет код задачи разные. Если это будет один и тот же человек, то он всегда сможет с собой договориться.
У них задача одна. Тестер выполняет задания программиста. Скажем, найден баг. Задача тестера создать тест воспроизводящий его и передать эстафету программисту. Иногда даже тестер и баг правит.
В> Нужен высокий уровень самодисциплины и квалификации что бы честно прописать тесты самому себе.
Еже понятно, что новичек и разгильдяй — это плохой выбор. Да и высокий уровень не помешает.
Ну, а раз у кого-то уровень низкий, то пусть не пеняет на то что не в языке дело, а повышает свой уровень.
В>Так мы говорим про эффективность программиста или про эффективность разработки ПО?
Я уже отвечал на этот вопрос. Раз речь идет о ЯП, то мы обсуждаем тех кто ими пользуется. У нас сайт не для менеджеров.
В>Потому как программист это обычно только код. А код, даже с документацией без поддержки и настройки.
Еще раз. Настройки — это очередной момент который должен быть автоматизирован. Если ты вместо отладки или написания нового кода тратишь время на конкурирование софа, то ты тратишь время зря.
В>Вы знаете, что разработчики больших систем практически не боятся кражи исходников?
Нет. Не знаю. И вижу обратные факты. Как и вижу примеры когда кражи исходников не боятся разработчики мелких программ. Это зависит от множеств факторов. В том числе от психологии.
Вы хотите поговорить о психологии?
В> ДАже с документацией? Потому что эти исходники и документация без людей и процесса ни шиша не стоят.
Это зависит. Дай мне исходники системы защиты и ты очень облегчишь мне ее вскрытие.
В>Вы под разработку ПО с кодированием не путаете?
Нет.
В>Написать 1000 строк кода, пусть даже и работающего это не разработка ПО. Нужен код, который делает то что от него требуется.
Ага. Но написание 10 строк в месяц нельзя оправдать ничем. Особенно тем, что в разработке ПО код не главное. В прочем, это по любому чушь.
В>Я не говорил про неважность кода.
Тогда о чем мы спорим? Ты влез в спор между тем, кто утверждал, что язык не важен, так как не важен. Мол они чем-то другим занимается вместо разработки.
В> Я говорил что остальные аспекты не менее важны. Нельзя утверждать, что код это самая важная часть разработки ПО.
Много важного есть в жизни. Я не ставлю это под сомнение. Но в разработке ПО код — это главное. И он не может быть не важен.
Очень часто люди тратят много времени на модели и прочий высокопарный бред (о котором и говорится в статье) только потому, что используемый язык так далек от предметной обрасли, что высказывание одного слова из предметной области на выбранном языке выливается в создание целых иерархий классов.
Эти люди начинают вместо программирования заниматься "дизайном системы", что на практике выливается в чаяпития у белой достки и в рисование развесистых иерархий классов.
Но когда у них спрашивают почему нет результата, и зачем они взяли столь неподходящий язык, то они начинают говорить, что дело не в языке, просто задача очень сложная.
В>А тестер?
А тестер, если он дело делает, а не мышью в монитор тычет, тоже программист.
В> А аналитик?
А он что делает то?
В>А архитектор?
А он? Он код не пишет? А что он пишет? Зачем он нужен то? Модели рисовать? Ну, вот и причина всех неудач. Он ведь тоже программирует, только на другом языке. И это не язык предметной области, но и не язык программирования. Это детская книзка-раскраска. Он просто играет за ваши деньги. И делает он это потому, что выбранный вами язык не может напрямую решать поставленных задач.
В>А ПМ?
ПМ? Он бухгалтер. Его задача проверять кто что сделал и задания раздавать. Но он хотя бы делом занят.
Потом ПМ он один на проект. И он точно не может оцениваться в 90% времени.
В> А технический писатель?
А бухгалтер?
А уборщица?
А вахтер?
В>А тех. саппорт?
А секретарша?
В>Они не участвуют в производстве программного продукта?
Нет. Они выполняют свою работу. Связанную с разработкой, но не разработку.
У нас вопрос был один. Важен выбор языка в разработке ПО или нет. Мне сказали не важен. Я не поверил. Вахтеры и техрайтеры тут ничего не доказывают.
VD>>А если ваша фирма тратит мало времени на разработку и много на разные другие вещи, то просто отдайте разработку профессионалам. Они обойдутся дешевле. А сами сосредоточитесь на том что у вас получается хорошо. Ну, там на продажах, маркетинге, выигрывании тендеров и т.п.
В>Все наоборот. Если фирма тратит много на кодирование, то что то там не ладно
Почему не ладно?
В> — за последение 10-15 лет эффективность кодирования за счет новых технологий, языков, библиотек и т.д. выросла на порядок, если не больше.
Это заблуждение. Эффективность мэйнстрим-программиста поднялась совсем незначительно.
Реально прорывом был переход к языка высокого уровня от ассемблеров.
Кое-что конечно сдвинулось и после, но трудоемкость разработки ПО до сих пор запредельная. Техрайтер может наклепать 10 страниц текстов за день. А программист 10 строк работающего кода.
В> А вот эффективность других операций выросла не сильно ( ну за исключением может быть тестирования путем введения ).
Это каких, позвольте узнать?
В>Так что доля кодирования в производстве программного продукта упала.
Гы-гы. Это эффективность создания ПО упала. Когда ПО делали отдельные индивидуумы, то их КПД было Х, а когда этим занялись большие конторы, то оно стало падать.
В>Вы наверное просто не участвовали в серьезных внедрениях.
Опять не угадал. Участвовал и не раз. И потому я полностью уверен, что это не та работа которую должен выполнять программист.
В>Например в случае полугодового проекта фаза кодирования занимает месяца два. А большая часть — сбор и обработка требований, внедрение.
Хреново работаете. Что еще можно сказать.
Потом на заказных системах клин светом сошелся что ли? В коробке фаза выявления требований вообще отсутствует в чистом виде. Пользователи просят фич и их включают в следующие релизы. А вот на проектирование, написание кода и тестирование уходит основное время.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
I>>У тебя баги бывают ? VD>Бывают. I>>Почему не вижу от тебя призывов заменить VladD2 ? VD>Потому что я себе доверяю. Если есть баг и я знаю о нем, то поправлю.
Или ты знаешь про все свои баги, тогда не ясно, откуда они берутся, или "то лучше их заменить, а не заставлять проверять их работу."
I>>Не бывает идеальных исполнителей. VD>Не бывает. Но это не оправдание чтобы заниматься не своим делом.
Перечень обязанностей у разработчика уже совсем не тот что 10-15 лет назад.
VD>Это по фигу. Больше или меньше тут не применимы. Он не программист и потому говорить о том, сколько он тратит время на программирования не имеет смысла.
Вот я тебе про тоже и говорю — SSE != программист Это ж ты говоришь, что SSE Должен 90% времени сидеть в коде, а щас вот выдал "сколько он тратит время на программирования не имеет смысла.". Вероятно ты собирался написать чтото другое но подсознание взяло верх над тобой
I>>Ну ты в курсе, оптимизация должна быть mature VD>Какая на фиг оптимизация? Я сказал "автоматизация".
Если ты считаешь что автоматизация бизнеса не является оптимизацией, то говорить не о чем. Любой бизнес есть достаточно сложная СМО. Снижение затрат в одной из частей этой СМО (разработка) или увеличение эффективности одной из частей(разработка) может запросто вести к ухудшению выходных показателей.
Повторяю — запросто. Вот здесь двух мнений быть не может, но ты похоже уверен что любую часть СМО можно оптимизировать отдельно от всей СМО И да, разработка слишком часто неявляется узким местом в приведеной СМО.
I>>Конторы ничего не закапывают. Оптимизировать такие расходы нужно в том случае, если они становятся критическим местом.
VD>А если они не критичны, то о них и говорить не стоит. Но раз у вас 90% времени программиста уходит на черт знает что (вроде развертывания софта), то они точно критичны и их нужно автоматизировать.
Я тебя непойму, сам ведь жалуешься на бедность но похоже не понимаешь, что бедность это не причина твоего подхода, а наоборот, результат. Это ж не я смешиваю обязанности, а ты сам Я говорю про то что обязанности SSE уже изменились. Ты же пишешь, что вынужден, что тебе от бедности надо совмещать обязанности да еще предлагаешь одну единственную оптимизацию как локальное сокращение расходов в отрыве от всего процесса Похоже такой взгляд и есть причина той бедности и вынужденного совмещения обязанностей о которой ты же сам и пишешь.
I>>А почему ты решил, что во всех фирмах программист это самый критический участок процесса ? VD>Я так не решал. Но мы говорим о программисте. Так что не надо сюда приплетать черт знает что.
Программист это слишком общий термин. Безопасника, админа тоже можно считать программистами. А вот software enginer уже совсем другие обязанности и одним только программированием не ограничиваются.
SSE, т.е. senior softare enginer или senior softare developer обязательно должны уметь работать с требованиями, уметь формулировать, проверять, руководить девелоперами попроще и много чего другого.
VD>Если в вашей фирме основные трудозатраты — это навешивание лапши на уши клиентов, то это всего лишь значит, что основной деятельностью вашей фирмы не является разработка ПО. Но если у вас есть программист, то его основной задачей, все равно, остается написание кода. А если он делает что-то еще, то он а) не программист; б) априори неэффективен (так как совмещение всегда снижает эффективность).
Давай проверим. Я работаю в фирме которая нумер 1 в своём бизнесе и конкуренты это гиганты вроде AT&T и наш продукт это наш софт. Твой ход Готов выслушать твой рассказ почему грамотная организация разработки не вывела твою фирму в лидеры хотя бы в России.
Здравствуйте, VladD2, Вы писали:
В>>Нет в мире совершенства. Но свести тестирование только к написанию кода тестов это еще дальше от эффективности. Поговорите с любым грамотным QA инженером на эту тему.
VD>Да говорил. Они так и делают.
Значит ты не тех набрал Всегда есть тонны нюансов.С одной тсороны есть большие плюсы, когда тестеры чуть-чуть девелоперы, они могут лазить по коду и выискивать скользкие места. С другой стороны, есть плюсы когда обязанности сильно разделены. Тем не менее свести всё к написанию тестов не получится по той причине что цели пользователя нельзя на 100% покрыть тестами.
В>>Именно что UI. И оно автоматизируется. НО не все и трудоемко. А заказчику плевать, что у вас прекрасно работает внутренние функции, если в интерфейсе он видит какую то гадость.
VD>Конечно! Если это так, то у вас тесты плохие. Ну, или это единичный случай которым можно пренебречь.
Свести особенности человеческой психологии к набору тестов это сильно. Почему ты до сих пор нобелевку не получил ? Ай да ПерельманVladD2.
VD>Простой пример, если мы пишем парсер, то куда проще отладить грамматику нежели вручную написанный парсер, потому как за деревьями не будет видно леса.
Некоторые фирмы делают проще — покупают продукт с исходным кодом, садят студентов подфикшивать мелочевку и периодическо покупают новые версии и тем самым увеличивают прибыль на порядок да еще при сокращении расходов на разработку до минимума.
VD>Если деплоймент автоматический, а язык не требует подпорок вроде разных Струтсов и прочих IoC-ов, то и проблемы этой не возникнет никогда.
Струтсы и ИоКи растут не из языка а из обязанностей-зависимостей. Как только проект разрастается до определенного уровня он гарантировано превращается в монолит и сопротивляется рефакторингу и язык здесь при при чем. Причины находятся в человеческой психике
Пример, который ты сам и привеёл, — компилятор Немерле. Было бы всё так просто, как ты рассказал, не было бы твоих постов про монолит и сложности рефакторинга.
VD>Еще раз. Настройки — это очередной момент который должен быть автоматизирован. Если ты вместо отладки или написания нового кода тратишь время на конкурирование софа, то ты тратишь время зря.
Хочешь сказать, что app.config и web.config ты редактируешь раз в год ? Я в это не поверю Работая с asp.net или wcf туда надо лазить дённо и нощно.
В>>Написать 1000 строк кода, пусть даже и работающего это не разработка ПО. Нужен код, который делает то что от него требуется. VD>Ага. Но написание 10 строк в месяц нельзя оправдать ничем. Особенно тем, что в разработке ПО код не главное. В прочем, это по любому чушь.
Написание кода это не самоцель. Цель она у бизнеса. Потому если девелопер потратил неделю и нашел фреймворк который закрывает проблему и который нужно с нуля писать пару лет, и при этом написал 10 строчек — он сэкономил вагоны веремени денег и полезен бизнесу.
VD>Много важного есть в жизни. Я не ставлю это под сомнение. Но в разработке ПО код — это главное. И он не может быть не важен.
Если код важен, то это не значит, что код важно писать 90% времени см пример выше.
VD>Очень часто люди тратят много времени на модели и прочий высокопарный бред (о котором и говорится в статье) только потому, что используемый язык так далек от предметной обрасли, что высказывание одного слова из предметной области на выбранном языке выливается в создание целых иерархий классов.
Допустим. Вот нужен мне мега-ДСЛ вроде linq но с моей спецификой. Смотрю я твои мессаги и вижу, что даже linq задээсэлить у тебя не выходит, потому что запятые не так используются. Как быть ?
В такой ситуации embedded lang + resharper далеко не факт что уступят ...(ой!) да с отказом от совместимости уже во второй версии
VD>Эти люди начинают вместо программирования заниматься "дизайном системы", что на практике выливается в чаяпития у белой достки и в рисование развесистых иерархий классов.
В сложной системе как правило очень широкое АПИ. И здесь без иерархий классов пока ничего не придумано. Компонентная модель нынче целиком на ООП, вот когда можно будет лямбды да кортежи пользовать в WCF-метододах, тогда твои слова станут актуальными.
VD>Но когда у них спрашивают почему нет результата, и зачем они взяли столь неподходящий язык, то они начинают говорить, что дело не в языке, просто задача очень сложная.
Ты попутал язык и речь Задача сложная == речь не прокачана. Мощный язык это нисколько не компенсирует. Речь осваивают десятками лет а не переходом на новый компилятор.
В>> А аналитик? VD>А он что делает то?
Собирает требования в кучку и контролирует их качество. Примерно так.
В>>А архитектор?
VD>А он? Он код не пишет? А что он пишет? Зачем он нужен то? Модели рисовать? Ну, вот и причина всех неудач. Он ведь тоже программирует, только на другом языке. И это не язык предметной области, но и не язык программирования. Это детская книзка-раскраска. Он просто играет за ваши деньги. И делает он это потому, что выбранный вами язык не может напрямую решать поставленных задач.
Вопросы, какие решает архитектор, это например структура проекта — использовали ли бд и какую и тд. Не совсем ясно, как язык может здесь помочь
В>>А ПМ?
VD>ПМ? Он бухгалтер. Его задача проверять кто что сделал и задания раздавать. Но он хотя бы делом занят.
Его задача это создавать условия, что бы решались конкретные задачи бизнеса А задачи раздавать и контролировать может и кто нибудь другой, например TL или Key Dev.
В>>Все наоборот. Если фирма тратит много на кодирование, то что то там не ладно
VD>Почему не ладно?
Потому что кодирование это исполнение. Принятие решений, проектирование, выбор направления, учет рисков, долгосрочные, среднесрочные, краткосрочные цели, приоритеты, накопление экспы — это требует вагоны времени.
Т.е. если фирма в основном кодит, то скорее всего движется непойми куда, а выхлопа от топ-менеджмента и маркетинга нет вовсе. Ты в курсе, что маркетинг это множитель ? 90% времени на маркетинг, это значит, грубо говоря, что эффект 1 программиста увеличивается в 9 раз.
VD>Это заблуждение. Эффективность мэйнстрим-программиста поднялась совсем незначительно.
Когда менеджед не было, мейнстрим был нативным и мейнстрим-программисты тратили дни, недели и даже месяцы на поиски бага с указателями. Сейчас они просто пишут код, который при наличии новых иснтрументов можно быстро и надёжно пофиксить.
VD>Реально прорывом был переход к языка высокого уровня от ассемблеров.
Менеджед и сопутствующие инструменты это
VD>Кое-что конечно сдвинулось и после, но трудоемкость разработки ПО до сих пор запредельная. Техрайтер может наклепать 10 страниц текстов за день. А программист 10 строк работающего кода.
Программист может не написать ни одной строчки и при этом сэкономить техрайтеру пару сотен страниц, а бригаде тестеров месяц тестирования, своим коллегам — недели багфикса и все потому, что вовремя посмотрит видеопрезентации новинок.
В>>Например в случае полугодового проекта фаза кодирования занимает месяца два. А большая часть — сбор и обработка требований, внедрение.
VD>Хреново работаете. Что еще можно сказать.
Две трети на сбор требований и внедрение это очень хорошо вообще говоря Или ты предлагаешь как в студенческих проектах -два дня высасывать идею, полгода долбить и за один день выбросить ?
VD>Потом на заказных системах клин светом сошелся что ли? В коробке фаза выявления требований вообще отсутствует в чистом виде.
Мягко говоря это не так. Обычно этой фазой занимаются люди настолько выше программистов, что программисты даже не в курсе, что проект который они начали писать сегодня, реально начался два года назад.
>Пользователи просят фич и их включают в следующие релизы. А вот на проектирование, написание кода и тестирование уходит основное время.
Это называется реакционный подход, по принципу китайского ширпотреба — была бы дырка товар а жених покупатель найдется.
Здравствуйте, hardcase, Вы писали:
H>Сразу видно, что ты не играл в Z (там так базовый юнит назывался) H>Вот тебе ссылка на правильный словарь. Grunt — это пехотинец.
А зачем мне играть в малоизвестную игрушку?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Сори времени на обсуждение полезности траты рабочего времени нет. Работать надо.
Отвечу только вот на это:
I>Хочешь сказать, что app.config и web.config ты редактируешь раз в год ? Я в это не поверю Работая с asp.net или wcf туда надо лазить дённо и нощно.
Так не используйте эти asp.net или wcf, если они вам работать мешают. "wcf" — это банальный овердизайн. Для организации RPC в Интернете достаточно REST-а. Наклепать для него фрэймворк или макру труда не составляет (или даже готовый взять). Так зачем грызть этот кактус?
Зачем править app.config и web.config я тоже не представляю. Нужная конфигурация должна лежать в репозитории. Если что-то нужно настраивать под конкретную машину, то нужно писать скрипты автоматизирующие эти настройки.
Но ручного труда быть не должно. Руками мы должны писать код.
Неужели такая простая мысль может вызвать непонимание?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>Я так не решал. Но мы говорим о программисте. Так что не надо сюда приплетать черт знает что. VD>Если в вашей фирме основные трудозатраты — это навешивание лапши на уши клиентов, то это всего лишь значит, что основной деятельностью вашей фирмы не является разработка ПО. Но если у вас есть программист, то его основной задачей, все равно, остается написание кода. А если он делает что-то еще, то он а) не программист;
VD>б) априори неэффективен (так как совмещение всегда снижает эффективность).
вот скажи, текст ты сам набираешь или машинистку заставляешь?
это я к тому что утверждение "совмещение всегда снижает эффективность" н верно так как разделение труда тянет за собой взаимодействие, которое может стать узким местом.
Здравствуйте, VladD2, Вы писали:
I>>Хочешь сказать, что app.config и web.config ты редактируешь раз в год ? Я в это не поверю Работая с asp.net или wcf туда надо лазить дённо и нощно.
VD>Так не используйте эти asp.net или wcf, если они вам работать мешают. "wcf" — это банальный овердизайн. Для организации RPC в Интернете достаточно REST-а.
Недостаточно, _особенно_ в Интернет. Как немерле может заставить чужие сервисы поддерживать REST ?
Вот есть прилага которая работает с десятком источников, часть из них олдскульный http, часть из них REST, часть на Soap, часть вообще не пойми на чем.
Как решить это с помощью REST ?
>Наклепать для него фрэймворк или макру труда не составляет (или даже готовый взять). Так зачем грызть этот кактус?
Придется выписывать весь стек технологий. Может еще и поисковик вроде гугла написать самому ?
VD>Зачем править app.config и web.config я тоже не представляю. Нужная конфигурация должна лежать в репозитории. Если что-то нужно настраивать под конкретную машину, то нужно писать скрипты автоматизирующие эти настройки.
.net так устроен. прикручиваешь логгер, надо править конфиг, прикручиваешь бд — надо править конфиг. Лезешь в инет — все в конфиге. К тебе лезут из инета — опять конфиг. Куда ни ткни вылазит этот конфиг.
VD>Но ручного труда быть не должно. Руками мы должны писать код. VD>Неужели такая простая мысль может вызвать непонимание?
Ты ни много ни мало предложил выписывать велосипеды для всего на свете.
Здравствуйте, Ikemefula, Вы писали:
I>Недостаточно, _особенно_ в Интернет. Как немерле может заставить чужие сервисы поддерживать REST ? I>Вот есть прилага которая работает с десятком источников, часть из них олдскульный http, часть из них REST, часть на Soap, часть вообще не пойми на чем. I>Как решить это с помощью REST ?
Сделай переходник. Но не трахаться с WCF сделав его основной интерфейсной библиотекой.
Да и что это за чудные сервисы? Где вы их берете? Весь цивилизованный мир в последнее время клепает сервисы в REST-стиле. Публичные сервисы в формате Soap делают только люди с полным майрософтом головного мозга.
>>Наклепать для него фрэймворк или макру труда не составляет (или даже готовый взять). Так зачем грызть этот кактус?
I>Придется выписывать весь стек технологий. Может еще и поисковик вроде гугла написать самому ?
У гугла используется Soap? О, как! А мужики из гугля и не знали!
Вот, все что я смог найти по запросу "Soap google".
Так что google — это отличный аргумент! Ты еще Яндекс в пример приведи .
WCF и Soap — overdesign. Они не для жизни сделаны, а для галочки. А разные дуболомы используют их, чем портят жизнь себе и окружающим.
VD>>Зачем править app.config и web.config я тоже не представляю. Нужная конфигурация должна лежать в репозитории. Если что-то нужно настраивать под конкретную машину, то нужно писать скрипты автоматизирующие эти настройки.
I>.net так устроен.
Да, ну? Это гловы у людей так устроены. Они вместо того чтобы один раз подумать и сделать как следует, предпочитают не думая каждый раз повторять одни и те же трудоемкие операции.
I>прикручиваешь логгер,
А у меня вот, с логером проблем нет.
I>надо править конфиг,
Не забывай добавлять — "тебе надо".
I>прикручиваешь бд — надо править конфиг.
Что за прикручиваешь? В прочем, кури вот это.
I>Лезешь в инет — все в конфиге.
Ну, дык. Можно проще сказать. Используешь каменный молоток — программируешь в ХМЛ-е.
I>К тебе лезут из инета — опять конфиг. Куда ни ткни вылазит этот конфиг.
Ну, вот вы и занимаетесь этим всем вместо разработки. А потом убеждаете всех окружающих, что код — это не главное, так как вы тратите основное свое время не разную фигню.
VD>>Но ручного труда быть не должно. Руками мы должны писать код. VD>>Неужели такая простая мысль может вызвать непонимание?
I>Ты ни много ни мало предложил выписывать велосипеды для всего на свете.
Лучше уж велосипеды, чем используемые тобой самокаты.
К тому же, эти велосипеды пишутся, в основном, поверх ваших же самокатов.
Вот, если бы, те кто борется с этими самокатами, вместо этого взяли более подходящие инструменты и реализовали бы нужные им велосипеды, то глядишь сейчас бы не пришлось вести разговоры о 90% времени затрачиваемого неизвестно на что.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Сделай переходник. Но не трахаться с WCF сделав его основной интерфейсной библиотекой.
Никто и не трахается. ВЦФ это уже практически стандарт.
VD>Да и что это за чудные сервисы? Где вы их берете? Весь цивилизованный мир в последнее время клепает сервисы в REST-стиле. Публичные сервисы в формате Soap делают только люди с полным майрософтом головного мозга.
Ну иди да авторитетно объясни, а то до сих пор люди до хрипа спорят что лучше, соап и рест
I>>Придется выписывать весь стек технологий. Может еще и поисковик вроде гугла написать самому ?
VD>У гугла используется Soap? О, как! А мужики из гугля и не знали!
Очень смешно, сказано было про стек технологий, а ты там соап углядел
VD>WCF и Soap — overdesign. Они не для жизни сделаны, а для галочки. А разные дуболомы используют их, чем портят жизнь себе и окружающим.
Это уже практически стандарт.
VD>Да, ну? Это гловы у людей так устроены. Они вместо того чтобы один раз подумать и сделать как следует, предпочитают не думая каждый раз повторять одни и те же трудоемкие операции.
Это лучше, чем каждому выписывать стек технологий как ты предложил. ВЦФ дает возможность легко и просто связать например ЕФ и Сервелат. Сколько тебе нужно времени что бы на своем велосипеде добиться такого же эффекта ?
I>>надо править конфиг, VD>Не забывай добавлять — "тебе надо".
Расскажи как без конфига сделать так, что бы можно было настраивать логирование после запуска приложения
I>>прикручиваешь бд — надо править конфиг.
VD>Что за прикручиваешь? В прочем, кури вот это.
Это просто поделка. До ЕФ ей как до небес.
VD>Ну, дык. Можно проще сказать. Используешь каменный молоток — программируешь в ХМЛ-е.
Как без конфига сменить прокси после запуска приложения в котором нет УИ ?
I>>К тебе лезут из инета — опять конфиг. Куда ни ткни вылазит этот конфиг.
VD>Ну, вот вы и занимаетесь этим всем вместо разработки. А потом убеждаете всех окружающих, что код — это не главное, так как вы тратите основное свое время не разную фигню.
Твои велосипеды требуют на порядок больше времени.
I>>Ты ни много ни мало предложил выписывать велосипеды для всего на свете. VD>Лучше уж велосипеды, чем используемые тобой самокаты.
Я люблю использовать готовое, которое работает, протестировано и развивается, а не ломает совместимость уже ко второй версии.
VD>Вот, если бы, те кто борется с этими самокатами, вместо этого взяли более подходящие инструменты и реализовали бы нужные им велосипеды, то глядишь сейчас бы не пришлось вести разговоры о 90% времени затрачиваемого неизвестно на что.
Ну да, 90% времени писали бы велосипеды и под это дело закладывали бы в 10 раз больший бюджент
Здравствуйте, cvetkov, Вы писали:
C>Здравствуйте, VladD2, Вы писали:
VD>>Я так не решал. Но мы говорим о программисте. Так что не надо сюда приплетать черт знает что. VD>>Если в вашей фирме основные трудозатраты — это навешивание лапши на уши клиентов, то это всего лишь значит, что основной деятельностью вашей фирмы не является разработка ПО. Но если у вас есть программист, то его основной задачей, все равно, остается написание кода. А если он делает что-то еще, то он а) не программист;
VD>>б) априори неэффективен (так как совмещение всегда снижает эффективность). C>вот скажи, текст ты сам набираешь или машинистку заставляешь?
Я когда был лид программистом, писал только интерфейсы и узкие места, другую часть (95% кода) писали "машинистки"
C>это я к тому что утверждение "совмещение всегда снижает эффективность" н верно так как разделение труда тянет за собой взаимодействие, которое может стать узким местом.
+100500, это кстати во многих бюрократических компаний убивает весь творческий процесс.
Но мне кажется по совмещению тут имеется немного другое, помнится мне выражение — что программист подобен жонглеру. Переключение на другой род занятий ведет к "пересетапу переменных окружений" а это накладные расходы.
Но заметь это только временый период — разделить. То что некоторые люди будут делать 2-3 смежных действия это одно, главное тут в том что ты будешь видеть кубики для оптимизации всего процесса.
Я например пришел в компанию где один вид работы занимал 2-3 дня, сейчас спустя пол-года этот процесс занимает 2-3 минуты, и что вы думаете кричат что так долго.
Но даже не в этом успех, а в том что я отделил работу программиста — скриптовщика — дизайнера — художника, они могут делать свою работу, не зная даже о программистах.
З.Ы. Эта технология сейчас была проверена на западной компании — стока радости я не слышал от их дизайнеров и художников, одним словом — "Awesome!!!"
Поэтому теперь как только я вижу — комуникацию людей, работа не по должности, и тд, у меня начинается алергия
Здравствуйте, enji, Вы писали:
E>нуб — всего-навсего "новичек", негативного окраса вроде бы нет. Или я не прав?
"newbie" еще можно охарактеризовать как указание на новичка без негативного окраса, но "n00b" — это уже негативная окраска. Не то, что бы какое-то оскорбление, но тем не менее.
Здравствуйте, IROV.., Вы писали:
C>>вот скажи, текст ты сам набираешь или машинистку заставляешь? IRO>Я когда был лид программистом, писал только интерфейсы и узкие места, другую часть (95% кода) писали "машинистки"
понятно. не хочеш разговора по существу так и скажи
Здравствуйте, cvetkov, Вы писали:
C>Здравствуйте, IROV.., Вы писали:
C>>>вот скажи, текст ты сам набираешь или машинистку заставляешь? IRO>>Я когда был лид программистом, писал только интерфейсы и узкие места, другую часть (95% кода) писали "машинистки" C>понятно. не хочеш разговора по существу так и скажи
Вроде бы я ответил — заставляю машинистку, или мы так, по троллить?
Здравствуйте, IROV.., Вы писали:
C>>>>вот скажи, текст ты сам набираешь или машинистку заставляешь? IRO>>>Я когда был лид программистом, писал только интерфейсы и узкие места, другую часть (95% кода) писали "машинистки" C>>понятно. не хочеш разговора по существу так и скажи IRO>Вроде бы я ответил — заставляю машинистку, или мы так, по троллить?
ну и кто тут после этого ответа тролит?
Здравствуйте, cvetkov, Вы писали:
C>Здравствуйте, IROV.., Вы писали:
C>>>>>вот скажи, текст ты сам набираешь или машинистку заставляешь? IRO>>>>Я когда был лид программистом, писал только интерфейсы и узкие места, другую часть (95% кода) писали "машинистки" C>>>понятно. не хочеш разговора по существу так и скажи IRO>>Вроде бы я ответил — заставляю машинистку, или мы так, по троллить? C>ну и кто тут после этого ответа тролит? как же задолбали эти тролли, все лучшего! пока!
Здравствуйте, AndrewVK, Вы писали:
VD>>Сделай переходник. Но не трахаться с WCF сделав его основной интерфейсной библиотекой.
AVK>WCF прекрасно подходит и для RESTful сервисов.
Ну, тебе виднее. Только не очень ясно на фиг он REST-а нужен? Плюс почему сразу full? Жить надо по обстоятельствам .
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
A>>Автор за стопицот лет так и остался нубом, только комментарии перестал писать
VD>И еще он не понял, того что в большинстве случаев просто нельзя написать код настолько близким к описанию проблемы, чтобы избавиться от комментарией. Точнее может и можно, но для этого язык должен позволят вводить другой язык — язык предметной области (DSL).
Но самое главное, что не понял афтор, это то, что программы пишутся не для компьютеров, а для людей, которые потом будут разбираться в том, что он понаписал. И что среди читаетелей его творения будет народ и с опытом < 20 лет. Вот для них и пишутся коментарии, и оставляются пропуски между чем то связанными кусками программы.
Здравствуйте, Brutalix, Вы писали:
B>Здравствуйте, VladD2, Вы писали:
A>>>Автор за стопицот лет так и остался нубом, только комментарии перестал писать
VD>>И еще он не понял, того что в большинстве случаев просто нельзя написать код настолько близким к описанию проблемы, чтобы избавиться от комментарией. Точнее может и можно, но для этого язык должен позволят вводить другой язык — язык предметной области (DSL).
B>Но самое главное, что не понял афтор, это то, что программы пишутся не для компьютеров, а для людей, которые потом будут разбираться в том, что он понаписал. И что среди читаетелей его творения будет народ и с опытом < 20 лет. Вот для них и пишутся коментарии, и оставляются пропуски между чем то связанными кусками программы.
Эх. Не могу не влезть с банальностью — программы пишутся для людей, который потом будут их пользовать. А все остальное это средства, в том числе и возможность нормально разобраться потом другим прграммистам. И есть код, для которого нет явной эконовической выгоды поддерживать — например прототипы, когда надо просто проверить то или иное решение. Или когда код пишется для разового действия (разовая миграция данных, к примеру).
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Ikemefula, Вы писали:
I>>Никто и не трахается. ВЦФ это уже практически стандарт.
VD>У МС таких стандартов выше крыши. И ежики, из тех кто боится думать своей головой, колются и режутся грызя эти кактусы.
Можешь и не грызть, если ты сидишь в небольшой конторке завязаной не автоматизацию узкоспециализированого бизнеса.
VD>На самом деле нужно понимать, что МС очень выгодно привязывать пользователей своими "чуть другими" технологиями. Но зачем это пользователям?
С позиции человека в "небольшой конторке завязаной не автоматизацию узкоспециализированого бизнеса" это незачем. А реально soap тот же заметить просто нечем, потому что на нём держится кучка сервисов. Хочешь предлагать решение — пиши сервисы сам (и потрать десяток лет) или пользуйся готовым.
Кому нужен изобретатель уникального стека технологий вроде WCF ? Такие технологии это как раз то, где пользователю нужна унификация — это удешевляет продукты и снижает риски.
Пользователям не нужно десять разных технологий для создания сайтов, потмоу что рынок труда фрагментируется и решения получаются низкокачественными и дорогими, например что бы купить книгу в электромагазине надо по пол-часа кликать и то результат не гарантирован, например потому что великий разработчик решил с нуля написать биллинговую систему.
Вот десять технологий для моделирования скажем зубного протеза очень даже надо, потому что позволяет создать более эффективные решения.
Здравствуйте, VladD2, Вы писали:
VD>Ну, тебе виднее. Только не очень ясно на фиг он REST-а нужен?
1) Если контракты сложные (много операций, сложная структура входных и выходных данных) — WCF заметно уменьшает количество boilerplate кода.
2) Базовый уровень WCF долго и упорно вылизывали на предмет надежности, масштабируемости и поведения под большой нагрузкой. Если вдруг такое понадобится на собственном велосипеде — будет потрачено лишнее время и ресурсы
3) Большая часть сервисов WCF никак на SOAP не завязана — шифрование, различные методы аутентификации, поддержка авторизации, инстанцирование, сессии, модель расширения и т.п. Соответственно в WCF ты получишь для них готовую и качественную реализацию.
Ну а REST сам по себе — всего лишь еще один вариант оформления адресов и сообщений в удаленном взаимодействии, так что он прекрасно укладывается в архитектуру.
Впрочем, если сервис простой, либо нужна работа под Моно, вполне возможно что лучше его будет реализовать на ASP.NET MVC. Крайний раз лично я так и поступил.
VD> Плюс почему сразу full?
Не full, а ful. Термин такой, RESTful.
Conforming to the REST constraints is referred to as being "RESTful".
... << RSDN@Home 1.2.0 alpha 5 rev. 1537 on Windows 7 6.1.7601.65536>>
Здравствуйте, Ikemefula, Вы писали:
I>Можешь и не грызть, если ты сидишь в небольшой конторке завязаной не автоматизацию узкоспециализированого бизнеса.
О, как?! Гордо, так с пафасом!
А ничё, что Гугль и IBM без WCF обходятся?
VD>>На самом деле нужно понимать, что МС очень выгодно привязывать пользователей своими "чуть другими" технологиями. Но зачем это пользователям?
I>С позиции человека в "небольшой конторке
Ну, эту песню ты своим клиентам пой, а не мне. Я человек технический. С позиции технаря WCF — это овердизайн с непонятным назначением. А ты просто перечитал прессрелизов от МС. Вот и все.
I>завязаной не автоматизацию узкоспециализированого бизнеса" это незачем. А реально soap тот же заметить просто нечем, потому что на нём держится кучка сервисов.
Ага обеспечивающух инфраструктуру SOAP. В реальности же SOAP — это такой RPC (вызов процедур по сетке), но с огромным количеством пресс-релизов и бушита.
I> Хочешь предлагать решение — пиши сервисы сам (и потрать десяток лет) или пользуйся готовым.
Гугль, Яндекс и куча контор по меньше предлагают сетевые сервисы в формате REST (или по его мотивам). И только ты не замечаешь тенденции.
Я могу даже поработать настрадамусом и предсказать чем вся эта история с WCF-ом кончится. Через несколько лет в МС возобладает здравый смысл и они сами доработают свой WCF (или создадут новые библиотеки) для того чтобы было удобно работать с REST-ом. А ты, или сделаешь вид, что ничего не произошло, или перейдешь в стан обиженных.
I>Кому нужен изобретатель уникального стека технологий вроде WCF ?
Да, никому не нужно. Потому я и говорю, что WCF — это глупость несусветная. Боксу дали показать какой из него отличный дизайнер выйдет и он сделал это. Ну, а то что сама технология является тупиковой — это никому интересно не было.
Весь мир уже несколько лет юзает REST — очень простой и интуитивно понятный стандарт.
I>Такие технологии это как раз то, где пользователю нужна унификация — это удешевляет продукты и снижает риски.
Унифицировать нужно протокол. И чем он проще, тем лучше. WCF, бай дефолт, юзает тупиковый SOAP. Весь мир же предпочел понятный человеку REST. Сколько еще нужно доносить эту простую мысль?
I>Пользователям не нужно десять разных технологий для создания сайтов,
Я тебе по сикрету скажу, что для создания сайтов, во всем мире, дотнет используется довольно редко. ПХП или Жаба используются куда чаще. И там просто нет ответной части от WCF. Так что вы со своими сервисами живете в каком-то отдельном мире. Вы их делаете сами для себя. Они никому больше не нужны.
I>потмоу что рынок труда фрагментируется и решения получаются низкокачественными и дорогими,
С WCF, то? Ну, а как же по другому? Согласен!...
I>например что бы купить книгу в электромагазине надо по пол-часа кликать и то результат не гарантирован,
Да ладно? Как нельзя к стати, сегодня заказывал в http://www.ozon.ru книги. И как-то нормально все у них. Наверно WCF используют .
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Унифицировать нужно протокол. И чем он проще, тем лучше. WCF, бай дефолт, юзает тупиковый SOAP.
Нет у WCF никакого бай дефолт. Биндинг указывать надо обязательно, даже в самом минимальном варианте. И SOAP используется далеко не во всех стандартных биндингах.
... << RSDN@Home 1.2.0 alpha 5 rev. 1537 on Windows 7 6.1.7601.65536>>
Здравствуйте, VladD2, Вы писали:
VD>Гугль, Яндекс и куча контор по меньше предлагают сетевые сервисы в формате REST (или по его мотивам). И только ты не замечаешь тенденции.
VD>Я могу даже поработать настрадамусом и предсказать чем вся эта история с WCF-ом кончится. Через несколько лет в МС возобладает здравый смысл и они сами доработают свой WCF (или создадут новые библиотеки) для того чтобы было удобно работать с REST-ом. А ты, или сделаешь вид, что ничего не произошло, или перейдешь в стан обиженных.
Ты не поверишь, уже создали. В рамках все того же WCF.
Здравствуйте, VladD2, Вы писали:
I>>Можешь и не грызть, если ты сидишь в небольшой конторке завязаной не автоматизацию узкоспециализированого бизнеса.
VD>О, как?! Гордо, так с пафасом! VD>А ничё, что Гугль и IBM без WCF обходятся?
У них джава и С++ это основные направления.
I>>С позиции человека в "небольшой конторке
VD>Ну, эту песню ты своим клиентам пой, а не мне. Я человек технический. С позиции технаря WCF — это овердизайн с непонятным назначением. А ты просто перечитал прессрелизов от МС. Вот и все.
Я вообще по WCF ничего не читал, посмотрел примеры и всё само заработало. Где тут овердизайн, не совсем понятно.
I>>завязаной не автоматизацию узкоспециализированого бизнеса" это незачем. А реально soap тот же заметить просто нечем, потому что на нём держится кучка сервисов. VD>Ага обеспечивающух инфраструктуру SOAP. В реальности же SOAP — это такой RPC (вызов процедур по сетке), но с огромным количеством пресс-релизов и бушита.
Кучка сервисов которые я упомянул, это бизнес-сервисы. Они просто используют Soap, вот и всё. Нужно объяснять, чем отличается бизнес-сервис от сервиса, котоырй обеспечивает инфраструктуру Soap ?
I>> Хочешь предлагать решение — пиши сервисы сам (и потрать десяток лет) или пользуйся готовым. VD>Гугль, Яндекс и куча контор по меньше предлагают сетевые сервисы в формате REST (или по его мотивам). И только ты не замечаешь тенденции.
Пусть предлагают, это недостаточно что бы soap отсох.
VD>Я могу даже поработать настрадамусом и предсказать чем вся эта история с WCF-ом кончится. Через несколько лет в МС возобладает здравый смысл и они сами доработают свой WCF (или создадут новые библиотеки) для того чтобы было удобно работать с REST-ом. А ты, или сделаешь вид, что ничего не произошло, или перейдешь в стан обиженных.
У меня ощущение, что ты никак не можешь понять, что soap держится не на микрософте, гугле или яндекес. soap держится на тех бизнес-сервисах которые его до сих пор используют. От меня ровно ничего не зависит, я пока еще не Ceo корпорации-гиганта с размером примерно с ibm
Так вот до тех пор, пока не появится конкурент с аналогичным сервисом, но построеным на rest, до тех пор soap будет жить.
VD>Весь мир уже несколько лет юзает REST — очень простой и интуитивно понятный стандарт.
В том то и дело, что не весь. REST даже не доминирует.
I>>Такие технологии это как раз то, где пользователю нужна унификация — это удешевляет продукты и снижает риски. VD>Унифицировать нужно протокол. И чем он проще, тем лучше. WCF, бай дефолт, юзает тупиковый SOAP. Весь мир же предпочел понятный человеку REST. Сколько еще нужно доносить эту простую мысль?
Не весь мир. Ты мягко говоря передёргиваешь.
I>>Пользователям не нужно десять разных технологий для создания сайтов,
VD>Я тебе по сикрету скажу, что для создания сайтов, во всем мире, дотнет используется довольно редко. ПХП или Жаба используются куда чаще.
Разница то какая, всё равно нужна одна технология, а не зоопарк.
>И там просто нет ответной части от WCF. Так что вы со своими сервисами живете в каком-то отдельном мире. Вы их делаете сами для себя. Они никому больше не нужны.
Ты никак не можешь понять простую вещь, что soap не мой и даже не наш.
I>>потмоу что рынок труда фрагментируется и решения получаются низкокачественными и дорогими, VD>С WCF, то? Ну, а как же по другому? Согласен!...
Нет. Технологий вроде WCF вагон и маленькая тележка, вот это и есть фрагментация. Напишешь ты на своём Немерле еще один стек — это только увеличит фрагментацию.
I>>например что бы купить книгу в электромагазине надо по пол-часа кликать и то результат не гарантирован,
VD>Да ладно? Как нельзя к стати, сегодня заказывал в http://www.ozon.ru книги. И как-то нормально все у них. Наверно WCF используют .
Считаешь, что если баг не воспроизвёлся, то его и нет ? Это новость
Здравствуйте, AndrewVK, Вы писали:
AVK>Нет у WCF никакого бай дефолт. Биндинг указывать надо обязательно, даже в самом минимальном варианте. И SOAP используется далеко не во всех стандартных биндингах.
А зачем нужны все эти настройки, биндинги, конфиги интерфейсы, контракты и прочая мура, если все что тебе нужно — это выстовить на некоторой юрле динамически генерируемый хмл или джейсон? Другими словами в чем соль?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
L>>Ты не поверишь, уже создали. В рамках все того же WCF.
VD>Вау! (с) Я даже не успеваю поработать предсказателем, как все сбывается! Осталось только понять зачем нужен весь этот болерплэйт.
Здравствуйте, Ikemefula, Вы писали:
VD>>А ничё, что Гугль и IBM без WCF обходятся?
I>У них джава и С++ это основные направления.
Ну, и? А я о чем? Никому не нужен WCF. Всех интересует интерфейс. SOAP — это тупик. А для REST WCF
является овердизайном. И уж точно WCF не оерделяет никакие такие стандарты ради которых нужно было бы привязываться к WCF.
I>Я вообще по WCF ничего не читал, посмотрел примеры и всё само заработало. Где тут овердизайн, не совсем понятно.
С тем же успехом ты мог посмотреть примеры по HttpHandler и у тебя все точно так же заработало бы. Но ты мне рассказываешь про какие-то там корпоративные стандарты.
В прочем, я уже окончательно потерял нить обсуждения, забыл причем тут портрет, и причем тут ньюб. Так что, видимо, надо закругляться.
I>Кучка сервисов которые я упомянул, это бизнес-сервисы. Они просто используют Soap, вот и всё. Нужно объяснять, чем отличается бизнес-сервис от сервиса, котоырй обеспечивает инфраструктуру Soap ?
Нужно объяснять зачем они используют Soap. И за одно не плохо было бы показать эту кучу жизненно необходимых сервисов. А то я вот, все время, встречаю сервисы в ала REST формате. Может ты говоришь не о сервисах, а о каких-то там готовых библиотеках с интерфейсом на SOAP или WCF?
I>Пусть предлагают, это недостаточно что бы soap отсох.
Это тенденция. Осмысленная и логичная. Избыточный и сложный формат вытесняется простым и достаточным. Всегда бы так.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>А зачем нужны все эти настройки, биндинги, конфиги интерфейсы, контракты и прочая мура, если все что тебе нужно — это выстовить на некоторой юрле динамически генерируемый хмл или джейсон? Другими словами в чем соль?
Соль в том, что код уже написан и работает. Представь на секунду, что программисты не пишут каждый свою версию MS Office а используют уже готовый через automation API. C WCF ровно тоже самое.
Есть сервисы которые нужно заюзать, не я их пишу, но они есть — какая контора их предоставляет, приложение, разработчики — это всё дело десятое. Пока они будут пользовать soap(и все что угодно), этот soap(и все что угодно) будет востребован.
Здравствуйте, VladD2, Вы писали:
I>>У них джава и С++ это основные направления.
VD>Ну, и? А я о чем? Никому не нужен WCF. Всех интересует интерфейс.
Это передёргивание.
VD>И уж точно WCF не оерделяет никакие такие стандарты ради которых нужно было бы привязываться к WCF.
Стандартом на платформе .Net является сам WCF. Хочешь — пиши свой собственный стек, главное не удивляйся что он никому не нужен.
I>>Я вообще по WCF ничего не читал, посмотрел примеры и всё само заработало. Где тут овердизайн, не совсем понятно.
VD>Нужно объяснять зачем они используют Soap. И за одно не плохо было бы показать эту кучу жизненно необходимых сервисов. А то я вот, все время, встречаю сервисы в ала REST формате. Может ты говоришь не о сервисах, а о каких-то там готовых библиотеках с интерфейсом на SOAP или WCF?
Я говорю о бизнес-сервисах. Т.е. сервисах за которые люди платят деньги. Например таким сервисом является специализировный поисковик, которй в своей области рвёт гуглы, бинги, яхи вместе взятые просто в хлам. Соответсвенно разивается на деньги людей которым нужна эта самая специализация. Контора-разработчик один из гигантов, на первых строчках. Soap это уже свершившийся факт, его использует целая кучка толстых и тонких клиентов всякого рода. Переписывать на другой протокол это значит надо переписыватьвообще всю инфрастурктуру. Ты хорошо понимаешь, чего хочешь ?
I>>Пусть предлагают, это недостаточно что бы soap отсох. VD>Это тенденция. Осмысленная и логичная. Избыточный и сложный формат вытесняется простым и достаточным. Всегда бы так.
Тенденция это унификация взаимодействия, а несущий протокол вообще не должен маячить. Что интересно, WCF c этой задачей справляется, а REST, который модный до безобразия, чем поможет в данном вопросе?
Здравствуйте, VladD2, Вы писали:
VD>А зачем нужны все эти настройки, биндинги, конфиги интерфейсы, контракты и прочая мура, если все что тебе нужно — это выстовить на некоторой юрле динамически генерируемый хмл или джейсон? Другими словами в чем соль?
Затем, что иногда этих урлов много и на вход тоже довольно сложная по структуре информация приходит. А вокруг еще какая нибудь аутентификация похитрее. Можно, конечно, все это руками реализовать, но с использованием WCF будет существенно проще.
... << RSDN@Home 1.2.0 alpha 5 rev. 1537 on Windows 7 6.1.7601.65536>>
Здравствуйте, VladD2, Вы писали:
VD>Ну, и? А я о чем? Никому не нужен WCF. Всех интересует интерфейс. SOAP — это тупик. А для REST WCF VD>является овердизайном. И уж точно WCF не оерделяет никакие такие стандарты ради которых нужно было бы привязываться к WCF.
Можешь рассказать, как по-простому сделать колбэки и стриминг? А то может действительно мы что-то упускаем.
Никому не нужен WCF. Нужен SOAP иди REST. А — это всего лишь библиотека упрощающая их реализацию. И если в случае SOAP в WCF есть смысл, то в случае REST в WCF смысла нет. REST реализуется на коленке за два дня программстом среднего уровня.
Я с RESTful не знаком. Они там реализовали поддержку REST-а, или навернули слой совместимости со своими контрактами и прочим овердизайном?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Sinix, Вы писали:
S>Что самое неприятное, все утверждения поданы в бескомпромиссном гуру-стиле и возразить получается только "отучаемся говорить за всех". Я специально прочитал текст дважды и не нашёл ни одного более-менее внятного тезиса, только "все вокруг — нубы, а я — д'Артатьян!". Что тут обсуждать —
Про "плотность кода", тем не менее, замечание в тему. Пробелами и кучей комментов действительно стоит отделять некие "этапы" алгоритмов. А читаешь код новичков, и такое ощущение, что каждая строка уже "этап".
Про динамику — тоже доля истины есть. Но вывод там должен быть не в плане динамики (сам автор не понял, что именно он понял), а в некоей неразборчивости в ср-вах у профессионала и индиферентности к т.н. "подходам". Т.е. после понимания, что все эти ср-ва и "подходы" сами по себе не так важны, а лишь интересны как инструменты для достижения цели... и тогда много других инструментов оказываются вполне подходящими. В т.ч. динамические языки для большого класса задач. А у новичков зачастую исходные цели обильно приправляются сугубо собственными, напр: поюзать такую-то билиотеку/паттерн/язык, попробовать "на вкус" то-то и то-то.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Ведмедь, Вы писали:
В>>Если сюда добавить анализ требований, тестирование и внедрение, то от написания кода и останется 10-20 процентов времени.
VD>О, как? А написание тестов — это не написание кода?
Тесты разные бывают. В более-менее высокоуровневых тестах гвоздем программы выступает сам тестовый сценарий. И он зачастую требует всяких данных и предварительной инициализации заведомо больше, чем основное тело тестирующего кода (которое может вообще быть пару строк).
VD>Сбор же требований и внедренеие — это не задачи программиста. Если у вас эти задачи решает программист, то вы заведомо используете его время не эффективно.
Слишком грубое разделение труда. Никто до последней молекулы программисту требования не разжевывает. Программисты, требующие такого разжевывания, никому не нужны. Программисту ставят задачу, например, заставить работать совместно А и B, и он уже сам уточняет требования, разбирается в протоколах и т.д. Никто за него это делать не будет. А в итоге, трудоемкость этой части анализа может заметно превысить собственно кодирование и тестирование.
Мой пример тоже далеко не общий, но твое заблуждение очень даже обще. Программист редко (почти никогда) имеет дело со спецификациями, достаточными для "тупого" кодирования. Почти всегда ставятся относительно высокоуровневые задачи из некоей предметной области, будь-то автоматизация бизнеса, или окучивание неких сугубо технических подробностей. Поэтому почти всегда сначала надо строить модель из предметной области, и уточнять требования, по мере того, как модель становится все более детальной, а после их уточнения уже выходить на окончательный список требуемой функциональности + ограничений. А уточнение требований — это процесс, при котором одно высокоуровневое требование порождает несколько (иногда десятки) зависимых требований. А уж сколько подробностей генерят сочетания неких требований, на первый взгляд противоречивых... но это уже как повезет.
VD>С тестами же все как с обычным кода. Чем гибче язык, тем лучше на нем можно автоматизировать тестирование.
Это касается только примитивных тестов примитивной же функциональности. Если функциональности много, то постепенно язык становится пофиг. Те или иные ср-ва автоматизации наворачиваются все-равно, и некая начальная точка, данная языком/платформой, оказывается слишком малым % в общих затратах на развитие тестового окружение.
Всё, что ты говоришь, выглядит актуально для наколенных поделок с небольшим сроком жизни.
VD>Ну, и на тесты не должно уходить более 20% времени разработки.
От предметной области зависит. Такой низкий % характерен для сугубо вычислительных задач, где синтетика максимально близка к самой предметной области, т.е. подготовка/разработка автоматического тестирования (любого уровня) дается относительно дешево. Но взять хотя бы твою любимую область — компиляцию. Тут объем трудоемкости для разработки всего, связанного с тестированием (в основном, исходных данных, т.е. кода для компиляции) по трудоемкости может многократно превышать затраты на кодирование и отладку всего, что покрываемо юнит-тестами. Иначе эту работу вместо тебя будут делать юзвери, а это допустимо разве что для опен-сорса.
VD>Несомненно! Но работает в этом решении как раз таки код. А раз так, то все что не связанно с написанием кода — это не производтиельные расходы. И их нужно сокращать. Так?
Нет, конечно. Это такие же важные этапы. Непроизводительные расходы — это борьба с неточными спецификациями. Или клиентами, их генерящими. Сокращать или нет — зависит от модели бизнеса. Если вполне допустимо сваливать на плечи юзверов часть трудоемкости по верификации программы.. то почему бы и нет. А если сие недопустимо, то сокращение твоих "непроизводительных расходов" может привести к сокращению или потере собственно бизнеса.
В>>2. Формализованные и понятные требования. ТОже без единой строчки кода
VD>Вот это уже дело программистов. И то скорее, в некоторых случаях, ее выполняют выделенные еденицы вроде архиеткров и т.п.
Обычно очень поверхностно. И это правильно, если разобраться. Должна оставаться некая свобода действий для того, кто будет всё это реализовывать, т.е. кто будет лучше всех знать подробности конкретного участка.
VD>Опять же, для формилизации прототипирование будет не лишним. Так что строчки кода уже могли бы и появиться.
От предметной области зависит. Если предметная область достаточно исследована "кем-то еще", будь то математические алгоритмы обработки сигналов или четко описанные спецификации неких протоколов, то прототипирование и даром не надо. Прототипирование вообще зачастую нужно более для уточнения требуемых для "неизведанной области" ресурсов (если никто не имел достаточного опыта для оценки трудоемкости до этого), чем для архитектуры, бо любые подробности обычно спрятать за интерфейсами/протоколами без проблем.
Хотя, если весь проект такой, что никто никогда и близко с ничем подобным не сталкивался, то тут требуется "прототипирование всего". Но такие проекты обычно никто и не начинает сразу на 100%. Берется 5-10% человекоресурсов для разработки прототипа, и только потом принимается решение, быть ли проекту вообще или ну его нафик. Т.е. к моменту начала основных работ опять же, прототипирования практически не будет.
VD>Это у вас тоже программисты делаю? Не, я согласен, тут нужно создать инсталлятор (если пользователей много), проестироват его, написать инструкцию, если надо. Но это не задача программиста. Или задача специально выделенного программиста-прикладника.
Мде? И этот программист "со стороны" должен лучше тебя знать, какие зависимости тянет твой код? Оригинально... В общем, любые нетривиальные инсталляции случаются от кучи зависимостей, зачастую противоречивых. Начиная от версий осей, компиляторов и сторонних библиотек. Особенно если вспомнить, что существует вселенная и за пределами дотнета.
VD>А на этапе проектирования вы что делали? Или у вас получившееся решение отличается от исходного?
Конечно отличается. Оно обычно только на текущей итерации не должно особо отклоняться от спецификаций. Но сами спецификации практически никогда не устаканиваются до начала разработки. Каждая итерация обогащает спецификации. Все современные и популярные процессы разработки пляшут от тех самых итераций. Собственно, итерации и нужны для того, чтобы в разработке были детерминированные точки, в которых меняются/дополняются спецификации. Т.е. фактически все эти процессы разработки так или иначе отталкиваются от требования иметь возможность изменять целевые требования, но сохранять при этом детерминированность процесса разработки. Т.е. чтобы нивелировать неизбежно возникающий хаос, если бы требования менялись в произвольные моменты времени.
VD>Ну, да опять же. По уму тут нужно привлекать техрайтеров. Или опять получается использование программиста не по назначению. Ну, да по бедности и такое бывает. Но раз так, то не надо считать, что это часть разработки. Это часть работы которую человек вынужден совмещать с трудом программиста.
В этом и есть труд программиста. Его задача — придумать, как обыграть предметную область. В общем, как сделать вычислительное ср-во полезным клиенту. Поэтому всегда приходится глубоко вникать в предметную область. Насчет тех-райтеров и "бедности"... не надо про утопичные сценарии. Даже в самых богатых конторах есть некий минимальный уровень, когда на поддержку спецификации назначаются выделенные люди. И этот уровень обычно очень высок. Все интерфейсы более нижнего уровня неплохо живут и на самодокументировании, т.е. на доках, получаемых автогенерилками. Что-то нетривиальное, понятно, бывает описанно дополнительно, но это скорее редкость на приватных уровнях модулей.
В>>4. Теперь все это надо СДАТЬ
VD>О, как? А это тоже программист делает?
Гы... главное в сдаче — это подготовка к ней. Готовый продукт сдать-то может кто угодно. Например, ссылка в вебе.
VD>Ребята, да у вас какая-то каша получается. Вы смешиваете несколько видов деятельности и на этом основании говорите, что разработка не является основным видом деятельности. Но это всего лишь разные виды деятельности. В конторах где есть более 4 человек она должна выполнятся разными людьми.
Популярное заблуждение. Больше 40-ка не хочешь?
Для 4 человек можно разве что тестера выделить. Остальные будут разработчиками, а все остальные роли будут поделены м/у собой (и тестером в т.ч.), т.е. будет совмещение. Это от того, что очень сложно делить информационный объем сугубо на горизонтальные пласты. При таком кол-ве людей каждый должен будет знать всё на своем уровне. Проще, начиная с какого-то уровня делить вертикально, т.е. по предметным областям. Вот и получается, что программировать будут все. Пусть даже кто-то и лидер, это не меняет ничего принципиально.
VD>А программист должен: VD>1. Проектировать. VD>2. Кодировать. VD>3. Писать и прогонять тесты. VD>4. Отлаживать и исправлять ошибки.
Абсолютно правильно. Но проектирование без требований не бывает. А требования необходимо анализировать, уточнять, развивать. Выше уже высказывался. М/у требованиями и функционалом должно стоять соответствие 1:1 на любом уровне разработки, т.е. без работы над требованиями обычно никуда. А теперь учитываем, что это рисунок лишь одной итерации, т.е. в процессе нормальной разработки это всё приходится делать по кругу.
VD>Все это процессы непосредственно связанные с кодом. В любой из фаз, программист пишет, читает или думает о коде.
1. О требованиях и модели, позволяющей реализовать эти требования
2. Об интерфейсах, зависимостях, требованиях и модели
3. О требованиях + наводимых перекрестных сценеариях + граничные случаи + инварианты и т.д.
4. Когда ошибки по невнимательности, то думает о коде. Но эту тривиальность даже обсуждать лень. Все гораздо интересней, когда ошибки связаны с неполным/неверным представлением о предметной области или порождены багами в требованиях/спецификациях. Тогда приходится думать вовсе не понятиями кода.
Не знаю, когда там программист думает о коде. Я зычастую написал и забыл. У меня их сотни строк ежедневно, что о них думать? Но вот зависимости, высокоуровневые интерфейсы/протоколы, требования, выбранная модель их реализоции, особенности предметной области — это надо в памяти держать постоянно, чтобы назавтра иметь возможность накатать очередную сотню-другую строк... а сам код я обычно не помню. Да он и пишется на автомате и мозжечком больше, когда "общую картинку" в голове построишь. Как в той сказке: одну беру, на другую смотрю, третья мерещится... примерно так.
В>>И кстати , если кодирование начинает занимать в процессе слишком много времени, то одно из двух: В>>1. Слишком мало времени уделяется другим фазам
VD>Ага. Заключению договров и внедрению .
Внедрение внедрению рознь... Если много зависимостей от подробностей окружения, то на обыгрывание сих подробностей уйдет заметно времени. И ничего не попишешь.
В>>(скорее всего страдает тестирование или сбор требований — соответственно или много багов доходит до заказчика или заказчик получает не то что хотел ).
VD>И что, много багов не относится к коду? Халтурно писали код, получите море отладки. Уделяйте больше времени и внимания качеству написания кода, и получите меньше отладки. А лучше повышайте уровень кода, и уровень его контроля.
Удивительно, что это написал человек, работающий над компилятором. Сколько уже было исправлений, которые порождены исключительно разночтениями или даже исправлениями спецификаций языка? Не счесть. Как бы внимательно не писался код, этого было не избежать. Это же та самая стадия тестирования. Которая, правда, выполнялась сообществом.
VD>Ну, да если плевать на код и не считать его главным, а потом обосновывать баги тем, что код — это не главное, то конечно можно и до такого абсурда договориться.
Да фигню по трудоемкости занимают баги, связанные с невнимательностью программиста, т.е. порожденные "некрасивым" кодом. Я не говорю о клинических случаях, когда программист ошибся специальностью, здесь обсуждать и нечего... но для обычного программиста-спеца это именно так — подробности низкоуровневого кода некритичны в общей трудоемкости.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Ikemefula, Вы писали:
VD>Никому не нужен WCF. Нужен SOAP иди REST. А — это всего лишь библиотека упрощающая их реализацию.
Это не библиотека, это уже технология, при чем ориентированая не на бизнес а на инфраструктуру. Следовательно она должна быть одна единственная.
>И если в случае SOAP в WCF есть смысл, то в случае REST в WCF смысла нет. REST реализуется на коленке за два дня программстом среднего уровня.
Не совсем ясно, кто такой программист среднего уровня. На большую часть самопальных реализаций REST нельзя взглянуть без слёз. Потому, скажем, если "программист среднего уровня" это "десять+ лет опыта в реализации протоколов в т.ч. RPC и тд." то я абсолютно согласен
Здравствуйте, Ikemefula, Вы писали:
VD>>Никому не нужен WCF. Нужен SOAP иди REST. А — это всего лишь библиотека упрощающая их реализацию.
I>Это не библиотека, это уже технология, при чем ориентированая не на бизнес а на инфраструктуру. Следовательно она должна быть одна единственная.
В программировании есть более четкие понятия:
1. Алгоритм — точный набор инструкций, описывающих порядок действий исполнителя для достижения результата решения задачи за конечное время.
2. Библиотека — набор подпрограмм или классов, используемых для разработки ПО.
3. Протокол (передачи данных) — набор соглашений интерфейса логического уровня, которые определяют обмен данными между различными программами.
Так вот WCF — это именно библиотека. Ее замена не меняет ровным счетом ничего. Объясняется это очень просто — эта библиотека использует в качестве протокола стандарты. Раньше это был только SOAP. Теперь вот, оказывается, появился еще REST. Но оба протокола стандартизированы и, стало быть, проблем с заменой библиотек нет.
А "Технология" — это общие, не несущие ничего конкретного, слова.
I>Не совсем ясно, кто такой программист среднего уровня. На большую часть самопальных реализаций REST нельзя взглянуть без слёз.
REST — это очень простой протокол. По сути он состоит из роутинга и сериализации данных. Если не брать стриминг (который для организации RPC не нужен), то реализовывать там особо и не чего.
Скажу больше. Если RESTful, который (как оказалось) теперь входит в состав WCF, позволяет без лишнего гимора (присущего WCF-у при работе с SOAP) реализовывать REST и обеспечивает хорошую производительность, то его точно так же можно использовать для реализации публичных сервисов. Но полагаться, при этом, нужно именно на протокол (т.е. на REST), а не WCF и великий Майкрософт.
I>Потому, скажем, если "программист среднего уровня" это "десять+ лет опыта в реализации протоколов в т.ч. RPC и тд." то я абсолютно согласен
Какой-то набор слов. Но опыт реализации RPC — это точно положительный опыт. По крайней мере человек должен знает что такое протокол, а что библиотека. И должен понимать, что библиотека не обязана быть одной единственной. Если можно взять (или написать) существенно более простую библиотеку обеспечивающую лучшие характеристики, то лучше так и поступить. Как минимум не будешь привязан к конкретной версии фрэймворка.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>В программировании есть более четкие понятия:
Ты слишком сильно упрощаешь. Технология это гарантии того, что инструмент будет не только работать, но по ём можно получить поддержку-консультацию-помощь, можно ожидать что на рынке труда будут специалисты владеющие технологией, гарантия того, что инструмент будет хорошо работать вместе с другими технологиями.
Соответсвенно если ты отказываешься от технологии, у тебя резко на пустом месте образуется зависимость от ЧФ, при чем все еще в инфраструктурной части, которая вобщем то без бизнес-специфики никому не нужна.
VD>Так вот WCF — это именно библиотека. Ее замена не меняет ровным счетом ничего. Объясняется это очень просто — эта библиотека использует в качестве протокола стандарты. Раньше это был только SOAP. Теперь вот, оказывается, появился еще REST. Но оба протокола стандартизированы и, стало быть, проблем с заменой библиотек нет.
Библиотеку заменить просто так не получится. Как правило любой клиентский код почти намертво привязывается ко внутренностям библиотеки.
VD>А "Технология" — это общие, не несущие ничего конкретного, слова.
Для тебя — да. Ты мог бы и не повторяться.
I>>Не совсем ясно, кто такой программист среднего уровня. На большую часть самопальных реализаций REST нельзя взглянуть без слёз.
VD>REST — это очень простой протокол. По сути он состоит из роутинга и сериализации данных. Если не брать стриминг (который для организации RPC не нужен), то реализовывать там особо и не чего.
Наверное это основная причина, по которой самопальные реализации REST есть просто УГ
I>>Потому, скажем, если "программист среднего уровня" это "десять+ лет опыта в реализации протоколов в т.ч. RPC и тд." то я абсолютно согласен
VD>Какой-то набор слов. Но опыт реализации RPC — это точно положительный опыт. По крайней мере человек должен знает что такое протокол, а что библиотека. И должен понимать, что библиотека не обязана быть одной единственной. Если можно взять (или написать) существенно более простую библиотеку обеспечивающую лучшие характеристики, то лучше так и поступить. Как минимум не будешь привязан к конкретной версии фрэймворка.
Заюзав WCF и столкнувшись с необходимостью накинуть админку например на сервелате или требование реализовать мобайл клиент на этом сервелате, окажется что нет никаких проблем с этим — у микрософта все продумано. А если вдруг ОРМ придется заюзать, то внезапно оказывается что EF отлично вписывается в эту схему. А когда понадобится воркфлоу, опаньки, снова всё отлично вписывается , а у тебя любое изменение требований это геморрой с написанием своих "библиотек", эдакий возврат в девяностые но на дотнете
В любом более менее серьёзном проекте столько вещей, что выбор wcf-не-wcf уже не стоит, т.к. это выбор между n готовых решений или n**2 самопальных велосипедов.
Здравствуйте, Ikemefula, Вы писали:
I>>>А реально soap тот же заметить просто нечем... IT>>Можно подумать до soap жизни на земле не было. I>При чем здесь жизнь до soap ?
При том, что "реально soap тот же заменить просто нечем".
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Ikemefula, Вы писали:
I>Заюзав WCF и столкнувшись с необходимостью накинуть админку например на сервелате или требование реализовать мобайл клиент на этом сервелате, окажется что нет никаких проблем с этим — у микрософта все продумано.
Не всё. Продуманы только простейшие стандартные варианты. Шаг влево-вправо — попытка к бегству и будешь инет рыть и исходники ковырят до опупения. За это время на доморощенных средствах задачу уже давно можно было бы решить.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
I>>>>А реально soap тот же заметить просто нечем... IT>>>Можно подумать до soap жизни на земле не было. I>>При чем здесь жизнь до soap ?
IT>При том, что "реально soap тот же заменить просто нечем".
", потому что на нём держится кучка сервисов." Я готов использовать всё что угодно, но эти сервисы работают на soap даже у конкурентов следовательно, soap заменить нечем.
Здравствуйте, Ikemefula, Вы писали:
IT>>При том, что "реально soap тот же заменить просто нечем".
I>", потому что на нём держится кучка сервисов." Я готов использовать всё что угодно, но эти сервисы работают на soap даже у конкурентов следовательно, soap заменить нечем.
Т.е. ты всего лишь навсего зыбыл добавить "в моём конкретном случае".
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, AndrewVK, Вы писали:
AVK>Затем, что иногда этих урлов много и на вход тоже довольно сложная по структуре информация приходит.
Для этого, согласись, можно написать куда более легкую и не замороченную реализацию.
AVK>А вокруг еще какая нибудь аутентификация похитрее.
Разве что. Вот только скорее всего придется использовать аутентификацию что использовалась до этого на сайте (например, нашу или какой-нить ОпенАйДи). RESTful это поддерживает?
AVK>Можно, конечно, все это руками реализовать, но с использованием WCF будет существенно проще.
Честно признаюсь, что на WCF я очень давно не глядел. Я как его увидел, сразу понял, что это полнейший овердизайн. Потому и не следил за его развитием. Если они сделали качественную поддержку REST-а, то возможно многие мои слова я взял бы обратно.
Я тогда, пользуясь случаем, задам несколько вопросов.
Они сделали там сериализацию в JSON?
А возможность поднять сервис без конфигов и сложной инициализации?
Как реализован роутинг?
Если атрибутами, то какими средствами он сопоставляется с методами? Во время компиляции или опять рефлексия?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, IT, Вы писали:
I>>", потому что на нём держится кучка сервисов." Я готов использовать всё что угодно, но эти сервисы работают на soap даже у конкурентов следовательно, soap заменить нечем.
IT>Т.е. ты всего лишь навсего зыбыл добавить "в моём конкретном случае".
Я не понял что ты хотел сказать. М.б. ты считаешь что можно взять да за два денька переписать всю инфраструктуру сервисов для конторы-гиганта которая в топе находится ? Если сможешь, то да, я согласен, что это мой конкретный случай
Куда WS-ReliableMessaging ? Или REST этому уже научился ?
Здравствуйте, Ikemefula, Вы писали:
I>Я не понял что ты хотел сказать.
Я не понял чего ты не понял
I>М.б. ты считаешь что можно взять да за два денька переписать всю инфраструктуру сервисов для конторы-гиганта которая в топе находится ?
Да будет тебе известно, что отличие конторы-гиганта от конторы не гиганта лишь в том, что в конторе-гиганте легче делаются гигантские ошибки.
I>Если сможешь, то да, я согласен, что это мой конкретный случай
Ну не за два денька, но иногда и таким приходися заниматься — методично устранять чужие гигантские и не очень глупости.
I>Куда WS-ReliableMessaging ? Или REST этому уже научился ?
Без понятия что это за хрень. Она может мне помочь засериализовать граф объектов?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, VladD2, Вы писали:
AVK>>Затем, что иногда этих урлов много и на вход тоже довольно сложная по структуре информация приходит. VD>Для этого, согласись, можно написать куда более легкую и не замороченную реализацию.
Не соглашусь. Да, для простейших в плане API сервисов типа гуглевых WCF конечно же оверкилл. В ситуациях же, когда в API фигурируют сотни сущностей и зоопарк разных протоколов WCF очень неплохое решение.
VD>Разве что.
Это лишь один из моментов. А что ты скажешь насчет потоковой передачи? P2P? Дуплекса? Нотификаций? Сохранения стейта между вызовами? Реализовывать все это с нуля поверх голого HTTP стека — полный затрахен.
VD> Вот только скорее всего придется использовать аутентификацию что использовалась до этого на сайте (например, нашу или какой-нить ОпенАйДи).
Это если ты публичный сервис делаешь? А корпоративщики, они много интересной муйни понапридумали на тему.
VD> RESTful это поддерживает?
REST это не специфицирует. Собственно, REST почти ничего не специфицирует, кроме протокола HTTP. Так, набор общих идей.
VD>Если они сделали качественную поддержку REST-а, то возможно многие мои слова я взял бы обратно.
Поддержка там вполне нормальная и без уродливых хвостов типа как WS в сиквел вкрячивали или СО+ в IIS. Благодаря как раз тому якобы овердизайну, который позволил это сделать в рамках штатной архитектуры.
VD>Они сделали там сериализацию в JSON?
Сериализация в JSON не есть обязательное требование для REST. XML там используется не реже. Впрочем, поддержка JSONP там тоже присутствует — все что нужно это пометить требуемый метод атрибутиком [WebGet(ResponseFormat = WebMessageFormat.Json)]
VD>А возможность поднять сервис без конфигов и сложной инициализации?
Без конфигов можно, но не в IIS, только как standalone. Что ты понимаешь под сложной инициализацией я ХЗ — в простейшем случае достаточно просто подсунуть стандартный уже сконфигурированный биндинг. Это 1-2 строки кода.
VD>Как реализован роутинг?
Есть готовый модуль роутинга. Дальше — тем же атрибутом [WebGet(UriTemplate = "...")]. Формат шаблона такой же как для MVC.
VD>Если атрибутами, то какими средствами он сопоставляется с методами? Во время компиляции или опять рефлексия?
Рефлексия. Но один раз сделать это при старте сервиса совершенно не проблема. MVC вон куда больше через рефлексию дергает, и никого вроде это не напрягает.
Впрочем, при желании ты и свой роутер можешь написать, WCF это позволяет.
... << RSDN@Home 1.2.0 alpha 5 rev. 1537 on Windows 7 6.1.7601.65536>>
Здравствуйте, VladD2, Вы писали:
VD>Раньше это был только SOAP.
Блин, как с глухим. WCF с самого начала поддерживал несколько протоколов, не только SOAP.
VD> Теперь вот, оказывается, появился еще REST. Но оба протокола стандартизированы
Нет, REST не стандартизован.
VD>Скажу больше. Если RESTful, который (как оказалось) теперь входит в состав WCF
Точно не читаешь вообще, что тебе пишут. RESTful это не WCF, это так называется любой сервис, соответствующий идеологии REST.
... << RSDN@Home 1.2.0 alpha 5 rev. 1537 on Windows 7 6.1.7601.65536>>
Здравствуйте, AndrewVK, Вы писали:
I>>>Куда WS-ReliableMessaging ? Или REST этому уже научился ? IT>>Без понятия что это за хрень. AVK>Протокол доставки сообщений с гарантией.
Это вообще какая-то комбинация слов, не имеющая смысла. А если я компьютер из розетки выдерну, как ты доставку сообщения гарантируешь?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, VladD2, Вы писали:
VD>Честно признаюсь, что на WCF я очень давно не глядел. Я как его увидел, сразу понял, что это полнейший овердизайн. Потому и не следил за его развитием. Если они сделали качественную поддержку REST-а, то возможно многие мои слова я взял бы обратно.
VD>Я тогда, пользуясь случаем, задам несколько вопросов. VD>Они сделали там сериализацию в JSON?
Да, еще в .NET 3.5 SP1
VD>А возможность поднять сервис без конфигов и сложной инициализации?
Это как? Две строки задать binding — сложная инициализация? Конфиг чаще всего не нужен, но с ним проще работать, так как можно поменять вообще все (протокол, формат, шифрование) не меняя кода.
VD>Как реализован роутинг?
Атрибутами
VD>Если атрибутами, то какими средствами он сопоставляется с методами? Во время компиляции или опять рефлексия?
Рефлексия, а смысл что-то другое делать? Тупо на десериализацию больше уйдет времени.
А еще есть wcf data services — самое то для JS на клиенте.
Здравствуйте, IT, Вы писали:
IT>Это вообще какая-то комбинация слов, не имеющая смысла. А если я компьютер из розетки выдерну, как ты доставку сообщения гарантируешь?
Ну, никто не говорил что гарантия 100%. С MSMQ когда нибудь работал? Если да, то должен понимать, о чем речь. Если нет — смысл в том, чтобы при помощи специальных хидеров и протоколов, а так же возможности ретрейна, постараться доставить все сообщения в нужном порядке и без дубликатов, а если не вышло то получить гарантированно отказ, а не глюки. Но если ты провод из розетки выдернешь, то, конечно, ничего не получишь.
... << RSDN@Home 1.2.0 alpha 5 rev. 1537 on Windows 7 6.1.7601.65536>>
Здравствуйте, IT, Вы писали:
I>>Куда WS-ReliableMessaging ? Или REST этому уже научился ?
IT>Без понятия что это за хрень. Она может мне помочь засериализовать граф объектов?
Здравствуйте, 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 ... Помоему автор переживает деэволюцию.
Статья учит плохому — мне очень не понравилось что там в комментах сразу же повылазили ленивые программисты, которые гордяться что не комментят код. Хотя известно что поддерживать такой некоментированный монолитный код ...
Если нам не помогут, то мы тоже никого не пощадим.
Хотя нет, закрывать глаза на тонны успешных мейнстрим-языков со статической типизацией — это важнейший принцип онолитега, так что всё ок.
