Пункты не выносил в корень контекстного меню. Стандартными пользовался всегда. Теми, что вынесены по дефолту по вашем варианту, а теми, что во вложенном меню, две буквы приходилось нажимать.
Вот сейчас TortoiseGit пользуюсь, теперь не очень удобно, потому что две менюшки теперь на букву T стало, а ещё он тормозит чё-то по сравнению с TortoiseSvn.
Можно проще объяснить: программист может написать такой код, который протестировать невозможно или очень тяжело, тогда тестировщик хрен напишет тест к нему и вообще не часто встречаются QA и неплохой программист в одном лице.
Поговаривают, что на микролимитах FL сейчас и так одни боты играют… Так что можно смело искать баги в этих ботах и писать своих, которые будут их обыгрывать :)
Мониторы 16:10 как-то не очень прижились и сейчас их почти нет. Когда себе покупал домой, искал как раз такой, но из того, что было либо очень дорого, либо нет HDMI.
В общем и сейчас выбор минимальный в одном из магазинов:
1920x1080 — 169
1920х1200 — 7
Ну не бывает безвыходных ситуаций. Бывает, что не хватает опыта и квалификации.
Не представляю, что может помешать вынести пару методов из одного класса в отдельный класс и покрыть их тестами. Это конечно всё сильно упрощённо, но так оно мне и представляется на самом деле.
Не должно быть отдельной задачей рефакторинга. Рефакторинг должен протекать одновременно с разработкой.
Не вижу необходимости полгода заниматься тупо рефакторингом. Код работает, вроде даже без ошибок — зачем его трогать? А вот если понадобилось поменять и находим баги или трудно вносить изменения туда, куда нужно — то почему бы не порефакторить? Потратить день-два-неделю, в зависимости от того, сколько нужно изменений внести помимо рефакторинга, но не полгода, занимаясь тупо переписыванием с нуля.
С большой вероятностью при такой организации никто не проверяет зависимость финансовых показателей от качества кода, количества багов и так далее.
Да и мне кажется, что финансовые показатели от этого не сильно зависят на самом деле и не особо нужно их оценивать в зависимости от этого. На мой взгляд, в разработке нужно оценивать зависимость затраченного времени и количества багов от качества и количества написанного кода. В общем, это уже совсем другая стезя, но активно развивающиеся компании должны приходить и к этому, потому что иначе погрязнут в своём коде.
Опять же, есть зависимость от того, B2C или B2B проект. Во случае B2B никуда от этого не деться, потому что сроки/качество/количество поджимают условиями договоров обычно.
Да, в реальности нередко всё не так, как я пишу. И это, конечно, не радует.
Но с другой стороны это говорит о том, что есть куда стремиться.
Вообще, когда такая реальность, что делаем как быстрее, вчерашним числом и задача меняется несколько раз в неделю — на мой взгляд в этом случае в компании плохой менеджмент и организация бизнес-процессов, и, что самое главное, никто и не пытается толком их наладить.
Что для рефакторинга, что для тестов, что для бизнес-процессов, на мой взгляд, прежде всего нужны хорошие руководители, которые могут наладить те процессы, в которых они разбираются понимают, при этом без значительного ущерба для рабочего времени всех сотрудников в целом. То есть, чтобы и проект на месте не стоял, но и чтобы в целом улучшались все протекающие процессы постепенно.
Просмотрел ещё раз 4 свойства юнит-тестов в статье. Ни одно из них не говорит, что юнит-тесты позволяют избежать большего числа ошибок, чем обзоры и инспекции кода.
В общем, не об этом автор хотел нам рассказать.
Не сомневаюсь, что такая проблема бывает довольно часто. Собственно, нужен грамотный подход и хорошая команда, которая может заниматься рефакторингом и покрытием тестами без отрыва от основных задач. Ну и менеджмент соответствующий, который понимает, чем жертвы на рефакторинг и покрытие тестами обернутся в будущем против продолжения развивать проект в том виде, в котором он сейчас есть.
Я бы начал с того, что не писал бы новый код без тестов. А дальше, когда приходится копаться в старом коде, потихоньку переписывать его с тестами. На самом деле, рефакторинг, независимо от того, для покрытия ли кода тестами пишется или просто какой-то говнокод хочется переписать, должен протекать непрерывным процессом сквозь все стадии разработки проекта.
Предположу, что бородатый проект было сложно протестировать, а под внедрением юнит-тестов вы подразумевали именно их написание и регулярный запуск.
Если это так, то внедряли вы их неправильно. Нужно было ещё и рефакторить код таким образом, чтобы он становился тестируемым.
Подмена букв не прокатит? Ну да, чтобы запустить проект не прокатит, а для тестового приложения вполне прокатывает, сам лично создавал. Может уже и поправили конечно, это было полгода назад где-то.
Да напишите уже им по ссылке contact us. Topface в Facebook зааппрувили без проблем.
И, кстати, старинный русский способ подмены латинских букв русскими тоже вполне прокатывает, если уж так хочется вот прямо сейчас создать приложение.
Вот сейчас TortoiseGit пользуюсь, теперь не очень удобно, потому что две менюшки теперь на букву T стало, а ещё он тормозит чё-то по сравнению с TortoiseSvn.
Чтобы заработать на бирже, не нужно покупать биржу.
В любом случае, HDMI втыкается проще, что в монитор, что в ноутбук :)
В общем и сейчас выбор минимальный в одном из магазинов:
1920x1080 — 169
1920х1200 — 7
Не представляю, что может помешать вынести пару методов из одного класса в отдельный класс и покрыть их тестами. Это конечно всё сильно упрощённо, но так оно мне и представляется на самом деле.
Не вижу необходимости полгода заниматься тупо рефакторингом. Код работает, вроде даже без ошибок — зачем его трогать? А вот если понадобилось поменять и находим баги или трудно вносить изменения туда, куда нужно — то почему бы не порефакторить? Потратить день-два-неделю, в зависимости от того, сколько нужно изменений внести помимо рефакторинга, но не полгода, занимаясь тупо переписыванием с нуля.
Да и мне кажется, что финансовые показатели от этого не сильно зависят на самом деле и не особо нужно их оценивать в зависимости от этого. На мой взгляд, в разработке нужно оценивать зависимость затраченного времени и количества багов от качества и количества написанного кода. В общем, это уже совсем другая стезя, но активно развивающиеся компании должны приходить и к этому, потому что иначе погрязнут в своём коде.
Опять же, есть зависимость от того, B2C или B2B проект. Во случае B2B никуда от этого не деться, потому что сроки/качество/количество поджимают условиями договоров обычно.
Но с другой стороны это говорит о том, что есть куда стремиться.
Вообще, когда такая реальность, что делаем как быстрее, вчерашним числом и задача меняется несколько раз в неделю — на мой взгляд в этом случае в компании плохой менеджмент и организация бизнес-процессов, и, что самое главное, никто и не пытается толком их наладить.
Что для рефакторинга, что для тестов, что для бизнес-процессов, на мой взгляд, прежде всего нужны хорошие руководители, которые могут наладить те процессы, в которых они разбираются понимают, при этом без значительного ущерба для рабочего времени всех сотрудников в целом. То есть, чтобы и проект на месте не стоял, но и чтобы в целом улучшались все протекающие процессы постепенно.
Насколько я понял, он как раз мокать ничего не хочет.
В общем, не об этом автор хотел нам рассказать.
Я бы начал с того, что не писал бы новый код без тестов. А дальше, когда приходится копаться в старом коде, потихоньку переписывать его с тестами. На самом деле, рефакторинг, независимо от того, для покрытия ли кода тестами пишется или просто какой-то говнокод хочется переписать, должен протекать непрерывным процессом сквозь все стадии разработки проекта.
Если это так, то внедряли вы их неправильно. Нужно было ещё и рефакторить код таким образом, чтобы он становился тестируемым.
И, кстати, старинный русский способ подмены латинских букв русскими тоже вполне прокатывает, если уж так хочется вот прямо сейчас создать приложение.