デスマーチの仕組み

"If painful programming were the most cost-effective way to produce working software, programmers would be morally obliged to suffer stoically or to find other jobs."
"Fortunately, you do not have to choose between pleasure and productivity. The programming techniques that make code a joy to write overlap with those that most efficiently produce software."
 - SANDI METZ

どっかの誰かに聞かせてやりたい　ITドカタが正義な国だと無理か....
本気で overlap with じゃなくてconflict with とか most efficiently じゃなくて the matter of preference とか思ってそう... そういう場所がうじゃうじゃあるので、精神を病む人が多い業界になってしまっている　業界を挙げてそもそも誇れないのに、業界のしがらみもクソもない。個人的に「職業プログラマー」という言葉は恥ずかしい単語だと考える「割り切り」みたいだ

エンジニアの職場環境や理念として、「楽しく」「生き生きと」「新しいものを積極的に取り入れ」「可能な限り楽をしようとする」という大原則から大幅に外れることがあってはならない。「新しい言語は覚えたくないけど大変なことをするのは得意です」って人をあまりにも多く見てきた。そんなエコシステムが生み出す幸福などありえない。デスマーチの根本原因だ。気づいてない。昔「私はphpに明るくない」なんてことを言われたりもしたが、phpなんて覚えるのに2、3時間もかからない。その2, 3時間を惜しむ意味がわからない。だから仕事量が増えている。Java をJavaでリプレイスする意味もわからない。明らかに金をドブに捨てている。一つの言語を覚える時間の方が、無駄な仕事をたくさん量産してデスマーチに突っ込んで、毎日意味もなく１０時まで居残って仕事をするよりも結果的に、等比級数的に、時間も工数もcost-effectiveである。

例えば僕の知ってるある現場では、こんなコードが山ほど横に並列に並んでいる:

class Model1 {
  @annotation1
  @annotation2
  /*
    * 顧客ナンバー
    */
  public String empNo() ;

  @annotation1
  @annotation2 
  @annotation3
 /*
   * 日付更新追加区分
  */
  public String dtUpdWCtgr();


  @annotation1
  @annotation2 
  @annotation3(size = 3)
  /*
    * 日付フラグ二次長
   */　
  public String dtFlgNxtLen();

 ....

 /*
   * 顧客ナンバーをセットする
   */
  public void setEmpNo(String empNo){
     this.empNo = empNo;
  }

 / *
   *　顧客ナンバーを取得する
   */
  public String getEmpNo(){
      return this.empNo;
  }


  /*
    * 日付更新追加区分をセットする
    */
  public void setDtUpdWCtgr(String dtUpdWCtgr){
     this.dtUpdWCtgr = dtUpdWCtgr;
  }

 / *
   * 日付更新追加区分を取得する
   */
  public String getDtUpdWCtgr(){
      return this.dtUpdWCtgr;
  }



 / *
   *日付フラグ二次長をセットする
   */   public void setDtFlgNxtLen(String dtFlgNxtLen){
     this.dtFlgNxtLen = dtFlgNxtLen;
  }

 / *
   * 日付フラグ二次長を取得する
   */  public String getDtFlgNxtLen(){
      return this.dtFlgNxtLen;
  }

 .....

}

こんなクラスを何十と横に並べた上、（しかも同じデータや定義は再利用はせず、それぞれ全部書く（分散記述）、ため同じコードやコメントが何十ファイルにまたがって複製してかかれている）これはインプット部門で、さらにアウトプット部門もあり、かつ、入れ子になっているものは入れ子用のクラスを作ることで対応、依存関係が強すぎて誰かが何かを変更したら一回ずつ他のメンバーもそれに合わせて一つ一つ変更する

だから例えば誰かのつるのひとこで日付フラグ二次長　じゃなくて　日付フラグ二次って名前に変えてー　と言われたら関連するとこを全部洗い出して一個一個手で変えていかないといけない。そんなのが半永久的に降ってくる感じ



闇は深い



ちなみに私ならこうやる


ファイル名 : model1.dsl
==========================================================
employeeNumber             | S  |   顧客ナンバー             |  @annotation {1,2,3} | @action {}
categoryOfUpdatedDate   |  I  |  日付更新追加区分    |   @annotation {4,5  } |  @action {x}
dateFlagSecondaryLength | I | 日付フラグ二次長    |   @annotation {1,2,3}| @action {}
...


ファイル名: ReadData.java
==========================================================
class <T> ReadData {
    public  T get(String key, Integer index,  List<T> options){
        List<String> values = ReadDsl.getDSL(FILE_PATH).getValues(key);
        return assignValueWithType(values.get(index), values.get(1));
    }

    public void set(String key, Integer index, List<T> options){
        // set  
    }

    public Tuple getAll(Integer index){
        Tuple t = new Tuple(); 
        ReadDsl.getDSL(FILE_PATH).getAllValues(index){ (value, type) =>
             t.add(assignValueWithType(value, type));
        };
        return t;
    }

   public void setAll(Integer index){
        // set all
   }

    public assignValueWithType(String value, String type){
        switch (type){
           case "S":
               return value.toString();
           case "I":
               return value.toInteger();
            default:
               throw Exception();
        }
    }

}



ファイル名: ReadDsl.java
==========================================================
class ReadDsl{
    public static Map<String, List<String>> getDSL {
         // parse model1.dsl into multi-dimentional array
         // convert array into map
         // return map
    } 
}


まあ細かいJavaのルールなんていちいち覚える気ないからそこは雑になってるけど、

さて、どっちが長期的に使いやすいしヒューマンエラーも少ないだろうか？？？？？

機能とデータを分けられてない時点でスタート地点にすら立ってないってこと。

Javaみたいなスカトロ言語でもこれくらいはマシにかけるのに、コードのセンスがない人がプロジェクトを引っ張ること自体意味わからない。

前者をやりきることが「良い仕事」っていう空気だから、できる人からどんどん逃げられていくのではないか？？？？？

コードについてもbetterとか好みとかじゃなくて優劣の差が明確だと思うが....

そういう仕事の仕方だから、長時間に必然的になる。

闇は深い