Wiki Category: Дао

Про разработку програм и продуктов

Отлично сказано!

Я тут может очевидное кому-то скажу, а кому-то может неочевидное.

Часто бывают программеры, которые типа “на проекте был бардак – ни четких ТЗ, ни куда гребем непонятно”. Это от непонимания, что никто никогда не знает зачем ПО вообще делают, и куда дорога вывезет. За редкими исключениями.

Давайте от противного. Вот есть, условно, MS Word. Туда никаких фичей, кроме текущих – и не надо. Да и тех что есть – можно выкосить половину. Можно ли сделать точно также? Да, думаю где-то за 100M баксов – вполне. Что копейки по сравнению с продажами. Можно ли достать 100 лямов, переписать Word – и зарабатывать как MS? Неа. Потому что срать будет всем на ваш новый Word. Чтобы стать продуктом, Office-у пришлось прожить с людьми десятилетия, делать фичи типа “радужный 3D-текст Comic Sans-ом с тенью” – потому что тогда это было модно. А потом – поддерживать эти фичи. Учить поколения людей форматировать пробелами. И так, не мытьем, но катаньем, они захватили рынок.

Сложность и сила ПО – не в текущем его наборе фич, а в возможности его постоянно менять. А талант программиста – не в том чтобы по спеке сделать с тестами. Он про то, чтобы предсказать куда дует ветер, и про вычленить те кусочки, которые скорее всего пригодятся – когда надо будет разобрать и собрать всё заново. Или понять что хер угадаешь куда вывезет, и просто писать код быстро, просто и без ошибок. А как поменялось – стирать и переписывать.

Сам код – вообще имеет отрицательную ценность – чем его больше, тем хуже, если ценность продукта постоянна.

Технический долг на проекте

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

Читать дальше

Разрабы работают медленно и дорого — и люди считают нас лентяями. Просто в разработке всё сложно

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

Читать дальше

Никто не умеет управлять программистами — и все придумывают костыли, вместо решений

Есть компании, где процесс разработки реально работает отлично. Я скажу вам почему — они выиграли в лотерею. У них оказалось намного больше людей, которые хотят работать — с такими, как не управляй, все будет идти хорошо. Даже манагерскую мишуру с бордами они используют для дела, а их перформанс и по джировым, и по интуитивным метрикам ясно виден. И когда их менеджеры-не-разрабы приходят мешать им, у них за спиной стоит шикарный продукт, который даёт им право посылать эти говорящие головы к черту.

Но такая команда — фантастическая удача. А обычно происходит вот что. На десять человек у тебя два, которые хотят работать. Один из них тимлид, а второй увольняется.

Читать дальше

Хорошие программисты пишут код, лучшие — тикеты

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

Читать дальше

Как закаляется сталь

И, вот, ты остался один. Тебе не с кем посоветоваться по проблемам, которые тебе волнуют. Нет, конечно, ты можешь о чём-то поговорить с другими одиночками, они даже попробуют тебе чем-то помочь, но по факту – ты один на один с твоей областью проблем.

Читать дальше

20 вещей, которые я вынес за 20 лет в программировании

– Не боритесь с инструментами — библиотеками, языками, платформами — чем бы то ни было. Старайтесь использовать присущие им конструкции
– Вы пишите код не для машин.
– Технический долг как фастфуд: допустим в умеренных количествах, но если войдёт в привычку, не успеете оглянуться, как он убьёт продукт, и это будет больно.
– Хороший код не требует документации, но отличный код задокументирован по определению.
– Никогда не начинайте кодить (разрабатывать какое-то решение), полностью не вникнув в суть задачи.

Читать дальше

Программирование — не тяжелый физический труд, но все равно отстой

Вы полностью компетентны, и все хорошо, и вдруг все ломается.

«Шо за нах?» — восклицаете вы и начинаете отлавливать проблему. Выясняется, что однажды один идиот решил, что раз другой идиот решил, что 1/0 равно бесконечности, он может использовать это как условное обозначение для «бесконечности» для упрощения своего кода. Затем не-идиот справедливо решил, что это идиотизм, то, что должен был решить первый идиот, но поскольку он этого не сделал, не-идиот решил стать козлом и сделать это ошибкой компиляции. Затем он решил никому не говорить, что это ошибка, потому что он козел, и теперь все ваши снежинки — моча, а вы даже не можете найти кошку.

Читать дальше

Тимлид – это сержант

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

Читать дальше

Немного рефлексии на тему неспособности работать в больших компаниях

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

Читать дальше

samdark: Про проектирование и архитектуру

markdown проще рендерить единообразно, удобней хранить и делать diff.
Хороший монолит не хуже микросервисов. Плохие микросервисы с нечёткими границами гораздо хуже монолита.
Кешируйте только когда оптимизации перестали помогать.
Большинство на первый взгляд странных решений в доставшемся вам legacy-проекте там не просто так.

Читать дальше