Как стать автором
Обновить
-12
0

Пользователь

Отправить сообщение
Скажем так студия жрет ресурсов не мало, а Idea еще больше. Не у каждого комп/ноут с 10 ядрами и 32 Gb оперативки.
С современными IDE, не нужно что-то там пролистывать, чтобы узнать, что у класса есть и что он может. В языках с динамической типизацией, конечно, с этим посложнее. Но статически типизированные языки, начиная от C# и Java, и заканчивая более молодыми — в хедерах не нуждаются от слова «совсем».
Да да, а потом смотришь код таких граждан в VCS и все ссылки и типы объявлены как var, конечно они даже и подумать не могут, что их г-но будут читать не из их любимой IDE, review тоже доставляет.
Код должен быть такой, чтобы его было читать удобно даже из блокнота, более того, не все компилят код из IDE всегда, иногда бывает так, что есть блокнот или vim.
я хоть и не джавист. Но в .NET изначально были property, потом добавили еще всякого синтакического сахара. Возможно это облегчлило задачу для тех, кто пачками создает какие-то data classes, но в общем случае, когда свойств 10-15 примерно все тоже самое.
В общем такую штуку стоит тащить если есть очевидная выгода, например ветвистый DAL (Data Access Layer), в остальных случаях стоит наверное подумать.
А как будет выглядеть стандартная реализация иерархии контролов, пусть даже древних финформз.
Или вы говорите о реализации бизнес логики в функциональном стиле?
Да не скажут они ничего конкретного и нового, если говорить про адептов.
Единственное собственное введение scrum это StoryPoints, которые непонятно когда и как работают, т.к. граничные условия использования scrum не обозначены.
А все остальное присовено. Цикл разработки чистой воды RUP, именно в описании этого пройесса формализовали и выделили фазы разработки ПО, а сокращенное время итрации заслуга не scrum, а окружения и инструментов разработки.

А вы не пробовали посчитать какие-нить метрки в разрезе количество дефектов, отклонение по времени наопределенных участках кода? Есть гипотеза что в некачественном коде сложно давать оценки и возникает больше ошибок.
@Around("callAtMyServiceSecurityAnnotation(user)")
АОП сковзная функциональность, которую вполне можно вызывать через статический вызов класса, внутри которого инстанс соаздается через ServiceLocator.
public static Security{
private static final Lazy<ISecurityService> lazySecurityService = new Lazy(Container::Resolve<ISecurityService>)

public void logEvent(anyparams){
lazy.value.logEvent(anyparams);
}
}

В общем случае это тоже не идеальное решение, непонятно в какое время будет проинстанциирован ISecurityService и когда уничтожен, но такой подход избавляет от ненужных параметров в конструкторе и в случае падения stacktrace более наглядный. А кода примерно столько же, что аннтоация, что строчка вызова.
Заранее оценить трудоемкость задачи, без погружения в детали, довольно сложно, особенно если задач несколько тысяч, как было в нашем случае.

Это систематическая ошибка стоит того, чтобы над ней поразмышлять. Однако при условии, что команда мотивирована, и все работают добросовестно, это говорит лишь о том, что реальный срок люди указать не могут, исполнители не учитывают осложняющие факторы, которые в большинстве случаев возникают в ходе работы.

Попытки управлять на детальном уровне централизованно, по большому количеству задач с большой степенью неопределенности обречены на провал.

ВЫ столько набросили, что у аджайл(скрам/канбан) адептов щас кое-что задымится и взорвется. Особенно понравилось про мотивацию, редко когда видишь управленцев, которые пытаются разобраться и побороть первопричину, а не следствие.
В который раз повторяюсь, но всегда интересно читать реальный опыт человека, чем какую-то книжную муть про стори поинты и планинг покер — который по их замыслу должен подойти всем.
Это просто огонь!
Вот это тяга, вот это креатив, машина чарлза бэбиджа отдыхает :)
Пошел отключать ребенку интерент, хочешь играть — приудмай сам!
Видел все, знаю единственный рецепт от боли: налаживать связи с адекватными людьми на проктах.

