Comments 201
Спасибо за конспект и поздравляю с днем рождения, всего наилучшего. Глядя на картинки задумался о дополнительном объеме работ для наполнения статьи. Успехов в работе.
UFO just landed and posted this here
Видимо, графомания.
Чтобы написать самому такой объём, нужно знать и уметь очень много. Принцип качественной статьи: «Своди страницу в абзац, а абзац — в предложение!». Но знаний не хватает, а писать хочется.
Опять же, можно пообсуждать какие-то тезисы, а в случае чего — сослаться на авторитет.
Да и времени для написания статьи требуется меньше. Сочинение пишется дольше изложения.
Чтобы написать самому такой объём, нужно знать и уметь очень много. Принцип качественной статьи: «Своди страницу в абзац, а абзац — в предложение!». Но знаний не хватает, а писать хочется.
Опять же, можно пообсуждать какие-то тезисы, а в случае чего — сослаться на авторитет.
Да и времени для написания статьи требуется меньше. Сочинение пишется дольше изложения.
Поздравляю автора с днем рождения и спасибо за статью.
Я не стал бы так судить о человеке. Не стоит забывать что вы смотрите на всех через призму своего восприятия людей. А в отношении себя могу сказать что мне было интересно прочитать эту выжимку из книги и мне не понадобилось выделять на это много времени. А с временем у меня уже давно проблемы и насобирался большой список того что нужно прочитать, изучить, попробовать. Теперь я могу судить о книге и понять хочу ли я ее прочитать и какой приоритет.
Зона потока — зло.
Странно, свой лучший код я написал именно в «зоне потока», я его называю состояние драйва или «поймал волну». Видимо, потому что такое состояние появляется, когда у тебя в голове сложился весь пазл, ты имеешь полную картинку и превращаешь её в код и самое главное — никто не отвлекает.
Я думаю, что, в большинстве своем, пункты про зону потока и ночное программирование, это весьма индивидуальные вещи. Это чес всех под одну гребенку.
Но, в целом, статья очень годная.
Автору душевное спасибо, а так же легкой сдачи заказов и проектов, с днем рождения:)
Но, в целом, статья очень годная.
Автору душевное спасибо, а так же легкой сдачи заказов и проектов, с днем рождения:)
Хм, а я вот с автором согласен. Пару раз написал «в потоке» код, порядка 2000 строк, а через неделю на него стыдно смотреть было. Хорошо, что это был одноразовый отчёт. То есть, код работал работал без ошибок, но был страшен.
Так отрефакторить после никто не мешает, не спеша по уже рабочему коду.
Просто в такие моменты получается находить решения сложных проблем или увязывать между собой кусочки масштабной системы. И тут поток дает отличный результат.
Вообще такое состояние я отношу к «удержанию абстракций повышенной сложности», т.е. в обычном написании программы, программист удерживает в голове одну или несколько абстракций и перекладывает их на пишущийся код. А в моменты просветления сложность удерживаемой абстракции увеличивается. Где-то даже статья была про это, как бы не на хабре…
Просто в такие моменты получается находить решения сложных проблем или увязывать между собой кусочки масштабной системы. И тут поток дает отличный результат.
Вообще такое состояние я отношу к «удержанию абстракций повышенной сложности», т.е. в обычном написании программы, программист удерживает в голове одну или несколько абстракций и перекладывает их на пишущийся код. А в моменты просветления сложность удерживаемой абстракции увеличивается. Где-то даже статья была про это, как бы не на хабре…
Проблема с «Зоной потока» в том, что
1. У вас отсуствует в этот период адекватный фидбек. Программист, можно сказать, становится зашорен и мчится напролом к созданию той картины, которую он нарисовал в своей голове. Это полностью противоречит идее agile разработки, которая предполагает, что вы двигаетесь в работе короткими циклами, постоянно оглядываясь назад и по сторонам чтобы вовремя заметить, что вы свернули где-то не туда.
Опять же, когда человек вдруг вытаскивают из зоны (что обязательно случается рано или поздно) это вызывает у него фрустрацию, а потом еще время на попытки опять в эту зону попасть.
2. Люди, входящие в «зону» становятся трудно достижимыми для их сокомандников. Создание программного продукта это стройка, а не марафон; тут важна возможность быстро обсудить что-то с коллегой, сделать ревью кода, показать прототип и т.п.
1. У вас отсуствует в этот период адекватный фидбек. Программист, можно сказать, становится зашорен и мчится напролом к созданию той картины, которую он нарисовал в своей голове. Это полностью противоречит идее agile разработки, которая предполагает, что вы двигаетесь в работе короткими циклами, постоянно оглядываясь назад и по сторонам чтобы вовремя заметить, что вы свернули где-то не туда.
Опять же, когда человек вдруг вытаскивают из зоны (что обязательно случается рано или поздно) это вызывает у него фрустрацию, а потом еще время на попытки опять в эту зону попасть.
2. Люди, входящие в «зону» становятся трудно достижимыми для их сокомандников. Создание программного продукта это стройка, а не марафон; тут важна возможность быстро обсудить что-то с коллегой, сделать ревью кода, показать прототип и т.п.
1. а причем здесь agile? Вы путаете теплое с мягким, не конечно вы можете программировать во главе с Грефом по agile, но кто сказал что нельзя пользоваться потоком? Меня всегда напрягают проповедники и их последователи своей безапелляционностью и неприятием всего отличающегося от их веры.
2. А зачем мне сокомандники, я спокойно обхожусь без них в течении дня. Поток у меня длится час-два и этого обычно хватает на решение какой-то проблемы. В результате, по вашим словам, у меня складывается ощущение, что вы каждые полчаса устраиваете митинг, чтобы обменяться мнениями. Но это же говорит о слабости членов вашей команды и слабой проработке архитектуры создаваемой системы :)
2. А зачем мне сокомандники, я спокойно обхожусь без них в течении дня. Поток у меня длится час-два и этого обычно хватает на решение какой-то проблемы. В результате, по вашим словам, у меня складывается ощущение, что вы каждые полчаса устраиваете митинг, чтобы обменяться мнениями. Но это же говорит о слабости членов вашей команды и слабой проработке архитектуры создаваемой системы :)
Не спора ради, т.к. каждый волен сам определять комфортный способ работы, а чтобы прояснить мою позицию:
Agile в данном контексте это не какой-то там SCRUM, а именно сам подход к работке, подразумевающий, что работа бъется на короткие циклы (вплоть до 5 минут). При таком подходе ваш фокус не распыляется, и каждый N минут у вас есть какой-то законченый кусок работы (метод, класс или еще что-то).
По поводу сокомандников тут я вижу проблему в том, что если каждый сидит в зоне потока, то, во-первых, коллеги боятся лишний раз посоветоваться друг с другом, т.к. любой из них может находиться в потоке, а во-вторых, потоки разных людей не синхронизированы, т.е. найти время, когда все члены команды вне потока чтобы провести митинг становится сложно. Имхо, такая ситуация не способствует атмосфере взаимопомощи и командной работы.
Agile в данном контексте это не какой-то там SCRUM, а именно сам подход к работке, подразумевающий, что работа бъется на короткие циклы (вплоть до 5 минут). При таком подходе ваш фокус не распыляется, и каждый N минут у вас есть какой-то законченый кусок работы (метод, класс или еще что-то).
По поводу сокомандников тут я вижу проблему в том, что если каждый сидит в зоне потока, то, во-первых, коллеги боятся лишний раз посоветоваться друг с другом, т.к. любой из них может находиться в потоке, а во-вторых, потоки разных людей не синхронизированы, т.е. найти время, когда все члены команды вне потока чтобы провести митинг становится сложно. Имхо, такая ситуация не способствует атмосфере взаимопомощи и командной работы.
UFO just landed and posted this here
Вы переходите в другую крайность — неужели вы думаете что всегда работаю в потоке? Нет конечно. Но в любом случае, когда отвлекают от программирования или обдумывания — я этого сильно не люблю, а если еще и каждые 5 минут… такое случается только со студентами, но и на них есть управа :)
Agile в данном контексте это не какой-то там SCRUM, а именно сам подход к работке, подразумевающий, что работа бъется на короткие циклы (вплоть до 5 минут). При таком подходе ваш фокус не распыляется, и каждый N минут у вас есть какой-то законченый кусок работы (метод, класс или еще что-то).
Но при таком подходе вы не увидите/не прогнозируете ни средне-, ни долгосрочную линию работы.
Да и насчет ближней — тоже вопрос.
Давно предполагаю, что фанатичное следование Scrum/Agile зачастую говорит о синдроме дефицита внимания, о неспособности сконцентрироваться хотя бы на пару часов, чтобы рассмотреть задачу в целом.
В рамках Scrum долгосрочное планирование осуществляется с помощью бэклога, среднесрочное в рамках спринта, а краткосрочное в рамках ежедневных пятиминуток. В общем и в целом планированию выделяется достаточно времени, на проектах длиною год и более в итоге может получиться даже больше чем на таком проекте по водопаду.
На бумаге все хорошо,
но практике программисты не видят ничего кроме пятиминуток.
Получается mushroom management с быстрыми короткими движениями между скрамами.
Даже если и видна стратегическая перспектива, то результат, который можно пощупать, нужно показывать к следующему ежедневному скраму, соответственно, работа на перспективу, даже относительно ближайшую, программистами не ведется.
Ну а если при этом еще и времени на планирование выделяется больше, чем по водопаду…
но практике программисты не видят ничего кроме пятиминуток.
Получается mushroom management с быстрыми короткими движениями между скрамами.
Даже если и видна стратегическая перспектива, то результат, который можно пощупать, нужно показывать к следующему ежедневному скраму, соответственно, работа на перспективу, даже относительно ближайшую, программистами не ведется.
Ну а если при этом еще и времени на планирование выделяется больше, чем по водопаду…
Возможно это индивидуально. Но по опыту вижу что человек работал в потоке, когда коммитет больше 10 файлов за раз (бывает и по 50), а в сообщении коммита не способен нормально описать чем занимался. Обычно такой код проскакиевает код ревью. Но в дальнейшем возникают проблемы с его поддержкой. Так называемая "стрельба дробью". Когда для внесения небольших изменений, в результате неявных зависимостей, нужно перелопачивать все эти файлы.
За годы работы заметил такой прикол: чем меньше проект, над которым работаешь, тем эффективнее «зона потока». И наоборот, в больших проектах «зона потока» часто создает большое количество трудноуловимых ошибок.
П.с. по крайней мере, со мной так :)
П.с. по крайней мере, со мной так :)
Видимо, это связано с тем, что для того, чтобы поддерживать код, написанный в состоянии волне, нужно снова входить в это состояние.
и самое главное — никто не отвлекает.
Может, ключевой момент в том, что никто не отвлекает? Получается, что у вас Зона, наверняка, ночью. Верно же?
Сам регулярно «ловил волну». Могу сказать, что иногда намного полезнее остановиться и подумать что и зачем я делаю и нет ли способа лучше. Были ситуации, когда «на гребне волны» писались не оптимальные алгоритмы или принятые решения уходили далеко от поставленной задачи.
Потому что «зона потока» — не зло. Более того это чуть ли не единственная причина, по которой мы становимся программистами и по-настоящему любим свою работу.
Хороший программист в состоянии потока остается хорошим программистом, плохой — плохим.
В который раз к утверждению про «поток зло» напоминаю про книжку: Михай Чиксентмихайи, «Поток».
Хороший программист в состоянии потока остается хорошим программистом, плохой — плохим.
В который раз к утверждению про «поток зло» напоминаю про книжку: Михай Чиксентмихайи, «Поток».
А у Спольски, тоже широко популярного у узких кругах, можно было прочитать, что зона потока это добро, и что программистов нельзя отвлекать, и им друг друга тоже нельзя отвлекать, т.к. даже самый простой вопрос соседа «как сделать то или это» выбивает того из зоны потока на 15 минут.
И кому верить? — Фаулер вот тоже авторитет.
Я к чему — ну немного… надоели все эти менеджерские техники и фанатичное им следование или их пропагандирование.
Может быть, лучше учить языки, библиотеки, принципы проектирования, учиться разбивать задачи на интересные подзадачи, и весь такой прочий технический олдскул, а не надеяться на некие техники как культ карго.
И кому верить? — Фаулер вот тоже авторитет.
Я к чему — ну немного… надоели все эти менеджерские техники и фанатичное им следование или их пропагандирование.
Может быть, лучше учить языки, библиотеки, принципы проектирования, учиться разбивать задачи на интересные подзадачи, и весь такой прочий технический олдскул, а не надеяться на некие техники как культ карго.
Ну во первых с Днем рождения! :)
Желаю счастья, здоровья и всего всего чего душа пожелает :)
Что то многовато программистов в эти дни родилось, особенно если начать с прекрасной Ады ;)
По всем выше перечисленным пунктам можно полностью согласится, хотя в каждом случае бывают исключения.
Например на счет «нет», вроде думаешь что нет, не справишься, а начал схватил «волну» и в срок успел и глазу приятно :)
НО опять все это исключения, жизнь слишком многогранна что бы могла уместится в простые рамки :)
Желаю счастья, здоровья и всего всего чего душа пожелает :)
Что то многовато программистов в эти дни родилось, особенно если начать с прекрасной Ады ;)
По всем выше перечисленным пунктам можно полностью согласится, хотя в каждом случае бывают исключения.
Например на счет «нет», вроде думаешь что нет, не справишься, а начал схватил «волну» и в срок успел и глазу приятно :)
НО опять все это исключения, жизнь слишком многогранна что бы могла уместится в простые рамки :)
Может быть ничего нового статья, как таковая, не несет, и кто-то скажет, что «это все обман, чтобы набрать классы», но на мой взгляд лучше лишний раз напомнить о подобных книгах, пусть это и приводит к дублированию. Лично видел, как труды Мартина переворачивали сознание людей. С днем рождения! :)
Проверяется просто: попробуйте внести изменения в ваш код. Если это вызовет боль чуть ниже пояса, — значитЗначит стоит попробовать руками :Dс гибкостью у вас всё плохо.
Если же вы профессионал, — это ваша обязанность. Когда руководитель ставит нереальный срок, ваша обязанность сказать «нет». Если вам предлагают быстрое, но архитектурно слабое решение, ваша обязанность сказать «нет». Когда вам предлагают работать по ночам, ваша обязанность сказать «нет».
Вы уволены… :-)
Вы уволены… :-)
и чего минусанули nckma? Мне руководитель так и сказал: «Нам надо выпускать продукт, а не всякой красотой заниматься». Да, он — быдлокодер и плевал он на C++11, шаблоны проектирования и прочее. Но быстро сменить работу не всегда получается, чтобы с такими особями не общаться
он — быдлокодер и плевал он на C++11, шаблоны проектирования и прочее
Костыльный программист :)
Проблема в том, что желание спроектировать красивую архитектуру часто перерастает в оверинжиниринг. Необузданный перфекционизм — вообще бич воодушевленных (passionate) программистов. Вполне естественно в таких случаях желание руководителей не допускать такого развития событий, но почти всегда это приводит к противоположной крайности.
Чаще всего, это не оверинжениринг, а желание сделать просто хорошо. Не идеально, не супероптимально.
Просто хорошо.
Которое другие тут же закидывают лозунгами типа «идеальная архитектура», «оверинжениринг» и т.д. и т.п.
Как результат эти закидыватели выглядят, в глазах руководства, как «прагматичные» разработчики «ориетированные на бизнес». Они попадают в лиды и говноподходы продолжают культивироваться.
Итог — имеем то, что имеем…
Просто хорошо.
Которое другие тут же закидывают лозунгами типа «идеальная архитектура», «оверинжениринг» и т.д. и т.п.
Как результат эти закидыватели выглядят, в глазах руководства, как «прагматичные» разработчики «ориетированные на бизнес». Они попадают в лиды и говноподходы продолжают культивироваться.
Итог — имеем то, что имеем…
UFO just landed and posted this here
Тут есть большая разница. "архитектурно слабое решение" нормальное, если у вас не будет необходимости потом бороться с недостатками. Например нам нужно сделать что-то за 2 дня. И мы можем сделать это что-то за два дня, но есть еще нефункциональные требования, нагрузки, безопасность… Мы понимаем что решение, с которым мы можем успеть несет в себе огромные риски. А потому лучше сказать нет, ибо на самом деле эта реализация сродни ложному обещанию: Мы как бы все сделали, но потом придется переделывать. Причем как правило клиент будет больше расстроен тем, что его вовремя не предупредили о рисках.
Другой пример. Попросили вас сделать что-то, что будет использоваться лишь раз. Например — импорт данных из одной системы в другую. Эта операция будет происходить ровно один раз. И объем данных известен. Но разработчик хочет сделать правильно, пишет отдельный компонент, который использует какой-нибудь потоковый парсер, импорт по частям, заботится о производительности решения и т.д. Словом, делает "правильно" и тратит на эту одноразовую штуку в 3 раза больше времени.
То есть по сути, разработчик всегда должен понимать зачем он что делает, и исходя из этого уже оценивать плюсы/минусы принимаемых решений и искать наиболее эффективный вариант.
Ну и слава богу! Валить надо как можно скорее из такой компании, где за выражение экспертного мнения указывают на дверь.
Возможно в больших городах с этим проще. В маленьком городе просто некуда бежать…
Вы уволены… :-)
Пожалуй, для каких-то работодателей может случиться и так. Но часто такая позиция вызывает уважение. Чуть подробнее в комменте ниже.
По-моему, нужно оставаться честным с самим собой. Оставаться честным с командой. Это касается как и сроков, объемов и трудности задач. Сколько было случаев, когда заведомо занижали эстимейты, озвучивали их команде, а в процессе работы чувствовали угрызения совести и в итоге срыв срока сдачи, потеря контроля и ссоры в команде. Научиться не бояться говорить правду, говорить что это займет больше времени, во время работы сообщать что первоначальная оценка оказалась неверной.
Спасибо за статью. С днем рождения!
Спасибо за статью. С днем рождения!
Да! Очень, прям, точно вы сформулировали мысль. Если мы будем поступать по совести, то всё будет хорошо и у нас, и у заказчика.
Конкретно у меня очень странная проблема.
Я считаю, что поставленные задачи невозможно выполнить качественно и в срок. Многие коллеги «в курилке» согласны со мной. Однако на совещаниях я остаюсь в одиночестве и только я говорю, что все плохо со сроками и плохо с архитектурой. Остальные продолжают уверять менеджмент, что все отлично и все можно сделать.
Получается, что я один и есть «хромая утка», которая постоянно говорит неприятности.
Не очень весело. Для себя решил, пожалуй лучше больше молчать и больше соглашаться.
Я считаю, что поставленные задачи невозможно выполнить качественно и в срок. Многие коллеги «в курилке» согласны со мной. Однако на совещаниях я остаюсь в одиночестве и только я говорю, что все плохо со сроками и плохо с архитектурой. Остальные продолжают уверять менеджмент, что все отлично и все можно сделать.
Получается, что я один и есть «хромая утка», которая постоянно говорит неприятности.
Не очень весело. Для себя решил, пожалуй лучше больше молчать и больше соглашаться.
С днем рождения)
Вот вопрос с зоной потока мне действительно показался спорным… Я наоборот в таком случае облачаюсь в наушники, ставлю телефон на dnd и пишу, пишу, пишу… А на следующий день или через некоторое время делаю ревью с рефакторингом и переписываю какие-то вещи.
Когда читаю очередную статью про полезные советы Мартина (или советы по мотивам его книг), каждый раз хочется прокричать — «Только не забывайте включать критическое мышление!». Сегодня видимо критическая масса накопилась :)
Стоит ли совет про скромность и непогрешимость применять к самому Мартину — решайте сами. Давайте парочку других моментов разберём.
«Зона потока — зло». То есть, предлагается делать себя менее счастливым (подробности есть в книге Поток, и да, расшифровка термина у авторов может чуть отличаться, но база общая). Нет, спасибо. Не знаю как у всех, лично мной в состоянии потока реализовано много красивых идей. То, что потом ревью кода стоит сделать — это не вопрос :)
«Понимают интересы работодателя и заказчика.» vs. «Говорите «Нет»».
Оба пункта горячо поддерживаю. Но предлагаемые варианты как говорить «нет» не показывают понимания интересов.
В этом разговоре накосячили оба участника (можно спорить кто больше). Если ко мне, как к разработчику, придут с задачей и сроками, которые плохо сосуществуют в одной вселенной, я буду разбираться, как можно что-то в них скорректировать. Если я как менеджер приду к разработчику с такой задачей, я объясню цели показа в пятницу — может, в итоге, нужно показать только визуальную часть или вполне подойдёт реализация только типичного сценария.
Вообще говоря, я не люблю слово «невозможно», особенно, когда его говорят сразу после того, как услышали название задачи. Даже для NP-полных задач :) Ведь если разобраться в том, что действительно необходимо сделать, может оказаться, что алгоритм всегда будет работать на малом объёме данных или вполне устраивает приблизительное решение.
P.S. Про «Код должен быть покрыт тестами на 100%» не буду особо комментировать. Надеюсь, все понимают, что 100% покрытие не гарантирует корректность кода.
Стоит ли совет про скромность и непогрешимость применять к самому Мартину — решайте сами. Давайте парочку других моментов разберём.
«Зона потока — зло». То есть, предлагается делать себя менее счастливым (подробности есть в книге Поток, и да, расшифровка термина у авторов может чуть отличаться, но база общая). Нет, спасибо. Не знаю как у всех, лично мной в состоянии потока реализовано много красивых идей. То, что потом ревью кода стоит сделать — это не вопрос :)
«Понимают интересы работодателя и заказчика.» vs. «Говорите «Нет»».
Оба пункта горячо поддерживаю. Но предлагаемые варианты как говорить «нет» не показывают понимания интересов.
— Это невозможно, на разработку и отладку поиска нужно две недели.
— Нам нужно показать клиенту в пятницу. Давай постараемся.
В этом разговоре накосячили оба участника (можно спорить кто больше). Если ко мне, как к разработчику, придут с задачей и сроками, которые плохо сосуществуют в одной вселенной, я буду разбираться, как можно что-то в них скорректировать. Если я как менеджер приду к разработчику с такой задачей, я объясню цели показа в пятницу — может, в итоге, нужно показать только визуальную часть или вполне подойдёт реализация только типичного сценария.
Вообще говоря, я не люблю слово «невозможно», особенно, когда его говорят сразу после того, как услышали название задачи. Даже для NP-полных задач :) Ведь если разобраться в том, что действительно необходимо сделать, может оказаться, что алгоритм всегда будет работать на малом объёме данных или вполне устраивает приблизительное решение.
P.S. Про «Код должен быть покрыт тестами на 100%» не буду особо комментировать. Надеюсь, все понимают, что 100% покрытие не гарантирует корректность кода.
UFO just landed and posted this here
Фаулер про покрытие тестами: http://martinfowler.com/bliki/TestCoverage.html
Если вы тестируете осознанно и качественно, можно ожидать покрытия в районе 90%. В то же время, покрытие 100% выглядит подозрительно — выглядит так, будто кто-то специально пишет тесты таким образом, чтобы получить высокий процент покрытия, но не задумываясь о том, что он делает.
(If you are testing thoughtfully and well, I would expect a coverage percentage in the upper 80s or 90s. I would be suspicious of anything like 100% — it would smell of someone writing tests to make the coverage numbers happy, but not thinking about what they are doing.)
Так в чем же ценность анализа покрытия кода тестами? Это просто помогает определить, какие части вашего кода не протестированы.
So what is the value of coverage analysis again? Well it helps you find which bits of your code aren't being tested
Шикарная статья, спасибо! С, с днём рождения :) Многих счастий и малых багов :)
Насколько красиво написано, настолько же далеко от суровой реальности, если только ты не работаешь в компании уровня гугла или мс. Больше 10 лет кручусь по фирмам-стартапам, где обычно есть только директор/основатель/маркетолог/гуманитарий, придумывающий как поднять бабла, и понимающий, что это нужно было еще «вчера». А дальше они нанимают «компьютерного грамотея», который делает «всё» (включая даже закупки и установку оборудования на места, если таковое будет использоваться плюс сидение на техподдержке). Работа 24/7/365. Какое ТДД, какой контроль качества? Забилдилось? ура, заливаем в продакшен, а жизнь сама отбракует неудачные решения.
Конечно, я не фанат таких условий, но я и сам не вижу альтернатив, как небольшим компаниям в условиях тотальной экономии бюджета пытаться что-то вывести на рынок, когда они даже не знают примет ли народ их решение.
Конечно, я не фанат таких условий, но я и сам не вижу альтернатив, как небольшим компаниям в условиях тотальной экономии бюджета пытаться что-то вывести на рынок, когда они даже не знают примет ли народ их решение.
я к тому, что в большинстве случаев (согласно принципу, что 20% времени/усилий дают 80% качества) рациональней сделать 5 разных вещей, и, возможно, одна из них стрельнет, чем до посинения доводить до идеала код и отлаживать процесс разработки, думая, что проект не взлетает только из-за багов, а не просто потому что он никому не нужен.
Вася и Петя одновременно начали писать один и тот же продукт.
Вася был «ориентирован на результат» и начал сразу писать говнокод не продумав толком архитектуру.
А Петя месяц разрабатывал архитектуру, месяц делал удобный интуитивный интерфейс, которому позавидывал бы Джони Айв, потом месяц писал тесты, потом два месяца писал сам код и получил идеальное стабильное приложение.
Но Вася выпустил уже через месяц первую версию программы, пусть и не идеальную, пусть с багами, но рабочую, и начал её продавать. Ещё через месяц выпустил вторую версию исправляющие баги первой и добавляющие новые баги. Ещё через месяц на доходы от продаж нанял двух толковых программеров, которые за два месяца перелопатили весь код, согласно пожеланиям пользователей допилили интерфейс и выпустили третью версию программы.
Итого, через пять месяцев у Васи было два работника, куча клиентов и сносно работающее приложение отвечающее желаниям клиентов.
У Пети было вылизанное никому не известное приложение, минус на банковском счёте и ни одного клиента.
В завершение этого выдуманного примера можно сказать, что через полгода Вася купил все наработки Пети, Петю взял в штат тестировщиком, а сам по пьяни разбился на своём новеньком Туареге (с) баш
Жёсткая правда. Малодушие до сих пор мешает иногда говорить нет.
Зона потока для меня — это спокойная, почти не отвлекающая музыка, либо её отсутствие и почти полная тишина в студии, при этом я сконцентрирован и все получается хорошо.
С днём рождения! :) Интересно будет прочесть эту книгу.
Зона потока для меня — это спокойная, почти не отвлекающая музыка, либо её отсутствие и почти полная тишина в студии, при этом я сконцентрирован и все получается хорошо.
С днём рождения! :) Интересно будет прочесть эту книгу.
UFO just landed and posted this here
А мне кажется, нет ничего здоровее, чем заранее продуманный режим дня. Встал, принял душ, выпил два стакана воды и за книжки. Ну, или в другое запланированное вами заранее время. Важно выделять его ежедневно.
Если вы работаете 40 часов в неделю, — запланируйте на работу 60 часов. Из них 40 часов вы потратите на работодателя, а оставшиеся 20 — на самообразование.
плохой совет. Хороший должен быть: если работаешь 40 часов в неделю, планируй на работу 30, а оставшиеся 10 на самообразование, в будущем потенциально связанное с тематикой проекта. Ибо твои новые знания втройне окупятся для фирмы.
А вот читаю, и думаю…
Больно принципы описанные в статье, и, очевидно, в книге, похожи на законы Дхармы. Быть хорошим программистом сложно! Но интересно.
Еще раз с днем рождения!
От кришнаита и программиста.
Больно принципы описанные в статье, и, очевидно, в книге, похожи на законы Дхармы. Быть хорошим программистом сложно! Но интересно.
Еще раз с днем рождения!
От кришнаита и программиста.
С днём рождения бро!
Про говорить «нет» — реально ценно, правда чем больше тебе платят тем сложнее это сказать :)
Про говорить «нет» — реально ценно, правда чем больше тебе платят тем сложнее это сказать :)
Собственный опыт говорит об обратном.
Чем больше тебе платят, тем больше прислушиваются к твоему мнению.
Хотя конечно же всегда есть исключения.
Чем больше тебе платят, тем больше прислушиваются к твоему мнению.
Хотя конечно же всегда есть исключения.
Мне платят за то, что я говорю нет. Реально, это работает: я ж не просто посылаю его в зад и не делаю то, что он просит. На всё есть обоснование, и когда работодатель понимает, что каждый отказ обоснован его же интересами, он начинает уважать.
Недавно клиент просить впилить на карту дополнительные виды флажков. Я говорю «нет», объясняю почему, спрашиваю зачем оно надо и предлагаю альтернативное решение. Все счастливы.
А вот донести до человека свою точку зрения — это целое искусство. Бывает, на одно письмо из четырёх строк уходит полчаса.
Недавно клиент просить впилить на карту дополнительные виды флажков. Я говорю «нет», объясняю почему, спрашиваю зачем оно надо и предлагаю альтернативное решение. Все счастливы.
А вот донести до человека свою точку зрения — это целое искусство. Бывает, на одно письмо из четырёх строк уходит полчаса.
Не всегда есть возможность сказать "нет", когда заказчик требует необходимый функционал в любом виде, пусть даже с помощью костылей.
P.S.: С днем рождения.
В основном согласен, но, к сожалению, бизнес этого не понимает, практически нереально найти работу без плохокода, все бешено набирают технический долг неведомо на что надеясь, а потом когда развитие бизнеса стопорится обвиняют программистов в том, что они мол нифига не делают, хотя они заняты латанием дыр в тонущем проекте и не имея времени отдавать технический долг продолжают усугублять ситуацию.
Очень понравилась эта книга. Интересная.
Прекрасная, полезная и интригующая статья.
Думаю, такая книга будет полезна как начинающим программистам ( каковым являюсь я), так и опытным.
Александр, Поздравляю Вас С Днем Рождения! Здоровья и удачи Вам во всем.
И если Ваше предложение по книге в силе, то: mikemet@yandex.ru
Думаю, такая книга будет полезна как начинающим программистам ( каковым являюсь я), так и опытным.
Александр, Поздравляю Вас С Днем Рождения! Здоровья и удачи Вам во всем.
И если Ваше предложение по книге в силе, то: mikemet@yandex.ru
с Днем рождения))
6. Помогайте и принимайте помощь
Может быть поэтому?!
произведение известное, в рекламе не нуждается
Полагаю так и есть, я слышал о ней, но прочитать руки не доходили. После этого конспекта понял, что книгу всё таки стоит прочитать. Ну и точно есть люди услышавшие о ней в первый раз.
navff с днем рождения )
Этот коммент был ответом на #comment_9957724, но что-то пошло не так.
С днём рождения :)
Владимир, спасибо за статью. Я только вхожу в мир программирования и больше половины написанного тут точно отражают мои «проблемы», которые я считал достоинством (как отказ от помощи, в сторону решения своими силами). Поздравляю Вас с днем рождения! Успехов вам!
интересная статья, спасибо. с днем рождения))
Очень не согласен с пенуктом 2
Таким образом легко впасть в другую крайность. Заболеть оверинжинирингом. Ваши решения будут супер гибкими, но релиз у вас будет раз в два месяца, а у конкурентов два раза в неделю и вы потеряете клиентов.
Имхо в случае с быстрым и архитектурно слабым решением, ненадо говорить «нет». Нужно найти компромис. Возможно для POC нужно сделать именно так, но обязательно договорится о доп. времени на приведение такого кода в порядок в будущем (тут конечно тоже свои ньюансы...)
В целом легко сказать «нет», но это не отличает проффесионала. Это так же идет в разрез с пунктом ниже о понимании бизнеса клиента и работодателя.
Если вам предлагают быстрое, но архитектурно слабое решение, ваша обязанность сказать «нет»
Таким образом легко впасть в другую крайность. Заболеть оверинжинирингом. Ваши решения будут супер гибкими, но релиз у вас будет раз в два месяца, а у конкурентов два раза в неделю и вы потеряете клиентов.
Имхо в случае с быстрым и архитектурно слабым решением, ненадо говорить «нет». Нужно найти компромис. Возможно для POC нужно сделать именно так, но обязательно договорится о доп. времени на приведение такого кода в порядок в будущем (тут конечно тоже свои ньюансы...)
В целом легко сказать «нет», но это не отличает проффесионала. Это так же идет в разрез с пунктом ниже о понимании бизнеса клиента и работодателя.
А разве нельзя сказать «нет» и предложить альтернативу? Или отложить. Или сделать проще.
Наша задача — сделать клиенту хорошо. Если я быстро нахреначу ему копипаста с стэковерфлоу, не поняв, как оно работает, в будущем это обернётся большими проблемами.
А вообще, в книге более подробно расписано про «нет» и статья не отражает всего, что написано в оригинале.
Наша задача — сделать клиенту хорошо. Если я быстро нахреначу ему копипаста с стэковерфлоу, не поняв, как оно работает, в будущем это обернётся большими проблемами.
А вообще, в книге более подробно расписано про «нет» и статья не отражает всего, что написано в оригинале.
Все-же полезно для краткого ознакомления такие статьи. Мне вот интересно. Интересно также и сами мысли после прочтения по поводу книги и около её.
Автора конечно с днюхой.
Отличная статья для начинающих! Спасибо огромное за потраченное время на конспект, с удовольствием буду ждать продолжения. И с Днем Рождения Вас!!! Будьте счастливы, и успеха во всем!
Спасибо за хорошу статью по правильному распредению времени）Это даже касатеся не только программирования, но и другихотраслей в целом. Картинки доставили。 И самое главное~Поздравляю Вас с Днем Рожденья, Счастья, здоровья, творческих успехов, стабильности и процветания！ Пустт все у Вас получится
Я поддерживаю автора статьи, конспекты книг от консультантов очень нужны, так как в них 90% воды, но здравые мысли бывают. Из того, что я читал: "Чистый код", "Рефакторинг", "Шаблоны корпоративных приложений", сейчас больше не вспомню.
Поздравляю с днем рождения. Желаю, чтобы не убавлялись силы и выносливость, чтобы не исчезали желания и мечты. Чтобы не только день рождения, но и каждый последующий день приносили удовлетворение от жизни, вдохновение к свершениям и желание жить, любить, творить.
Конечно есть пункты которые не ко всем подходят, но в целом всё не лишено логики и здравого смысла. Нашёл для себя статью полезной.
Happy birthday . I'll be happy if you send me the book in electrical version:) P.S. I want the book on DC, 12V, 2A. Thanks.
Поздравляю с днём рождения, желаю счастью в личной жизни!
ПУХ… shakandrew
Ну по поводу ночного программирования можно поспорить, уже настолько привык к тому, чтобы кодить ночью, что днём просто нет желания… просто руки не хотят браться за дело.
Так что по-моему это сугубо индивидуальный вопрос.
ПУХ… shakandrew
Ну по поводу ночного программирования можно поспорить, уже настолько привык к тому, чтобы кодить ночью, что днём просто нет желания… просто руки не хотят браться за дело.
Так что по-моему это сугубо индивидуальный вопрос.
А никого в статье не смущает 40 часов работа + 5 часов обед + 20 часов дорога + 5 часов на сборы на работу + 56 часов сна + 20 часов на обучение в неделю = 146 часов в неделю для работы из 168. И идеальный программист оставляет себе только 22 часа в неделю на дела, спорт(активный отдых), семью. Никого не смущает, что идеальный программист должен жить только работой? А такие статьи уничтожают нашу жизнь.
Дык работайте дома. Вы ж программист
На дорогу как-то многовато. Но вообще можно сильно совмещать дорогу и самообразование.
UFO just landed and posted this here
Основной аргумент у меня лично против удаленной работы — недостаточная способность технических средств обеспечить максимально эффективные коммуникации.
UFO just landed and posted this here
Как по мне, то текстовые методы необходимы, прежде всего, для документирования результатов решения проблем, а вот выработка этих решений наиболее эффективна в голосовом режиме как минимум. То есть текстовое общение в крайнем случае, когда нормально возможности обсудить нет. Одна из проблем текстового общения — очень неэффективная модерация совещаний, нет возможности кого-то перебить, пока он полностью свою мысль не изложит.
Например?
Например, углы обзора типичных камер и экранов не обеспечивают нормальной возможности видеть одновременно нескольких участников конференций, с одним-то сложно без специального оборудования. Сложно обеспечить трансляцию процесса рисования схем на бумажке или доске, особенно без ущерба для видеоряда самого рисующего. Звуковые тракты (стандартные микрофон-динамик) не обеспечивают естественную звуковую картину.
Не, возможно, где-то в Гугле или МС обеспечивается практически полный эффект присутствия, но наверняка окупается стоимость оборудования для этого хорошо если для топов.
Не, возможно, где-то в Гугле или МС обеспечивается практически полный эффект присутствия, но наверняка окупается стоимость оборудования для этого хорошо если для топов.
А сон тоже сугубо для работы нужен? Иначе можно было бы обойтись без него?
Отличная статья с хорошими иллюстрациями. Спасибо!
Только слова благодарности за статью! А что касается критики — то никто не идеален :-)
Уже долгое время хочу стать лучше и никак не могу остановиться на этом пути…
Уже долгое время хочу стать лучше и никак не могу остановиться на этом пути…
С Днём Рождения!!!
Спасибо за статью. Поздравляю с днем рожденья! Желаю большИх финансовых инструментов!
С днем рождения. Успехов в работе и жизни. Спасибо за статью!
Пасибо. Норм конспект. Жду продолжения. С днем рождения. Неиссякаемого вдохновения тебе. Моей жене сегодня тоже др.
Как будто мой ПМ писал. Работай больше, проси меньше. Ошибок в коде быть не должно, тестировщики не для этого там сидят. Учись сам, в свободное время, компания не обязана это оплачивать. Проблемы начальства — твои проблемы, твои проблемы — твои проблемы. Ты должен всем, не, серьезно, всем! Тебе никто и ничего.
Этот человек хоть один автотест написал? Он знает на сколько это трудоемкая задача?
Вообщем, Вы извините, но статья жуткая «вода». Местами уровня папблика вконтакте.
Каждый кусок кода должен быть протестирован для всех возможных ситуаций. Если это делать вручную, — у вас не будет времени на разработку
Этот человек хоть один автотест написал? Он знает на сколько это трудоемкая задача?
Вообщем, Вы извините, но статья жуткая «вода». Местами уровня папблика вконтакте.
Ваш ПМ — мудрый человек.
Если бы… И что вообще тут мудрого? То, что программисты должны писать код без ошибок — это вообще наиглупейшая мысль. Человек не может держать в голове все логику среднего+ проекта.
Извиняться перед тестировщиками… Какому мудрецу это вообще могло в голову прийти? Извиняться за то, что нормально? Их профессия, как результат понимания того, что в текущих реалиях без ошибок никак.
Вы же понимаете, что если я до передачи задачи в QA, проверю все возможные тест-кейсы, то после меня эти же кейсы (как минимум) проверят они? Вам не кажется, что это нерационально?
Про стопроцентное покрывание тестами я уже написал, это гиганская работа. По опыту, на написание тестов уходит столько же времения (а то и больше), как на саму фичу.
К тому же, автотесты — не панацея. Как по мне, то они вообще не для этого. Они для того, чтобы программист мог спокойно рефакторить проект. И быстро находить, где и чего он поломал.
Я считаю, мудрый ПМ — это человек, который всегда держит в голове то, что ошибки будут. И выстраивает рабочий процесс, отталкиваясь от этого. Не летает в облаках, не надеется на удачу, не думает, что он сможет заставить программиста писать без ошибок.
Не хочу писать слишком большой комментарий. А так, тут поле не паханное, извините, подобного бреда.
Извиняться перед тестировщиками… Какому мудрецу это вообще могло в голову прийти? Извиняться за то, что нормально? Их профессия, как результат понимания того, что в текущих реалиях без ошибок никак.
Вы же понимаете, что если я до передачи задачи в QA, проверю все возможные тест-кейсы, то после меня эти же кейсы (как минимум) проверят они? Вам не кажется, что это нерационально?
Про стопроцентное покрывание тестами я уже написал, это гиганская работа. По опыту, на написание тестов уходит столько же времения (а то и больше), как на саму фичу.
К тому же, автотесты — не панацея. Как по мне, то они вообще не для этого. Они для того, чтобы программист мог спокойно рефакторить проект. И быстро находить, где и чего он поломал.
Я считаю, мудрый ПМ — это человек, который всегда держит в голове то, что ошибки будут. И выстраивает рабочий процесс, отталкиваясь от этого. Не летает в облаках, не надеется на удачу, не думает, что он сможет заставить программиста писать без ошибок.
Не хочу писать слишком большой комментарий. А так, тут поле не паханное, извините, подобного бреда.
UFO just landed and posted this here
По-моемому, в статье нигде не говориться что ошибок в коде быть не может. Посыл в том, что не стоит отправлять на QA стадию код в котором, очевидно, есть ошибка, в надежде авось проскочит. Так же не стоит отправлять фичу вообще не протестировав ее. Я имею в виду прогнав тот кусок работы, что вы сделали. Вы удивитесь, но есть люди которые как то запилив очередной компонент, даже не попробуют его в работе хотя бы на заведомо валидных сценариях. А QA он действительно для другого, он должен проверить что компонент не обрушил нигде функционал неочевидным образом и проверить на разные edge cases.
А QA он действительно для другого, он должен проверить что компонент не обрушил нигде функционал неочевидным образом и проверить на разные edge cases.
Не согласен. Грубо говоря, за обрушение части функционала неочевидным образом отвечает Quality часть QA, а вот за то, что реализованная часть функционала работает очевидным (описанным в ТЗ и подобных документах) образом отвечает Acceptance часть.
Вы бы лучше книжку почитали, чем столько сил на комменты тратить.
Не нравится ПМ — у нас свободное общество, где можно менять работу. Ошибки в коде будут, но это исключительная ситуация, когда ваш код не прошёл ваш собственный контроль качества. А если вы пишете в надежде на тестировщиков, — значит вы поступаете непрофессионально.
100% покрытие тестами окупится, когда вам нужно будет изменить что-то в системе. Прогнал тесты и увидел, где сломалось. Если тестов нет, с ростом системы будет расти неуверенность в успехе изменений. Так система превратится в склад устаревшего кода.
Не нравится ПМ — у нас свободное общество, где можно менять работу. Ошибки в коде будут, но это исключительная ситуация, когда ваш код не прошёл ваш собственный контроль качества. А если вы пишете в надежде на тестировщиков, — значит вы поступаете непрофессионально.
100% покрытие тестами окупится, когда вам нужно будет изменить что-то в системе. Прогнал тесты и увидел, где сломалось. Если тестов нет, с ростом системы будет расти неуверенность в успехе изменений. Так система превратится в склад устаревшего кода.
Этот человек хоть один автотест написал? Он знает на сколько это трудоемкая задача?
Если вы имеете в виду Роберта Мартина (автора книги), то он написал очень много автотестов, в том числе фреймворк для приемочного тестирования, код которого состоит на 30% из кода тестов. Думаю он знает о чем он говорит. С цитатой которую вы привели я согласен на 200%.
Интересно, особенно для начинающего программиста, буду стремиться к тому, чтобы быть хорошим программистом. Большое спасибо! С Днём Рождения!
С мнением о зоне потока согласен.
В последний раз при работе в зоне, я казалось поднял с 10% до 80% готовность проекта, а при сборке получил сообщение о неожиданной ошибки и закрытии приложения. Выдвинул и проверил множество теорий, вплоть до ошибки IDE :)
В итоге, на поиск причины ушло непозволительно много времени, а ошибка была весьма глупая, во вложенном цикле делался инкремент к счетчику внешнего цикла, из-за этого данные неверно инициализировались и вообще говорить о дальнейшей работе приложение нет смысла.
Скорей всего этого не случилось, будь я в здравом уме и следил за своими действиями
P.S. С днем рождения (да-да, признаю, этот комментарий здесь только ради этой книги :3 ). Всем добра!
В последний раз при работе в зоне, я казалось поднял с 10% до 80% готовность проекта, а при сборке получил сообщение о неожиданной ошибки и закрытии приложения. Выдвинул и проверил множество теорий, вплоть до ошибки IDE :)
В итоге, на поиск причины ушло непозволительно много времени, а ошибка была весьма глупая, во вложенном цикле делался инкремент к счетчику внешнего цикла, из-за этого данные неверно инициализировались и вообще говорить о дальнейшей работе приложение нет смысла.
Скорей всего этого не случилось, будь я в здравом уме и следил за своими действиями
P.S. С днем рождения (да-да, признаю, этот комментарий здесь только ради этой книги :3 ). Всем добра!
Шикарная статья, спасибо за информацию!
Владимир, С ДНЕМ РОЖДЕНИЯ!!!
Владимир, С ДНЕМ РОЖДЕНИЯ!!!
Спасибо за конспект. Распечатал некоторые моменты крупным текстом и и расклеил возле рабочего места. С днем рождения, всех благ, удачи, счастья.
Спасибо! Интересная статья, отличные иллюстрации, заставляет задуматься…
С Днём Рождения! ;)
С Днём Рождения! ;)
Спасибо за конспект, ждём следующую часть. И с днём рождения, всех благ и качественного программирования!
С Днем Рождения!
Владимир, спасибо за статью.
С Днем Рождения!
С Днем Рождения!
Спасибо. Полезно.
С днем рождения! Всех благ и без багов.
Автора поздравляю с днём рождения!
<<Рабам нельзя говорить «Нет», а наёмным работникам можно.>>
Прозвучало довольно двояко :)
<<Рабам нельзя говорить «Нет», а наёмным работникам можно.>>
Прозвучало довольно двояко :)
С днём рожденья!
Интересно.
Спасибо, за хорошую статью. Поздравляю с днем рождения. Желаю развития и творческого вдохновения.
И нормальным людям нужно всегда понимать, что манипуляция, известная у криминальных элементов как «Пацан должен отвечать за базар» не означает, что кто-то «должен рвать энное место до последнего если вдруг что-то не срастается». Это означает все лишь «Никогда не давай невыполнимых обещаний». По-моему в это упирается большинство пунктов.
Да-да! Во-первых, с Днем Рождения :) Прикольный способ посчитать сколько наверняка дочитало до самого конца.
А так во многом откликается, хотя я бы не был столь безапелляционным в высказываниях.
Понятно, что статья — конспект, но все же для меня было бы ценнее услышать насколько это соответствует личному опыту автора с примерами.
А так во многом откликается, хотя я бы не был столь безапелляционным в высказываниях.
Понятно, что статья — конспект, но все же для меня было бы ценнее услышать насколько это соответствует личному опыту автора с примерами.
Поставил минус за «Зона потока — зло». По моему опыту это не так.
Вы — молодец, потому что открыто пишете о том, что поставили минус.
А вы не забыли перед тем, как поставить минус посчитать по одному плюсу за остальные пункты, сложить и вывести результат? Я не для оценок пишу, однако, сообщаю на будущее: на подготовку одной такой статьи уходит не меньше 8 часов времени автора + 4 часа времени иллюстратора. Время на прочтение книги не считаю, потому что всё равно бы прочитал.
А ещё, нужно вспомнить, что это конспект книги, а не личное мнение автора. Хотя по части «зона потока — зло», мнение автора статьи совпадает с мнением автора книги.
Я вижу, вы сами пишете на Хабр и, возможно, не помешает немного уважения к другим авторам.
А вы не забыли перед тем, как поставить минус посчитать по одному плюсу за остальные пункты, сложить и вывести результат? Я не для оценок пишу, однако, сообщаю на будущее: на подготовку одной такой статьи уходит не меньше 8 часов времени автора + 4 часа времени иллюстратора. Время на прочтение книги не считаю, потому что всё равно бы прочитал.
А ещё, нужно вспомнить, что это конспект книги, а не личное мнение автора. Хотя по части «зона потока — зло», мнение автора статьи совпадает с мнением автора книги.
Я вижу, вы сами пишете на Хабр и, возможно, не помешает немного уважения к другим авторам.
С днем рождения!!! Хороших людей вокруг, здоровья и успехов!
Хороший конспект! Понравился. Со многими вещами абсолютно согласен, остальных просто, наверное, не понял. Нужно углубиться в изучение :)
Хороший конспект! Понравился. Со многими вещами абсолютно согласен, остальных просто, наверное, не понял. Нужно углубиться в изучение :)
«Я постараюсь» — это же мое. Пришла пора меняться, спасибо за статью!
С днем)
С днем)
Спасибо за статью и с днем рождения! С удовольствием прочитаю всю книгу
Мне показалось, что 75% статьи подойдет любым специалистам, немного специфическую терминологию изменить:
Далее про самообучение, работу в коллективе, режим дня, планирование труда, оценка сроков. От врача и математика, до сантехника.
Используют правило «Не навреди». Вашкодтруд должен работать и вы не должны ничего ломать. Конечно, это не каждому под силу, но по мере профессионального роста, количество ошибок в вашемкодетруде будет стремиться к нулю.
Далее про самообучение, работу в коллективе, режим дня, планирование труда, оценка сроков. От врача и математика, до сантехника.
С днем рождения))
Что касается статьи то статья крайне интересная, было бы вдвойне интересно (для меня как для аналитика) как это можно применить к стадии работы с Заказчиком и проектирования. Все же программистам легче четко оговаривать сроки и условия, поскольку как правило перед ними стоит четкая задача (если исключить те случаи когда программист сам себе аналитик).
И было бы крайне интересно прочесть продолжение)
Что касается статьи то статья крайне интересная, было бы вдвойне интересно (для меня как для аналитика) как это можно применить к стадии работы с Заказчиком и проектирования. Все же программистам легче четко оговаривать сроки и условия, поскольку как правило перед ними стоит четкая задача (если исключить те случаи когда программист сам себе аналитик).
И было бы крайне интересно прочесть продолжение)
как это можно применить к стадии работы с Заказчиком и проектирования
Это тип… пару месяцев выясняем требования, пару месяцев проектируем? потом пару недель это кодим, тестируем и по итогу получаем от клиента "это немного не то"?
Все же программистам легче четко оговаривать сроки и условия, поскольку как правило перед ними стоит четкая задача
Программисты должны учавствовать в процессе анализа, поскольку они компетентны говорить "вот это решение будет дорого, но если вот так то дешево". А когда это делают только аналитики, обычно получается не самый оптимальный вариант. Да и фидбэк клиенту проще получать по прототипам каким-нибудь.
Мы закладываем время на вычитку спецификаций программистами. Программист читает труд аналитика в конфлуенсе и ставит лайк, если всё хорошо. Если что-то не так, оставляет заметки на полях. Пока есть заметки, текст к клиенту не идёт. Так вы побуждаете разработчика сказать «нет» на ранней стадии проекта.
С Денриком! Удачи и благополучия!
С днем рождения, но книгу не надо ;)
После прочтения статьи создается впечатление, что идеальный програмист — это такой радужный волшебный единорог. Т.е. его тоже не существует.
Мне вот интересно, когда люди пишут такие книги они учитывают вообще, что каждый программист это живой человек. И, в это трудно поверить, но в своей жизни он не только программирует.
После прочтения статьи создается впечатление, что идеальный програмист — это такой радужный волшебный единорог. Т.е. его тоже не существует.
Мне вот интересно, когда люди пишут такие книги они учитывают вообще, что каждый программист это живой человек. И, в это трудно поверить, но в своей жизни он не только программирует.
UFO just landed and posted this here
Да. Когда оброс бытом, можно смело начинать пушить в репозиторий всякую дрянь в надежде на тестировщиков, перестать учиться и начинать говорить «я постараюсь». Все взрослые так делают.
tema_sun, возможно, автор книги — программист с многолетним стажем и семьёй? Можно проверить.
tema_sun, возможно, автор книги — программист с многолетним стажем и семьёй? Можно проверить.
Отличная статья! С днем рождения)
Поздравляю с днем рождения!
Книгу не читал, будет в тему :)
Книгу не читал, будет в тему :)
С днем рождения! Очень интересная статья, читается легко, все сразу улаживается в голову. Респект за стиль!
Вот совсем недавно на собственой шкуре понял, что это милое честное пионерское «Я постараюсь» вообще никому добра не делает, а самое неприятное, что в конце концов сам себе оказываешся злым Буратино.
Вот совсем недавно на собственой шкуре понял, что это милое честное пионерское «Я постараюсь» вообще никому добра не делает, а самое неприятное, что в конце концов сам себе оказываешся злым Буратино.
ТС, статья понравилась! С днем рождения, счастья, здоровья, держись там!
С Днём Рождения!
От почитателя философии буддизма и начинающего программера C#!
Спасибо за статью!
И да прибудет с автором Нирвана (или хотя бы Самадхи) :)
От почитателя философии буддизма и начинающего программера C#!
Спасибо за статью!
И да прибудет с автором Нирвана (или хотя бы Самадхи) :)
Интересная статья и мой первый коммент на хабре. С Днем рождения!
Очень хороший обзор. С Днём рождения!)
С Днем рождения. Творческих успехов и профессионального роста.
Спасибо за перевод. Перечитывать до полного просветления. С Днем Рождения!
Люди, статья статёй, но не забывайте критически мыслить! Я не со всеми пунктами согласен с автором:
> Используют правило «Не навреди»
Какая-то калька с врачебной клятвы Гиппократа. Причём, мало чем на неё похожая. Что значит «не навреди»? «вы не должны ничего ломать» — вот например ты пишешь робота-парсера, который ходит по сайту ЦБ, и скачивает котировки? Вред? Ну, относительный вред — ведь мы напрягаем серверы ЦБ. ЦБ не загнётся, всё вроде норм. А если это не ЦБ, а какой-нибудь маленький сервачок маленького проекта, с интересной нужной информацией? Ему уже будет вред. Второй пример: ты пришёл к выводу, что надо всё переписывать с нуля. При этом часть функционала потеряется. Это вред? -вред. Твой код сломает что-то? -да, сломает. Правило нарушается? -нарушается.
> Контроль качества не должен ничего найти
Совсем за уши притянуто. Можно месяцы искать в коде ошибки, и выдавать красивый законченный код, а можно отдать код сразу по готовности, и исправить маленькие косяки по мере их обнаружения. Когда задач много, сроки поджимают (не горят, но поджимают), то ты просто не можешь позволить себе тратить много времени на вылизывание кода. (про баланс кода-результата).
Про тестирование примерно то же самое — тесты могут покрывать хоть 100% кода, но это не значит, что код выполняет свою задачу как задумывалось.
> Скромны
Тут какой-то бред. В заголовке говорится «скромны», а в тексте под ним говорится про суровость и обязательное отсутствие чувства юмора.
> Знают свою область
Тоже этот штамп «программист должен писать код в ИТ-отделе». Жизнь меняется, и нужно под неё подстраиваться. Сейчас есть стабильная и очень результативная тенденция иметь своих программистов в каждом отделе. Про это пока не пишут, т.к. все привыкли, что всех программистов надо сажать в одном месте, а всех маркетологов в другом. А когда их садят вместе друг с другом, то отдел маркетологов становится вдруг автоматизированным(программисты автоматизировали маркетинг), а отдел ИТ вдруг продуктивным (маркетологи начали нормально пиарить руководству ИТ-шников).
Автору navff :
> кто поздравит с ДР, тот получит электроверсию книжки в ЛС
А что там с лицензиями? Я надеюсь, вы отправляете лицензионные купленные копии каждому вас поздравившего? Если это не так, то вы становитесь нелегальным распространителем цифрового контента. Вы ведь не зря указали ссылку на озон в самом первом предложении. Получается, вы сейчас пишете: я купил книгу на озоне (за 299р), и делюсь бесплатно с вами на хабре!
Можно много говорить про этику, правильно это или плохо, но награждать не принадлежащим вам контентом(читать — украденным) других людей за какие-либо действия (поздравления в данном случае) — не этично с моей точки зрения.
> Используют правило «Не навреди»
Какая-то калька с врачебной клятвы Гиппократа. Причём, мало чем на неё похожая. Что значит «не навреди»? «вы не должны ничего ломать» — вот например ты пишешь робота-парсера, который ходит по сайту ЦБ, и скачивает котировки? Вред? Ну, относительный вред — ведь мы напрягаем серверы ЦБ. ЦБ не загнётся, всё вроде норм. А если это не ЦБ, а какой-нибудь маленький сервачок маленького проекта, с интересной нужной информацией? Ему уже будет вред. Второй пример: ты пришёл к выводу, что надо всё переписывать с нуля. При этом часть функционала потеряется. Это вред? -вред. Твой код сломает что-то? -да, сломает. Правило нарушается? -нарушается.
> Контроль качества не должен ничего найти
Совсем за уши притянуто. Можно месяцы искать в коде ошибки, и выдавать красивый законченный код, а можно отдать код сразу по готовности, и исправить маленькие косяки по мере их обнаружения. Когда задач много, сроки поджимают (не горят, но поджимают), то ты просто не можешь позволить себе тратить много времени на вылизывание кода. (про баланс кода-результата).
Про тестирование примерно то же самое — тесты могут покрывать хоть 100% кода, но это не значит, что код выполняет свою задачу как задумывалось.
> Скромны
Тут какой-то бред. В заголовке говорится «скромны», а в тексте под ним говорится про суровость и обязательное отсутствие чувства юмора.
> Знают свою область
Тоже этот штамп «программист должен писать код в ИТ-отделе». Жизнь меняется, и нужно под неё подстраиваться. Сейчас есть стабильная и очень результативная тенденция иметь своих программистов в каждом отделе. Про это пока не пишут, т.к. все привыкли, что всех программистов надо сажать в одном месте, а всех маркетологов в другом. А когда их садят вместе друг с другом, то отдел маркетологов становится вдруг автоматизированным(программисты автоматизировали маркетинг), а отдел ИТ вдруг продуктивным (маркетологи начали нормально пиарить руководству ИТ-шников).
Автору navff :
> кто поздравит с ДР, тот получит электроверсию книжки в ЛС
А что там с лицензиями? Я надеюсь, вы отправляете лицензионные купленные копии каждому вас поздравившего? Если это не так, то вы становитесь нелегальным распространителем цифрового контента. Вы ведь не зря указали ссылку на озон в самом первом предложении. Получается, вы сейчас пишете: я купил книгу на озоне (за 299р), и делюсь бесплатно с вами на хабре!
Можно много говорить про этику, правильно это или плохо, но награждать не принадлежащим вам контентом(читать — украденным) других людей за какие-либо действия (поздравления в данном случае) — не этично с моей точки зрения.
Владимир, спасибо за конспект, в ожидании 2 части ) С днем рождения, Вселенского счастья Вам!
Спасибо за хорошую статью. С днем рождения!
Познавательная статья. С днем рождения!
UFO just landed and posted this here
Некоторые моменты в статье позволили узнать себя, очень интересно было читать. С днём рождения!)))
Ну что ж, спасибо за освещение такой темы. И с днем рождения! Чтоб дела все шли как по маслу — самое главное)
У меня тоже скоро, кстати. Прям под новый год. :D
Спасибо! С днем рождения!
С днем рождения! Успехов вам в достижении ваших целей! и с наступающим заодно!
С Днём рождения!
С «Зоной потока» не согласен. Считаю, что это что-то вроде «поймать волну». В такие моменты продуктивность подскакивает, и ты пишешь много больше, получая вдвое больше удовольствия. Драйв же :)
Правда, в таком состоянии очень просто и легко уйти в over-engineering, но ничего не мешает потом перечитать тонны кода, и поправить, где надо.
Вот тут, конечно, надо «включать голову» и держать себя в руках. Так как люди, что ломают твой «поток», конечно, раздражают. Это как любимую кость у собаки начать отнимать — можно остаться покусанным. Или как у наркомана — дозу… В общем, мало кому нравится, когда кайф ломают :) С другой стороны, когда ты отслеживаешь это — бороться с собственным негативом, конечно, легче.
И с днем рождения, да :) Всяческих успехов и роста во всех интересующих сферах :)
Правда, в таком состоянии очень просто и легко уйти в over-engineering, но ничего не мешает потом перечитать тонны кода, и поправить, где надо.
Верный признак Зоны, — это когда вы невежливо отвечаете на телефонные звонки и не рады даже хорошим людям.
Вот тут, конечно, надо «включать голову» и держать себя в руках. Так как люди, что ломают твой «поток», конечно, раздражают. Это как любимую кость у собаки начать отнимать — можно остаться покусанным. Или как у наркомана — дозу… В общем, мало кому нравится, когда кайф ломают :) С другой стороны, когда ты отслеживаешь это — бороться с собственным негативом, конечно, легче.
И с днем рождения, да :) Всяческих успехов и роста во всех интересующих сферах :)
Об том и речь, что задолбаетесь читать и править потом. А возможно и не вы, что хуже многократно. Вспомните постулаты Agile-техник: марафон, а не спринт; постоянная скорость; движение маленькими шажками и т.д. Игра в планирование, TDD, парное программирование — все направлено на то, чтобы разработчик семь раз думал, один раз делал и семьдесят семь раз не переделывал. Ведь экстаз — он такой, да.
Насчёт Зоны потока Мартин не говорил, что это исключительно зло. Он так же приводил пример когда состояние потока уместно — например, когда вы изучаете что-то новое и тренируетесь в этом.
Присоединяюсь к флешмобу :) Владимир, с Днем Рождения! Продолжайте радовать добротными конспектами и да пребудет с вами Сила.
UFO just landed and posted this here
Спасибо за интересную и полезную статью, жду продолжения. С Днем Рождения!
Хорошая статья некоторые вещи были знакомы, а вот в некоторых увидел как глупо я поступаю. С днём рождения!
Спасибо за конспект. С днем рождения и творческих успехов в будущем!
С Днём рождения, Владимир! Пусть ваш код в конечном итоге всегда будет безупречным:)
Насчет говорить «нет»…
Лучше не просто говорить «нет», а еще объяснить сколько стоить будет «да».
Мы же «профессионалы» и понимаем, что за счет качество можно купить время.
Которым потом расплатимся тем же временем. :-)
Лучше не просто говорить «нет», а еще объяснить сколько стоить будет «да».
Мы же «профессионалы» и понимаем, что за счет качество можно купить время.
Которым потом расплатимся тем же временем. :-)
— А бывают случаи, когда в срок нельзя уложиться ни за какие деньги?
—Такое впечатление, что да. Заказчик хочет сферического коня, а коня нет. И привезут только в пятнице, а нужно выкатить версию завтра, потому что выставка, на которую приедет Медведев именно завтра. Так что вместо коня вы ставите заглушку: «тут будет сферический конь».
—Такое впечатление, что да. Заказчик хочет сферического коня, а коня нет. И привезут только в пятнице, а нужно выкатить версию завтра, потому что выставка, на которую приедет Медведев именно завтра. Так что вместо коня вы ставите заглушку: «тут будет сферический конь».
С днем рождения. Желаю дальнейшего творческого развития. Будет интересно почитать книгу :)
С днем рождения!
Жду вторую часть тоже :)
Жду вторую часть тоже :)
Отличная работа, ждём 2 часть. С днем рождения! И мы не стареем а добавляем + 1 к мудрости. Успехов в начинаниях.
С Днем Рождения! Хороший конспект) Спасибо за старания.
А как можно уверенно сказать «да» (особенно с точными сроками) или «нет», если я не имею понятия, справлюсь ли с поставленной задачей? Скажем, она для меня новая — в той области, с которой я до сих пор не имел дела. Это надо изучить вопрос, освежить в памяти или почитать что-нибудь из теории по теме, повтыкать в гугл и стек оверфлоу, наметить пару возможных решений и попытаться их реализовать, посмотреть что получилось — отбраковать неудачные и попробовать другие. Тут ну никак язык не поворачивается сказать что-то отличное от «ок, я попробую что-нибудь придумать».
Не согласен со знанием всех там алгоритмов. Я например на вскидку не вспомню алгоритм сортировки, я им последний раз пользовался тыщу лет назад, и если надо будет, я открою книгу и посмотрю. Всегда раздрожает, когда на собеседованиях человек начинает с ухмылкай вас гонять по алгоритмам которыми он пользуется каждый день, а вы до этого работали вообще в другой области и решили сменить сферу деятельности, и про эти алгоритмы последний раз в институте слышали.
Sign up to leave a comment.
Идеальный программист. Часть 1