Люди, а как вы выбираете количество unittest’ов, которое писать?
С одной стороны, вроде чем лучше покрытие — тем лучше. С другой стороны unitTest’ы — это тоже код, который при изменении основного кода нужно поддерживать.
Опять же, для небольшого классика на несколько килобайт кода, зачастую можно наколбасить кучу тестов, которые будут проверять кучу разнообразных граничных условий.
Собственно говоря, как вы выбираете, когда остановиться?
Недавно у меня появилась идея небольшого проектика. Так ничего особенного, можно сказать забава с какими-то минимальными возможностями вдалеке. Для проектика нужен небольшой сайт… ну скажем 3-5 страничек, точное количество пока не совсем понятно, но что-то в этом диапазоне. Ну и какой-то не сложный дизайн.
Подумал и решил выдать это дело на RentACoder. Выложил и получил эдак 30 bid’ов и немножко был поражен. Начинаются bid’ы от $400 и заканчиваются $3k.
Те кто были на нижней стороне диапазона имеют либо достаточно фиговые отзывы, либо не имеют их вообще. По моему опыту заказывать у них — это выстрел себе в ногу. Боли много, толку мало.
ok. Смотрим на тех, кто может сделать это профессионально и достаточно хорошо (люди, которые имеют достаточно много отзывов и уже работали над такими же проектами). Ух… $1.5-$3K. Мдя… Я конечно хочу этот проектик, но если вдуматься то, я в результате получу просто сайт, который нужно еще раскручивать и т.п. Собственно, я получу очень небольшую кучку кода и дизайн, взамен я должен отдать эквивалент, скажем недельной поездки с женой на Гаваи.
Я вполне понимаю, что скажем для Москвы $500 — это уже не деньги. И ясно, что человеку там для хорошей жизни нужно делать уже некоторое количество таких проектов. Однако, RentACoder сайт всемирный и Вася Пупкин живущий где-нибудь в небольшом городке в Малазии, зарабатывая $1000 в месяц будет чувствовать себя местным королем.
В целом, чувствуется некая взвинченность нижнего ценового диапазона. Кстати, я вполне осознаю, что при этом есть задавленность вниз среднего ценного диапазона (на большинство средних проектов идет дикая конкуренция).
В целом, пока проектик лежит на полке. Делать его самому мне совсем сейчас не светит, времени мало и веб опыт достаточно ограниченный, поэтому осознаю, что убью времени гораздо больше, чем хотелось бы.
Один из читателей блога задал вопрос:
Как лучше всего распределять время и рабочий график программиста?
Я это спрашиваю в связи с тем, что в последнее время стал замечать, что совершенно не могу работать в офисе. Меня эта обстановка сковывает и я целый день занимаюсь фигнёй и ковыряюсь в интернете. Но совершенно по-другому обстановка выглядит дома. Тут я могу сосредоточенно думать, могу писать код по 4-5 часов подряд. И всегда, самые интересные мысли приходят когда я занимаюсь совершенно посторонними вещами.
В общем, если предоставить мне некую свободу, мне кажется я принесу больше пользы компании, потому что смогу больше думать и больше создавать, не находясь в рамках офисной обстановки.
Не уверен, но думаю не у одного меня такое ощущение: приходишь на работу работать, потому что это надо не тебе, а директору. Хотя хочется приходить на работу творить и создавать новое, ради удовольствия.
Как я понимаю, под «распределять время/рабочий график» имелось в виду «когда, где и как» работать.
Разобью вопрос на несколько частей.
1) Есть ли единый (и самый лучший) метод работы, который подойдет всем?
2) Какие методы хороши для каких видов работы?
3) Куда послать директора или что нужно фирме?
4) Творить или не творить?
Итак пойдем по пунктам.
1) Есть ли единый (и самый лучший) метод работы, который подойдет всем?
Бьюсь об заклад, это будет единственный вопрос, по которому все сойдутся в мнениях. Единственного и правильного решения не существует. Один человек «сова» и ему хорошо работать вечером, другой «жаворонок» и ему хорошо работать утром. Кто-то быстрее заныривает в работу, а кто-то буквально из-за мелкого внешнего раздражителя выпадает и долго не может сосредоточиться.
Так, что скорее важно разобраться какой метод работы подходит лучше для вас. Что подводить нас к второму пункту.
2) Какие методы хороши для каких видов работы?
Я бы сказал, что есть два типа программистской работы: требующая концентрации и требующая коммуникации. Решение сложный задач, добавление большего количество «мяса» на скелет, отладка — требует концентрации. Создание архитектуры, работа с QC, интеграция, планирование требует коммуникации.
Ну и логично, что в зависимости от того, что вы делаете (в основном и прямо сейчас) гораздо выгоднее быть либо в тихом закрытом помещении (офисе, домашней обстановке) или в комнате где сидят другие люди с которыми вам нужно общаться.
3) Куда послать директора или что нужно фирме?
Если вы работаете в обстановке, которая не подходит для вашего типа деятельности, то это может обозначать несколько вещей
Категория недопонимание:
— вы делаете не тот тип деятельности который от вас на самом деле от вас ожидали (например, вы — team lead и должны со всеми общаться, а вы хотите на неделю запереться дома и активно педалить код)
— просто ваше начальство не осознает, что вы могли бы быть более продуктивным работая по другому.
Тут, все просто. Вы идете и в спокойной обстановке обсуждаете, как сделать так, чтобы и вы и фирма выиграли (вы получили более подходящий метод работы. фирма получила более эффективного программиста).
Категория несоответствие:
— вы осознаете, что от вас хотят (например сосредоточение на коде), но вы хотите совсем другого (team leader’ство с постепенным переходом в менеджеры)
— вашей компании может не быть прямой выгоды от того, что вы работаете эффективно (например для тех компаний которые берут внешние проекты c time&material оплатой, может складываться ситуации, когда выгодно чтобы программист делал как можно дольше (естественно удерживая это ниже уровня, когда заказчик уйдет)
Это уже слегка похуже. Но, в целом, опять же, можно пойти к начальству и попытаться найти какое-то разумное решение. Хотя тут оно уже не всегда возможно.
Категория конфликт:
— вы и компания хотите чего-то одного (например эффективности), а ваш прямой начальник хочет чего-то совсем другого (минимального напряжения на работе, при игнорировании целей фирмы).
В общем решать такую ситуацию, что плевать против ветра. Силы уйдет много, а результат будет один — сами себя оплюете. Я бы рекомендовал вместе вложения сил в военные действия внутри фирмы, спокойно разослать ваше резюме и найти другое место работы.
Кстати, еще одно замечание по поводу сосредоточения. Я сам по себе знаю, частенько начинаешь копаться в инете, когда просто не хочется за что-то браться. В таком случае, лучше себя заставить из зачастую быстрее сделать не слишком вкусную задачу, чем пол дня мусолить и откладывать ее.
— Неправильное разделение на классы (в одни запихнуто куча разного, в других одна функция, которую можно было присоединить к другому классу)
— Отсутствие комментариев
— Гигантские функции на 20 экранов
— Куча глобальных и статических переменных
— Отсутствие разумных интерфейсов и всяческое другое притеснение encapsulation
— Исходные файл в многие тысячи строк и сотни килобайт
Ух… поубивал бы…
P.S. Я еще забыл — отсутствие единообразия по любому выбранному критерию и дублирование (хотя иногда оно три- или четверолирование) кода.
