Коммуникации в программировании — во сне и наяву / Комментарии / Хабр

Delphinum 6 июн 2016 в 20:06

Меньше перегородок и стен между разными проектными командами и функциональными подразделениями

Обожаю слушать обсуждения дизайнеров за час до дедлайна. Это так успокаивает и помогает настроится *сарказм: off*

Antervis 7 июн 2016 в 05:54

«кто в опенспейсе сидел тот в цирке не смеется?»

Delphinum 7 июн 2016 в 18:53

Надеюсь до управленцев таки дойдет, что не всем разработчикам удобно сидеть в окружении пяти десятков таких же разработчиков без какого либо разделения (хотя бы перегородками) и они начнут активнее практиковать работу из дома как опцию.

ServPonomarev 7 июн 2016 в 07:57

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

onehell 7 июн 2016 в 18:49

Не то чтобы квадратично, но как full mesh… Строго говоря, n * (n — 1) / 2 и числа таки да, получаются большими.
Дело вот в чем: так ли уж обязательно общаться по принципу «все со всеми»? Не обязательно. Зависит от процессов внутри проекта, от того, насколько понятна задача и еще много от чего.

mird 7 июн 2016 в 22:12

n*(n-1)/2 = (n^2)/2 — n/2 ~O(n^2) Как это не квадратично?!!!

onehell 8 июн 2016 в 09:09

Вы правы

syslinux 7 июн 2016 в 11:09

Спасибо очень познавательно, а главное на злобу дня.

burjui 15 июл 2016 в 02:09

Сто раз уже описанные принципы, которых всё равно не все и не всегда придерживаются, даже сам знаешь, где, Александр. Сколько Agile не обмазывайся, всё равно решения будут вытекать из личных качеств ответственного за них. Люди постоянно ошибаются, принимают решения сгоряча (времени нет, релиз, блаблабла) и просто тупят. Сдаётся мне, пока разработка ПО не станет наукой и не обрастёт научными теориями, никакая методология не будет гарантировать успех даже в 50% случаев. Лучшая методология — та, что сведёт человеческий фактор к минимуму. Разумеется, нельзя трактовать это (как нынче модно) как превращение разработчика в легко заменяемый винтик в механизме, и слепую "ориентированность на результат", при которой бычно лепится говнокод, а рефакторинг, тесты и т.п. отметаются, т.к. не дают гарантии результата. Не стоит забывать и про ошибку выжившего: ~~медведи сильнее~~ «Слухи об уме и доброте дельфинов основаны на рассказах уставших пловцов, которых они толкали к берегу, но мы лишены возможности услышать рассказ тех, кого они толкали в другую сторону». О фейлах не любят писать, не правда ли?

Немного о комментариях. Пишу их в исключительных случаях, когда кодом сказать не получается. Я считаю, что разработчик должен как можно больше тренироваться в написании кода, а не комментариев, тогда и навык будет расти соответствующий. К тому же, комментарии всегда вторичны. Если ЯП не позволяет лаконично выражать очевидные идеи, его нужно менять на лучший. В идеале разработчик должен иметь в арсенале достаточно выразительный ЯП, чтобы комментарии не понадобились никогда. Кто пишет под JVM или Android: пишите на чём-то более-менее приличном, благо выбор есть (для Android — пока только Kotlin). Писать на голой Java — всё равно, что рисовать пяткой, только со временем легче не станет.

_{P.P.S. Слово "коммуницировать" должно умереть.}