Поглотят, испортят, да и черт с ними. Слишком много менеджмента, который который руками водит по воздуху водит, как у Райкина: "я как руковожу, я руками вожу. Сам не работаю и вас не заставляю". В Red Hat одна только Ким Хаммондз чего стоит, как ее провожали из Боинга, а уж сколько она в Дойче делов наделала, ради ИмБР.
Не могу найти новость, где работники единодушно были рады тому, что она уходит и под новостью было только более 100 корневых комментариев.
Чтобы компания была успешной, в ней прежде всего должен быть адекватный менеджмент действующий в интересах компании, а не в собственных интересах направленных на создание иллюзии результатов работы и собственным продвижением по службе.

Весь девятый и десятый класс мы с моим одноклассником были заняты написанием симулятора операционной системы
парни вы крутые, реально!
Грепать я тогда не умел, парсить страницы — тоже, а про xml и csv знал очень обрывочно. Поэтому техническое решение было очень странным:
это все фигня. Дорогу осилит идущий, главное что задача была решена и решена за обозримое время. Не надо все знать, надо просто иметь мозги чтобы уметь находить/придумывать решение проблемы. Если бы вам надо было обработать 1000 страниц, я уверен, что вы бы дошли до парсинга.

Спасибо! Всегда интересно читать про свой опыт, про подходы, ошибки и эволюцию. В последнее время слишком много всяких консультантов, которые учат работать по аджайл, обскрамившись, натягивая канбан по книжкам.
Удачи вам!
Покрытие тестами это метрика абстрактного коня в вакууме. Надо четко понимать, что означает 30% покрытия тестами и что покрыто этими тестами, а главное за чем.
Из практики, модульными тестами надо покрывать обработку всевозможных данных, когда некоректный расчет ведет, к ошибке, а не к падению, которое тестер или тестовая среда с легостью обнаружат.
Например парсинг, процессинг и т.д. покрывал бы сильно, а модель поведения кнопки отправить, да там и так все предельно просто. Но как всегда все зависит.
Опять таки неплохо трекать какие тесты падаюбт часто, а какие не падают вообще, на каком участке кода дефектов много, а на каком их нет вообще. В зависимости от этого и организовывать покрытие тестами.
Абстракная цифра покрытие тестами в 30% не говорит абсолютно ни о чем.

Не ответил на главный вопрос автора. Все что можно оценить, оцениваем, все что нет, не оцениваем.

Я не знаю кто такой Майкл Кох и какой продукт он написал. Изначально оценка в sp выглядит очень слабой попыткой характеризовать динамику. На этот "Гербалайф" купилась целая куча деланных менеджеров, которые мало того что в софте не понимают, так и в принципе в управлении.
Пусть возьмём модель scrum, sp и так далее. Может изучал не так детально, но никто не приводил граничных условий когда эта модель работает, а когда нет. В энтерпрайзе, когда пара строчек в минуту может обернуться тем, что тебе надо поговорить 3 другими командами, у тех свои зависимости, в итоге строчка становится очень дорогой, и часто это выясняется только в процессе работы. Оценка в sp уже уехала. Второе легаси говнокод, в нем очень сложно давать оценки, т.к. не всегда понятно, какое изменение что за собой тянет. Более того перед изменением часто надо сделать рефакторинг, чтобы не усугублять ситуацию. А там бывает и дизайн надо обсудить и какие-то варианты попробовать, оценка мало предсказуема.
Разный уровень знания кода и технологий, кто то уже работал, кому то немного изучить. Оценки разные.


По опыту для точных краткосрочных оценок нужен хороший и понимаемый код и слаженная работа команды, тогда все можно оценивать в часах, днях. Но чтобы построить слаженную команду и контролируемый процесс, необходимо применять совсем другие методики и инструменты.


