"Подгорает" здесь не в смысле "подо мной уже стул тлеет после чтения твоего кода", а в смысле "у нас сроки/проект горят". Т.е. вопрос всё равно о неких цифрах и фактах, а не о субъективном восприятии. Извиняюсь, если неточно выразился.
Вот именно для того, чтобы не спорить, что есть баг, а что есть говнокод (или кто из двух кодообезьян говнокодистее, или какой стиль именования/отступов/расстановки скобок самый правильный, или какой из /анти/паттернов является на самом деле таковым), я и предлагаю сводить всё к числам. Боль есть? - Значит говно! Работает и ни у кого не подгорает? - Молодцы, продолжайте!
Если до рефакторинга в куске кода находили 4 бага в неделю, а после стало в среднем 1.5, то до рефакторинга код был явно не очень.
Если одна сферическая задача в вакууме раньше занимала 36.2 часа разработки, а после переписывания стала закрываться за 7.1 часов - аналогично.
[совсем реальный кейс с настоящими цифрами] Если раньше один критичный алгоритм занимал 10.000 строк кода и покрывал 17 возможных комбинаций входных значений из 640.000, а потом стал занимать 100 строк (просто сотня, а не сто тысяч) и покрывать все 640.000...
Нет, официально они нигде не принимаются (хотя по факту кое-где могут закрыть глаза). По личному опыту это было так: заходим в ТЦ, спрашивают galimybių pasas, жена делает глаза кота из Шрека и показывает сертификат прививки Спутником. Большинство говорит "у нас такое конечно нельзя, но вы проходите". Но один раз нарвались на принципиальную тётеньку. Примерно 10 раз прокатило, 1 - нет.
P.S.: Это касается и анализов тоже. "Не европейское - значит, понарошку."
При въезде с прививкой "Спутником" сдаётся анализ на антитела за 30-35 евро, после чего получается обычный паспорт возможностей (QR-код для входа в магазины и ТРЦ, на местном galimybių pasas), действующий 2 месяца. (Жена проделала это полтора месяц а назад.)
Потому что WPF не лучше WinForms. Да, в некоторых местах он шагнул далеко вперёд: темплейты, стили, анимации, свойства и события прокачались, разметку теперь не нужно переписывать при изменении DPI или языка (ну ладно, хотя бы не так часто и геморройно). Но в некоторых вещах (RichTextBox и WebBrowser) он просто не юзабелен, только WindowsFormsHost и спасает... P.S.: ~10 лет опыт работы с WPF, ~5 лет WinForms.
По моему опыту - это лотерея. Если кода, ипользующего подкапотные костыли .NET и WinForms мало, то вполне возможно, что удастся реально обойтись заявленным в статье Application.SetDefaultFont. Шаг в сторону (не ту) - здравствуйте, две недели отладки. Мигрировал по версиям 2 своих pet-проекта и 2 крупные enterprise-системы. Ни разу не угадал с прогнозом сложности таких изменений - причём ошибался в обе стороны.
Абсолютно верно! Я не против принципов Agile, я против возведения их в абсолют. Собственно, про это и примеры (надеюсь, герои моих примеров икают сейчас).
Попробую отстоять точку зрения автора статьи, исходя из своего опыта. IMHO, Agile - это про гибкость огранизации в контексте проиходящих изменений, возможность реагировать на feeback и делать pivot-ы. Перечисленные вами принципы являются советами, помогающими этого достичь. Упомянутые автором разбиение работы на порции - наиболее простым и часто используемым способом увеличить гибкость, управляемость и предсказуемость. Но если просто свести весь Agile к четырём принципам, будет следующее (реальные случаи):
"Работающий софт важнее документации, be agile!" - произносит менеджер, отвественный за спецификацию к сложной технической системе. А когда он пишет-таки спецификацию перед самым релизом, выясняется, что там написано "как хотелось бы", а не "как есть" - а соответствующие переделки займут пару месяцев.
"Люди важнее процессов" - заявляет организация и внедряет Agile. Из 32 человек команды разработки продукта с 1.5 миллионами клиентов за два месяца увольняются 29, которым не понравился такая передовая методология.
Под соусом "заказчик важнее контракта" были пропихнуты изменения, на реализацию которых были брошены все ресурсы. После чего заказчик начал угрожать иском на круглую сумму из-за того, что не было сделано то, что было указано в контракте (вот же сюрприз!).
В grpc не полетело его несуществование на момент разработки описываемого проекта. Мы релизнулись в октябре 2014, а grpc был представлен в августе 2016.
Если вопрос будет про «что лучше использовать сейчас?», я отвечу «а что лично Вам удобнее?» Я, поизучав grpc, для своих маленьких проектов с клиент-серверным взаимодействием остановился на WCF. Что я буду использовать, когда мне дадут enterprise-проект, связанный с клиент-сервером? Буду посмотреть в конкретной ситуации. Может — grpc, может — wcf, а может и cgi, реализованный на ассемблере. Всё от конкретных требований.
IMHO, смысла что-то срочно куда-либо мигрировать вообще очень мало. Мой опыт показывает, что реальной необходимости миграции в большинстве случаев нет. Есть требования заказчика, сформированные в результате прочтения статей о том, что «все системы такого-то типа должны обладать таким-то набором функций» (список из 10-20 позиций, из которых заказчик будет использовать хорошо если 2-3). Есть стремление всего более нового, вне зависимости от того, сколько будет стоить обновить инфраструктуру до требуемого уровня. Есть надежды на серебрянную пулю (типа «вот переведу свою систему в облака/микросервисы — и сразу заживу!»). А есть, наоборот, дремучее легаси, которое написано ещё до твоего рождения и уже не одно десятилетие портит людям кровь, но никто его не будет менять из риска хоть что-то потерять — а с ним тоже взаимодействовать надо. Повторяю, это только IMHO, но я очень мало видел примеров того, как миграция на новые инструменты или версии приносила реальные преимущества, а не тонну геморроя.
Пример: примерно раз в два года наша компания «перезжает» на новую версию Visual Studio. Разрабатываемое решение большое, проектов в нём много, разных типов, покрытие тестами — моё почтение. Каждый раз при переезде примерно месяц у всей команды (не одна сотня человек) проект будет или не открываться, или не компилироваться, или не работать, или значительная часть тестов упадёт. Я не говорю уже про тормоза и зависания новой версии первые полгода или отваливающиеся расширения и дополнения среды разработки.
grpc — не исключение. WCF нет в актуальных версиях? А что из предоставляемых в актуальных версиях планируется использовать? А почему архитектура организована таким образом, что проект зависит от фреймворков? А если с архитектурой всё хорошо, то откуда проблемы с миграцией?
Господа, не стоит холиварить за инструменты. Их было много, и их ещё больше будет. За свои 20 лет активного программирования я насмотрелся всякого: и забивания гвоздей микроскопами (с неизменным выводом «эти ваши микроскопы все гамно»), и выдающегося применения совершенно неподходящих для этого вещей («в умелых руках и срамной уд — балалайка»). Весь смысл статьи (помимо очевидной горькой самоиронии) заключён во втором её выводе: последовательное повторное решение задачи с помощью изменяющихся инструментов ведёт к углубленному изучению этих самых инструментов и связанных с ними технологий.
Я предпочитаю про жив/мёртв не спорить, потому что встречал самые удивительные примеры использования инструментов и технологий, включая MS-DOS в 2006 году. Кроме того, есть отрасли, в которых исторически сложилось отставание на 2-3 года от мировых трендов.
1. Согласен.
2. Дефолтная локаль и у меня есть. То есть, при выходе новой версии можно переключиться на язык по умолчанию, посмотреть на нужную строку в программе, скормить её автопереводчику и записать в локализацию самому. Способ костыльный, зато позволяет не простаивать в ожидании официальной локализации.
Да, такая проблема есть. Впрочем, это не намного хуже, чем «текст, вшитый в приложение», который чаще всего является нечитаемой аббревиатурой с кучей подчёркиваний.
Gettext я не использовал. Всё-таки это стороннее решение, которое надо ещё решить использовать. А иерархия нужна, потому что перевести фразу правильно можно только тогда, когда знаешь контекст, в котором она употребляется. Если ты видишь, в каком месте и какой формы она она прицеплена (есть подробный иерархический ключ), то и перевести просто. Если просто видишь фразу, висящую в вакууме, то и при переводе сделать максимум получится сферического коня. Пример из текущего проекта с нынешней работы: 6 строк, лежащих в разных местах, в английской локализации имеют вид «Successfull». В японской локали все шесть строк разные, хоть и говорят об успешном завершении.
"Подгорает" здесь не в смысле "подо мной уже стул тлеет после чтения твоего кода", а в смысле "у нас сроки/проект горят". Т.е. вопрос всё равно о неких цифрах и фактах, а не о субъективном восприятии. Извиняюсь, если неточно выразился.
Вот именно для того, чтобы не спорить, что есть баг, а что есть говнокод (или кто из двух кодообезьян говнокодистее, или какой стиль именования/отступов/расстановки скобок самый правильный, или какой из /анти/паттернов является на самом деле таковым), я и предлагаю сводить всё к числам.
Боль есть? - Значит говно!
Работает и ни у кого не подгорает? - Молодцы, продолжайте!
Если до рефакторинга в куске кода находили 4 бага в неделю, а после стало в среднем 1.5, то до рефакторинга код был явно не очень.
Если одна сферическая задача в вакууме раньше занимала 36.2 часа разработки, а после переписывания стала закрываться за 7.1 часов - аналогично.
[совсем реальный кейс с настоящими цифрами] Если раньше один критичный алгоритм занимал 10.000 строк кода и покрывал 17 возможных комбинаций входных значений из 640.000, а потом стал занимать 100 строк (просто сотня, а не сто тысяч) и покрывать все 640.000...
Нужно продолжать?
Немножко юмора из личного опыта (комментарии в реальном Enterpsise-коде):
// Массив вместо ArrayList использован здесь просто из-за лени.
// Something about dark magic. Do not delete this emty "if", because it causes view invalidation.
(Моё любимое, for ever, судя по истории - коммент на месте удалённой строки кода) // Юра, извини.
Нет, официально они нигде не принимаются (хотя по факту кое-где могут закрыть глаза). По личному опыту это было так: заходим в ТЦ, спрашивают galimybių pasas, жена делает глаза кота из Шрека и показывает сертификат прививки Спутником. Большинство говорит "у нас такое конечно нельзя, но вы проходите". Но один раз нарвались на принципиальную тётеньку. Примерно 10 раз прокатило, 1 - нет.
P.S.: Это касается и анализов тоже. "Не европейское - значит, понарошку."
При въезде с прививкой "Спутником" сдаётся анализ на антитела за 30-35 евро, после чего получается обычный паспорт возможностей (QR-код для входа в магазины и ТРЦ, на местном galimybių pasas), действующий 2 месяца. (Жена проделала это полтора месяц а назад.)
Потому что WPF не лучше WinForms. Да, в некоторых местах он шагнул далеко вперёд: темплейты, стили, анимации, свойства и события прокачались, разметку теперь не нужно переписывать при изменении DPI или языка (ну ладно, хотя бы не так часто и геморройно). Но в некоторых вещах (RichTextBox и WebBrowser) он просто не юзабелен, только WindowsFormsHost и спасает...
P.S.: ~10 лет опыт работы с WPF, ~5 лет WinForms.
По моему опыту - это лотерея. Если кода, ипользующего подкапотные костыли .NET и WinForms мало, то вполне возможно, что удастся реально обойтись заявленным в статье Application.SetDefaultFont. Шаг в сторону (не ту) - здравствуйте, две недели отладки. Мигрировал по версиям 2 своих pet-проекта и 2 крупные enterprise-системы. Ни разу не угадал с прогнозом сложности таких изменений - причём ошибался в обе стороны.
Абсолютно верно! Я не против принципов Agile, я против возведения их в абсолют. Собственно, про это и примеры (надеюсь, герои моих примеров икают сейчас).
Попробую отстоять точку зрения автора статьи, исходя из своего опыта. IMHO, Agile - это про гибкость огранизации в контексте проиходящих изменений, возможность реагировать на feeback и делать pivot-ы. Перечисленные вами принципы являются советами, помогающими этого достичь. Упомянутые автором разбиение работы на порции - наиболее простым и часто используемым способом увеличить гибкость, управляемость и предсказуемость. Но если просто свести весь Agile к четырём принципам, будет следующее (реальные случаи):
"Работающий софт важнее документации, be agile!" - произносит менеджер, отвественный за спецификацию к сложной технической системе. А когда он пишет-таки спецификацию перед самым релизом, выясняется, что там написано "как хотелось бы", а не "как есть" - а соответствующие переделки займут пару месяцев.
"Люди важнее процессов" - заявляет организация и внедряет Agile. Из 32 человек команды разработки продукта с 1.5 миллионами клиентов за два месяца увольняются 29, которым не понравился такая передовая методология.
Под соусом "заказчик важнее контракта" были пропихнуты изменения, на реализацию которых были брошены все ресурсы. После чего заказчик начал угрожать иском на круглую сумму из-за того, что не было сделано то, что было указано в контракте (вот же сюрприз!).
Если вопрос будет про «что лучше использовать сейчас?», я отвечу «а что лично Вам удобнее?» Я, поизучав grpc, для своих маленьких проектов с клиент-серверным взаимодействием остановился на WCF. Что я буду использовать, когда мне дадут enterprise-проект, связанный с клиент-сервером? Буду посмотреть в конкретной ситуации. Может — grpc, может — wcf, а может и cgi, реализованный на ассемблере. Всё от конкретных требований.
Пример: примерно раз в два года наша компания «перезжает» на новую версию Visual Studio. Разрабатываемое решение большое, проектов в нём много, разных типов, покрытие тестами — моё почтение. Каждый раз при переезде примерно месяц у всей команды (не одна сотня человек) проект будет или не открываться, или не компилироваться, или не работать, или значительная часть тестов упадёт. Я не говорю уже про тормоза и зависания новой версии первые полгода или отваливающиеся расширения и дополнения среды разработки.
grpc — не исключение. WCF нет в актуальных версиях? А что из предоставляемых в актуальных версиях планируется использовать? А почему архитектура организована таким образом, что проект зависит от фреймворков? А если с архитектурой всё хорошо, то откуда проблемы с миграцией?
P.S.: Извините за «простыню». Так получается…
2. Дефолтная локаль и у меня есть. То есть, при выходе новой версии можно переключиться на язык по умолчанию, посмотреть на нужную строку в программе, скормить её автопереводчику и записать в локализацию самому. Способ костыльный, зато позволяет не простаивать в ожидании официальной локализации.