Программирование — только для умных
Как же надоело слушать от технически некомпетентных «гуманитариев» и домохозяек рассуждение о доступном для всех, в том числе и для ржавых чайников, программировании через соединение кубиков. Чепуха это полнейшая. За программирование отвечает левое полушарие, которое в эпоху фейсбука, кофе и взаимного лайкания и обсуждения зверушек в соцсетях — постепенно атрофируется у современных гуманоидов. Хотите резко поднять мотивацию у программиста? Покажите ему, как менеджер проекта решает элементарную задачку: вычисляет экстремумы и перегибы функции через нахождение производных первого и второго порядка, заливая капающей из ушей кровью рабочий стол и издавая инфразвуки от нечеловеческого перенапряжения!
И хотя в истории были случаи попыток массового обучения «простых» людей программированию — без досконального знания алгоритмов, тонкостей языка программирования и особенностей работы операционной системы максимум, на который вы можете рассчитывать — это получить бригаду фронт-энд «разработчиков»/верстальщиков (специально взял в кавычки), которым не нужно знать лишнего, кроме как «чтобы выглядело красиво».
А самое страшное, что может тут произойти — это работать с ненастоящими программистами долго и успешно над простыми примитивными проектами, не требующих глубоких знаний, а затем заняться интересным, сложным проектом с примесью Computer Science — веселье предстоит просто улетное: все ломанутся на StackOverflow и начнут заново изобретать… алгоритмы и удивляться, что TCP отличается от IP!
Детали — важны, как никогда ранее
К сожалению, чтобы программировать правильно, нужно знать язык программирования глубоко и широко. Если это простые динамические языки типа Python, Ruby, PHP, JavaScript — то знать там особо нечего, тонкостей и внезапных сложностей практически нет и можно лепить что лепится и оно будет как-то работать до определенного момента.
Но чтобы писать на «настоящих» промышленных ЯП, таких как C++, Java или C# — требуется интенсивная подготовка в течении парочки лет и чтение и понимание толстых книжечек и всех тонкостей языка. Но это только начало — важно научиться программировать в парадигме ООП — а это еще тройка лет и чтение другой стопки книжечек по шаблонам проектирования.
Если скучно, то можно разбавить жизнь программиста, применяя функциональные сладости на гране извращений типа лямбд и замыканий — но от этого всегда можно отказаться и вернуться к здоровому аскетизму и православному ЗОЖ.
Проектирование — иначе просто нельзя
Вы правда поверили сказкам, что можно размазать эмоциональный бред на листочки, а на обратной стороне написать definition of done в стиле «фи/не фи» и не проектировать? Да вы, братец, с ума сошли. Любая более-менее сложная система требует обмозговывания и потребления у доски пары десятков чашек кофе. Логическая схема сущностей, ролей, формальное описание алгоритмов — должны быть сделаны с полной алгебраической беспощадностью. Тут, как раз, пригодится знание UML. Иначе вы будете похожи на обезьяну, с пренебрежением поглядывающую на коммутационный щит с проводами с мыслью: «фигня вопрос, все тут и так понятно, главное — я такая красивая». Поэтому не позволяйте глупости и лени захватить мозг проектной команды и всегда строго формализуйте сложные вещи.
Программистами — не нужно управлять
Откуда вообще появились менеджеры в программных проектах? А все просто — программисты часто настолько демонически умны, что могут направить проект мимо цели в область эстетики и совершенства, наплевав на сроки и жадного клиента — просто по идеологическим соображениям, просто из-за любви к прекрасному. Поэтому, разработчикам скорее нужны не менеджеры — а воспитатели и вдохновители, умеющие говорить приятные вещи про код, про клиента, про жизнь и вовремя покупающие печеньки и кофе.
До сих пор не знаете самый любимый фильм у программистов? Вот же он — обязательно устраивайте еженедельный просмотр, кино отлично мотивирует, особенно перед встречами с клиентом!
Но программные проекты — это не только код и программисты с вспомогательным персоналом, это еще и бизнес. А при наличии особо истеричных тетенек-инвесторов возникает такая политическая абстракция, как сроки и бюджет. Именно это и порождает класс IT-менеджеров. К большому сожалению, для эффективного и бережливого управления командой — менеджеру, положа руку на сердце, необходимо быть технически подкованным, вникать в детали проекта и оценивать риски. Ощущая компетентного «вожака», команда интуитивно помогает ему хоть как-то, хоть грубо и не точно, но по совести — попытаться оценить риски и прикинуть оценки и затраты времени, чтобы хоть как-то успокоить политическую истерику на более высоких уровнях абстракции. И это — часто ведет к успеху.
Но если менеджер сознательно «включает дурачка», надевает «розовые очки» и начинает публично играться в листочки c эмоциональным бредом (ProductBacklog), досочки (Burndown), картишки (PlanningPoker) и улыбаться на Retrospective так, что ждешь, что вот вот случится каминг-аут — то, скорее всего, проект обречен и сделать уже ничего нельзя.
«Из курочки — сварит и дурочка»
Поэтому — расслабьтесь и не пытайтесь изучить и отличить "водопад" от RUP, а Scrum от Kanban — это не поможет. Сосредоточьте усилия на поиске настоящих программистов! Команда сама выберет наиболее адекватную проекту методологию, число тестировщиков, аналитиков и, что особенно важно, бригаду адаптации эмоциональных эманаций клиента в область строгой формализации и алгоритмов — всяких менеджеров разных мастей и научит их работать.
Парадокс, но имея адекватную команду программистов, становится неважно, какую методологию выбрать — поверьте, любая методология, даже самая «страшная и ужжжасная» под именем «без ТЗ» — приведет проект к успеху и взлету в срок с прекрасным техническим качеством. В принципе, можно даже стать волшебником изумрудного города — и проект все равно взлетит. И наоборот — набрав «сантехников» по объявлению, вам не поможет даже самая правильная, единственная правильная методология в мире — водопад. Люди запутаются в собственном коде и документации до такой степени, что придется набирать несколько каскадов тестировщиков, проверяющих баги предыдущего каскада (в периоде).
Agile — для спецназа
Важно очень хорошо уяснить, что Agile сейчас просто выгоден менеджменту для защиты от «истеричных инвесторов» и поэтому так популярен — и превращает команду разработки в подобие Макдональдса с теоретической взаимозаменяемостью, прозрачностью и… также теоретической, отчуждаемостью. Сразу видно, как хорошо все управляется: нет умников, все заняты делом, циферки растут, люди бегают — но это все, конечно полная чушь.
Agile, в своей сути, это, так сказать, методология сотрудничества разработчиков высшей категории профессионализма, находящихся нередко под действием легких наркотиков и сверкающих от собственного подлинного совершенства — с клиентом в стремлении сделать крутое и классное решение, желательно в срок (чтобы тетеньки не истерили), но которым обязательно можно будет гордиться! Все, вот это Agile — чувствуете уровень и разницу с тем, что сегодня подается под похожим соусом? :-) Становится очевидно, что набрав молодежь и оппившись кофе (или покуривши чего-то), прочитав пару-тройку эмоциональных книжек про итерации и ретроспективы и как всем стало хорошо — вы просто наверняка сломаете себе и команде шею, причем так красиво и эффектно, что будете икать всю оставшуюся жизнь.
Никогда не забывайте историю появления XP и судьбу девушки-product owner, которую Kent Beck с невменяемыми заказчиками довели до паралича и нервного тика лица. Зато да, книжки написали интересные… :-)
Качество кода и сплоченность команды — превыше всего
Запомните, что самое важное в программном проекте, который пишут настоящие программисты — это красота и стройность программного кода! Именно он привлекает к себе людей, мотивирует их вкладывать на свое развитие время и энергию. Остальные составляющие — производные.
А что такое красота программного кода? Это:
- простота
- ясность
- лаконичность
- последовательность
- понимание, что происходит «под капотом» и правильное использование возможностей операционной системы и протоколов
- расширяемость или готовность к этому
- документация только там, где она нужна!
Человек открывает код… и ему приятно развивать его дальше, у него повышается настроение! А бывает же, что открываешь код и с трудом сдерживаешься от рвоты — это правда жизни.
И не важно, на каком языке программирования пишут ваши джедаи кремния. Можно великолепно писать на JavaScript, вводя читающих в состояние интеллектуального экстаза. А можно поставить на поток низкопробное порно на java и гнать жуткий депресняк, распугивая не только крыс, но и маскирующихся под людей инопланетян…
Выводы
- Не забивайте себе голову методологиями разработки программного обеспечения — это не поможет
- Сосредоточьтесь в первую очередь на поиске и наеме профессиональных, настоящих программистов и вспомогательного персонала (аналитики, тестировщики, менеджеры всех мастей)
- Если удалось подобрать адекватную команду — пусть она сама выберет методологию разработки и знайте, что с любой методологией проект скорее всего взлетит
- Если не удалось подобрать адекватную команду — лучше меняйте работу, ибо вас скорее всего загрызут «истеричные тетеньки-инвесторы» политическими требованиями дать оценки и попасть в сроки. Либо вы попадете в медленно падающий и пылающий дирижабль с эмоциональными листочками на стенах, утренних Stand-ups для идиотов-социофобов, создающих лишь бы что — зато в срок! Рассчитайте высоту, найдите парашют и готовьтесь покинуть это бесовское место раньше начала фейерверка :-)
P.S.: По-секрету, говорят есть способ все таки взлететь в любом случае — работать по строгому водопаду с ТЗ, unit-тестами, жесточайшей дисциплиной и человеческими жертвоприношениями Ктулху. Но это если повезет. А иначе вы попадете в суровую атмосферу Первой мировой и будете заниматься матстатистикой — прогнозом и подсчетом потерь личного состава от лягания лошадей и вести активную борьбу с каннибализмом. Удачи!
Комментарии (118)
maxru
03.02.2017 17:37+13Опять битрикс толкает речь про красоту программного кода. Сколько ещё это терпеть?
AlexSerbul
03.02.2017 17:38А что делать? Нравится красивый код, снится и сводит с ума.
maxru
03.02.2017 18:32Поэтому на старый некрасивый код можно и забить.
AlexSerbul
03.02.2017 18:33Да его рефакторят на D7 с OOP, просто его много очень.
maxru
06.02.2017 16:51+1Я видел D7.
Если взять статические методы классов и запихнуть их в статические методы классов, но с неймспейсами — это не совсем рефакторинг )
AlexSerbul
06.02.2017 16:53Не, ну там не все уныло так :-) Появились объекты, настоящие, с конструкторами! Используются исключения, константы, все по взрослому. Постепенно стандартные компоненты переведут на объектную модель тоже.
maxru
06.02.2017 17:00+1Постепенно стандартные компоненты переведут
Вот про это я слышу с 7 версии что-ли.
Пока что вижу, что пилятся новые фичи, а старые не трогают, их же не продашь новым клиентам.
Появились объекты, настоящие, с конструкторами!
А иногда 2 или 3 объекта! И документации нет, какой использоваться непонятно по причине отсутствия документации и меток deprecated. А иногда ещё бывает так, что половина модуля переписана, а вторую половину методов нужно использовать из старых.
AlexSerbul
06.02.2017 17:04Но вообще если метод публичный, общее правило — можно использовать. Если он исчезнет внезапно — пишите либо в саппорт либо мне в личку, будем разбираться
maxru
08.02.2017 14:35+1Да мне особо не надо, я не ваш клиент, просто недавно понадобилось написать модуль интеграционный для битрикса, так выяснилось, что по D7 документации кот наплакал, что часть логики в шаблонах до сих пор и что максимум что можно сделать обработчиком СД — это вернуть свою цену.
В итоге я сидел и читал сорцы один за другим, чтобы отловить ваши "события", которые не настоящие события при этом.
keenondrums
03.02.2017 17:49+1Перестал читать на «Но чтобы писать на «настоящих» промышленных ЯП, таких как C++, Java или C#»
AlexSerbul
03.02.2017 17:50+3Зря, дальше интереснее :-)
MikailBag
03.02.2017 19:41+2Но с простотой Вы перегнули, имхо.
В Erlang и ассемблере классов нет, и они что простыми сразу стали?
Оттого что в языке нет встроенной статической типизации — он не становится сильно проще.
LekaOleg
03.02.2017 22:45+2«До сих пор не знаете самый любимый фильм у программистов? „Вот же он“ (ссылка на фильм) — обязательно устраивайте еженедельный просмотр, кино отлично мотивирует, особенно перед встречами с клиентом!» — С коллегами посмеялись!))
AlexSerbul
04.02.2017 00:06Ну классный же фильм, у парня собачку прибили, а у разработчика клиент неадекватный и баги в коде и — и вперед :-)
Wyrd
04.02.2017 14:24+2Кто эта девушка — первый product owner — которую довели до нервного тика? Где можно про это прочитать? Просветите, пожалуйста.
AlexSerbul
04.02.2017 14:44+3Marie Dearment
https://en.wikipedia.org/wiki/Chrysler_Comprehensive_Compensation_System#endnote_customerRepBurnout
http://www.coldewey.com/publikationen/conferences/oopsla2001/agileWorkshop/hendrickson.html
i360u
04.02.2017 16:49+3Тяжело читать текст, где после каждого нового предложения заново приходится решать, автор это серьезно или он так "пошутил". Потому, что некоторые тезисы выглядят, вроде как, серьезно, а остальные вызывают фейспалм. Что это было вообще и зачем?
serg_p
05.02.2017 21:55Закон дырявой абстракции — http://russian.joelonsoftware.com/Articles/LeakyAbstractions.html
serg_p
05.02.2017 21:56https://ru.m.wikipedia.org/wiki/Уровень_абстракции_(программирование)
AlexSerbul
05.02.2017 22:01Ну смотри, ООП пытается защитить нас, снижая сложность — это инструмент снижения сложности ПО. Но если его применить неправильно, станет сложнее :-)
bapcyk
05.02.2017 22:06-2Как всегда о засилье дураков. Старо как мир. Но справедливости ради, разве не недоучки — люди с незаконченным высшим, придумали т.н. паттерны ооп? От которых число дураков выросло даже експоненциально в нашей отрасли. И еще, как можно ставить в пример java, когда, пожалуй, ни одно упрощение яп до уровня недоучек не привело столь много дилетантов в ит? :)
AlexSerbul
05.02.2017 22:07-2Ну в java попытались как-то стабилизировать адскую свободу в C++ — не согласен, что не получилось. А вот в всяких python что понатворили…
ApeCoder
05.02.2017 22:24+1Думаю у Питона достаточно строгий дизайн или что вы имеете ввиду вообще?
AlexSerbul
06.02.2017 12:30Думаю он излишне аскетичен на гране примитивизма. Где нормальная инкапсуляция с человеческими protected/private? Нет ее и наверно не будет
ApeCoder
06.02.2017 13:01+2Так это не "понятнворили" а "недонатворили". Это раз. Во-вторых, там есть инкапусуляция, в-третьих, это динамический язык со своими динамическими традициями (сравнивать с JS, ruby, lisp)
AlexSerbul
06.02.2017 12:38Вот яркий пример использования языка не по назначению: http://www.opennet.ru/opennews/art.shtml?num=45984
Понятно, тут можно спорить. Но по моему мнению — Scala должна занять эту нишу.
ApeCoder
05.02.2017 22:20+1Но справедливости ради, разве не недоучки — люди с незаконченным высшим, придумали т.н. паттерны ооп?
Patterns originated as an architectural concept by Christopher Alexander (1977/79). In 1987, Kent Beck and Ward Cunningham began experimenting with the idea of applying patterns to programming – specifically pattern languages – and presented their results at the OOPSLA conference that year.[6][7] In the following years, Beck, Cunningham and others followed up on this work.
Beck attended the University of Oregon between 1979 and 1987, receiving B.S. and M.S. degrees in computer and information science.[3]
Cunningham was born in Michigan City, Indiana.[6] He received his Bachelor's degree in interdisciplinary engineering (electrical engineering and computer science) and his master's degree in computer science from Purdue University, graduating in 1978.[7]
От которых число дураков выросло даже експоненциально в нашей отрасли.
Мне кажется, не дураки от паттернов, а просто дураки применяют паттерны по-дурацки :)
s-kozlov
06.02.2017 06:15+1Мне кажется, не дураки от паттернов, а просто дураки применяют паттерны по-дурацки :)
На самом деле, есть два вида дураков. Первые начитываются книжек по паттернам и начинают пихать их куда ни попадя. А вторые ничего не читают и просто говнокодят. И если у первых болезнь довольно быстро проходит на реальных проектах, то у вторых вообще не лечится.ApeCoder
06.02.2017 09:30+2Первые начитываются книжек по паттернам и начинают пихать их куда ни попадя
Я думаю, люди, не испытывающие потребности называть других именно дураками, сказали бы, что это нормальный этап обучение чему бы то ни было — попробовать его в разных условиях.
http3
06.02.2017 14:24+1Туда же дрочерство на ООП и фреймворки.
Только я сомневаюсь, что болезнь лечится :) Больные считают себя здоровыми.
oldpunk
06.02.2017 12:31+2Запомните, что самое важное в программном проекте, который пишут настоящие программисты — это красота и стройность программного кода! Именно он привлекает к себе людей, мотивирует их вкладывать на свое развитие время и энергию.
Самое главное в программном проекте это его функциональность, удобство использования для конечного потребителя. Но никак не стройность программного кода. Больше скажу всем, кроме программистов, наплевать как он там построен внутри, на чем написал, протестирован ли. Если же он непонятный, или неудобный в использовании, или просто несет никому ненужный функционал, как бы красиво он написан не был, он отправится в мусорную корзину, и никто ничего в него вкладывать не будет.AlexSerbul
06.02.2017 12:32-1:-) шутите. Ориентироваться на потребительского дебила — не интересно, поверьте. Если бы так писали серьезные продукты, типа mysql или linux — до чего бы докатились, страшно подумать
s-kozlov
06.02.2017 13:24+3Ну вам лично может и не интересно, но есть куча проектов не для айтишников, а для «потребительского дебила»: фейсбуки там всякие, винды… хотя это же несерьезные продукты, ими ведь пользуются всего лишь сотни миллионов людей, да и доход от них измеряется в жалких миллиардах.
AlexSerbul
06.02.2017 13:30Почему, facebook интересный продукт, дал много опенсорсу, там нормальный код внутри, уверен! Винда — тоже классный продукт, разве нет?
s-kozlov
06.02.2017 14:10+1Это я к тому, что винда и фейсбук, будучи казуальными продуктами, ориентированы на широкую аудиторию — «потребительского дебила». А если бы это было не так, они бы либо вообще не взлетели, либо их доли в потребительском сегменте болтались в районе статистической погрешности, как у линукса (и по той же причине).
Насчет кода винды: не видел, но подозреваю там жуткий говнокод.
AlexSerbul
06.02.2017 13:31+1Суть в том, что говнокод ооочень сложно и дорого развивать. И если продукт развивается и довольно долго — там сильная техническая команда и разумный код.
s-kozlov
06.02.2017 14:13+1Суть в том, что говнокод ооочень сложно и дорого развивать
Конечно. А совершенный код может тоже потребовать огромного или даже бесконечного времени.
Neikist
06.02.2017 12:37+1Именно он привлекает к себе людей, мотивирует их вкладывать на свое развитие время и энергию.
Обратите внимание на этот кусок. И имеются в виду программисты. Плохо себе представляю программиста которого может мотивировать на развитие говнокод.AlexSerbul
06.02.2017 12:40Согласен абсолютно! Тот, кто останется копаться в д… ме — скорее всего имеет проблемы с самооценкой и что они напишут дальше…
oldpunk
06.02.2017 12:58-1По мне так в битриксе лютый говнокод, но это не мешает быть ему успешным продуктом, и привлекать кучу программистов. И успешный проектов на нем реализована куча.
AlexSerbul
06.02.2017 13:25Не согласен. В Битриксе стройная довольно лаконичная архитектура и разумный, читаемый код. Есть малюсенькие фрейворки, в которых логика более отточена — но просто они… маленькие.
oldpunk
06.02.2017 12:56+1Обратил, работать над продуктом который пользуется популярностью намного приятнее чем над «мертвым» продуктом. Это мотивирует, когда ты реализовал какую то фичу и люди начинают этим пользоваться. А если ты написал мега красивый по коду модуль и никто этим не пользуется, нафиг оно надо?
Насчет говнокода, мне например нравиться рефакторить старые проекты, делать код читабельные, удобнее в использовании. Но это имеет смывсл только тогда когда продукт пользуется спросом.AlexSerbul
06.02.2017 12:57А как можно рефакторить говнокод без 100 тестировников и юнит-тестов? Согласен, что если продукт популярный — с ним интереснее работать, конечно.
oldpunk
06.02.2017 12:59+1кто вам мешает писать тесты на свой код?
AlexSerbul
06.02.2017 13:26Тесты не дают писать менеджеры проектов, т.к. сроки постоянно горят :-)
oldpunk
06.02.2017 15:28+1Я просто оставлю это здесь
Developers do not need to ask for permission for doing tdd or programming in pairs. Professionalism never requires consent. @lemiorhan
Asking permission to do TDD is like asking permission to use a keyboard. @JamesSaliba
Ну вы меня поняли…AlexSerbul
06.02.2017 16:32И много вы видели проектов с хорошим покрытием юнит-тестами? Не проще ли модульно программировать с качественной инкапсуляцией и писать интеграционные и смок-тесты? :-)
VMichael
10.02.2017 12:44+1Юношеский максимализм.
Конечно, дома вы можете делать TDD в свое удовольствие.
А когда вам платят за работу, вы будете делать то, за что вам платят, увы.
Это жизнь.
Можно развести холивара много, про отличного специалиста нарасхват, но я видел не одного человека, который увольнялся с такими мыслями, а потом просился обратно.
И в большинстве случаев, его место уже было занято.
Тут недавно говорилось, что на начальном этапе TDD всего лишь удваивает время написания продукта.
Какая ерунда.
Ввалить еще миллион-другой в разработку.
Нужно смело сказать об этом тому, кто за это платит.AlexSerbul
10.02.2017 13:18Согласен, TDD слишком дорого и не дает гарантии. Гораздо спокойнее писать модульно, с инкапсуляцией, с головой, аккуратно и иметь набор функциональных тестов.
breakoffbrain
06.02.2017 15:18+1если код будет неясным и некрасивым, то рано или поздно он превратится в кучу мусора, поддерживать его станет невозможно, как и добавлять новые функции — в итоге этот «многофункциональный код» будет на свалке
oldpunk
06.02.2017 15:35Это технические детали на которые конечному потребителю плевать. Им плевать сложно вам добавлять функционал или нет, тратите вы на это 10 минут или 10 дней. Им важен результат. Вот вы пользуетесь Windows, Linux, mysql, mssql и т.д., и вы лазили у них в исходный код и это для вас стало решающим использовать их или нет? Сомневаюсь.
breakoffbrain
06.02.2017 15:43конечному потребителю может и наплевать, а вот конкурентам, которые могут быстрее и проще добавлять новый качественный функционал — нет;)
oldpunk
06.02.2017 16:02Сколько фейсбуков появилось одновременно с текущим и сколько появилось после? Самое важное тут не качество кода, а время. Кто первый, то и съест основную часть пирога. А когда ты на коне можно озадачиться рефакторингом с целью уменьшения времени на внедрении нового функционала.
AlexSerbul
06.02.2017 16:34Я понимаю вас. Мы говорим, думаю, об одном — писать разумно, без фанатизма и чтобы можно было взлететь и потом расширять. Так могут писать только профессионалы.
oldpunk
06.02.2017 16:43Я просто говорю что красивый код никак не влияет но то взлетит проект или нет.
AlexSerbul
06.02.2017 16:50Он повышает шансы устойчивости к нагрузке и быстрой адаптации к требованиям клиентов, которые нужно будет, часто, быстро удовлетворить как раз во время запуска за короткое время.
oldpunk
06.02.2017 16:57Ну уж на нагрузку он никак не влияет, даже наоборот. Даже наоборот в красивом коде больше абстракций, которые создают дополнительную нагрузки при исполнении кода. Ну а клиентов на начальном периоде у вас вряд ли будет много. Если только вы не уже не супер известная компания, но это совсем другой случай :)
AlexSerbul
06.02.2017 17:01Абстракции позволяют провести быстрый аудит производительности и пофиксить тормоза в нужных точках, а не бегать по копипасченному спагетти, вырывая с кровью куски и ломая все остальное :-)
oldpunk
06.02.2017 17:08я все понимаю, но опять же, если у вас эта нагрузка есть. Я работал в проекте в основе которого лежала оч неплохая идея, достаточно интересная, подобного в России не было. Но за время работы сменилось 3 тимлида, и каждый говорил что написано все очень плохо. В итоге мы переписывали 3 раза с нуля, ушло много времени и денег. За это время появилось оч много проектов с таким же функционалом, и наш затерялся в этой куче, 5-10к посетителей, половина с рекламы. Код в итоге получился более-менее, но кому он теперь нужен. Проект в который вбухали миллионы, теперь на свалке, не отбив даже половины.
nekt
11.02.2017 06:23Ни один хороший тимлид не даст переписывать все с нуля — это никогда не работает. Так что скорее всего да, было написано все очень плохо.
ApeCoder
06.02.2017 16:19Им плевать сложно вам добавлять функционал или нет, тратите вы на это 10 минут или 10 дней.
То есть им в любой точке времени T плевать, есть функционал или нет?
oldpunk
06.02.2017 16:32Возьмем для примера что то типа фейсбука, У него допустим нет возможности выкладывать видео, а на сайте бабушкины-тапочки.ком есть. Но никто не будет уходить с фейсбука и-за этого, все будут ждать функционал. Потому что на фейсбуке у тебя 500 друзей, а на тапочках ни одного, с кем тебе там делиться видео, если там никого нет?
AlexSerbul
06.02.2017 16:33Потребителю плевать, а менеджеру проекта не должно быть побоку это.
oldpunk
06.02.2017 16:47Многие проекты начинаются командой из 1-4 человек, а менеджеры появляются когда проект уже чего то добился. Конечно крупные компании не будут писать говнокод, и будут у них менеджеры, аналитики и т.д. но это не спасает от того что проект полностью провалится, взять хотя бы гугл+, есть у меня подозрения что написан он добротно, но кому теперь это надо?
AlexSerbul
06.02.2017 16:51Согласен в принципе. Но мне попадались проекты в крупных компаниях, которые внутри выглядели ужасно просто — парадокс :-)
oldpunk
06.02.2017 17:00Архитектура вообще дело сложное. Особенно когда проект начинается без видения каким он в итоге должен стать, тут ничего не поможет. Перерабатывая потом его, намного легче создать более удобную архитектуру, потому что вы уже знаете каким он должен быть и какие задачи решать. Но опять же не факт что это у вас получится.
AlexSerbul
06.02.2017 17:02Согласитесь, опытный разработчик обладает предчувствием развития архитектуры и требований — он правильно пишет классы, называет методы, создает разумные таблицы. Неопытный такое закостенелое чудовище может создать, что его полгода распутывать придется.
oldpunk
06.02.2017 17:10+1На то он и опытный, потому что он уже писал такой закостенелый код и спотыкался на этом и теперь знает как сделать лучше сразу :)
VMichael
10.02.2017 12:49+1Не всегда к сожалению.
У меня сложилось мнение, что некоторым этого не дано.
Я тут приходил в компанию, в гости, из которой ушел несколько лет назад.
Те же люди, когда с них сняли контроль за архитектурой, стали говнокодить и лепить костылики, лишь бы быстрее.
Я расстроился.
Спрашивал, как же так, ребята (хотя уже не ребята, взрослые люди).
Да как то так, говорят. Закрывали вот, потребности.
mad_nazgul
07.02.2017 12:40+1Можно было сказать проще.
Индустрия программирование еще не достигла уровня индустриальной промышленности.
А болтается где-то на уровне мануфактуры/кустарного производства.
:-)s-kozlov
07.02.2017 13:03+1Индустрия программирование еще не достигла уровня индустриальной промышленности.
Я нифига не понял. Индустрия — синоним промышленности. Так что вы хотели сказать? «Индустрия программирование еще не достигла уровня индустриальной индустрии»?
denvor
07.02.2017 17:11+1Меня всегда приятно удивляет, когда хороший профи -айтишник еще и отлично излагает. Отличный стиль! С выводами хотел бы поспорить… но не могу — оглядываюсь и да, все так.
AlexSerbul
07.02.2017 17:12Спасибо! Ну тут да, личные выводы. Я просто хочу проблему обострить и в комментах найти ответы на вопросы :-)
AlexSerbul
07.02.2017 17:12Спасибо! Ну тут да, личные выводы. Я просто хочу проблему обострить и в комментах найти ответы на вопросы :-)
NewMan_by
11.02.2017 11:56+1Уж очень похоже на какое-то очень эмоциональное раздутое ИМХО, не имеющее никого подкрепления, кроме личного опыта, видимо, часто неудачного. Какие-то крайности: важен только совершенный код, важны только люди, а вот остальное нет. Все важно, и люди, и качество кода, и процессы и еще куча всего. К сожалению, не увидел у автора понимания, что такое тот же Agile
VMichael
Статья какая то сумбурная и не логичная, возможно это стеб или ирония,
но выводы в разделе «Выводы» верны.
i360u
И чем именно верны эти сумбурные выводы? Лично я наблюдал массу эпичных факапов у любителей квадратно-гнездовых водопадов и "человеческих жертвоприношений".
VMichael
Вот эти выводы верны, хотя они совсем не вытекают из статьи.
Я всегда говорю, недавно вот дочери говорил, она сейчас менеджер проектов разработки, начинающий — главное в ИТ (а скорее всего в любой работе) люди правильные. Остальное, вторично, как вспомогательный инструмент.
Я, конечно, не мега управленец, ленивый для этого, не люблю писанину и отчетность, но поруководил немного, лет 15, начиная от бригад электрослесарей на шахтах, до команд программистов.
И мой личный опыт (а для каждого именно личный опыт имеет обычно решающее значение), говорит, что правильные люди сделают работу и без методологии.
А неправильным и методология не поможет.
i360u
Да эти выводы действительно верны. Простите, был слегка сбит с толку остальной статьей.
ApeCoder
Мне кажется у автора мысль движется в ту сторону, что и у всяких беков и фаулеров, когда говорят про agile maturity или engineering fluency, только он говорит в самобытно-эмоциональном стиле, что забавно в сочетании с понятиями "эмоциональный бред" и "эмоциональные листочки на стенках", которые он сам и применяет :)
MichaelIgitov
Тут только один есть вопрос — каждый себя считает правильным. А уже программисты и подавно.
И все вроде правильные — а проект (проекты) падают, как в водопад…
VMichael
Тут уж да, область опыта.
У меня не было загубленных проектов, наверное, я делал, что то не так.
Быть может некоторые товарищи лезут в область, в которой им природа не дала таланта, а очень хочется поиметь плюшек.
Опыт работы с таким товарищем у меня есть.
Когда к нам (не софтверная контора) пришел новый ИТ директор (сын хорошего друга одного из ТОПов) и заявил, что мы делаем не так, как положено в бест практиках создания ПО, а мы создали систему автоматизировавшую деятельность всей компании (кроме бухгалтерии и кадров, там царит 1С, туда мы заливали счета).
Зарубил расширение команды, о котором было договорено с гендиром.
Стал внедрять сервис деск.
Создал комитет по приоритезации задач (разработка уже захлебывалась от нехватки ресурсов).
Зарубил задачи направленные на развитие системы.
Стал накапливаться технический долг.
Как итог, я ушел (я был руководителем управления разработки ПО), ушел тех. диром в стартап, потом работал в банке.
Через три месяца после меня ушел ведущий программист (ушел в Озон)
Через полгода после меня ушел мой зам (в Яндекс) и веб программист (открыл собственную студию небольшую).
Т.е. ядро команды разработки было уничтожено, хотя люди были правильные.
Система катилась по инерции (хорошее ядро трудно сразу засадить).
После этого было объявлено, что система уже монстр, которого сопровождать трудно, практически невозможно, и ее нужно менять с помощью подбора новой «платформы», которую доработают под компанию оутсорсеры.
Платформа не нашлась, а аутсорсеры выкатывали ценник, который компании казался заоблачным, почему то.
Еще через пару лет директор по ИТ ушел искать другую работу.
Новый директор по ИТ увеличил штат и продолжают пилить, то, что мы создали, через, вот уже 5 лет после моего ухода из компании.
К чему это я.
А, как пример, когда человек, не умеющий создавать, не умеющий руководить, но с амбициями, связями и подвешенным языком, приходит и разваливает то, что построили до него.
А потом рассуждает о том, как найти правильных людей (не про вас конечно, а ситуация в общем), какая методология лучше, какие бэст практики.
Если я сам могу создавать системы, проектировать и реализовывать, я могу оценить, что делают люди,
я по их работе «чувствую» правильный ли это человек.
А когда человек сам ничего не может, но лезет руководить, будут фейлы, какую бы методику не выбрали.
Idot
… и самое печальное, что такой «золотой мальчик», продолжит свой путь в качестве «опытного руководителя», так как уже имеет руководящий опыт.
VMichael
Да, это увы, жизнь.
nikolayv81
Эта особенность системы может быть уничтожена только сверху, но там часто слишком много поднявшихся таким образом, и они не дают, возможно не от злого умысла.
Всегда в таких случаях вспоминаю фразу сказанную мне много лет назад: "Так было и в Союзе, директора разорившегося завод ставили управлять другим, не в рабочие же ему идти"
MichaelIgitov
Да. Это частая история — мы такие классные, но пришел кто-то и все развалил…
Это фейл руководителя — значит создавали не те системы или не так доносили ценность до ТОПа.
«Умеющий создавать и руководить» определяется по результатам.
VMichael
Я уже 5 лет как ушел из той компании.
А компания до сих пор живет на ПО, которое мы создали.
Ну, вам со стороны, конечно виднее.
Хорошо иметь ясную и непротиворечивую картину мира, без сомнений и колебаний :)
MichaelIgitov
Ну что-ж — хороший предмет для гордости.
Непонятно только Ваши обиды (уж простите — а «человек сам ничего не может, но лезет руководить, будут фейлы, какую бы методику не выбрали.» ничего как на обиду не похоже) на тех, кто дал шанс Вам и вашей команде создать продукт в компании и развиваться дальше вне её.
Тем более если такой результат отличный.
Ну а про картину мира — хороший аккорд знатока и психолога :)
VMichael
Какая уж это обида, это обобщение на основе личного опыта работы и по результатам деятельности таких персонажей.
А фразы типа, это такое лицемерие из книжек, типа Карнеги, или как говорится «сказки для бедных».
Товарищи не давали шанс, товарищам нужен был результат, за который они платили, с весьма жестким контролем. Если бы продукт не пошел, я пошел бы на выход очень быстро. А я там 6 лет проработал.
MichaelIgitov
Про «сказки для бедных» понравилось. Лучше всего на это ответил Джек Ма:
«Самое трудное, это помочь бедным людям.
— Дайте им что-то бесплатно, они подумают, что это ловушка.
— Предложи им идею с минимальным вложением, они скажут что прибыль — маленькая.
— Скажи им инвестировать в большой бизнес, они ответят, что нет денег.
— Скажи им попробовать новые идеи, они скажут, что нет опыта.
— Скажи им заняться традиционным бизнесом, они ответят, что это сложно.
— Расскажи им про новую бизнес-модель, они скажут, что это MLM.
— Посоветуй им открыть магазин, они скажут, что нет никакой свободы.
— Скажи им заняться бизнесом, они ответят, что нет знаний.
Но у них есть что-то общее:
Они любят спрашивать у гугл, слушать друзей, которые являются такими же безнадежными.»
Дискуссию заканчиваю за исчерпанием темы, спасибо за общение.
AlexSerbul
Хорошо как сказано и глубоко, скопировал себе, буду перечитывать :-)
VMichael
Я как бы не настаиваю, вы не дискутируйте дальше, если нет желания.
Про бедных, у меня другое представление (наверное, потому, что я вырос в СССР).
Потому, что они уже попадали в такие ловушки.
Считать они тоже умеют.
И это правда.
И это правда. Пока они будут пробовать новые идеи они могут и с голоду помереть.
Типа традиционный бизнес не требует вложений.
Так и это не исключено.
Странный ответ, вымышленный. Скорее скажут, что нет денег на открытие.
Снова странный ответ. Скорее, см. выше.
Вот она, главная фраза. Остальное так, прикрытие, типа афоризмами. Перефразирую:
Бедные сами виноваты в том, что они бедные, просто они «безнадежные».
О, это отличная холиварная тема.
— Непонятно, правда, при чем тут статья автора.
s-kozlov
Вы прекрасно проиллюстрировали мышление типичного бедняка (уж простите) своими ответами: оно негативное.
Odrin
Мне кажется это не просто ирония, а самоирония. А последний пункт в выводах как раз про компанию «1С-Битрикс».