Всегда поражало что как можно оценивать сложный процесс разработки по одному графику попугаев? Куча факторов, в том числе противодействующих аккумулируются в одном графике. Вот график пошел не туда куда надо, какие факторы на это повлияли, хрен знает.
Очень напоминает форекс разводил, вот тут будет фигура "голова-плечи", курс идёт по волнам Эллиота, создаваемыми давлением Бойля Мариотта, значит тут продаем и тут покупаем, с вас 100$ за торговлю на истории))
Прежде чем вообще что-то изучать, всегда оцениваю результат этих людей: что они уже сделали, а всякие продаваемых "Гербалайфа" с канбаном, скрамом, скейлд аджайл фреймворком идут лесом — слишком много продаванов. Посмотрите как организован процесс написания ядра линукс, вот процесс Торвальдса стоит изучить, потому что результат как говорится "на лицо", а что эти продаваны сделали я не знаю.

Нет, как раз по примеру ВК, когда кртиш вниз, потом вверху начинают пролистываться страницы. и как уже заметели ниже, по идее отсчет страниц должен осуществляться в прямом порядке: последнее сообщение имеет бОльший номер, но отображение надо делать с конца. Т.е. я открываю и сразу не последней странице например 13456.
Парадигма так себе и людей придется приучать. Зато нет никакой однозначности.
На первой странице первое сообщение, на N поновее, находясь на Nой, если кто-то допишет еще 10 страниц, то ок, мотаем конец.
Что мешает по скролу двигаться по страницам? И бесконечная прокрутка и позиция в тексте win-win.
Сайтами с бесконечной прокруткой стараюсь не использовать — уважаю свое время. Далеко не все отдают верстку и дизайн профессионалам, а у гиковой молодежи все новое — хорошее, все старое — плохое.
Со времен оконного интерфейса парадигма пользовательского интерфейса не изменилась, немного добавилась адаптивонсть и динамичность. Возможно такие даже и не представляют, что с UI можно работать только на клавиатуре, при чем достаточно быстро, да останется Tab+(shift/ctrl) во веки веков.
На хабре при переходе tab'ом на кнопки сохранить фокус не показывается :(, но по space срабатывают

Вот это у граждан пригорело))
Автору огромное спасибо за анализ фич, очень интересно.
Есть ощущение что микрософт наняла каких-то джунов наркоманов для которых нефункциональный, но яркий UI дизайн, как вход в казино или дизайн сайта новичками из 90х.
Я уже перестал привыкать к продуктам и их фичам. Потому что мало кто развивает продукт эволюционным способом. То ко революция только новые технологии и все такое хипстерскрое, никто не думает об эргономике: хоткеи и (шрифт+)таб позволяют делать вещи мгновенно.
Большинство таких ux забывает о целевой функции приложения.
Добавь в qip групповые чаты/звонки и распределенность, написать нативные клиенты и будет всё в шоколаде.
Начиная с конца 90 функции общения не изменились, а клиентов просто вагон.
У нас корпоративный чат slack based, тоже та ещё поделка.

Не будет проектами черт с ним, будет что-то другое.
Капиталистический проект нужен и важен только тогда, когда он полезен гражданам государства, а в остальном случае наплевать. Остался на плаву — хорошо, нет — туда ему и дорога.

Так и у других айфонов не было.
И СССР был после войны, а до этого череда гражданских войн и потресений.
Что значит не доставалось?
А поезда, самолёты, учреждения, школы, машиностроение.
Вы думаете вы сейчас будите иметь сильно больше, если перестать продавать нефть?
Что у нас в РФ делают с 0, преимущественно отверточная сборка и использование ископаемых с очень низкой степенью переработки.
Но уже как то вверх и в рост все не идет

Я хочу выпустить скайрим, мне нужно оплачивать труд 90 разработчиков на протяжение 5 лет. Оценка снизу говорит что это порядка 40 млн$. Кто их вернет инвестору?
Выделил жирным и подчеркнул, тот кто брал в долг пусть тот и думает.
Разве они не имеют права ставить свои условия по использованию этого продукта?
Нет конечно, тогда производители авто могут брать деньги за количество поездок, вкл/выкл двигателя итак далее.

Информация

В рейтинге
Не участвует
Зарегистрирован
Активность