В такой постановке холиварный вопрос.
Обычно идёт трейдофф на скорость разработки.
Если архитектурой и рефакторингом не заниматься, то разработка новых фич становится очень дорогой.
Если заниматься слишком много — разработка становится слишком дорогой.
Была хорошая статья про отношение % времени на дизайн и объёмом приложения, найду — добавлю.
Многие программисты, написав тесты, перестают думать. Перестают моделировать поведение программы в голове и ловить баги «аналитически». А ведь предположения, допущенные при написании теста, далеко не всегда отражают реальность — то, как этот класс будет использовать клиент и в каком состоянии будет система.
Зачастую решение состоит из сложного пересечения модулей, где надеятся на юнит-тесты рискованно.
Действительно IoC решает многие проблемы с моками, но вопрос, нужны ли юнит тесты и насколько? Сколько стоит их поддерживать и оправдывают ли они себя? Или всё-же лучше сделать ударёние на приёмочные и интеграционные тесты — которые медленней, гоняются на сервере — но при этом тестируют интеграцию нескольких компонент, практически не изменяются с кодом и могут рассказать какую-то бизнесс историю, будучи написанными читабельно?
В каждом проекте по-своему, призыв прост — перестать из ТДД делать священный грааль — часто юнит тесты увеличивают стоимость содержания кода, не давая ничего взамен.
На практике получается именно так, да. Но ведь это же не здравый смысл, это лень думать и недальновидность.
Есть же Су-Ха-Ри — не понимая, не изменишь методологий ты во благо.
Это статья вместе с Коуберном и моим опытом говорит не об ненужности методологий — а о том, что здравый смысл должен превалировать над инструментом.методологией. Если, конечно, вы хотите сделать успешный проект.
Есть простой фреймворк для java REST-full JSON web service: http://dropwizard.codahale.com/
Это попытка совместить Jetty/Jersey/Jackson.
В результате код выглядит достаточно логично и лаконично.
'has a' and 'is a'
Дом является Строением — используем наследование.
Дом обладает ванной — используем композицию.
Субъективно, наследование делает код сложночитаемым и плохо поддерживаемым.
Особенно если принципы дизайна (открытости\закрытости и пр.) не учитывались при написании кода.
Бывает так, что щит плодит… не особо защищает и перевирает требования, в общем.
Не всем программистам нужна защита, чего (лично мне) не хватает — это корректной частой конструктивной обратной связи от менеджера.
это конечно неочевидно, но автор заявляет основную проблему — в контенте игр, идее.
Такую проблему легко починить сделав пару успешных игр на аутсорсинге — понять что пипл хавает.
Затем сделать нечто своё с успешным опытом за плечами.
Надо продавать то, что хорошо получается. Писать игры получается, создавать — нет. Значит, надо продавать навык написания игр.
Абсолютно согласен. Такое себе обналичивание лояльности.
При условии правильной информационной политики Мерседес бы вытеснил своим супер двигателем остальных производителей, а для роста продаж вполне можно использовать другие критерии машины(новый дизайн, электроника и пр.).
В этом примере скорее смотрится провал мировозрения, как управленческого, так и потребительского.
Да, социально-ответственный бизнесс пока является исключением, чем правилом, но при осознанном подходе (и устойчивости к рекламе) покупатель будет выбирать более качественный продукт, а не более популяризированный.
Здесь вопрос плавно переходит про воспитание, а это довольно болезненный и сложный вопрос для одного комментария
Политиками правят деньги, деньгами правят банкиры, банкирами управляет производство(в широком понимании слова). Производственные процессы стремятся к оптимизации. Цепочка спорная и грубая, но в общем верная.
Уже сейчас социально-ответственный бизнесс становится более распостранённым, и это замечательно. Так что мировое устройство не является чем-то настолько незыблемым, насколько оно хочет казаться.
смущает в его теории одна вещь:
если Жак Фреско считает свою экономику более конкурентноспособной, почему бы не запатентовать и выпустить на рынок\в социум часть инноваций, а на вырученные деньги построить город-сад?
пока он защищает свои изобретения от злых корпораций, создаётся впечатление, что мощность ресурсо-ориентированной экономики менее рыночной.
А слова и картинки — очень правильные, жаль на сайте проекта не нашёл ничего конкретного. Очень интересна была фраза про роботов, разбирающих старые города на запчасти.
Carrots and Sticks Don't Work: Build a Culture of Employee Engagement with the Principles of RESPECT book
Обычно идёт трейдофф на скорость разработки.
Если архитектурой и рефакторингом не заниматься, то разработка новых фич становится очень дорогой.
Если заниматься слишком много — разработка становится слишком дорогой.
Была хорошая статья про отношение % времени на дизайн и объёмом приложения, найду — добавлю.
То есть свинья и съесть хотела и трюфель нашла а тут ей раз — и запретили.
www.apa.org/helpcenter/willpower-limited-resource.pdf
Думаю, истина, как всегда, где-то посередине.
Вы подтвердили некоторые мои мысли по поводу продуктивности и дали пищу для новых.
Зачастую решение состоит из сложного пересечения модулей, где надеятся на юнит-тесты рискованно.
Действительно IoC решает многие проблемы с моками, но вопрос, нужны ли юнит тесты и насколько? Сколько стоит их поддерживать и оправдывают ли они себя? Или всё-же лучше сделать ударёние на приёмочные и интеграционные тесты — которые медленней, гоняются на сервере — но при этом тестируют интеграцию нескольких компонент, практически не изменяются с кодом и могут рассказать какую-то бизнесс историю, будучи написанными читабельно?
В каждом проекте по-своему, призыв прост — перестать из ТДД делать священный грааль — часто юнит тесты увеличивают стоимость содержания кода, не давая ничего взамен.
Есть же Су-Ха-Ри — не понимая, не изменишь методологий ты во благо.
http://dropwizard.codahale.com/
Это попытка совместить Jetty/Jersey/Jackson.
В результате код выглядит достаточно логично и лаконично.
Дом является Строением — используем наследование.
Дом обладает ванной — используем композицию.
Субъективно, наследование делает код сложночитаемым и плохо поддерживаемым.
Особенно если принципы дизайна (открытости\закрытости и пр.) не учитывались при написании кода.
Не всем программистам нужна защита, чего (лично мне) не хватает — это корректной частой конструктивной обратной связи от менеджера.
Такую проблему легко починить сделав пару успешных игр на аутсорсинге — понять что пипл хавает.
Затем сделать нечто своё с успешным опытом за плечами.
Надо продавать то, что хорошо получается. Писать игры получается, создавать — нет. Значит, надо продавать навык написания игр.
При условии правильной информационной политики Мерседес бы вытеснил своим супер двигателем остальных производителей, а для роста продаж вполне можно использовать другие критерии машины(новый дизайн, электроника и пр.).
В этом примере скорее смотрится провал мировозрения, как управленческого, так и потребительского.
Да, социально-ответственный бизнесс пока является исключением, чем правилом, но при осознанном подходе (и устойчивости к рекламе) покупатель будет выбирать более качественный продукт, а не более популяризированный.
Здесь вопрос плавно переходит про воспитание, а это довольно болезненный и сложный вопрос для одного комментария
Уже сейчас социально-ответственный бизнесс становится более распостранённым, и это замечательно. Так что мировое устройство не является чем-то настолько незыблемым, насколько оно хочет казаться.
если Жак Фреско считает свою экономику более конкурентноспособной, почему бы не запатентовать и выпустить на рынок\в социум часть инноваций, а на вырученные деньги построить город-сад?
пока он защищает свои изобретения от злых корпораций, создаётся впечатление, что мощность ресурсо-ориентированной экономики менее рыночной.
А слова и картинки — очень правильные, жаль на сайте проекта не нашёл ничего конкретного. Очень интересна была фраза про роботов, разбирающих старые города на запчасти.